* clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-12 14:17 ` Markus Elfring @ 2019-10-12 14:17 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-12 14:17 UTC (permalink / raw) To: linux-clk, linux-samsung-soc, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, I tried another script for the semantic patch language out. This source code analysis approach points out that the implementation of the function “_samsung_clk_register_pll” contains also a call of the function “kmemdup”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 * Do you find the usage of the format string “%s: could not allocate rate table for %s\n” still appropriate at this place? * Is there a need to adjust the error handling here? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-12 14:17 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-12 14:17 UTC (permalink / raw) To: linux-clk, linux-samsung-soc, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, I tried another script for the semantic patch language out. This source code analysis approach points out that the implementation of the function “_samsung_clk_register_pll” contains also a call of the function “kmemdup”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 * Do you find the usage of the format string “%s: could not allocate rate table for %s\n” still appropriate at this place? * Is there a need to adjust the error handling here? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-12 14:17 ` Markus Elfring @ 2019-10-15 14:49 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-15 14:49 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hi Markus, 2019年10月12日(土) 23:17 Markus Elfring <Markus.Elfring@web.de>: > > Hello, > > I tried another script for the semantic patch language out. > This source code analysis approach points out that the implementation > of the function “_samsung_clk_register_pll” contains also a call > of the function “kmemdup”. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 > https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 Thanks for the report. > > * Do you find the usage of the format string “%s: could not allocate > rate table for %s\n” still appropriate at this place? Yes, AFAICT there is nothing wrong with that format string. > > * Is there a need to adjust the error handling here? No, there isn't much that can be done if we fail the allocation at such an early stage. That said, there is no need to print any warnings or error messages on allocation failure, so technically they could be removed. It doesn't really give us anything in case of existing code, though, and only makes a potential for merge conflicts, so I'd just leave it alone. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-15 14:49 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-15 14:49 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hi Markus, 2019年10月12日(土) 23:17 Markus Elfring <Markus.Elfring@web.de>: > > Hello, > > I tried another script for the semantic patch language out. > This source code analysis approach points out that the implementation > of the function “_samsung_clk_register_pll” contains also a call > of the function “kmemdup”. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 > https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 Thanks for the report. > > * Do you find the usage of the format string “%s: could not allocate > rate table for %s\n” still appropriate at this place? Yes, AFAICT there is nothing wrong with that format string. > > * Is there a need to adjust the error handling here? No, there isn't much that can be done if we fail the allocation at such an early stage. That said, there is no need to print any warnings or error messages on allocation failure, so technically they could be removed. It doesn't really give us anything in case of existing code, though, and only makes a potential for merge conflicts, so I'd just leave it alone. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-15 14:49 ` Tomasz Figa @ 2019-10-15 17:55 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-15 17:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > That said, there is no need to print any warnings or error messages on > allocation failure, so technically they could be removed. Do you find information sufficient from the Linux allocation failure report? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-15 17:55 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-15 17:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > That said, there is no need to print any warnings or error messages on > allocation failure, so technically they could be removed. Do you find information sufficient from the Linux allocation failure report? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-15 17:55 ` Markus Elfring @ 2019-10-16 11:43 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-16 11:43 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, kernel-janitors, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML 2019年10月16日(水) 2:55 Markus Elfring <Markus.Elfring@web.de>: > > > That said, there is no need to print any warnings or error messages on > > allocation failure, so technically they could be removed. > > Do you find information sufficient from the Linux allocation failure report? A backtrace should be enough for this kind of a failure that shouldn't normally happen and if happens, then the rest of the system must be in a state already about to fail anyway. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-16 11:43 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-16 11:43 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, kernel-janitors, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML 2019年10月16日(水) 2:55 Markus Elfring <Markus.Elfring@web.de>: > > > That said, there is no need to print any warnings or error messages on > > allocation failure, so technically they could be removed. > > Do you find information sufficient from the Linux allocation failure report? A backtrace should be enough for this kind of a failure that shouldn't normally happen and if happens, then the rest of the system must be in a state already about to fail anyway. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-16 11:43 ` Tomasz Figa @ 2019-10-16 11:58 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-16 11:58 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > A backtrace should be enough for this kind of a failure that shouldn't > normally happen and if happens, then the rest of the system must be in > a state already about to fail anyway. Does this feedback mean that you would like to omit two extra error messages from this function implementation? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-16 11:58 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-16 11:58 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > A backtrace should be enough for this kind of a failure that shouldn't > normally happen and if happens, then the rest of the system must be in > a state already about to fail anyway. Does this feedback mean that you would like to omit two extra error messages from this function implementation? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-15 14:49 ` Tomasz Figa @ 2019-10-15 17:55 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-15 17:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > That said, there is no need to print any warnings or error messages on > allocation failure, so technically they could be removed. Do you find information sufficient from the Linux allocation failure report? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-15 17:55 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-15 17:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML > That said, there is no need to print any warnings or error messages on > allocation failure, so technically they could be removed. Do you find information sufficient from the Linux allocation failure report? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-15 14:49 ` Tomasz Figa @ 2019-10-16 10:55 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-16 10:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML >> * Is there a need to adjust the error handling here? > > No, there isn't much that can be done if we fail the allocation at > such an early stage. Can it matter to perform the setting “pll->rate_count” only according to a null pointer check for the variable “pll->rate_table” because of the function call “kmemdup”? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-16 10:55 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-16 10:55 UTC (permalink / raw) To: Tomasz Figa, linux-clk, linux-samsung-soc, kernel-janitors Cc: Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML >> * Is there a need to adjust the error handling here? > > No, there isn't much that can be done if we fail the allocation at > such an early stage. Can it matter to perform the setting “pll->rate_count” only according to a null pointer check for the variable “pll->rate_table” because of the function call “kmemdup”? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-16 10:55 ` Markus Elfring @ 2019-10-16 11:44 ` Tomasz Figa -1 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-16 11:44 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, kernel-janitors, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML 2019年10月16日(水) 19:55 Markus Elfring <Markus.Elfring@web.de>: > > >> * Is there a need to adjust the error handling here? > > > > No, there isn't much that can be done if we fail the allocation at > > such an early stage. > > Can it matter to perform the setting “pll->rate_count” only according > to a null pointer check for the variable “pll->rate_table” > because of the function call “kmemdup”? It would be a good practice indeed, but looking from the code, pll->rate_table is checked elsewhere, not pll->rate_count. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-16 11:44 ` Tomasz Figa 0 siblings, 0 replies; 22+ messages in thread From: Tomasz Figa @ 2019-10-16 11:44 UTC (permalink / raw) To: Markus Elfring Cc: open list:COMMON CLK FRAMEWORK, moderated list:SAMSUNG SOC CLOCK DRIVERS, kernel-janitors, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML 2019年10月16日(水) 19:55 Markus Elfring <Markus.Elfring@web.de>: > > >> * Is there a need to adjust the error handling here? > > > > No, there isn't much that can be done if we fail the allocation at > > such an early stage. > > Can it matter to perform the setting “pll->rate_count” only according > to a null pointer check for the variable “pll->rate_table” > because of the function call “kmemdup”? It would be a good practice indeed, but looking from the code, pll->rate_table is checked elsewhere, not pll->rate_count. Best regards, Tomasz ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <CGME20191012141739epcas3p31e41c151b30d49c94aeb933aa42dc9f7@epcas3p3.samsung.com>]
* clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-12 14:17 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-12 14:17 UTC (permalink / raw) To: linux-clk, linux-samsung-soc, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, I tried another script for the semantic patch language out. This source code analysis approach points out that the implementation of the function “_samsung_clk_register_pll” contains also a call of the function “kmemdup”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 * Do you find the usage of the format string “%s: could not allocate rate table for %s\n” still appropriate at this place? * Is there a need to adjust the error handling here? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-12 14:17 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-12 14:17 UTC (permalink / raw) To: linux-clk, linux-samsung-soc, Chanwoo Choi, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, I tried another script for the semantic patch language out. This source code analysis approach points out that the implementation of the function “_samsung_clk_register_pll” contains also a call of the function “kmemdup”. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 * Do you find the usage of the format string “%s: could not allocate rate table for %s\n” still appropriate at this place? * Is there a need to adjust the error handling here? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-12 14:17 ` Markus Elfring @ 2019-10-14 6:55 ` Chanwoo Choi -1 siblings, 0 replies; 22+ messages in thread From: Chanwoo Choi @ 2019-10-14 6:55 UTC (permalink / raw) To: Markus Elfring, linux-clk, linux-samsung-soc, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, On 19. 10. 12. 오후 11:17, Markus Elfring wrote: > Hello, > > I tried another script for the semantic patch language out. > This source code analysis approach points out that the implementation > of the function “_samsung_clk_register_pll” contains also a call > of the function “kmemdup”. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 > https://protect2.fireeye.com/url?k=7e77b0ebee9a0c3e.7e763ba4-43f341fdfe1d32b1&u=https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 > > * Do you find the usage of the format string “%s: could not allocate > rate table for %s\n” still appropriate at this place? > > * Is there a need to adjust the error handling here? drivers/clk/samsung/clk-pll.c considers the case of 'pll->rate_table is NULL' So, maybe just show the warning message if failed to allocate memory of 'pll->rate_table'. Bu, IMHO, the error handling is necessary in order to support what 'pll_clk->rate_table' isn't NULL. > > Regards, > Markus > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-14 6:55 ` Chanwoo Choi 0 siblings, 0 replies; 22+ messages in thread From: Chanwoo Choi @ 2019-10-14 6:55 UTC (permalink / raw) To: Markus Elfring, linux-clk, linux-samsung-soc, Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa Cc: LKML, kernel-janitors, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant Hello, On 19. 10. 12. 오후 11:17, Markus Elfring wrote: > Hello, > > I tried another script for the semantic patch language out. > This source code analysis approach points out that the implementation > of the function “_samsung_clk_register_pll” contains also a call > of the function “kmemdup”. > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id\x1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 > https://protect2.fireeye.com/url?k~77b0ebee9a0c3e.7e763ba4-43f341fdfe1d32b1&u=https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 > > * Do you find the usage of the format string “%s: could not allocate > rate table for %s\n” still appropriate at this place? > > * Is there a need to adjust the error handling here? drivers/clk/samsung/clk-pll.c considers the case of 'pll->rate_table is NULL' So, maybe just show the warning message if failed to allocate memory of 'pll->rate_table'. Bu, IMHO, the error handling is necessary in order to support what 'pll_clk->rate_table' isn't NULL. > > Regards, > Markus > > -- Best Regards, Chanwoo Choi Samsung Electronics ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() 2019-10-14 6:55 ` Chanwoo Choi @ 2019-10-14 8:05 ` Markus Elfring -1 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-14 8:05 UTC (permalink / raw) To: Chanwoo Choi, linux-clk, linux-samsung-soc, kernel-janitors Cc: Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 >> https://protect2.fireeye.com/url?k=7e77b0ebee9a0c3e.7e763ba4-43f341fdfe1d32b1&u=https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 … > drivers/clk/samsung/clk-pll.c considers the case of 'pll->rate_table is NULL' > So, maybe just show the warning message if failed to allocate memory > of 'pll->rate_table'. How do you think about to recheck information sources around the Linux allocation failure report? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=da94001239cceb93c132a31928d6ddc4214862d5#n878 > Bu, IMHO, the error handling is necessary in order to support > what 'pll_clk->rate_table' isn't NULL. Can an other error handling strategy make sense at this place? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() @ 2019-10-14 8:05 ` Markus Elfring 0 siblings, 0 replies; 22+ messages in thread From: Markus Elfring @ 2019-10-14 8:05 UTC (permalink / raw) To: Chanwoo Choi, linux-clk, linux-samsung-soc, kernel-janitors Cc: Michael Turquette, Stephen Boyd, Sylwester Nawrocki, Tomasz Figa, Aditya Pakki, Kangjie Lu, Navid Emamdoost, Stephen McCamant, LKML >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/samsung/clk-pll.c?id=1c0cc5f1ae5ee5a6913704c0d75a6e99604ee30a#n1275 >> https://protect2.fireeye.com/url?k=7e77b0ebee9a0c3e.7e763ba4-43f341fdfe1d32b1&u=https://elixir.bootlin.com/linux/v5.4-rc2/source/drivers/clk/samsung/clk-pll.c#L1275 … > drivers/clk/samsung/clk-pll.c considers the case of 'pll->rate_table is NULL' > So, maybe just show the warning message if failed to allocate memory > of 'pll->rate_table'. How do you think about to recheck information sources around the Linux allocation failure report? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=da94001239cceb93c132a31928d6ddc4214862d5#n878 > Bu, IMHO, the error handling is necessary in order to support > what 'pll_clk->rate_table' isn't NULL. Can an other error handling strategy make sense at this place? Regards, Markus ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2019-10-16 11:58 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-12 14:17 clk: samsung: Checking a kmemdup() call in _samsung_clk_register_pll() Markus Elfring 2019-10-12 14:17 ` Markus Elfring 2019-10-15 14:49 ` Tomasz Figa 2019-10-15 14:49 ` Tomasz Figa 2019-10-15 17:55 ` Markus Elfring 2019-10-15 17:55 ` Markus Elfring 2019-10-16 11:43 ` Tomasz Figa 2019-10-16 11:43 ` Tomasz Figa 2019-10-16 11:58 ` Markus Elfring 2019-10-16 11:58 ` Markus Elfring 2019-10-15 17:55 ` Markus Elfring 2019-10-15 17:55 ` Markus Elfring 2019-10-16 10:55 ` Markus Elfring 2019-10-16 10:55 ` Markus Elfring 2019-10-16 11:44 ` Tomasz Figa 2019-10-16 11:44 ` Tomasz Figa [not found] <CGME20191012141739epcas3p31e41c151b30d49c94aeb933aa42dc9f7@epcas3p3.samsung.com> 2019-10-12 14:17 ` Markus Elfring 2019-10-12 14:17 ` Markus Elfring 2019-10-14 6:55 ` Chanwoo Choi 2019-10-14 6:55 ` Chanwoo Choi 2019-10-14 8:05 ` Markus Elfring 2019-10-14 8:05 ` Markus Elfring
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.