From: Marc Kleine-Budde <mkl@pengutronix.de>
To: balbi@ti.com
Cc: r58472@freescale.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, Peter Chen <peter.chen@freescale.com>,
kernel@pengutronix.de, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
Date: Mon, 14 Jan 2013 18:54:22 +0100 [thread overview]
Message-ID: <50F4464E.7000605@pengutronix.de> (raw)
In-Reply-To: <20130114174054.GB12611@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 2355 bytes --]
On 01/14/2013 06:40 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 08:56:33PM +0800, Peter Chen wrote:
>
> <snip>
>
>>>> Usually there isn't any Changelog between IP cores used in the different
>>>> fsl processors (at least available outside of fsl), that makes it quite
>>>> difficult to say if something found on one imx is really the same as on
>>>> the other one. And they (usually) don't provide any versioning
>>>> information in a register or the documentation.
>>>>
>>>> just my 2¢
>>>
>>> $SUBJECT is trying to differentiate a single feature (or maybe two) to
>>> replace cpu_is_xxx(), then expose that on driver_data without creating
>>> one enum value for each release from fsl.
>>
>> Felipe, every one or two SoCs may have their special operations for
>> integrate PHY interface, clk operation, or workaround for IC
>> limitation.
>
> the particular PHY and clk used should be hidden by phy layer and clk
> API respectively. Workarounds, fair enough, we need to handle them; but
> ideally those should be based on runtime revision detection, not some
> hackery using driver_data.
If this is actually possible, I'd love to do this. But IP vendor don't
include a version register in their cores. :(
>> Maybe, it will add more future or SoCs (maybe not for this driver) in
>> the future, using enum is easier than string comparison for expanding
>> something.
>
> a) I never told you to *not* use enum. I said that creating DEVICE_A,
> DEVICE_B, DEVICE_C, DEVICE_D and DEVICE_E values when DEVICE_B,
> DEVICE_C and DEVICE_E behave exactly the same is unnecessary.
>
> b) you can't be expecting to add future SoCs support to fsl udc, I have
> already said and will repeat for the last time: move to chipidea ASAP.
>
> New SoCs cannot be added to fsl udc, you *must* use chipidea for
> anything new and move the legacy to chipidea eventually. I will wait for
> a full year for you to do that, but after that I will have to start
> deleting drivers for the sake of avoid duplication of effort.
+1
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
next prev parent reply other threads:[~2013-01-14 17:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-14 10:12 [PATCH v3 0/3] Fix the Build error for fsl_mxc_udc.c Peter Chen
2013-01-14 10:12 ` [PATCH v3 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id Peter Chen
2013-01-14 10:16 ` Felipe Balbi
2013-01-14 10:18 ` Marc Kleine-Budde
2013-01-14 10:24 ` Felipe Balbi
2013-01-14 10:34 ` Marc Kleine-Budde
2013-01-14 10:39 ` Felipe Balbi
2013-01-14 10:50 ` Marc Kleine-Budde
2013-01-14 10:53 ` Felipe Balbi
2013-01-14 11:03 ` Marc Kleine-Budde
2013-01-14 11:06 ` Felipe Balbi
2013-01-14 12:56 ` Peter Chen
2013-01-14 17:40 ` Felipe Balbi
2013-01-14 17:54 ` Marc Kleine-Budde [this message]
2013-01-14 17:57 ` Felipe Balbi
2013-01-15 1:31 ` Peter Chen
2013-01-14 10:12 ` [PATCH v3 2/3] usb: fsl_mxc_udc: replace MX35_IO_ADDRESS to ioremap Peter Chen
2013-01-14 10:17 ` Felipe Balbi
2013-01-14 12:58 ` Peter Chen
2013-01-14 13:10 ` Russell King - ARM Linux
2013-01-14 13:16 ` Peter Chen
2013-01-14 10:12 ` [PATCH v3 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc Peter Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50F4464E.7000605@pengutronix.de \
--to=mkl@pengutronix.de \
--cc=balbi@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=peter.chen@freescale.com \
--cc=r58472@freescale.com \
--cc=shawn.guo@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).