[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f2206e3-8b25-c6d7-505a-d4bb2fb5d66a@g0hl1n.net>
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
Powered by blists - more mailing lists