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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 18 May 2017 09:46:56 +0200
From:   Krzysztof Kozlowski <krzk@...nel.org>
To:     Richard Leitner <me@...l1n.net>
Cc:     Richard Leitner <richard.leitner@...data.com>,
        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 Thu, May 18, 2017 at 7:33 AM, Richard Leitner <me@...l1n.net> wrote:
>>> 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?

I understand. It is fine with me. You could make common part in few ways, e.g.:
1. prepare re-usable functions etc (as you said),
2. create one driver core (with init/probe/remove/exit etc) which
delegates most of the body to specific handlers around.

The benefit of the second approach is that one sees immediately that
there is one driver for entire family.


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

Ah yes, my mistake. I understood that you are asking about "platform
driver", not "platform data". From my perspective all boards use DT so
there is no platform data. In other drivers I found that some folks
from x86 world use SFI/platform_data but I do not know if it applies
here. Anyway removing platform data is fine with me.

Best regards,
Krzysztof