-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: 09 February 2016 15:32
To: linux-arm-kernel at lists.infradead.org
Cc: Gabriele Paoloni; Lorenzo.Pieralisi at arm.com; jcm at redhat.com;
tn at semihalf.com; linux-pci at vger.kernel.org; Linuxarm; xuwei (O); linux-
kernel at vger.kernel.org; linux-acpi at vger.kernel.org; Wangzhou (B);
liudongdong (C); Guohanjun (Hanjun Guo); bhelgaas at google.com;
zhangjukuo; Liguozhu (Kenneth); qiujiang
Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
controller ECAM compliant

On Monday 08 February 2016 17:21:27 Gabriele Paoloni wrote:

quoted

Hi Arnd

quoted

-----Original Message-----
From: Arnd Bergmann [mailto:arnd at arndb.de]
Sent: 08 February 2016 16:30
To: Gabriele Paoloni
Cc: linux-arm-kernel at lists.infradead.org; Guohanjun (Hanjun Guo);
Wangzhou (B); liudongdong (C); Linuxarm; qiujiang;

bhelgaas at google.com;

quoted

quoted

Lorenzo.Pieralisi at arm.com; tn at semihalf.com; linux-

pci at vger.kernel.org;

quoted

quoted

linux-kernel at vger.kernel.org; xuwei (O); linux-acpi at vger.kernel.org;
jcm at redhat.com; zhangjukuo; Liguozhu (Kenneth)
Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe

host

quoted

quoted

controller ECAM compliant

On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:

quoted

quoted

Doesn't this break backwards compatibility?

Well Hip05/Hip06 SoCs are used into evaluation boards
For the Estuary project.

https://github.com/hisilicon/estuary

As this new driver gets upstream we'll merge this new driver into

estuary

quoted

and release a new version of the firmware to support it.

So what happens to folks running the old firmware then?

So far we haven't released the PCIe nodes dtsi upstream and we think
we can handle the firmware upgrade for our current users either
by pointing them to the updated Estuary branch or by internal
channels

The dts files in the kernel tree are not really that important,
the question is whether you are breaking things for real users.

If the upstream drivers work on some released firmware version,
they should keep working.

quoted

quoted

quoted

quoted

I think you need to use a new compatible string in the firmware
if you change the register layout, and then change the driver
to support both the old and the new layout.

You are right, for some reason in this patchset I missed the

Documentation

quoted

update that I posted in the previous one, i.e.:

--- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt

@@ -23,8 +23,8 @@ Optional properties:
 Hip05 Example (note that Hip06 is the same except compatible):
        pcie at 0xb0080000 {
                compatible = "hisilicon,hip05-pcie", "snps,dw-

pcie";

quoted

quoted

quoted

-               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000

0

quoted

quoted

0x2000>;

quoted

-               reg-names = "rc_dbi", "config";
+               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000

0

quoted

quoted

0x0f00000>;

quoted

+               reg-names = "rc_dbi", "ecam-cfg";

That is not the compatible string, it's an undocumented register

set.

quoted

Sorry, I misunderstood here, got it now :)

quoted

You can either define the a new compatible string that gives the
"config"
registers a new meaning, or you change the binding to allow two

either

quoted

quoted

a "config" or an "ecam-cfg" register set, and let the driver handle
both.

As per reply above I think that it would be quite easy for us to
let out current users update the BIOS so I don't think there is any
value in maintaining two version of the drivers one of which will
not be used.

What do you think?

Requiring a BIOS update for a kernel update is really bad, even more
so when the same BIOS update breaks older kernels.

Well I see your point.

To be honest I won't expect many users of the old BIOS version since
as I said we plan to send out the BIOS update to pretty much every user,
however on the other side it is not too much effort for me to add code
to support both ECAM/non ECAM, 
so ok I'll fix this in v3,

Many Thanks

Gab

	Arnd