Re: [PATCH 1/5] i2c: rcar: add renesas,i2c-rcar-gen1/gen2 in DT compatible

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Morimoto-san,

Thanks for your comments!

On Thu, Aug 7, 2014 at 2:19 PM, Kuninori Morimoto
<kuninori.morimoto.gx@xxxxxxxxx> wrote:
>
> Hi Magnus
>
>> The problem is that "gen2" is not something that is pre-defined. As
>> you may have noticed earlier, new SoCs keep on coming and even though
>> they may be part of "gen2" they may or may not be compatible with the
>> "gen2" compatible string. So based on that, if we use the SoC part
>> number in the compatible string we at least know what the support
>> status is.
>
> Do you mean "driver" table ?
> This patch doesn't remove SoC level compatible from driver.

Yes, this applies to the compatible string table in each driver.
Because "gen2" is an ongoing project we have no idea what kind of new
products that will come out - that may or may not be compatible with
the "gen2" current compatible strings... And these strings are only
really specifying if our current version of the driver is compatible
or not. We should instead describe the hardware dependency IMO.

> And additionally,
> we can check support status in Document/devicetree/...txt
> and Geert is doing it now ?
> (Which SoC is working/supporting)

Right, that is good!

My main concern is not the support status though. It is more about how
to handle the "gen2" compatible string over time. Please see below for
some example of difficulties introduced by this approach.

>> So I agree that sharing hardware makes sense from a resource saving
>> point of view. However in reality there may be smaller differences
>> between devices used for each version within the generation though.
>
> Yes, "maybe" it has smaller difference, but what is the problem ?
> Driver is already have SoC level compatible.
> Why we can't update it ?

We can of course update anything, the question is just why we should. =)

> Or, "maybe" we can add new property for it ?
> It can keep compatible anyway, because current code is already working.

In my opinion having a "gen2" compatible string in the driver does not
help anything. For the existing SoCs we already have compatible
strings. For new SoCs we can simply add the new part number to the
driver.

Perhaps you are thinking about the case when new "compatible" SoCs
come out, the idea that we want to not modify the driver but just add
DTS and then everything should work as-is. This is a great idea, and
for this to work we want to have "hardware block version number" from
the device team. Until we have that I believe it is best to not use
"gen2" compatible strings. Let me explain why.

1) We don't know if the hardware is compatible unless it is documented to be so
2) We can test using the same compatible string, but it just means the
current driver implementation happens to work
3) If all registers and features are used by the driver then we can
perhaps assume that we have tested the hardware
4) The common case with a driver is that not all hardware features are
used, so some are untested and unknown compatibility wise
5) If we use "gen2" compatible string then future driver feature
extensions may break some hardware
6) To avoid breakage in 5) we have test on all known platforms which
is quite difficult
7) People will ship out of tree code using the generic binding so we
cannot perform testing in 6) on all platforms
8) The meaning of "gen2" is changing over time, so it is not a fixed
definition of anything
9) In the end, this discussion is matter of describing compatibility
of hardware or software implementation.
10) DT bindings should in theory work with multiple operating systems.
So we have to describe hardware, not software.

With this in mind I think the best way forward is as follows:
A) Keep on using per-SoC compatible string unless it is documented somewhere
and in parallel
B) Work on getting per-device hardware version number from hardware device team

> In my opinion, we can use SoC level compatible name if it was special,
> otherwise, we can use generation level compatible.
> Platform side DTS file should include SoC and generation level compatible
> from first support patch. If possible, series compatible too.
> like this
>
>         compatible = "renesas,i2c-r8a7790", "renesas,i2c-rcar-gen2", "renesas,i2c-rcar"
>
> But, it is too late for Gen1/Gen2.
> I don't want to have more pointless string in driver in Gen3 or later.

I understand your opinion. I don't want to have pointless strings in
new SoCs either.

>From my point of view your proposal adds problematic dependencies for
each device without too much upside. The problem will happen over time
when adding features. It is in my opinion easier to just add the
compatible string entry for a new SoC together with the rest of the
SoC support activity. There is no easy way out when the hardware is
changing - we have to modify the code anyway! Of course, if the
hardware is not changing then it is a different story. But in such
case we need to have documented compatibility somewhere...

What is your opinion about "B) per-device hardware version number"?

> But yes, we want to know which SoC is supported.
> We can use Document/devicetree/...txt for this purpose

I agree about that portion. =)

Cheers,

/ magnus
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux