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
| ||
|
Date: Tue, 25 Aug 2020 16:40:23 +0200 From: Matthias Schiffer <matthias.schiffer@...tq-group.com> To: Fabio Estevam <festevam@...il.com> Cc: Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>, NXP Linux Team <linux-imx@....com>, "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" <linux-arm-kernel@...ts.infradead.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: (EXT) Re: (EXT) Re: [PATCH 2/2] ARM: dts: imx6qdl: tqma6: minor fixes On Tue, 2020-08-25 at 11:24 -0300, Fabio Estevam wrote: > Hi Matthias, > > On Tue, Aug 25, 2020 at 4:22 AM Matthias Schiffer > <matthias.schiffer@...tq-group.com> wrote: > > > Hmm, unless I'm overlooking something, this is not going to work: > > > > - spi_get_gpio_descs() sets num_chipselect to the maximum of the > > num_chipselect set in the driver and the number of cs-gpios > > > > - spi_imx_probe() sets num_chipselect to 3 if not specified in the > > device tree > > > > So I think we would end up with 3 instead of 1 chipselect. > > Oh, this has changed recently in 8cdcd8aeee281 ("spi: imx/fsl-lpspi: > Convert to GPIO descriptors"): > .... > > - } else { > - u32 num_cs; > - > - if (!of_property_read_u32(np, "num-cs", &num_cs)) > - master->num_chipselect = num_cs; > - /* If not preset, default value of 1 is used */ > > Initially, if num-cs was not present the default value for > num_chipselect was 1. > > - } > + /* > + * Get number of chip selects from device properties. This > can be > + * coming from device tree or boardfiles, if it is not > defined, > + * a default value of 3 chip selects will be used, as all the > legacy > + * board files have <= 3 chip selects. > + */ > + if (!device_property_read_u32(&pdev->dev, "num-cs", &val)) > + master->num_chipselect = val; > + else > + master->num_chipselect = 3; > > Now it became 3. > > I think this is a driver issue and we should fix the driver instead > of > requiring to pass num-cs to the device tree. > > > num-cs is not even documented in the spi-imx binding. Makes sense. Does the following logic sound correct? - If num-cs is set, use that (and add it to the docs) - If num-cs is unset, use the number of cs-gpios - If num-cs is unset and no cs-gpios are defined, use a driver-provided default I'm not sure if 3 is a particularly useful default either, but it seems it was chosen to accommodate boards that previously set this via platform data. All SoCs I've checked (i.MX6Q/DL, i.MX6UL, i.MX7) have 4 internal CS pins per ECSPI instance, so maybe the driver should use that as its default instead?
Powered by blists - more mailing lists