linux-kernel - Re: Microchip USB Hub Driver Harmonization

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 18 May 2017 07:33:07 +0200
From:   Richard Leitner <me@...l1n.net>
To:     Krzysztof Kozlowski <krzk@...nel.org>,
        Richard Leitner <richard.leitner@...data.com>
Cc:     Linux USB List <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Richard Leitner <dev@...l1n.net>,
        Stephen Boyd <stephen.boyd@...aro.org>
Subject: Re: Microchip USB Hub Driver Harmonization

On 05/17/2017 06:01 PM, Krzysztof Kozlowski wrote:
> On Wed, May 17, 2017 at 12:58:38PM +0200, Richard Leitner wrote:
>> ...
>>
>> 1. Currently usb251xb uses i2c_smbus_*, usb3503 uses regmap_* and
>> usb4604 uses i2c_master_* functions for the hub configuration. What
>> would be the preferred solution?
>
> regmap? It is already widely used for I2C drivers. I think most (or even
> all?) new I2C drivers use regmap. It hides the real bus between common
> regmap API.

Ok. Thanks for that information. Then I will go for regmap.

>
>> 2. What would be a good prefix for common headers/functions/macros/etc.?
>> I thought of "mcusbhub"... Would that be OK? Or are there any
>> conventions/better proposals on that?
>
> If you are going to develop one driver for entire family, then you could
> even choose just one name. Let's say the most generic.
>
> I don't quite understand the meaning behind "harmonizing drivers".

I'm currently evaluating if it is feasible to create one common driver 
for all USBxxxx hubs. Due to the fact there are currently only 3 hub 
types implemented mainline (the Microchip homepage lists 36 USB Hub 
products [1]) it involves quite a lot data-sheet reading ;-)

As a first step (and also the final one if implementing a common driver 
is not feasible) I thought of creating a common header/source file which 
implements all "re-useable" functions/macros/etc. Would that also be an 
accepted solution?

>
>> 3. Currently only usb3503 supports "platform data". Is this still needed
>> or may it be removed?
>
> I think it is still used, e.g. by:
> arch/arm/boot/dts/exynos5250-spring.dts

Please correct me if I'm wrong, but isn't that DT only?

The reason why I'm asking if it may be removed is because the only file 
including "linux/platform_data/usb3503.h" is the usb3503.c driver itself 
and it's also the only file using "struct usb3503_platform_data".

Thanks & kind regards,
RichardL

[1] 
https://www.microchip.com/design-centers/usb/usb-hubs-and-devices/products/overview