netdev - Re: [PATCH 4/x] sunhme: switch to devres

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <7e286518-2f01-6042-4d23-94d8846774db@gmail.com>
Date:   Thu, 28 Jul 2022 20:33:01 -0400
From:   Sean Anderson <seanga2@...il.com>
To:     Rolf Eike Beer <eike-kernel@...tec.de>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 4/x] sunhme: switch to devres

On 7/28/22 3:52 PM, Rolf Eike Beer wrote:
> Am 2022-07-27 05:58, schrieb Sean Anderson:
>> On 7/26/22 11:49 PM, Sean Anderson wrote:
> 
>>> This looks good, but doesn't apply cleanly. I rebased it as follows:
> 
> Looks like what my local rebase has also produced.
> 
> The sentence about the leak from the commitmessage can be dropped then,
> as this leak has already been fixed.
> 
>>> diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c
>>> index eebe8c5f480c..e83774ffaa7a 100644
>>> --- a/drivers/net/ethernet/sun/sunhme.c
>>> +++ b/drivers/net/ethernet/sun/sunhme.c
>>> @@ -2990,21 +2990,23 @@ static int happy_meal_pci_probe(struct pci_dev *pdev,
>>>           qp->happy_meals[qfe_slot] = dev;
>>>       }
>>>
>>> -    hpreg_res = pci_resource_start(pdev, 0);
>>> -    err = -ENODEV;
>>>       if ((pci_resource_flags(pdev, 0) & IORESOURCE_IO) != 0) {
>>>           printk(KERN_ERR "happymeal(PCI): Cannot find proper PCI device base address.\n");
>>>           goto err_out_clear_quattro;
>>>       }
>>> -    if (pci_request_regions(pdev, DRV_NAME)) {
>>> +
>>> +    if (!devm_request_region(&pdev->dev, pci_resource_start(pdev, 0),
>>> +                  pci_resource_len(pdev, 0),
>>> +                  DRV_NAME)) {
>>
>> Actually, it looks like you are failing to set err from these *m
>> calls, like what
>> you fixed in patch 3. Can you address this for v2?
> 
> It returns NULL on error, there is no error code I can set.

So it does. A quick grep shows that most drivers return -EBUSY.

--Sean