From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753365AbbIOQuN (ORCPT ); Tue, 15 Sep 2015 12:50:13 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:41199 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752810AbbIOQuK (ORCPT ); Tue, 15 Sep 2015 12:50:10 -0400 Date: Tue, 15 Sep 2015 11:50:02 -0500 From: Felipe Balbi To: Peter Senna Tschudin CC: Felipe Balbi , Alan Stern , Sergei Shtylyov , Masanari Iida , , , "linux-kernel@vger.kernel.org" , Greg Kroah-Hartman Subject: Re: similar files: fusbh200-hcd.c and fotg210-hcd.c Message-ID: <20150915165002.GP19948@saruman.tx.rr.com> Reply-To: References: <20150908155257.GE25074@saruman.tx.rr.com> <20150914150155.GA25990@saruman.tx.rr.com> <20150915143307.GC19948@saruman.tx.rr.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dO6Thh8T/cwyDjv9" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --dO6Thh8T/cwyDjv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Tue, Sep 15, 2015 at 06:41:55PM +0200, Peter Senna Tschudin wrote: > On Tue, Sep 15, 2015 at 4:33 PM, Felipe Balbi wrote: > > On Mon, Sep 14, 2015 at 07:50:02PM +0200, Peter Senna Tschudin wrote: > >> On Mon, Sep 14, 2015 at 5:01 PM, Felipe Balbi wrote: > >> > On Sat, Sep 12, 2015 at 03:14:50PM +0200, Peter Senna Tschudin wrote: > >> >> >> Should these files be consolidated? And if so how? > >> >> > if you can find an easy way, that would be a very, very welcome p= atch. > >> >> > >> >> Is the ideal solution to consolidate both fusbh200-hcd.c and > >> >> fotg210-hcd.c in a single module? If this is the case, how to detect > >> >> at run time which version of the hw is present? Both are registered= as > >> > > >> > does it matter ? If they work the same way, why does it matter which > >> > one's running? > >> > >> I may be missing something simple, but based on a 2 page product > >> brief, fotg210 has more resources like memory. So even if the .c files > >> are _very_ similar, there are some configuration parameters that > >> differ, for example: > >> > >> fusbh200.h: > >> #define BMCSR_VBUS_OFF (1<<4) > >> #define BMCSR_INT_POLARITY (1<<3) > >> > >> fotg210.h: > >> #define OTGCSR_A_BUS_DROP (1 << 5) > >> #define OTGCSR_A_BUS_REQ (1 << 4) > > > > Can you detect that in runtime ? If you can, detect it. If you can't use > > different platform_device_id. > > > >> >> notebook (hp elitebook 840), and on a VM, even if neither has the hw > >> >> ($ sudo modprobe fusbh200-hcd). The module loads with the warning > >> >> "fusbh200_hcd should always be loaded before uhci_hcd and ohci_hcd, > >> >> not after". On another workstation running ubuntu, I could load both > >> >> modules at the same time, producing the same warning for each modul= e. > >> >> Should the module load if the device is not present? > >> >> > >> >> Other solution for consolidation would be to create a common_code.c, > >> >> keeping both fusbh200-hcd.c and fotg210-hcd.c only with the code th= at > >> >> differ. Is this better than what is there now? > >> >> > >> >> Other ideas? > >> > > >> > just combine them :-p Use platform_device_id to differentiate. >=20 > Can you check the f2xx branch at: >=20 > git@github.com:petersenna/linux.git >=20 > And tell me if this is the way to go for the consolidation of the two > drivers? I started with the newest driver, did code cleanup, and > started filling the new driver with parameters from the older > FUSBH200. At the moment it compiles for x86 and probably still works > for FOTG210 devices. A concrete question I have is if should I keep > making many patches for the consolidation or should I do a single big > patch with all changes? Comments are welcome. it's best to just send patches. Also, you gave me an ssh URL which I can't use because I don't have write access to your tree (and I don't want to have it). --=20 balbi --dO6Thh8T/cwyDjv9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJV+Ew6AAoJEIaOsuA1yqREuooP/ijc4EraWLXnNYw62NM4nfvt NwJMrJ6op7kErgyPHv0FZkbP0FWGAdvZrKZOq3VTp8j0fzgieLLcjKoBXPm/vds8 B96HhJB/YRoRis2c4Yp7aHlJhCPSsNYTQZh5z2537JnbVdWHH6WnSF7EAbToJWCR ApgKf9QRInoSpui+IuFrT4y5kDYLd5/0nFFbl6cWQiK6olvbGF0w1HLkHG0DDofx 0dv55VYasrmSBChYuHa+qosHbtGlRIlgJ3zqNOu+MxBLJgCDAcK2Dr2FJbHlZr4z r+xxU53qg1MLNjwCqnxuc0SPdS8B4EUG8WYeqSoOdHVvFh6Tio3E6IinplH5Hny9 hjiE0CjdDEjhl153w8Sew1M7LM9nt5eNo5YHhLRhivJkXtG6L0aXrh3L34PfYklw V2S1RzcHJ0NW7spbFttOEce0B4QW/b+6ixuCC30GKlbZ7rFPYeEjW7KoL151JTTM 57gSaL80KaUYJzKkCbfoXzbeKDFZSt9G+1LAW3ln/thzwAs5Hb3NSlbt9PoTqAZ6 ydFEK9+rZE2dXyDti6QBAtbfcWWA8A8E3cjmKYptwLFayyxTxsaReYyed6bzwx7Z b32LnA2k5dm5WFKa1p2sRoQSpUTlyzPDLro9vuJr5WM7nyU5yOk9ixRcajM6UDxq 3XM05oofwluclxvhE3hD =3WSc -----END PGP SIGNATURE----- --dO6Thh8T/cwyDjv9--