From: sergei.shtylyov@cogentembedded•com (Sergei Shtylyov)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] sh_eth: add R8A7791 support
Date: Sun, 08 Dec 2013 01:08:21 +0300 [thread overview]
Message-ID: <52A39C55.2070204@cogentembedded.com> (raw)
In-Reply-To: <20131118075433.GA1506@verge.net.au>
Hello.
On 11/18/2013 10:54 AM, Simon Horman wrote:
Too bad you haven't spoken out before I went and done this patch and its
follow-ups, at the point where I only laid out my plan of action in a reply to
Magnus...
>> Add support for yet another ARM member of the R-Car family, R-Car M2, also known
>> as R8A7791 -- it will share the code and data with previously added R8A7790.
>> Since the Ether devices in these SoCs are indistinguishable at least from the
>> driver's point of view, do not introduce a new platform device ID but modify
>> device name "r8a7790-ether" to "r8a779x-ether" throughout the files (and also
>> 'r8a7790_data' to 'r8a779x_data' in the driver), just like the names used for
>> R8A7778/9 SoCs.
> I realise that this is the approach that has been taken previously by this
> driver for some other SoCs but it is inconsistent with the approach that
> has (recently) emerged for drivers for Renesas IP.
> The problem with this approach is that although the hardware may appear to
> be the same in the absence of some kind of version number for the IP we
> can't be certain it is the same. Some difference may come to light later
> and then this system breaks down.
I don't think that'll be the case here, but do I understand your concern
about things breaking down.
> Sure, at that point we can create a more fine-grained compatibility string.
Slight correction of terms: we're dealing with platform device ID here,
not (device tree) compatibility string.
> But the approach that has emerged is that in the absence of a clearly
> documented version number for the hardware the SoC name is used as the
> version number.
I just deviated a little from this scheme by using a wildcard.
> I am also not entirely happy with the approach taken by this patch for
> two other reasons:
> 1) It removes rather than deprecating an existing compatibility string.
> Albeit one that may not actually be used in the wild.
We don't care about out of tree code, do we? At least I don't see how we
do that with our current platform device registration policy (mostly per board).
> 2) It changes both drivers/net/ and arch/arm/mach-shmobile/ code.
> This kind of cross-subsystem change can lead to conflicts which
> make Linus grumpy: this has occurred recently with shmobile code
> though not in this driver.
OK, let's do it your way, with adding another platform device ID, and so
doing only drivers/net/ change.
> That said, I did successfully test this patch in conjunction with
> companion patches for the r8A7791 SoC and Koelsch board.
I try not to post untested patches (except when I trust other people to do
the testing of their patches. :-)
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded•com>
WBR, Sergei
next prev parent reply other threads:[~2013-12-07 22:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 23:11 [PATCH] sh_eth: add R8A7791 support Sergei Shtylyov
2013-11-18 7:54 ` Simon Horman
2013-12-07 22:08 ` Sergei Shtylyov [this message]
2013-12-11 2:17 ` 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=52A39C55.2070204@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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