> @@ -146,6 +146,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
>
> cpu = of_get_cpu_node(policy->cpu, NULL);
>
> + of_node_put(cpu);
> if (!cpu)
> goto out;
Can the statement “return -ENODEV” be nicer as exception handling
in the if branch of
> @@ -131,7 +131,7 @@ static int drc_index_to_cpu(u32 drc_index)
>
> of_read_drc_info_cell(&info, &value, &drc);
> if (strncmp(drc.drc_type, "CPU", 3))
> - goto err;
> + goto err_of_node_put;
>
>
> @@ -71,6 +71,7 @@ int fsl_asoc_get_dma_channel(struct device_node *ssi_np,
> iprop = of_get_property(dma_np, "cell-index", NULL);
> if (!iprop) {
> of_node_put(dma_np);
> + of_node_put(dma_channel_np);
> return -EINVAL;
> }
> *dma_i
> @@ -221,8 +221,10 @@ int mpc837x_usb_cfg(void)
> int ret = 0;
>
> np = of_find_compatible_node(NULL, NULL, "fsl-usb2-dr");
> - if (!np || !of_device_is_available(np))
> + if (!np || !of_device_is_available(np)) {
> + of_node_put(np);
> return -ENODEV;
> Remove duplicate memory allocation failure error messages.
A single message can be omitted here.
https://lkml.org/lkml/2017/10/17/870
https://lore.kernel.org/patchwork/patch/842101/
https://lore.kernel.org/linuxppc-dev/e16c8b7d-de3a-6c96-9af4-dd0551cca...@users.sourceforge.net/
Will this detail
> Here needs a NULL check.
I find this change description questionable
(despite of a reasonable patch subject).
> Issue found by coccinelle.
Would an information like “Generated by: scripts/coccinelle/null/kmerr.cocci”
be nicer?
> ---
Will a patch change log be helpful here?
Regards,
Markus
> NULL check before kfree is unnecessary, so remove it.
Would you like to take similar update suggestions into account?
* 2019-09-04
KVM: PPC: Book3S HV: Delete an unnecessary check before kfree() in
__kvmhv_nested_page_fault()
* [-next] KVM: PPC: Book3S HV: remove redundant NULL check
https
Here needs a NULL check.
>> quite obvious?
I suggest to consider another fine-tuning for the wording also around
such “obvious” programming items.
>>> I find this change description questionable
>>> (despite of a reasonable patch subject).
I got further development concerns.
https://git.ke
>>> Here needs a NULL check as kzalloc may fail returning NULL.
I find this wording potentially confusing.
* Such function calls will usually succeed to return a pointer.
* The desired memory allocation can fail.
* Please choose an imperative wording for the change description.
>>> Issue was
> And we can remove the redundant assignments to attr and name.
How do you think about a wording like the following?
Two local variables will eventually be set to appropriate pointers
a bit later. Thus omit their explicit initialisation at the beginning.
Regards,
Markus
> Here needs a NULL check, as kzalloc may fail returning NULL.
>
> Issue was found by coccinelle.
* Do you really try to ignore (my) specific patch review comments
(for a moment)?
https://lore.kernel.org/linuxppc-dev/b7d64d4a-74dd-ee21-db7b-018070f12...@web.de/
https://lore.kernel.org/patch
> We don't need to go to the labal of out …
Please avoid a typo for this change description.
> fails, as there is nothing to do. Just return.
I suggest to reconsider also this wording.
Return directly after a call of the function “of_property_read_u64_array”
failed at the beginning.
> An
From: Markus Elfring
Date: Sun, 3 Nov 2019 13:23:13 +0100
The field “owner” is set by the core.
Thus delete an unneeded initialisation.
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/papr_scm.c | 1 -
1 file
Hello,
I have taken another look at the implementation of the function “fsl_udc_probe”.
A software analysis approach points the following source code out for
further development considerations.
https://elixir.bootlin.com/linux/v5.6.2/source/drivers/usb/gadget/udc/fsl_udc_core.c#L2443
https://git.k
>> Would you like to reconsider the shown condition check?
>
> Thanks for the finding. This is truly a software issue that need to
> be fixed.
I was unsure if I noticed another programming mistake.
> Would you submit a patch for it
Do other contributors know the affected software module better
> If the function "platform_get_irq()" failed, the negative value
> returned will not be detected here, including "-EPROBE_DEFER",
I suggest to adjust this change description.
Wording alternative:
The negative return value (which could eventually be “-EPROBE_DEFER”)
will not be detected here
> Hardware experiments show that the negative return value is not just
> "-EPROBE_DEFER".
How much will this specific error code influence our understanding
of the discussed software situation?
>>> + ret = udc_controller->irq ? : -ENODEV;
>> Will it be clearer to specify values for all c
> Changes to v3:
> - Collected more architectual Acks and Reviewed-by
* I suggest to avoid a typo in this description.
* Please separate the tag “PATCH” from the version descriptor in the subject.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/sub
> The patch 955ac624058f: "ASoC: fsl_easrc: Add EASRC ASoC CPU DAI
> drivers" from Apr 16, 2020, leads to the following Smatch complaint:
>
> sound/soc/fsl/fsl_easrc.c:1529 fsl_easrc_hw_free()
> warn: variable dereferenced before check 'ctx' (see line 1527)
Please avoid a typo in the final commit
> Hence, serialize hvc_open and check if tty->private_data is NULL before
> proceeding ahead.
How do you think about to add the tag “Fixes” because of adjustments
for the data synchronisation?
…
> +++ b/drivers/tty/hvc/hvc_console.c
…
@@ -384,6 +394,8 @@ static int hvc_open(struct tty_struct *tt
> Remove duplicate memory allocation failure error messages.
Will another background information be relevant for the final commit message?
ps3: Delete an error message for a failed memory allocation in two functions
https://lore.kernel.org/linuxppc-dev/58807b28-b2b9-7e77-11b8-21db43c9d...@users.s
> Remove an extra message for a memory allocation failure in
> function gelic_descr_prepare_rx().
Will another background information be relevant for the final commit message?
ps3_gelic_net: Delete an error message for a failed memory allocation in
gelic_descr_prepare_rx()
https://lore.kernel.or
> Typical usage in the backend source file would be:
Is there any information missing in this change description accidentally?
Regards,
Markus
From: Markus Elfring
Date: Tue, 2 Jul 2019 14:41:42 +0200
A bit of information should be put into a sequence.
Thus improve the execution speed for this data output by better usage
of corresponding functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus
> The np variable is still being used after the of_node_put() call,
> which may result in use-after-free.
> We fix this issue by calling of_node_put() after the last usage.
I imagine that this commit description can be improved a bit more
(by mentioning the influence of “immr_node”?).
How do yo
> @@ -204,6 +205,7 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy
> *policy)
> out_unmap_sdcasr:
> iounmap(sdcasr_mapbase);
> out:
> + of_node_put(cpu);
I would find the usage of a jump label like “put_node” nicer at such
a source code place.
Regards,
Markus
> According to Markus's suggestion, split it into two small patches:
> https://lkml.org/lkml/2019/7/8/520
Thanks that you picked adjustment possibilities up from my feedback.
https://lore.kernel.org/lkml/99840e11-e0e6-b3f4-e35b-56ef4ec39...@web.de/
Now I wonder why you omitted message recipient
> The immr_node variable is still being used after the of_node_put() call,
> which may result in use-after-free.
Was any known source code analysis tool involved to point such
a questionable implementation detail out for further software
development considerations?
Regards,
Markus
> we developed a coccinelle script to detect such problems.
How do you think about to give any attribution to this development software
in your commit descriptions?
> After a period of testing, we will send it to the LMKL mailing list later.
I am also curious then on how this area will evolve f
> we developed a coccinelle script to detect such problems.
Would you find the implementation of the function “dt_init_idle_driver”
suspicious according to discussed source code search patterns?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/cpuidle/dt_idle_states.
> 180 break; ---> Jump out of
> the loop without releasing it
The device node reference is released behind this for loop.
> 183 if (!of_device_is_available(state_node)) {
> 184 of_node_put(state_node);
Thi
> In my experience, when you start looking at these of_node_put things,
> all sorts of strange things appear...
How much will this situation influence the achievement of further improvements
also for your software?
Regards,
Markus
From: Markus Elfring
Date: Tue, 27 Aug 2019 08:44:20 +0200
A null pointer would be passed to a call of the function “of_node_put”
immediately after a call of the function “of_find_compatible_node” failed
at one place.
Remove this superfluous function call.
This issue was detected by using the
From: Markus Elfring
Date: Tue, 27 Aug 2019 10:16:32 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an unnecessary of_node_put() call
Use common error handling code
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 13
From: Markus Elfring
Date: Tue, 27 Aug 2019 09:19:32 +0200
Adjust jump targets so that a bit of exception handling can be better
reused at the end of this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/82xx/pq2ads
From: Markus Elfring
Date: Tue, 27 Aug 2019 14:33:21 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an unnecessary kfree() call
Delete an error message for a failed string duplication
arch/powerpc/platforms/pseries/dlpar.c
From: Markus Elfring
Date: Tue, 27 Aug 2019 13:34:02 +0200
A null pointer would be passed to a call of the function “kfree”
immediately after a call of the function “kstrdup” failed at one place.
Remove this superfluous function call.
This issue was detected by using the Coccinelle software
From: Markus Elfring
Date: Tue, 27 Aug 2019 13:37:56 +0200
Omit an extra message for a memory allocation failure in this function.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/dlpar.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc
From: Markus Elfring
Date: Wed, 4 Sep 2019 11:00:20 +0200
The kfree() function tests whether its argument is NULL
and then returns immediately.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
arch
> A workaround for the issue where …
Would you like to avoid a typo in the subject for the final commit message?
Will a cover letter become helpful also for the presented small patch series?
Regards,
Markus
> Add support to pass …
Why did you omit a cover letter for the discussed patch series once more?
Do you care for consequences according to message threading?
Regards,
Markus
> Cover letter just annoise people here.
How do you think about advices from another information source?
See also:
https://kernelnewbies.org/PatchSeries
Regards,
Markus
From: Markus Elfring
Date: Sat, 23 Dec 2023 20:02:02 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
One function call less in vas_window_alloc() after error detection
Return directly after a failed kasprintf() in map_paste_region
From: Markus Elfring
Date: Sat, 23 Dec 2023 19:35:13 +0100
The kfree() function was called in one case by the
vas_window_alloc() function during error handling
even if the passed variable contained a null pointer.
This issue was detected by using the Coccinelle software.
Thus use another label
From: Markus Elfring
Date: Sat, 23 Dec 2023 19:48:09 +0100
Return directly after a call of the function “kasprintf” failed
at the beginning.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/powernv/vas-window.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch
> Date: Tue, 21 Mar 2023 11:26:32 +0100
>
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
> Do not pass an error pointer to of_node_put()
> Fix exception handling
>
> arch/powerpc/pla
> Date: Sat, 25 Mar 2023 16:10:23 +0100
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (4):
> Fix exception handling in ppc4xx_pciex_port_setup_hose()
> Fix exception handling in ppc4xx_probe_pcix_bridge()
&g
> If there are no plans to enable this part code in the future,
Will the word combination “code part” become preferred for
a subsequent change description?
> we can remove this dead code.
And omit another blank line accordingly?
Regards,
Markus
: a2d2e1ec07a80946cbe812dc8c73291cad8214b2 ("[POWERPC] 4xx: PLB to PCI
Express support")
Fixes: 80daac3f86d4f5aafc9d3e79addb90fa118244e2 ("[POWERPC] 4xx: Add endpoint
support to 4xx PCIe driver")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 19 +++
Date: Thu, 16 Mar 2023 20:15:43 +0100
Some update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Fix exception handling in ppc4xx_pciex_port_setup_hose()
Fix exception handling in ppc4xx_probe_pcix_bridge()
Fix exception handling in
detected by using the Coccinelle software.
Fixes: 5738ec6d00b7abbcd4cd342af83fd18d192b0979 ("[POWERPC] 4xx: PLB to PCI-X
support")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --
detected by using the Coccinelle software.
Fixes: c839e0eff500af03de65e560c2e21c3831586e6e ("[POWERPC] 4xx: PLB to PCI 2.x
support")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --
Date: Thu, 16 Mar 2023 19:56:21 +0100
Some local variables will be set to an appropriate value before usage.
Thus omit explicit initialisations at the beginning of these functions.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 14 +++---
1 file changed, 7
.
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac ("Linux-2.6.12-rc2")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/pseries/reconfig.c | 26 ---
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/reconfig.c
b/ar
>> The label “out_err” was used to jump to another pointer check despite of
>> the detail in the implementation of the function “pSeries_reconfig_add_node”
>> that it was determined already that the corresponding variable contained
>> a null pointer (because of a failed function call in two cases).
The label “out_err” was used to jump to another pointer check despite of
the detail in the implementation of the function
“pSeries_reconfig_add_node”
that it was determined already that the corresponding variable contained
a null pointer (because of a failed function call
> It's been brought to my attention that there is in fact a crash bug
> in this function's error path:
How do you think about to mention any other contributors for attribution
according to this issue?
> np->parent can be an encoded error value, we don't want to of_node_put() that.
Will the deve
Date: Tue, 21 Mar 2023 11:26:32 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Do not pass an error pointer to of_node_put()
Fix exception handling
arch/powerpc/platforms/pseries/reconfig.c | 26 ---
1 file
/
Reported-by: Nathan Lynch
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Signed-off-by: Markus Elfring
---
V2:
This update step was added according to another change request.
arch/powerpc/platforms/pseries/reconfig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
.
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Signed-off-by: Markus Elfring
---
V2:
This update step was based on a previous change.
arch/powerpc/platforms/pseries/reconfig.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --
Date: Tue, 21 Mar 2023 11:26:32 +0100
A few update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Do not pass an error pointer to of_node_put()
Fix exception handling
arch/powerpc/platforms/pseries/reconfig.c | 26 ---
1 file
/
Reported-by: Nathan Lynch
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Signed-off-by: Markus Elfring
---
V2:
This update step was added according to another change request.
arch/powerpc/platforms/pseries/reconfig.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletio
.
Fixes: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 ("Linux-2.6.12-rc2")
Signed-off-by: Markus Elfring
---
V2:
This update step was based on a previous change.
arch/powerpc/platforms/pseries/reconfig.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --
Date: Sat, 25 Mar 2023 16:10:23 +0100
Some update suggestions were taken into account
from static source code analysis.
Markus Elfring (4):
Fix exception handling in ppc4xx_pciex_port_setup_hose()
Fix exception handling in ppc4xx_probe_pcix_bridge()
Fix exception handling in
.
Fixes: a2d2e1ec07a80946cbe812dc8c73291cad8214b2 ("[POWERPC] 4xx: PLB to PCI
Express support")
Fixes: 80daac3f86d4f5aafc9d3e79addb90fa118244e2 ("[POWERPC] 4xx: Add endpoint
support to 4xx PCIe driver")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 19 +++
was detected by using the Coccinelle software.
Fixes: 5738ec6d00b7abbcd4cd342af83fd18d192b0979 ("[POWERPC] 4xx: PLB to PCI-X
support")
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --
detected by using the Coccinelle software.
Fixes: c839e0eff500af03de65e560c2e21c3831586e6e ("[POWERPC] 4xx: PLB to PCI 2.x
support")
Signed-off-by: Markus Elfring
---
V3:
A closing parenthesis (which was overlooked somehow) was preserved
for an if statement.
arch/powerpc/platforms
Date: Sat, 25 Mar 2023 16:00:36 +0100
Some local variables will be set to an appropriate value before usage.
Thus omit explicit initialisations at the beginning of these functions.
Signed-off-by: Markus Elfring
---
arch/powerpc/platforms/4xx/pci.c | 14 +++---
1 file changed, 7
> A few update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
I would appreciate a bit more information about the reasons
why this patch series was rejected.
> One function call less in vas_window_alloc() after error d
>>> One function call less in vas_window_alloc() after error detection
>>
>> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/1f1c21cf-c34c-418c-b00c-8e6474f12...@web.de/
>
> It introduced a new goto and label to avoid a kfree(NULL) call, but
> kfree() explicitly accepts NULL and handles i
> This is explicit in Kernel documentation:
>
> /**
> * kfree - free previously allocated memory
> * @object: pointer returned by kmalloc() or kmem_cache_alloc()
> *
> * If @object is NULL, no operation is performed.
> */
>
> That's exactly the same behaviour as free() in libc.
>
> So Coc
So Coccinelle should be fixed if it reports an error for that.
>>>
>>> Redundant function calls can occasionally be avoided accordingly,
>>> can't they?
>>
>> Sure they can, but is that worth it here ?
>
> Coccinelle does what the developer of the semantic patch tells it to do.
> It doesn't sp
> Looking at that function, I however see a missing region release when
> ioremap_cache() fails.
Under which circumstances will the exception handling be completed also for
the implementation of the function “map_paste_region”?
https://elixir.bootlin.com/linux/v6.9-rc4/source/arch/powerpc/platform
From: Markus Elfring
Date: Fri, 19 Apr 2024 15:46:17 +0200
Add a minus sign before the error code “EBUSY”
so that a negative value will be used as in other cases.
This issue was transformed by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/net/ethernet/ibm/ibmvnic.c
> A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "devm_kcalloc".
I find the previous patch subject inappropriate.
Would you like to choose an alternative?
Regards,
Markus
From: Markus Elfring
Date: Thu, 10 Dec 2020 14:14:07 +0100
A local variable was used only within an if branch.
Thus move the definition for the variable “mm” into the corresponding
code block.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers
>> A local variable was used only within an if branch.
>> Thus move the definition for the variable “mm” into the corresponding
>> code block.
>
> You did nothing here except add a checkpatch warning :(
elfring@Sonne:~/Projekte/Linux/next-patched> scripts/checkpatch.pl
/home/elfring/Projekte/Bau/
> Please just remove the message instead, it's a tiny allocation that's
> unlikely to ever fail, and the caller will print an error anyway.
How do you think about to take another look at a previous update suggestion
like the following?
powerpc/nvram: Delete three error messages for a failed memor
>>> Please just remove the message instead, it's a tiny allocation that's
>>> unlikely to ever fail, and the caller will print an error anyway.
>>
>> How do you think about to take another look at a previous update suggestion
>> like the following?
>>
>> powerpc/nvram: Delete three error messages f
> Fix it by adding a call to kobject_put() in the error path of
> kobject_init_and_add().
Thanks for another completion of the exception handling.
Would an other patch subject be a bit nicer?
…
> +++ b/drivers/misc/cxl/sysfs.c
> @@ -624,7 +624,7 @@ static struct afu_config_record
> *cxl_sysfs_
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst?id=f359287765c04711ff54fbd11645271d8e5ff763#n465
>> I just used the original author's label, should I replace all his labels
>> like'err','err1' with reasonable one.
>
> No.
Do you in
> Please note that you are responding to someone that a lot of kernel
> developers and maintainers have blacklisted as being very annoying
I can understand that you can occasionally become annoyed.
> and not helpful at all.
I got the impression that some contributors (including you)
found also
> Okay, so I don’t have to send the v2 patch.
It will become more interesting under which circumstances the presented
software development concerns will be taken better into account.
Regards,
Markus
> Fix unchecked return value for clk_prepare_enable.
>
> And because clk_prepare_enable and clk_disable_unprepare should
> check input clock parameter is NULL or not, then we don't need
> to check it before calling the function.
I propose to split the adjustment of two function implementations
int
> In-Reply-To:
I guess that it should be sufficient to specify such a field once
for the header information.
> Because clk_prepare_enable and clk_disable_unprepare should
> check input clock parameter is NULL or not internally,
I find this change description unclear.
> then we don't need to
> clk_prepare_enable and clk_disable_unprepare check the input
> clock parameter in the beginning of the function,
These functions call further functions which perform null pointer checks.
> if the parameter
> is NULL, clk_prepare
>>> if the parameter
>>> is NULL, clk_prepare_enable and clk_disable_unprepare will
>>> return immediately.
>>
>> The interpretation of these function implementations seems to be reasonable.
>> Would you like to achieve any improvements
…
> +++ b/drivers/pci/endpoint/pci-epc-core.c
…
> +void pci_epc_deinit_notify(struct pci_epc *epc)
> +{
…
> + mutex_lock(&epc->list_lock);
> + list_for_each_entry(epf, &epc->pci_epf, list) {
> + mutex_lock(&epf->lock);
> + if (epf->event_ops && epf->event_ops->epc_de
I suggest to specify email addresses for message recipients not only
in the header field “Cc”.
…
> +++ b/sound/soc/fsl/lpc3xxx-i2s.c
> @@ -0,0 +1,393 @@
…
> +static int lpc3xxx_i2s_startup(struct snd_pcm_substream *substream, struct
> snd_soc_dai *cpu_dai)
> +{
…
> + int ret = 0;
> +
> +
> Adds properties declared in the new DT bindings:
Add?How do you think about to replace such an
abbreviation?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc4#n94
Regards,
Marku
> This allows to share the regmap with other simple-mfd devices like
> nxp,lpc32xx-dmamux
Please choose an imperative wording for an improved change description.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.10-rc4#n94
Re
…
> this driver allows to route a signal request line thru the multiplexer for
> given peripheral.
Would you like to choose an imperative wording for an improved change
description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rs
> With the driver for nxp,lpc3220-dmamux we can remove the pl08x platform
> data and let pl08x driver to create peripheral channels from the DT
> properties.
Do you see opportunities to improve such a change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Docum
…
> Signed-off-by: Ma Ke
Under which circumstances will this information be corrected anyhow?
The usage of mailing list addresses is probably undesirable for
the Developer's Certificate of Origin, isn't it?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/pro
…
> - The potential vulnerability was discovered as follows: based on our
> customized static analysis tool,
I became curious in which time range further corresponding information will be
published.
> extract vulnerability features[1],
Various software correcti
> In read_handle(), of_get_address() may return NULL if getting address and
> size of the node failed. When of_read_number() uses prop to handle
> conversions between different byte orders, it could lead to a null pointer
> dereference. Add NULL check to fix potential issue.
>
> Found by static ana
…
> +++ b/drivers/soc/fsl/qe/tsa.c
…
> +static int tsa_qe_serial_connect(struct tsa_serial *tsa_serial, bool connect)
> +{
…
> + spin_lock_irqsave(&tsa->lock, flags);
> + ret = ucc_set_qe_mux_tsa(ucc_num, connect);
> + spin_unlock_irqrestore(&tsa->lock, flags);
…
Under which circumstan
…
> hold, framer_get_status() is called witch in turn takes a mutex.
…
which?
Regards,
Markus
From: Markus Elfring
Date: Mon, 16 Sep 2024 19:25:00 +0200
Scope-based resource management became supported for some
programming interfaces by contributions of Peter Zijlstra on 2023-05-26.
See also the commit 54da6a0924311c7cf5015533991e44fb8eb12773 ("locking:
Introduce __cleanup()
From: Markus Elfring
Date: Fri, 11 Oct 2024 18:10:06 +0200
Replace an of_get_property() call by of_property_match_string()
so that this function implementation can be simplified.
Suggested-by: Christophe Leroy
Link:
https://lore.kernel.org/linuxppc-dev/d9bdc1b6-ea7e-47aa-80aa-02ae649ab
1 - 100 of 274 matches
Mail list logo