devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Magnus Damm <magnus.damm@gmail.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	SH-Linux <linux-sh@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Simon Horman <horms@verge.net.au>
Subject: Re: [PATCH 2/5] ARM: shmobile: r8a7791: add i2c master nodes to dtsi
Date: Mon, 17 Feb 2014 19:03:20 +0900	[thread overview]
Message-ID: <CANqRtoRgMaAzzvD9OK+=_J2Or5HZHzg4RUb899-bXjM7LKHSyw@mail.gmail.com> (raw)
In-Reply-To: <20140217093126.GE2633@katana>

On Mon, Feb 17, 2014 at 6:31 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> On Mon, Feb 17, 2014 at 10:23:31AM +0100, Geert Uytterhoeven wrote:
>> Hi Wolfram,
>>
>> On Mon, Feb 17, 2014 at 10:19 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> >> I think the tricky part is when a driver for "renesas,i2c-r8a7790" is updated
>> >> with a new feature for r8a7790, which doesn't necessarily exist in r8a7791.
>> >> Then the compatible entry above will cause breakage.
>> >
>> > If the driver is updated in that way, then it MUST introduce an r8a7791
>> > compatible entry and make sure the new feature is only used on r8a7790.
>> > Otherwise it is a bug. If this is adhered, we won't have a breakage
>> > because the specific entry (here r8a7791) always comes first. Or?
>>
>> That will indeed prevent breakage. But in the distributed development world,
>> the person who modifies the driver may not be aware of the r8a7791.
>
> Then it will break even with a seperate r8a7791 compatible entry as
> well, sadly. Currently, the only thing encoded in the .data field of all
> compatibles, is which generation of the core is used. This is the same
> for r8a7790 and r8a7791 (this is why they ARE compatible ;)). So, even
> in the unlikely case of an r8a7790-only-feature, some code/reactoring to
> make the distinction is absolutely necessary.

It won't break because anyone who modifies r8a7790 support need to
make it specific to that SoC to not pull in r8a7791 into some
assumption. Just because the driver assumes something now doesn't mean
the hardware actually is compatible.

I think I understand your proposal with making an assumption of the
current state of the driver and making sure to add the new SoC
compatible value before adjusting the fallback. But this mainly seems
like a optimization to improve throughput commit-wise. I actually
proposed the same way for SDHI, but now when I think about it I
realize that there is no shortcut for adding the compatible string to
the driver. It has to be done sooner or later anyway.

Or what am I missing? =)

/ magnus

  reply	other threads:[~2014-02-17 10:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-16  9:40 [PATCH 0/5] enable i2c on koelsch-dt (and cleanup lager) Wolfram Sang
2014-02-16  9:40 ` [PATCH 1/5] ARM: shmobile: r8a7791: remove superfluous interrupt-parents Wolfram Sang
2014-02-16  9:40 ` [PATCH 2/5] ARM: shmobile: r8a7791: add i2c master nodes to dtsi Wolfram Sang
2014-02-17  7:54   ` Wolfram Sang
2014-02-17  8:02     ` Magnus Damm
2014-02-17  9:11       ` Geert Uytterhoeven
2014-02-17  9:19         ` Wolfram Sang
2014-02-17  9:23           ` Geert Uytterhoeven
2014-02-17  9:31             ` Wolfram Sang
2014-02-17 10:03               ` Magnus Damm [this message]
2014-02-17 10:08                 ` Wolfram Sang
2014-02-17 10:11                   ` Magnus Damm
2014-02-17 10:25                     ` Wolfram Sang
2014-02-17  9:12       ` Wolfram Sang
2014-02-17  9:57         ` Magnus Damm
2014-02-16  9:40 ` [PATCH 3/5] ARM: shmobile: r8a7791: add i2c2 bus to koelsch dt Wolfram Sang
2014-02-16  9:40 ` [PATCH 4/5] ARM: shmobile: r8a7790: remove superfluous interrupt-parents Wolfram Sang
2014-02-16  9:40 ` [PATCH 5/5] ARM: shmobile: r8a7790: add i2c aliases to dtsi Wolfram Sang
2014-02-17  3:13 ` [PATCH 0/5] enable i2c on koelsch-dt (and cleanup lager) Magnus Damm
2014-02-17  3:19   ` 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='CANqRtoRgMaAzzvD9OK+=_J2Or5HZHzg4RUb899-bXjM7LKHSyw@mail.gmail.com' \
    --to=magnus.damm@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=horms@verge.net.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=wsa@the-dreams.de \
    /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).