linux-kernel - Re: [PATCH 2/3] firewire-sbp2: Ignore SBP-2 targets on the local node

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: <4F368E22.30500@bootc.net>
Date:	Sat, 11 Feb 2012 15:49:54 +0000
From:	Chris Boot <bootc@...tc.net>
To:	Clemens Ladisch <clemens@...isch.de>
CC:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Greg KH <gregkh@...uxfoundation.org>,
	linux1394-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] firewire-sbp2: Ignore SBP-2 targets on the local
 node

On 11/02/2012 15:46, Clemens Ladisch wrote:
> Chris Boot wrote:
>> On 11/02/2012 12:16, Clemens Ladisch wrote:
>>> Stefan Richter wrote:
>>>> On Feb 10 Chris Boot wrote:
>>>>> +    /* ignore targets on the local node */
>>>>> +    if (device->node == device->card->local_node) {
>>>>> +        dev_set_drvdata(&unit->device, NULL);
>>>>> +        return 0;
>>>>> +    }
>>>>
>>>> But I do wonder:  Shouldn't this be implemented by returning from the
>>>> driver probe method with an error? If so, which errno should be returned?
>>>
>>> -ENODEV or -ENXIO.
>>
>> Perhaps,
>
> It's what really_probe() in drivers/base/dd.c requires:
>
> 	if (ret != -ENODEV&&  ret != -ENXIO) {
> 		/* driver matched but the probe failed */
> 		printk(KERN_WARNING
> 		       "%s: probe of %s failed with error %d\n",
> 		       drv->name, dev_name(dev), ret);
> 	} else {
> 		pr_debug("%s: probe of %s rejects match %d\n",
> 		       drv->name, dev_name(dev), ret);
> 	}
>
>> but the meaning of those isn't quite what is happening here. We aren't
>> saying the device doesn't exist or is inaccessible, just that we don't
>> want to talk to it...
>
> ENODEV does not mean "no device" but "no _such_ device".

Sounds fair. I'll update my patch.

Cheers,
Chris

-- 
Chris Boot
bootc@...tc.net
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/