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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 07 Dec 2015 10:40:04 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Yankejian (Hackim Yim)" <yankejian@...wei.com>
Cc:	davem@...emloft.net, fengguang.wu@...el.com, robh+dt@...nel.org,
	pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	catalin.marinas@....com, will.deacon@....com,
	salil.mehta@...wei.com, Yisen.Zhuang@...wei.com,
	liguozhu@...wei.com, lisheng011@...wei.com,
	huangdaode@...ilicon.com, xuwei5@...ilicon.com,
	haifeng.wei@...wei.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: arRe: [PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)

On Monday 07 December 2015 15:14:13 Yankejian wrote:
> On 2015/12/6 6:19, Arnd Bergmann wrote:
> > On Saturday 05 December 2015 14:10:56 yankejian wrote:
> >> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> index 80411b2..ecacfa4 100644
> >> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >> @@ -4,8 +4,6 @@ Required properties:
> >>  - compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
> >>    "hisilicon,hns-dsaf-v1" is for hip05.
> >>    "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
> >> -- dsa-name: dsa fabric name who provide this interface.
> >> -  should be "dsafX", X is the dsaf id.
> >>  - mode: dsa fabric mode string. only support one of dsaf modes like these:
> >>                 "2port-64vf",
> >>                 "6port-16rss",
> >> @@ -26,9 +24,8 @@ Required properties:
> >>  
> >>  Example:
> >>  
> >> -dsa: dsa@...00000 {
> >> +dsaf0: dsa@...00000 {
> >>         compatible = "hisilicon,hns-dsaf-v1";
> >> -       dsa_name = "dsaf0";
> >>         mode = "6port-16rss";
> >>         interrupt-parent = <&mbigen_dsa>;
> >>         reg = <0x0 0xC0000000 0x0 0x420000
> >> diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> index 41d19be..e6a9d1c 100644
> >> --- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
> >> @@ -4,8 +4,9 @@ Required properties:
> >>  - compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
> >>    "hisilicon,hns-nic-v1" is for hip05.
> >>    "hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
> >> -- ae-name: accelerator name who provides this interface,
> >> -  is simply a name referring to the name of name in the accelerator node.
> >> +- ae-handle: accelerator engine handle for hns,
> >> +  specifies a reference to the associating hardware driver node.
> >> +  see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
> >>  - port-id: is the index of port provided by DSAF (the accelerator). DSAF can
> >>    connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
> >>    are called debug ports.
> >> @@ -41,7 +42,7 @@ Example:
> >>  
> >>
> > This looks like an incompatible change, as you add and remove
> > required properties. Is there a way to support both the old and
> > the new style?
> >
> >       Arnd
> >
> > .
> 
> Hi Arnd,
> Thanks for your suggestions.  it must be set the same strings in dsaf node and every enet node before.
> it seems inappropriate. as Rob Herring <robh@...nel.org> 's suggestions, that would solve associating
> enet with a particular dsaf. so we discus the solution with Yisen Zhuang <yisen.zhuang@...wei.com>.
> we decide to use the new way instead of the old one.

I agree the new form looks better than the original way, but I'm worried
about the migration path. You don't explain in the patch description
how you want to ensure that nothing breaks for existing systems.

We generally try to avoid doing incompatible changes altogether and
prefer to keep backwards compatibility, unless we can prove that no
other systems exist that would get impacted by the change.

Are you sure that nobody ships a DTB file for this hardware with their
firmware that would now require an incompatible update which in turn
breaks old kernels?

Are you sure that there is no hardware using the same dsa hardware
with out-of-tree dts files that need to make the same change but might
not be aware of the change?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ