From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755015AbdERHrA (ORCPT ); Thu, 18 May 2017 03:47:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:36394 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754590AbdERHq6 (ORCPT ); Thu, 18 May 2017 03:46:58 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38D50239DD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=krzk@kernel.org MIME-Version: 1.0 In-Reply-To: <3f2206e3-8b25-c6d7-505a-d4bb2fb5d66a@g0hl1n.net> References: <20170517160152.t34t43ocbzebpkfg@kozik-lap> <3f2206e3-8b25-c6d7-505a-d4bb2fb5d66a@g0hl1n.net> From: Krzysztof Kozlowski Date: Thu, 18 May 2017 09:46:56 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Microchip USB Hub Driver Harmonization To: Richard Leitner Cc: Richard Leitner , Linux USB List , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman , Javier Martinez Canillas , Richard Leitner , Stephen Boyd Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 18, 2017 at 7:33 AM, Richard Leitner 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