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]
Date:	Sat, 11 Feb 2012 16:46:55 +0100
From:	Clemens Ladisch <clemens@...isch.de>
To:	Chris Boot <bootc@...tc.net>
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

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".


Regards,
Clemens
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ