linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Kamil Debski <k.debski@samsung.com>
Cc: "'Kishon Vijay Abraham I'" <kishon@ti.com>,
	linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm@vger.kernel.org, kyungmin.park@samsung.com,
	Tomasz Figa <t.figa@samsung.com>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	gautam.vivek@samsung.com, mat.krawczuk@gmail.com
Subject: Re: [PATCH v2 1/5] phy: Add new Exynos USB PHY driver
Date: Mon, 28 Oct 2013 21:00:01 +0100	[thread overview]
Message-ID: <1548448.GBuE52miBt@flatron> (raw)
In-Reply-To: <025b01ced3e4$ec685db0$c5391910$%debski@samsung.com>

Hi Kamil,

On Monday 28 of October 2013 14:52:19 Kamil Debski wrote:
> Hi Kishon,
> 
> Thank you for your review! I will answer your comments below.
[snip]
> > > +
> > > +	switch (drv->cfg->cpu) {
> > > +	case TYPE_EXYNOS4210:
> > 
> > > +	case TYPE_EXYNOS4212:
> > Lets not add such cpu checks inside driver.
> 
> Some SoC have a special register, which switches the OTG lines between
> device and host modes. I understand that it might not be the prettiest
> code. I see this as a good compromise between having a single huge
> driver for all Exynos SoCs and having a multiple drivers for each SoC
> version. PHY IPs in these chips very are similar but have to be handled
> differently. Any other ideas to solve this issue?

Maybe adding a flag in drv->cfg called, for example, .has_mode_switch 
could solve this problem without having to check the SoC type explicitly?

[snip]
> > > +#ifdef CONFIG_PHY_EXYNOS4210_USB
> > 
> > Do we really need this?
> 
> No we don't. The driver can always support all Exynos SoC versions.
> These config options were added for flexibility.
> 
> > > +extern const struct uphy_config exynos4210_uphy_config; #endif
> > > +
> > > +#ifdef CONFIG_PHY_EXYNOS4212_USB
> > 
> > Same here.
> > 
> > > +extern const struct uphy_config exynos4212_uphy_config; #endif
> > > +
> > > +static const struct of_device_id exynos_uphy_of_match[] = { #ifdef
> > > +CONFIG_PHY_EXYNOS4210_USB
> > 
> > #if not needed here.
> 
> If the #ifdef CONFIG_PHY_EXYNOS4210_USB is removed then yes. Otherwise
> it is necessary - exynos4210_uphy_config may be undefined.

I believe this and other ifdefs below are needed, otherwise, with support
for one of the SoCs disabled, the driver could still bind to its 
compatible value.

Best regards,
Tomasz


  reply	other threads:[~2013-10-28 20:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-25 14:15 [PATCH 0/5] phy: Add new Exynos USB PHY driver Kamil Debski
2013-10-25 14:15 ` [PATCH v2 1/5] " Kamil Debski
2013-10-25 15:39   ` Kishon Vijay Abraham I
2013-10-28 13:52     ` Kamil Debski
2013-10-28 20:00       ` Tomasz Figa [this message]
2013-10-29 10:16         ` Kamil Debski
2013-10-29  9:52       ` Kishon Vijay Abraham I
2013-10-25 21:36   ` Kumar Gala
2013-10-28 13:52     ` Kamil Debski
2013-10-25 14:15 ` [RFC PATCH 2/5] phy: Add WIP Exynos 5250 support to the " Kamil Debski
2013-10-25 15:43   ` Kishon Vijay Abraham I
2013-10-28 13:52     ` Kamil Debski
2013-10-28 14:41     ` Vivek Gautam
2013-10-29  9:55       ` Kishon Vijay Abraham I
2013-10-29 10:14         ` Kamil Debski
2013-10-29 10:51           ` Kishon Vijay Abraham I
2013-10-25 14:15 ` [PATCH 3/5] phy: Add support for S5PV210 " Kamil Debski
2013-10-25 15:50   ` Kishon Vijay Abraham I
2013-10-26  1:40     ` Jingoo Han
2013-10-25 14:15 ` [PATCH 4/5] usb: ehci-s5p: Change to use phy provided by the generic phy framework Kamil Debski
2013-10-25 15:52   ` Kishon Vijay Abraham I
2013-10-26  1:27   ` Jingoo Han
2013-10-28 13:52     ` Kamil Debski
2013-10-26  9:41   ` Vivek Gautam
2013-10-28 13:53     ` Kamil Debski
2013-10-28 14:36       ` Vivek Gautam
2013-10-25 14:15 ` [PATCH 5/5] usb: s3c-hsotg: Use the new Exynos USB phy driver with " Kamil Debski
2013-10-25 15:53   ` Kishon Vijay Abraham I

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=1548448.GBuE52miBt@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gautam.vivek@samsung.com \
    --cc=k.debski@samsung.com \
    --cc=kishon@ti.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mat.krawczuk@gmail.com \
    --cc=s.nawrocki@samsung.com \
    --cc=t.figa@samsung.com \
    /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).