linux-kernel - Re: [PATCH 3/3] irqchip/mbigen: Use fw_devlink_relax

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cba05a2e-3121-4732-9e2f-73892e8047ab@huawei.com>
Date: Fri, 15 Aug 2025 10:15:33 +0800
From: "wangwensheng (C)" <wangwensheng4@...wei.com>
To: Saravana Kannan <saravanak@...gle.com>, Greg KH
	<gregkh@...uxfoundation.org>
CC: <rafael@...nel.org>, <dakr@...nel.org>, <tglx@...utronix.de>,
	<robh@...nel.org>, <broonie@...nel.org>, <linux-kernel@...r.kernel.org>,
	<chenjun102@...wei.com>
Subject: Re: [PATCH 3/3] irqchip/mbigen: Use fw_devlink_relax_consumers()
 helper



在 2025/8/15 2:05, Saravana Kannan 写道:
> On Thu, Aug 14, 2025 at 4:39 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>>
>> On Thu, Aug 14, 2025 at 07:10:23PM +0800, Wang Wensheng wrote:
>>> Use this to prevernt the consumer devices of mbigen to be probed too
>>> later.
>>>
>>> Signed-off-by: Wang Wensheng <wangwensheng4@...wei.com>
>>> ---
>>>   drivers/irqchip/irq-mbigen.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
>>> index 6f69f4e5dbac..4e96eb9b6a6a 100644
>>> --- a/drivers/irqchip/irq-mbigen.c
>>> +++ b/drivers/irqchip/irq-mbigen.c
>>> @@ -252,6 +252,8 @@ static int mbigen_of_create_domain(struct platform_device *pdev,
>>>
>>>                if (!mbigen_create_device_domain(&child->dev, num_pins, mgn_chip))
>>>                        return -ENOMEM;
>>> +
>>> +             fw_devlink_relax_consumers(&child->dev);
>>
>> Ick, no, individual drivers should not be doing this.  Saravana, any
>> ideas?
> 
> Yeah, I responded to patch 2/3.
> 
> To give a more specific answer, this driver is just adding platform
> devices to the platform bus that it never probes. They should create a
> class for these and add these devices to their own class. fw_devlink
> is smart enough about not waiting on class devices to probe. If for
> whatever reason, switching it to a class is impossible, then they
> should write a stub driver to probe these devices.
> 
> -Saravana

Thanks for your suggestion. I will try this way later.