lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 8 Feb 2016 17:21:27 +0000
From:	Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"Guohanjun (Hanjun Guo)" <guohanjun@...wei.com>,
	"Wangzhou (B)" <wangzhou1@...ilicon.com>,
	"liudongdong (C)" <liudongdong3@...wei.com>,
	Linuxarm <linuxarm@...wei.com>, qiujiang <qiujiang@...wei.com>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"Lorenzo.Pieralisi@....com" <Lorenzo.Pieralisi@....com>,
	"tn@...ihalf.com" <tn@...ihalf.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xuwei (O)" <xuwei5@...ilicon.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"jcm@...hat.com" <jcm@...hat.com>,
	zhangjukuo <zhangjukuo@...wei.com>,
	"Liguozhu (Kenneth)" <liguozhu@...ilicon.com>
Subject: RE: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
 controller ECAM compliant

Hi Arnd

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@...db.de]
> Sent: 08 February 2016 16:30
> To: Gabriele Paoloni
> Cc: linux-arm-kernel@...ts.infradead.org; Guohanjun (Hanjun Guo);
> Wangzhou (B); liudongdong (C); Linuxarm; qiujiang; bhelgaas@...gle.com;
> Lorenzo.Pieralisi@....com; tn@...ihalf.com; linux-pci@...r.kernel.org;
> linux-kernel@...r.kernel.org; xuwei (O); linux-acpi@...r.kernel.org;
> jcm@...hat.com; zhangjukuo; Liguozhu (Kenneth)
> Subject: Re: [RFC PATCH v2 2/3] PCI: hisi: Make the HiSilicon PCIe host
> controller ECAM compliant
> 
> On Monday 08 February 2016 15:55:35 Gabriele Paoloni wrote:
> > > 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
> > 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  

> 
> > > 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
> > 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@...0080000 {
> >                 compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
> > -               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0
> 0x2000>;
> > -               reg-names = "rc_dbi", "config";
> > +               reg = <0 0xb0080000 0 0x10000>, <0x220 0x00100000 0
> 0x0f00000>;
> > +               reg-names = "rc_dbi", "ecam-cfg";
> >
> 
> That is not the compatible string, it's an undocumented register set.

Sorry, I misunderstood here, got it now :)

> 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
> 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?

Thanks

Gab

> 
> 	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ