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:   Tue, 19 Feb 2019 13:24:51 +0000
From:   Måns Rullgård <mans@...sr.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: core: skip interfaces disabled in devicetree

Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:

> On Sat, Feb 16, 2019 at 05:04:52PM +0000, Mans Rullgard wrote:
>> If an interface has an associated devicetree node with status disabled,
>> do not register the device.  This is useful for boards with a built-in
>> multifunction USB device where some functions are broken or otherwise
>> undesired.
>> 
>> Signed-off-by: Mans Rullgard <mans@...sr.com>
>> ---
>>  drivers/usb/core/message.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
>> index bfa5eda0cc26..6b45d4835e41 100644
>> --- a/drivers/usb/core/message.c
>> +++ b/drivers/usb/core/message.c
>> @@ -2007,6 +2007,10 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
>>  	for (i = 0; i < nintf; ++i) {
>>  		struct usb_interface *intf = cp->interface[i];
>>  
>> +		if (intf->dev.of_node &&
>> +		    !of_device_is_available(intf->dev.of_node))
>> +			continue;
>
> Shouldn't you at least print some message out saying you are skipping
> this?  Odds are this is going to cause regressions in devices that were
> not expecting this, right?  So pointing them at why their devices now no
> longer work would be good :)

They will only be skipped if there is a device tree node for the
interface _and_ it has and explicit status = "disabled" property.
The default is still to create devices for all interfaces.

That said, printing a message is probably a good idea anyway.  Would
"info" level be appropriate for this?

-- 
Måns Rullgård

Powered by blists - more mailing lists