linux-kernel - Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

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:	Wed, 06 Apr 2016 13:19:04 +0300
From:	Felipe Balbi <balbi@...nel.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Lu Baolu <baolu.lu@...ux.intel.com>
Cc:	Oliver Neukum <oneukum@...e.com>,
	Mathias Nyman <mathias.nyman@...el.com>,
	Lee Jones <lee.jones@...aro.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Chanwoo Choi <cw00.choi@...sung.com>,
	MyungJoo Ham <myungjoo.ham@...sung.com>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi,

Greg Kroah-Hartman <gregkh@...uxfoundation.org> writes:
>> On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote:
>> > On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote:
>> >> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:
>> >>
>> >>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform b/Documentation/ABI/testing/sysfs-bus-platform
>> >>> index 5172a61..a2261cb 100644
>> >>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>> >>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>> >>> @@ -18,3 +18,18 @@ Description:
>> >>>  		devices to opt-out of driver binding using a driver_override
>> >>>  		name such as "none".  Only a single driver may be specified in
>> >>>  		the override, there is no support for parsing delimiters.
>> >>> +
>> >>> +What:		/sys/bus/platform/devices/.../intel_mux
>> >> Hi,
>> >>
>> >> is there any reason to call this "intel_mux"? We want a common interface
>> >> for such things. So how about "role_mux" or "master_slave_mux"?
>> > I agree, don't make this intel specific, as it shouldn't be.

right, we can easily change the name. What happens when
e.g. AMD/NVidia/TI/MediaTek/Allwinner/etc come up with a similar setup
which can't be supported by Intel's mux driver ? (see more below,
agreeing on a name here doesn't seem to be enough)

>> By the way, do you expect a class for port mux in sysfs?
>
> Why would you create a class?  What is that going to do here?

well, you said you didn't want this to be Intel-specific. We could just
change the name and remove "intel_" from it, but then we would fall into
this situation where possibly different mux drivers might be
needed. That almost requires some small abstraction between sysfs and
the actual implementation, does it not ?

A bus_type doesn't fit here and a simple 'agreement' that mux drivers
will create a sysfs file named 'mux' is too fragile. Thus...

> What happened to getting internal help in designing this api?  This
> shouldn't be my job :)

I looked at this Baolu but, at least to me, it's unclear what you're
hinting here. Sure, the API is a bit odd in that we register a mux and
unregister a device (that has been fixed), but is there anything else ?

We're not asking that you design the API for us, rather just make your
comments a little clearer.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (819 bytes)