Re: [PATCH] genirq: Add the entropy pool function to the PPI interrupt handler

["enlin.mu" <enlin.mu@linux.dev>]

On 2026/6/16 15:49, Greg KH wrote:
> On Tue, Jun 16, 2026 at 03:40:10PM +0800, enlin.mu wrote:
>>
>>
>> On 2026/6/16 15:24, Greg KH wrote:
>>> On Tue, Jun 16, 2026 at 03:17:00PM +0800, enlin.mu wrote:
>>>>
>>>>
>>>> On 2026/6/16 14:48, Greg KH wrote:
>>>>> A: http://en.wikipedia.org/wiki/Top_post
>>>>> Q: Were do I find info about this thing called top-posting?
>>>>> A: Because it messes up the order in which people normally read text.
>>>>> Q: Why is top-posting such a bad thing?
>>>>> A: Top-posting.
>>>>> Q: What is the most annoying thing in e-mail?
>>>>>
>>>>> A: No.
>>>>> Q: Should I include quotations after my reply?
>>>>>
>>>>> http://daringfireball.net/2007/07/on_top
>>>>>
>>>>> On Tue, Jun 16, 2026 at 02:26:18PM +0800, enlin.mu wrote:
>>>>>> Hi KH
>>>>>>
>>>>>> hardware: raspberrypi 5
>>>>>>
>>>>>> other patch(These two locations impact the entropy pool acceleration.
>>>>>> comment them out temporarily):
>>>>>> acer@raspberrypi:linux $ git diff drivers/of/fdt.c
>>>>>> drivers/char/hw_random/iproc-rng200.c
>>>>>> diff --git a/drivers/char/hw_random/iproc-rng200.c
>>>>>> b/drivers/char/hw_random/iproc-rng200.c
>>>>>> index 33bc28f429f6..af105faa88c6 100644
>>>>>> --- a/drivers/char/hw_random/iproc-rng200.c
>>>>>> +++ b/drivers/char/hw_random/iproc-rng200.c
>>>>>> @@ -296,10 +296,10 @@ static const struct dev_pm_ops iproc_rng200_pm_ops = {
>>>>>>     };
>>>>>>
>>>>>>     static const struct of_device_id iproc_rng200_of_match[] = {
>>>>>> -       { .compatible = "brcm,bcm2711-rng200", },
>>>>>> -       { .compatible = "brcm,bcm7211-rng200", },
>>>>>> -       { .compatible = "brcm,bcm7278-rng200", },
>>>>>> -       { .compatible = "brcm,iproc-rng200", },
>>>>>> +       { .compatible = "brcm,bcm2711-rng2000", },
>>>>>> +       { .compatible = "brcm,bcm7211-rng2000", },
>>>>>> +       { .compatible = "brcm,bcm7278-rng2000", },
>>>>>> +       { .compatible = "brcm,iproc-rng2000", },
>>>>>
>>>>> What is this change for?
>>>> This driver accelerates the initialization of the entropy pool. If this
>>>> dirver is added, the optimization effect of my patch will no longer be
>>>> clearly observable.
>>>
>>> Great, obviously your patch is not needed!
>>>
>>>>
>>>>>
>>>>>
>>>>>>            {},
>>>>>>     };
>>>>>>     MODULE_DEVICE_TABLE(of, iproc_rng200_of_match);
>>>>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>>>>> index 331646d667b9..13308d58785d 100644
>>>>>> --- a/drivers/of/fdt.c
>>>>>> +++ b/drivers/of/fdt.c
>>>>>> @@ -1100,7 +1100,7 @@ int __init early_init_dt_scan_chosen(char *cmdline)
>>>>>>
>>>>>>            rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
>>>>>>            if (rng_seed && l > 0) {
>>>>>> -               add_bootloader_randomness(rng_seed, l);
>>>>>> +               //add_bootloader_randomness(rng_seed, l);
>>>>>
>>>>> Why did you comment this out?
>>>> Before the kernel boots, the Raspberry Pi bootloader injects the rng-seed
>>>> property into the kernel's Device Tree to accelerate entropy pool
>>>> initialization. Therefore, I need to temporarily comment this out
>>>> to avoid interfering with the testing of my current patch.
>>>
>>> Again, that seems like the correct fix, don't change the common code
>>> path of all systems just because you don't want to accept the changes
>>> that have already been made for your platform to resolve this very
>>> issue!
>>
>> I think there might be a misunderstanding. The code below adds entropy pool
>> initialization, but this logic is missing in the PPI interrupt handler. I
>> believe this was simply an accidental omission.
>> ---------------------------
>> irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
>> {
>> 	irqreturn_t retval;
>>
>> 	retval = __handle_irq_event_percpu(desc);
>>
>> 	add_interrupt_randomness(desc->irq_data.irq);
>>
>> 	if (!irq_settings_no_debug(desc))
>> 		note_interrupt(desc, retval);
>> 	return retval;
> 
> Look back at your original patch.  It contained none of this
> information...

My apologies. I mistakenly assumed the context was obvious, but I 
realize now that it should have been explicitly documented in the 
original patch. I will send a v2 patch immediately with all this 
information added to the commit message.