From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: shmobile: koelsch: Conditionally select MICREL_PHY
Date: Wed, 18 Dec 2013 00:53:26 +0000 [thread overview]
Message-ID: <20131218005326.GE18992@verge.net.au> (raw)
In-Reply-To: <CAMuHMdV7y7GFrswa+f7ui8LSXj723_i5P6gBAG5ZOoMDP5LWyA@mail.gmail.com>
On Tue, Dec 17, 2013 at 11:10:15AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 17, 2013 at 1:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Dec 17, 2013 at 02:31:35AM +0300, Sergei Shtylyov wrote:
> >> On 12/16/2013 04:25 PM, I wrote:
> >> >>The koelsch board uses has an SH ethernet controller which uses a Micrel
> >> >>phy. Select MICREL_PHY for koelsch if SH_ETH is enabled to make use of the
> >> >>Micrel-specific phy driver rather than relying on the generic phy driver.
> >>
> >> > Frankly speaking, I'm seeing no advantages to doing that.
> >>
> >> Although wait, Geert has reported the absence of Rx FIFO overflow
> >> messages with this PHY driver, IIRC.
>
> I spoke too soon: apparently the statistical relevance of my reporting was
> too low. I still see them from time to time, but I think less than before (no
> numbers available).
>
> >> >>Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >>
> >> > Analogous changes are needed for BOCK-W and Lager boards since they all
> >> >use the same KSZ8041RNLI PHY chip. I was going to submit such changes with the
> >> >PHY IRQ patches but since no IRQ is generated still, this got delayed...
> >>
> >> Only I was going to do it via defconfigs...
> >
> > That was my initial approach too. However I have been convinced
> > that Kconfig is a better way forwards.
>
> Kconfig has the advantage that the minimal defconfigs will be smaller, so
> less churn there.
> However, it does mean you cannot disable the option anymore via your .config.
>
> In this case it's a bit difficult to decide, as sh_eth will work both
> with and without
> the specific PHY-driver.
>
> If no users want to disable it, I'd go for Kconfig.
It is indeed a tricky choice. But I think we should try going for Kconfig.
WARNING: multiple messages have this Message-ID (diff)
From: horms@verge.net.au (Simon Horman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: shmobile: koelsch: Conditionally select MICREL_PHY
Date: Wed, 18 Dec 2013 09:53:26 +0900 [thread overview]
Message-ID: <20131218005326.GE18992@verge.net.au> (raw)
In-Reply-To: <CAMuHMdV7y7GFrswa+f7ui8LSXj723_i5P6gBAG5ZOoMDP5LWyA@mail.gmail.com>
On Tue, Dec 17, 2013 at 11:10:15AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 17, 2013 at 1:31 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Dec 17, 2013 at 02:31:35AM +0300, Sergei Shtylyov wrote:
> >> On 12/16/2013 04:25 PM, I wrote:
> >> >>The koelsch board uses has an SH ethernet controller which uses a Micrel
> >> >>phy. Select MICREL_PHY for koelsch if SH_ETH is enabled to make use of the
> >> >>Micrel-specific phy driver rather than relying on the generic phy driver.
> >>
> >> > Frankly speaking, I'm seeing no advantages to doing that.
> >>
> >> Although wait, Geert has reported the absence of Rx FIFO overflow
> >> messages with this PHY driver, IIRC.
>
> I spoke too soon: apparently the statistical relevance of my reporting was
> too low. I still see them from time to time, but I think less than before (no
> numbers available).
>
> >> >>Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >>
> >> > Analogous changes are needed for BOCK-W and Lager boards since they all
> >> >use the same KSZ8041RNLI PHY chip. I was going to submit such changes with the
> >> >PHY IRQ patches but since no IRQ is generated still, this got delayed...
> >>
> >> Only I was going to do it via defconfigs...
> >
> > That was my initial approach too. However I have been convinced
> > that Kconfig is a better way forwards.
>
> Kconfig has the advantage that the minimal defconfigs will be smaller, so
> less churn there.
> However, it does mean you cannot disable the option anymore via your .config.
>
> In this case it's a bit difficult to decide, as sh_eth will work both
> with and without
> the specific PHY-driver.
>
> If no users want to disable it, I'd go for Kconfig.
It is indeed a tricky choice. But I think we should try going for Kconfig.
next prev parent reply other threads:[~2013-12-18 0:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 0:31 [PATCH] ARM: shmobile: koelsch: Conditionally select MICREL_PHY Simon Horman
2013-12-16 0:31 ` Simon Horman
2013-12-16 13:25 ` Sergei Shtylyov
2013-12-16 13:25 ` Sergei Shtylyov
2013-12-16 22:31 ` Sergei Shtylyov
2013-12-16 23:31 ` Sergei Shtylyov
2013-12-17 0:31 ` Simon Horman
2013-12-17 0:31 ` Simon Horman
2013-12-17 10:10 ` Geert Uytterhoeven
2013-12-17 10:10 ` Geert Uytterhoeven
2013-12-18 0:53 ` Simon Horman [this message]
2013-12-18 0:53 ` Simon Horman
2013-12-19 9:04 ` Simon Horman
2013-12-19 9:04 ` Simon Horman
2013-12-17 0:30 ` Simon Horman
2013-12-17 0:30 ` Simon Horman
2013-12-19 22:05 ` Sergei Shtylyov
2013-12-19 23:05 ` Sergei Shtylyov
2013-12-26 5:30 ` Simon Horman
2013-12-26 5:30 ` Simon Horman
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=20131218005326.GE18992@verge.net.au \
--to=horms@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.