linux-kernel - Re: [PATCH 1/3] spi/rockchip: add rk3036/rk3228/rk3368 socs for spi document

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:	Thu, 19 May 2016 18:20:58 +0200
From:	Heiko Stuebner <heiko@...ech.de>
To:	Caesar Wang <wxt@...k-chips.com>
Cc:	Mark Brown <broonie@...nel.org>,
	linux-rockchip@...ts.infradead.org,
	Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
	Xu Jianqun <jay.xu@...k-chips.com>,
	Kumar Gala <galak@...eaurora.org>,
	linux-kernel@...r.kernel.org,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/3] spi/rockchip: add rk3036/rk3228/rk3368 socs for spi document

Am Freitag, 20. Mai 2016, 00:04:07 schrieb Caesar Wang:
> 在 2016年05月19日 23:51, Heiko Stuebner 写道:
> > Am Donnerstag, 19. Mai 2016, 23:47:02 schrieb Caesar Wang:
> >> We had supported the rk3036/rk3066/rk3188/rk3228/rk3288/rk3368/rk3399
> >> family SoCs in linux kernel.
> >> 
> >> Let's add the other SoCs, in order to a better understanding from the
> >> rockchip spi document.
> >> 
> >> Signed-off-by: Caesar Wang <wxt@...k-chips.com>
> >> Cc: Rob Herring <robh+dt@...nel.org>
> >> Cc: Mark Brown <broonie@...nel.org>
> >> Cc: Heiko Stuebner <heiko@...ech.de>
> >> Cc: linux-rockchip@...ts.infradead.org
> >> ---
> >> 
> >>   Documentation/devicetree/bindings/spi/spi-rockchip.txt | 3 +++
> >>   1 file changed, 3 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> >> b/Documentation/devicetree/bindings/spi/spi-rockchip.txt index
> >> 1b14d69..305b542 100644
> >> --- a/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> >> +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.txt
> >> @@ -6,9 +6,12 @@ and display controllers using the SPI communication
> >> 
> >> interface. Required Properties:
> >>   - compatible: should be one of the following.
> >> 
> >> +    "rockchip,rk3036-spi" for rk3036.
> > 
> > shouldn't the rk3036 also get the rk3066 fallback. Looking at the driver
> > part (patch2) the rk3036 still is the same IP as for every other soc in
> > here.
> 
> Yep, the same IP.
> 
> Do you think we should keep the below style?
> 
> 1)
> "rockchip,rk3036-spi", "rockchip,rk3066-spi" for rk3036.
>   "rockchip,rk3066-spi" for rk3066.
>   "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
> ...
> 
> or
> 2)
>   "rockchip,rk3066-spi" for rk3066.
> "rockchip,rk3036-spi", "rockchip,rk3066-spi" for rk3036.
>   "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188
> ..
> 
> or
> 3)
> "rockchip, rockchip-spi" for rk3036 rk3066.......
> 
> Think about the 1) will be googd select.

or
(4) drop the fallbacks. We match against each compatible all the time 
anyway, so you could also simply do

  "rockchip,rk3036-spi" for rk3036
  "rockchip,rk3066-spi" for rk3066
  "rockchip,rk3188-spi" for rk3188

Maybe leave the fallbacks for existing socs, and just add the new ones 
without the fallbacks.

rockchip,rockchip-spi is not future proof ... i.e. in some future soc 
somebody might want to exchange the IP block against a different one, so 
being specific saves us from hassle then :-)


Heiko

> >>       "rockchip,rk3066-spi" for rk3066.
> >>       "rockchip,rk3188-spi", "rockchip,rk3066-spi" for rk3188.
> >> 
> >> +    "rockchip,rk3228-spi", "rockchip,rk3066-spi" for rk3228.
> >> 
> >>       "rockchip,rk3288-spi", "rockchip,rk3066-spi" for rk3288.
> >> 
> >> +    "rockchip,rk3368-spi", "rockchip,rk3066-spi" for rk3368.
> >> 
> >>       "rockchip,rk3399-spi", "rockchip,rk3066-spi" for rk3399.
> >>   
> >>   - reg: physical base address of the controller and length of memory
> >> 
> >> mapped region.