Re: [PATCH] mtd: cfi: remove redundant assignment to variable timeo
Hi Colin King, On Thu, 25 Mar 2021 17:45:14 +, Colin King wrote: > The variable timeo is being initialized with a value that is never read > and it is being updated later with a new value. The initialization is > redundant and can be removed. Fixed up $subject prefix to match existing convention for the file. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git cfi/next, thanks! [1/1] mtd: cfi: remove redundant assignment to variable timeo https://git.kernel.org/mtd/c/f3907773d6 -- Regards Vignesh
Re: [PATCH -next] i2c: omap: fix PM reference leak in omap_i2c_probe()
Hi. On 4/8/21 6:26 PM, Li Huafei wrote: > pm_runtime_get_sync will increment pm usage counter even it failed. > Forgetting to putting operation will result in reference leak here. Fix > it by replacing it with pm_runtime_resume_and_get to keep usage counter > balanced. > > Reported-by: Hulk Robot > Signed-off-by: Li Huafei > --- > drivers/i2c/busses/i2c-omap.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 12ac4212aded..edbe498d49b8 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1404,7 +1404,7 @@ omap_i2c_probe(struct platform_device *pdev) > pm_runtime_set_autosuspend_delay(omap->dev, OMAP_I2C_PM_TIMEOUT); > pm_runtime_use_autosuspend(omap->dev); > > - r = pm_runtime_get_sync(omap->dev); > + r = pm_runtime_resume_and_get(omap->dev); > if (r < 0) > goto err_free_mem; > > @@ -1525,7 +1525,7 @@ static int omap_i2c_remove(struct platform_device *pdev) > int ret; > > i2c_del_adapter(>adapter); > - ret = pm_runtime_get_sync(>dev); > + ret = pm_runtime_resume_and_get(>dev); > if (ret < 0) > return ret; > > There is a similar patch at: lore.kernel.org/r/20210407033030.13419-1-dinghao@zju.edu.cn But seems like this patch is better as it fixes module remove path as well. Would appreciate if you could work with author of above patch and come up with a single patch. Could you add stable tag and repost given that pm_runtime_resume_and_get() API is backported to stable kernels such as v5.4? Regards Vignesh
Re: [PATCH] i2c: omap: Fix rumtime PM imbalance on error
Hi, On 4/7/21 11:57 AM, Tony Lindgren wrote: > * Vignesh Raghavendra [210407 06:20]: >> Do we need a Fixes: tag to enable stable backports? > > Well pm_runtime_resume_and_get() was introduced quite recently, and > we already handle the error and bail out. And likely after an error > not much works anyways :) So it might be better to add just a stable > tag v5.10 and later as further backports are not likely needed. > Agree this is not a critical patch for backport. But I do know that pm_runtime_resume_and_get() is backported to v5.4 stable kernel at least [1]. So stable tag with v5.4 perhaps would probably help tools looking for patches to backport. [1] https://lkml.org/lkml/2020/12/28/588 > Naturally nothing stopping doing separate backports if really needed > though. > > Regards, > > Tony > Regards Vignesh
Re: [PATCH] i2c: omap: Fix rumtime PM imbalance on error
On 4/7/21 9:00 AM, Dinghao Liu wrote: > pm_runtime_get_sync() will increase the rumtime PM counter > even it returns an error. Thus a pairing decrement is needed > to prevent refcount leak. Fix this by replacing this API with > pm_runtime_resume_and_get(), which will not change the runtime > PM counter on error. > > Signed-off-by: Dinghao Liu > --- Do we need a Fixes: tag to enable stable backports? Reviewed-by: Vignesh Raghavendra > drivers/i2c/busses/i2c-omap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index 12ac4212aded..c9ee0875a79d 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -1404,7 +1404,7 @@ omap_i2c_probe(struct platform_device *pdev) > pm_runtime_set_autosuspend_delay(omap->dev, OMAP_I2C_PM_TIMEOUT); > pm_runtime_use_autosuspend(omap->dev); > > - r = pm_runtime_get_sync(omap->dev); > + r = pm_runtime_resume_and_get(omap->dev); > if (r < 0) > goto err_free_mem; > >
Re: [PATCH 2/2] mtd: spi-nor: add initial sysfs support
On 4/6/21 2:17 PM, Michael Walle wrote: > Hi, > > Am 2021-04-06 09:56, schrieb Vignesh Raghavendra: >> Hi, >> >> On 3/18/21 2:54 PM, Michael Walle wrote: >>> Add support to show the name and JEDEC identifier as well as to dump the >>> SFDP table. Not all flashes list their SFDP table contents in their >>> datasheet. So having that is useful. It might also be helpful in bug >>> reports from users. >>> >> >> Sorry for the delay.. >> >> There is already debugfs support for dumping JEDEC ID [1]. Any reason to >> add sysfs entry as well? > > This is per mtd while the sfdp is per flash device. IMHO both should > be at the same place. > >> That brings up another question. Since SFDP dumps are more of a debug >> aid, should this be a debugfs entry rather than sysfs entry? > > And you're not the first one asking that. My argument was that the > debugfs might not be available just when you need it. A developer > could easily rebuild a kernel, but imagine some user with a COTS > distro and some problems, then it is not that easy anymore. But > thats your call to make. > >> Note that sysfs entries are userspace ABIs just like syscalls and thus >> need to be documented in Documentation/ABI/testing/ or >> Documentation/ABI/stable. Thus need to be carefully designed compared to >> debugfs which are much more flexible. > > Ok. But I don't see a problem adding these read-only files > /sfdp > /name > /jedec-id > Hmm, ok. but do add documentation please. Regards Vignesh
Re: [PATCH 2/2] mtd: spi-nor: add initial sysfs support
Hi,
On 3/18/21 2:54 PM, Michael Walle wrote:
> Add support to show the name and JEDEC identifier as well as to dump the
> SFDP table. Not all flashes list their SFDP table contents in their
> datasheet. So having that is useful. It might also be helpful in bug
> reports from users.
>
Sorry for the delay..
There is already debugfs support for dumping JEDEC ID [1]. Any reason to
add sysfs entry as well?
That brings up another question. Since SFDP dumps are more of a debug
aid, should this be a debugfs entry rather than sysfs entry?
Note that sysfs entries are userspace ABIs just like syscalls and thus
need to be documented in Documentation/ABI/testing/ or
Documentation/ABI/stable. Thus need to be carefully designed compared to
debugfs which are much more flexible.
[1]drivers/mtd/spi-nor/core.c 3380
Regards
Vignesh
> The idea behind the sysfs module is also to have raw access to the SPI
> NOR flash device registers, which can also be useful for debugging.
>
> Signed-off-by: Michael Walle
> ---
> drivers/mtd/spi-nor/Makefile | 2 +-
> drivers/mtd/spi-nor/core.c | 5 +++
> drivers/mtd/spi-nor/core.h | 3 ++
> drivers/mtd/spi-nor/sysfs.c | 86
> 4 files changed, 95 insertions(+), 1 deletion(-)
> create mode 100644 drivers/mtd/spi-nor/sysfs.c
>
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 653923896205..aff308f75987 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,6 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0
>
> -spi-nor-objs := core.o sfdp.o
> +spi-nor-objs := core.o sfdp.o sysfs.o
> spi-nor-objs += atmel.o
> spi-nor-objs += catalyst.o
> spi-nor-objs += eon.o
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 4a315cb1c4db..2eaf4ba8c0f3 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3707,6 +3707,10 @@ static int spi_nor_probe(struct spi_mem *spimem)
> if (ret)
> return ret;
>
> + ret = spi_nor_sysfs_create(nor);
> + if (ret)
> + return ret;
> +
> return mtd_device_register(>mtd, data ? data->parts : NULL,
> data ? data->nr_parts : 0);
> }
> @@ -3716,6 +3720,7 @@ static int spi_nor_remove(struct spi_mem *spimem)
> struct spi_nor *nor = spi_mem_get_drvdata(spimem);
>
> spi_nor_restore(nor);
> + spi_nor_sysfs_remove(nor);
>
> /* Clean up MTD stuff. */
> return mtd_device_unregister(>mtd);
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index 668f22011b1d..dd592f7b62d1 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -488,4 +488,7 @@ static struct spi_nor __maybe_unused
> *mtd_to_spi_nor(struct mtd_info *mtd)
> return mtd->priv;
> }
>
> +int spi_nor_sysfs_create(struct spi_nor *nor);
> +void spi_nor_sysfs_remove(struct spi_nor *nor);
> +
> #endif /* __LINUX_MTD_SPI_NOR_INTERNAL_H */
> diff --git a/drivers/mtd/spi-nor/sysfs.c b/drivers/mtd/spi-nor/sysfs.c
> new file mode 100644
> index ..0de031e246c5
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/sysfs.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "core.h"
> +
> +static ssize_t name_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct spi_device *spi = to_spi_device(dev);
> + struct spi_mem *spimem = spi_get_drvdata(spi);
> + struct spi_nor *nor = spi_mem_get_drvdata(spimem);
> +
> + return sprintf(buf, "%s\n", nor->info->name);
> +}
> +static DEVICE_ATTR_RO(name);
> +
> +static ssize_t jedec_id_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct spi_device *spi = to_spi_device(dev);
> + struct spi_mem *spimem = spi_get_drvdata(spi);
> + struct spi_nor *nor = spi_mem_get_drvdata(spimem);
> +
> + return sprintf(buf, "%*phN\n", nor->info->id_len, nor->info->id);
> +}
> +static DEVICE_ATTR_RO(jedec_id);
> +
> +static struct attribute *spi_nor_sysfs_entries[] = {
> + _attr_name.attr,
> + _attr_jedec_id.attr,
> + NULL
> +};
> +
> +static ssize_t sfdp_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *bin_attr, char *buf,
> + loff_t off, size_t count)
> +{
> + struct spi_device *spi = to_spi_device(kobj_to_dev(kobj));
> + struct spi_mem *spimem = spi_get_drvdata(spi);
> + struct spi_nor *nor = spi_mem_get_drvdata(spimem);
> + struct sfdp *sfdp = nor->sfdp;
> + size_t sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
> +
> + return memory_read_from_buffer(buf, count, , nor->sfdp->dwords,
> +sfdp_size);
> +}
> +static BIN_ATTR_RO(sfdp,
Re: [PATCH 4/4] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
On 3/29/21 11:52 PM, Pratyush Yadav wrote: >>> + cdns,fifo-depth: >>> +description: >>> + Size of the data FIFO in words. >>> +$ref: "/schemas/types.yaml#/definitions/uint32" >>> +enum: [ 128, 256 ] >>> +default: 128 >>> + >>> + cdns,fifo-width: >>> +$ref: /schemas/types.yaml#/definitions/uint32 >>> +description: >>> + Bus width of the data FIFO in bytes. >>> +default: 4 >> I assume there's some constraints on this? > IIUC this is a matter of how the peripheral is implemented and there are > no clear constraints. Different implementations can use different bus > widths for the SRAM bus but I don't see any mention of minimum or > maximum values. FWIW, all users in the kernel use a 4 byte bus. > IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit wide) given this represents SRAM bus width. Binding can always be updated if there exists an implementation with higher SRAM bus width/fifo-width (although that's highly unlikely given there are no such examples today). But leaving it open ended with range of 0 to UINT_MAX sounds incorrect to me. >> With that, >> >> Reviewed-by: Rob Herring > Thanks. >
Re: [PATCH 3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav
> ---
Reviewed-by: Vignesh Raghavendra
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index b997d13f9ec5..3cbdd33384a0 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -592,7 +592,7 @@ fss: bus@fc0 {
> ranges;
>
> ospi0: spi@fc4 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x00 0x0fc4 0x00 0x100>,
> <0x05 0x 0x01 0x>;
> interrupts = ;
>
Re: [PATCH 1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav
> ---
Reviewed-by: Vignesh Raghavendra
> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> index 6c44afae9187..d56e3475aee7 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -180,7 +180,7 @@ fss: fss@4700 {
> ranges;
>
> ospi0: spi@4704 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x4704 0x0 0x100>,
> <0x5 0x 0x1 0x000>;
> interrupts = ;
> @@ -197,7 +197,7 @@ ospi0: spi@4704 {
> };
>
> ospi1: spi@4705 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x4705 0x0 0x100>,
> <0x7 0x 0x1 0x>;
> interrupts = ;
>
Re: [PATCH 2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
On 3/26/21 6:30 PM, Pratyush Yadav wrote:
> The TI specific compatible should be followed by the generic
> "cdns,qspi-nor" compatible.
>
> Signed-off-by: Pratyush Yadav
> ---
Reviewed-by: Vignesh Raghavendra
> arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> index 5408ec815d58..2ab5a7a15bd5 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> @@ -271,7 +271,7 @@ hbmc: hyperbus@47034000 {
> };
>
> ospi0: spi@4704 {
> - compatible = "ti,am654-ospi";
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> reg = <0x0 0x4704 0x0 0x100>,
> <0x5 0x 0x1 0x000>;
> interrupts = ;
>
[RESEND PATCH v2 2/2] arm64: dts: ti: k3-am64-evm/sk: Add OSPI flash DT node
Both AM64 EVM and SK have a 512Mb S28HS512T Octal SPI NOR flash.
Add DT node for the same.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Pratyush Yadav
---
Boot logs:
https://pastebin.ubuntu.com/p/VsMmyWk5SX/
https://pastebin.ubuntu.com/p/KFcMwSGxr5/
Resend:
Rebase onto latest -next
There is a warning related to dtbs_check which is because
spi-cadence-quadspi.txt is not converted to YAML.
v1: lore.kernel.org/r/20210309130514.11740-2-vigne...@ti.com
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 36 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 36 +
2 files changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 6331fd426157..9522f104d979 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -216,6 +216,22 @@ main_usb0_pins_default: main-usb0-pins-default {
AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
USB0_DRVVBUS */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -382,3 +398,23 @@ {
/* ADC is reserved for R5 usage */
status = "reserved";
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 8f9b1078b7b5..3a5bee4b0b0c 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -132,6 +132,22 @@ AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10)
PRG1_PRU1_GPO16.RGMII2_TXC */
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -248,3 +264,23 @@ cpsw3g_phy1: ethernet-phy@1 {
{
status = "disabled";
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--
2.31.0
[RESEND PATCH v2 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem
(FSS). Add DT entry for the same.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Pratyush Yadav
---
Rebase onto latest k3-dts-next
v1: lore.kernel.org/r/20210309130514.11740-1-vigne...@ti.com
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 25
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index dc852f63d1a2..a03b66456062 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -538,4 +538,29 @@ adc {
compatible = "ti,am654-adc", "ti,am3359-adc";
};
};
+
+ fss: bus@fc0 {
+ compatible = "simple-bus";
+ reg = <0x00 0x0fc0 0x00 0x7>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ospi0: spi@fc4 {
+ compatible = "ti,am654-ospi";
+ reg = <0x00 0x0fc4 0x00 0x100>,
+ <0x05 0x 0x01 0x>;
+ interrupts = ;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x0>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ clocks = <_clks 75 6>;
+ assigned-clocks = <_clks 75 6>;
+ assigned-clock-parents = <_clks 75 7>;
+ assigned-clock-rates = <1>;
+ power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
+ };
+ };
};
--
2.31.0
[RESEND PATCH] arm64: dts: ti: k3-am64-main: Add ADC nodes
AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same.
Default usecase is to control ADC from non Linux core on the system on
AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts
file. ADC lines are not pinned out on AM642 SK board, therefore disable
the node in k3-am642-sk.dts file.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Lokesh Vutla
---
Rebase onto latest k3-dts-next:
v1: lore.kernel.org/r/20210309130708.12391-1-vigne...@ti.com
Do note that dtbs_check warns about having the bindings converted to
YAML which is in my future TODO list.
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 17 +
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 5 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 4
3 files changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 7e7997e3adff..dc852f63d1a2 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -521,4 +521,21 @@ usb0: usb@f40{
dr_mode = "otg";
};
};
+
+ tscadc0: tscadc@28001000 {
+ compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+ reg = <0x00 0x28001000 0x00 0x1000>;
+ interrupts = ;
+ power-domains = <_pds 0 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 0 0>;
+ assigned-clocks = <_clks 0 0>;
+ assigned-clock-parents = <_clks 0 3>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am654-adc", "ti,am3359-adc";
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 1365e3164294..6331fd426157 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -377,3 +377,8 @@ cpsw3g_phy0: ethernet-phy@0 {
ti,fifo-depth = ;
};
};
+
+ {
+ /* ADC is reserved for R5 usage */
+ status = "reserved";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 397ed3b2e121..8f9b1078b7b5 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -244,3 +244,7 @@ cpsw3g_phy1: ethernet-phy@1 {
ti,fifo-depth = ;
};
};
+
+ {
+ status = "disabled";
+};
--
2.31.0
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/17/21 2:35 PM, Pratyush Yadav wrote: > On 17/03/21 06:09AM, tudor.amba...@microchip.com wrote: >> On 3/15/21 8:23 AM, Vignesh Raghavendra wrote: >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >>> content is safe >>> >>> On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: >>>> On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: >>>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know >>>>> the content is safe >>>>> >>>>> On 3/6/21 3:20 PM, Tudor Ambarus wrote: >>>>>> It makes the core file a bit smaller and provides better separation >>>>>> between the Software Write Protection features and the core logic. >>>>>> All the next generic software write protection features (e.g. Individual >>>>>> Block Protection) will reside in swp.c. >>>>>> >>>>>> Signed-off-by: Tudor Ambarus >>>>>> --- >>>>>> drivers/mtd/spi-nor/Makefile | 2 +- >>>>>> drivers/mtd/spi-nor/core.c | 407 +- >>>>>> drivers/mtd/spi-nor/core.h | 4 + >>>>>> drivers/mtd/spi-nor/swp.c| 419 +++ >>>>> >>>>> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a >>>>> bit: >>>>> >>>>> soft-wr-protect.c or software-write-protect.c ? >> >> Having in mind that we have the SWP configs, I think I prefer swp.c. >> But let's see what majority thinks, we'll do as majority prefers. >> Michael, Pratyush? > > I don't have much of an opinion on this tbh. But I usually prefer short > names so I'd go with swp.c here. Maybe also add a comment at the top of > the file mentioning the full name "Software Write Protection logic" or > something similar for clarification. > I don't have hard objection to swp.c. As Pratyush suggested, a comment at top of the file indicating the purpose would be good to have.
[RESEN DPATCH 2/2] arm64: dts: ti: k3-am642-evm/sk: Add OSPI flash DT node
Both AM64 EVM and SK have a 512Mb S28HS512T Octal SPI NOR flash.
Add DT node for the same.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Pratyush Yadav
---
Boot logs:
https://pastebin.ubuntu.com/p/mNG7ryv3w6/
https://pastebin.ubuntu.com/p/TZf9ZwSqqM/
Resend:
Rebase onto latest -next
There is a warning related to dtbs_check which is because
spi-cadence-quadspi.txt is not converted to YAML.
v1: lore.kernel.org/r/20210309130514.11740-2-vigne...@ti.com
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 36 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 36 +
2 files changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 188f0eb687fb..2f187555d04a 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -210,6 +210,22 @@ AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10)
PRG1_PRU1_GPO16.RGMII2_TXC */
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -364,3 +380,23 @@ {
/* ADC is reserved for R5 usage */
status = "reserved";
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index 8f9b1078b7b5..3a5bee4b0b0c 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -132,6 +132,22 @@ AM64X_IOPAD(0x0148, PIN_OUTPUT, 4) /* (Y10)
PRG1_PRU1_GPO16.RGMII2_TXC */
AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
PRG1_PRU1_GPO15.RGMII2_TX_CTL */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -248,3 +264,23 @@ cpsw3g_phy1: ethernet-phy@1 {
{
status = "disabled";
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--
2.30.2
[RESEND PATCH 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem
(FSS). Add DT entry for the same.
Signed-off-by: Vignesh Raghavendra
Reviewed-by: Pratyush Yadav
---
Resend:
Rebase onto latest -next
v1: lore.kernel.org/r/20210309130514.11740-1-vigne...@ti.com
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 25
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 1f33b8d0080b..d914a58680aa 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -508,4 +508,29 @@ adc {
compatible = "ti,am654-adc", "ti,am3359-adc";
};
};
+
+ fss: bus@fc0 {
+ compatible = "simple-bus";
+ reg = <0x00 0x0fc0 0x00 0x7>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ospi0: spi@fc4 {
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
+ reg = <0x00 0x0fc4 0x00 0x100>,
+ <0x05 0x 0x01 0x>;
+ interrupts = ;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x0>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ clocks = <_clks 75 6>;
+ assigned-clocks = <_clks 75 6>;
+ assigned-clock-parents = <_clks 75 7>;
+ assigned-clock-rates = <1>;
+ power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
+ };
+ };
};
--
2.30.2
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/9/21 12:58 PM, tudor.amba...@microchip.com wrote: > On 3/8/21 7:28 PM, Vignesh Raghavendra wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> On 3/6/21 3:20 PM, Tudor Ambarus wrote: >>> It makes the core file a bit smaller and provides better separation >>> between the Software Write Protection features and the core logic. >>> All the next generic software write protection features (e.g. Individual >>> Block Protection) will reside in swp.c. >>> >>> Signed-off-by: Tudor Ambarus >>> --- >>> drivers/mtd/spi-nor/Makefile | 2 +- >>> drivers/mtd/spi-nor/core.c | 407 +- >>> drivers/mtd/spi-nor/core.h | 4 + >>> drivers/mtd/spi-nor/swp.c| 419 +++ >> >> Hmmm, name swp.c does not seem intuitive to me. How about expanding it a >> bit: >> >> soft-wr-protect.c or software-write-protect.c ? >> > > I thought about the SWP configs that we have. > > How about keeping swp.c and rename configs to: > s/MTD_SPI_NOR_SWP_DISABLE/MTD_SPI_NOR_DISABLE_BOOT_SWP > s/MTD_SPI_NOR_SWP_DISABLE_ON_VOLATILE/MTD_SPI_DISABLE_BOOT_SWP_ON_VOLATILE > s/MTD_SPI_NOR_SWP_KEEP/MTD_SPI_NOR_KEEP_BOOT_SWP > > The renamed configs should better indicate that the software write protection > is disabled just at boot time, while the locking support is still enabled. > Otherwise one may think that with a MTD_SPI_NOR_SWP_DISABLE, all the > software write protection features are stripped/not available. > I am not a fan of renaming Kconfig options as it breaks make olddefconfig flow which many developers rely on. Regards Vignesh
Re: [PATCH RESEND][next] mtd: cfi: Fix fall-through warnings for Clang
On 3/5/21 1:49 PM, Gustavo A. R. Silva wrote: > In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple > warnings by explicitly adding multiple break statements and a return > instead of letting the code fall through to the next case. > > Link: https://github.com/KSPP/linux/issues/115 > Signed-off-by: Gustavo A. R. Silva > --- Acked-by: Vignesh Raghavendra Miquel, Feel free to queue this via mtd/next Regards Vignesh [...]
Re: [PATCH 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
Hi Nishanth
On 3/9/21 6:35 PM, Vignesh Raghavendra wrote:
> AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem
> (FSS). Add DT entry for the same.
>
> Signed-off-by: Vignesh Raghavendra
> ---
Please ignore the series. I see some instabilities in my testing... Will
repost once I have addressed them. Sorry for the noise.
Regards
Vignesh
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 25
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> index 5f85950daef7..bcec4fa444b5 100644
> --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -402,4 +402,29 @@ sdhci1: mmc@fa0 {
> ti,otap-del-sel-ddr50 = <0x9>;
> ti,clkbuf-sel = <0x7>;
> };
> +
> + fss: bus@fc0 {
> + compatible = "simple-bus";
> + reg = <0x00 0x0fc0 0x00 0x7>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + ospi0: spi@fc4 {
> + compatible = "ti,am654-ospi", "cdns,qspi-nor";
> + reg = <0x00 0x0fc4 0x00 0x100>,
> + <0x05 0x 0x01 0x>;
> + interrupts = ;
> + cdns,fifo-depth = <256>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x0>;
> + #address-cells = <0x1>;
> + #size-cells = <0x0>;
> + clocks = <_clks 75 6>;
> + assigned-clocks = <_clks 75 6>;
> + assigned-clock-parents = <_clks 75 7>;
> + assigned-clock-rates = <1>;
> + power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
> + };
> + };
> };
>
Re: [PATCH] arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM
On 3/1/21 11:35 AM, Aswath Govindraju wrote:
> Add pinmux details and device tree node for the EEPROM attached to SPI0
> module in main domain.
>
> Signed-off-by: Aswath Govindraju
> ---
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
>
> This patch depends on,
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210301055109.17626-3-a-govindr...@ti.com/
>
> arch/arm64/boot/dts/ti/k3-am642-evm.dts | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> index bfd849a29655..bc5bd7f896ab 100644
> --- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
> @@ -139,6 +139,15 @@
> AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (E19)
> USB0_DRVVBUS */
> >;
> };
> +
> + main_spi0_pins_default: main-spi0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0210, PIN_INPUT, 0) /* (D13) SPI0_CLK */
> + AM64X_IOPAD(0x0208, PIN_OUTPUT, 0) /* (D12) SPI0_CS0 */
> + AM64X_IOPAD(0x0214, PIN_OUTPUT, 0) /* (A13) SPI0_D0 */
> + AM64X_IOPAD(0x0218, PIN_INPUT, 0) /* (A14) SPI0_D1 */
> + >;
> + };
> };
>
> _uart0 {
> @@ -245,6 +254,19 @@
> pinctrl-0 = <_usb0_pins_default>;
> };
>
> +_spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi0_pins_default>;
> + ti,pindir-d0-out-d1-in = <1>;
> + eeprom@0 {
> + compatible = "microchip,93lc46b";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cs-high;
> + data-size = <16>;
> + };
> +};
> +
> {
> /* emmc */
> bus-width = <8>;
>
[PATCH] arm64: dts: ti: k3-am64-main: Add ADC nodes
AM64 SoC has a single ADC IP with 8 channels. Add DT node for the same.
Default usecase is to control ADC from non Linux core on the system on
AM642 GP EVM, therefore mark the node as reserved in k3-am642-evm.dts
file. ADC lines are not pinned out on AM642 SK board, therefore disable
the node in k3-am642-sk.dts file.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 17 +
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 5 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 4
3 files changed, 26 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index bcec4fa444b5..1bb1e292547d 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -427,4 +427,21 @@ ospi0: spi@fc4 {
power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
};
};
+
+ tscadc0: tscadc@28001000 {
+ compatible = "ti,am654-tscadc", "ti,am3359-tscadc";
+ reg = <0x00 0x28001000 0x00 0x1000>;
+ interrupts = ;
+ power-domains = <_pds 0 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 0 0>;
+ assigned-clocks = <_clks 0 0>;
+ assigned-clock-parents = <_clks 0 3>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am654-adc", "ti,am3359-adc";
+ };
+ };
};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 7dd8e94b108d..7154d34faf4c 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -280,3 +280,8 @@ flash@0{
#size-cells = <1>;
};
};
+
+ {
+ /* ADC is reserved for R5 usage */
+ status = "reserved";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index fc27470fc083..28059f07bef1 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -207,3 +207,7 @@ flash@0{
#size-cells = <1>;
};
};
+
+ {
+ status = "disabled";
+};
--
2.30.1
[PATCH 2/2] arm64: dts: ti: k3-am64-evm/sk: Add OSPI flash DT node
Both AM64 EVM and SK have a 512Mb S28HS512T Octal SPI NOR flash.
Add DT node for the same.
Signed-off-by: Vignesh Raghavendra
---
Bootlog:
SK: https://pastebin.ubuntu.com/p/gvxg7cFrXH/
EVM: https://pastebin.ubuntu.com/p/jb39GqkB78/
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 36 +
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 36 +
2 files changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index 1f1787750fef..7dd8e94b108d 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
@@ -133,6 +133,22 @@ AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18) I2C1_SCL
*/
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19)
I2C1_SDA */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -244,3 +260,23 @@ {
ti,driver-strength-ohm = <50>;
disable-wp;
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index aa6ca4c49153..fc27470fc083 100644
--- a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
@@ -90,6 +90,22 @@ AM64X_IOPAD(0x0268, PIN_INPUT_PULLUP, 0) /* (C18) I2C1_SCL */
AM64X_IOPAD(0x026c, PIN_INPUT_PULLUP, 0) /* (B19)
I2C1_SDA */
>;
};
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x, PIN_OUTPUT, 0) /* (N20) OSPI0_CLK */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* (L19) OSPI0_CSn0
*/
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* (M19) OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* (M18) OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* (M20) OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* (M21) OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* (P21) OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* (P20) OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* (N18) OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* (M17) OSPI0_D7 */
+ AM64X_IOPAD(0x0008, PIN_INPUT, 0) /* (N19) OSPI0_DQS */
+ >;
+ };
};
_uart0 {
@@ -171,3 +187,23 @@ {
ti,driver-strength-ohm = <50>;
disable-wp;
};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_default>;
+
+ flash@0{
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2500>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
--
2.30.1
[PATCH 1/2] arm64: dts: ti: k3-am64-main: Add OSPI node
AM64 SoC has a single Octal SPI (OSPI) instance under Flash SubSystem
(FSS). Add DT entry for the same.
Signed-off-by: Vignesh Raghavendra
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 25
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 5f85950daef7..bcec4fa444b5 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -402,4 +402,29 @@ sdhci1: mmc@fa0 {
ti,otap-del-sel-ddr50 = <0x9>;
ti,clkbuf-sel = <0x7>;
};
+
+ fss: bus@fc0 {
+ compatible = "simple-bus";
+ reg = <0x00 0x0fc0 0x00 0x7>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ospi0: spi@fc4 {
+ compatible = "ti,am654-ospi", "cdns,qspi-nor";
+ reg = <0x00 0x0fc4 0x00 0x100>,
+ <0x05 0x 0x01 0x>;
+ interrupts = ;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x0>;
+ #address-cells = <0x1>;
+ #size-cells = <0x0>;
+ clocks = <_clks 75 6>;
+ assigned-clocks = <_clks 75 6>;
+ assigned-clock-parents = <_clks 75 7>;
+ assigned-clock-rates = <1>;
+ power-domains = <_pds 75 TI_SCI_PD_EXCLUSIVE>;
+ };
+ };
};
--
2.30.1
Re: [PATCH v2 4/5] mtd: spi-nor: Move Software Write Protection logic out of the core
On 3/6/21 3:20 PM, Tudor Ambarus wrote: > It makes the core file a bit smaller and provides better separation > between the Software Write Protection features and the core logic. > All the next generic software write protection features (e.g. Individual > Block Protection) will reside in swp.c. > > Signed-off-by: Tudor Ambarus > --- > drivers/mtd/spi-nor/Makefile | 2 +- > drivers/mtd/spi-nor/core.c | 407 +- > drivers/mtd/spi-nor/core.h | 4 + > drivers/mtd/spi-nor/swp.c| 419 +++ Hmmm, name swp.c does not seem intuitive to me. How about expanding it a bit: soft-wr-protect.c or software-write-protect.c ? Regards Vignesh
Re: [PATCH] mtd: add OTP (one-time-programmable) erase ioctl
On 3/4/21 1:48 AM, Michael Walle wrote: > This may sound like a contradiction but some SPI-NOR flashes really > support erasing their OTP region until it is finally locked. Having the > possibility to erase an OTP region might come in handy during > development. > > The ioctl argument follows the OTPLOCK style. > > Signed-off-by: Michael Walle > --- Acked-by: Vignesh Raghavendra [...] Regards Vignesh
Re: [PATCH] MAINTAINERS: Add Michael and Pratyush as designated reviewers for SPI NOR
On 3/8/21 2:53 PM, Tudor Ambarus wrote: > It's already been the case for some time that Michael and Pratyush > are reviewing SPI NOR patches. Update MAINTAINERS to reflect reality. > > Signed-off-by: Tudor Ambarus > --- Acked-by: Vignesh Raghavendra > Michael, Pratyush, please send your Acked-by tags if you agree. > > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index d92f85ca831d..ba561e5bc6f0 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -16862,6 +16862,8 @@ F:arch/arm/mach-spear/ > > SPI NOR SUBSYSTEM > M: Tudor Ambarus > +R: Michael Walle > +R: Pratyush Yadav > L: linux-...@lists.infradead.org > S: Maintained > W: http://www.linux-mtd.infradead.org/ >
Re: [PATCH v1 1/1] mtd: spi-nor: intel-spi: Move platform data header to x85 subfolder
On 3/4/21 7:38 PM, Andy Shevchenko wrote:
> In order to group x86 related platform data move intel-spi.h to x85 folder.
>
> While at it, remove duplicate inclusion in C file.
>
> Signed-off-by: Andy Shevchenko
> ---
Nit, typo in $subject and commit message: s/x85/x86. Tudor may be able
to fix it locally while applying.
Apart from that
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> drivers/mtd/spi-nor/controllers/intel-spi.c | 1 -
> drivers/mtd/spi-nor/controllers/intel-spi.h | 2 +-
> include/linux/mfd/lpc_ich.h | 2 +-
> include/linux/platform_data/{ => x86}/intel-spi.h | 0
> 4 files changed, 2 insertions(+), 3 deletions(-)
> rename include/linux/platform_data/{ => x86}/intel-spi.h (100%)
>
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.c
> b/drivers/mtd/spi-nor/controllers/intel-spi.c
> index b54a56a68100..a413892ff449 100644
> --- a/drivers/mtd/spi-nor/controllers/intel-spi.c
> +++ b/drivers/mtd/spi-nor/controllers/intel-spi.c
> @@ -15,7 +15,6 @@
> #include
> #include
> #include
> -#include
>
> #include "intel-spi.h"
>
> diff --git a/drivers/mtd/spi-nor/controllers/intel-spi.h
> b/drivers/mtd/spi-nor/controllers/intel-spi.h
> index e2f41b8827bf..f2871179fd34 100644
> --- a/drivers/mtd/spi-nor/controllers/intel-spi.h
> +++ b/drivers/mtd/spi-nor/controllers/intel-spi.h
> @@ -9,7 +9,7 @@
> #ifndef INTEL_SPI_H
> #define INTEL_SPI_H
>
> -#include
> +#include
>
> struct intel_spi;
> struct resource;
> diff --git a/include/linux/mfd/lpc_ich.h b/include/linux/mfd/lpc_ich.h
> index 6ddca2bbb3a8..39967a5eca6d 100644
> --- a/include/linux/mfd/lpc_ich.h
> +++ b/include/linux/mfd/lpc_ich.h
> @@ -8,7 +8,7 @@
> #ifndef LPC_ICH_H
> #define LPC_ICH_H
>
> -#include
> +#include
>
> /* GPIO resources */
> #define ICH_RES_GPIO 0
> diff --git a/include/linux/platform_data/intel-spi.h
> b/include/linux/platform_data/x86/intel-spi.h
> similarity index 100%
> rename from include/linux/platform_data/intel-spi.h
> rename to include/linux/platform_data/x86/intel-spi.h
>
Re: [PATCH v2 3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
On 3/5/21 9:09 PM, Pratyush Yadav wrote:
> TI J7200 has the Cadence OSPI controller for interfacing with OSPI
> flashes. Add its node to allow using SPI flashes.
>
> Signed-off-by: Pratyush Yadav
> ---
Reviewed-by: Vignesh Raghavendra
>
> Notes:
> Changes in v2:
> - Do not force a pulldown on the DQS line because it already has a
> pulldown resistor.
>
> .../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 17 +
> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 36 +++
> 2 files changed, 53 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> index 359e3e8a8cd0..5408ec815d58 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
> @@ -269,6 +269,23 @@ hbmc: hyperbus@47034000 {
> #size-cells = <1>;
> mux-controls = <_mux 0>;
> };
> +
> + ospi0: spi@4704 {
> + compatible = "ti,am654-ospi";
> + reg = <0x0 0x4704 0x0 0x100>,
> + <0x5 0x 0x1 0x000>;
> + interrupts = ;
> + cdns,fifo-depth = <256>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x0>;
> + clocks = <_clks 103 0>;
> + assigned-clocks = <_clks 103 0>;
> + assigned-clock-parents = <_clks 103 2>;
> + assigned-clock-rates = <1>;
> + power-domains = <_pds 103 TI_SCI_PD_EXCLUSIVE>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> };
>
> tscadc0: tscadc@4020 {
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> index a988e2ab2ba1..34724440171a 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> @@ -100,6 +100,22 @@ J721E_WKUP_IOPAD(0x24, PIN_INPUT, 1) /* (A8)
> MCU_OSPI0_D6.MCU_HYPERBUS0_DQ6 */
> J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
> MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
> >;
> };
> +
> + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
> + pinctrl-single,pins = <
> + J721E_WKUP_IOPAD(0x, PIN_OUTPUT, 0) /*
> MCU_OSPI0_CLK */
> + J721E_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0) /*
> MCU_OSPI0_CSn0 */
> + J721E_WKUP_IOPAD(0x000c, PIN_INPUT, 0) /* MCU_OSPI0_D0
> */
> + J721E_WKUP_IOPAD(0x0010, PIN_INPUT, 0) /* MCU_OSPI0_D1
> */
> + J721E_WKUP_IOPAD(0x0014, PIN_INPUT, 0) /* MCU_OSPI0_D2
> */
> + J721E_WKUP_IOPAD(0x0018, PIN_INPUT, 0) /* MCU_OSPI0_D3
> */
> + J721E_WKUP_IOPAD(0x001c, PIN_INPUT, 0) /* MCU_OSPI0_D4
> */
> + J721E_WKUP_IOPAD(0x0020, PIN_INPUT, 0) /* MCU_OSPI0_D5
> */
> + J721E_WKUP_IOPAD(0x0024, PIN_INPUT, 0) /* MCU_OSPI0_D6
> */
> + J721E_WKUP_IOPAD(0x0028, PIN_INPUT, 0) /* MCU_OSPI0_D7
> */
> + J721E_WKUP_IOPAD(0x0008, PIN_INPUT, 0) /*
> MCU_OSPI0_DQS */
> + >;
> + };
> };
>
> _pmx0 {
> @@ -235,3 +251,23 @@ exp_som: gpio@21 {
> "GPIO_LIN_EN", "CAN_STB";
> };
> };
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_fss0_ospi0_pins_default>;
> +
> + flash@0{
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-tx-bus-width = <8>;
> + spi-rx-bus-width = <8>;
> + spi-max-frequency = <2500>;
> + cdns,tshsl-ns = <60>;
> + cdns,tsd2d-ns = <60>;
> + cdns,tchsh-ns = <60>;
> + cdns,tslch-ns = <60>;
> + cdns,read-delay = <4>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> +};
>
Re: [PATCH v2 2/3] arm64: dts: ti: am654-base-board: Enable 8D-8D-8D mode on OSPI
On 3/5/21 9:09 PM, Pratyush Yadav wrote:
> Set the Tx bus width to 8 so 8D-8D-8D mode can be selected. Change the
> frequency to 25 MHz. This is the frequency that the flash has been
> successfully tested with in Octal DTR mode. The total performance should
> still increase since 8D-8D-8D mode should be at least twice as fast as
> 1S-1S-8S mode.
>
> Signed-off-by: Pratyush Yadav
> ---
>
Reviewed-by: Vignesh Raghavendra
> Notes:
> No changes in v2.
>
> arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> index fe3043943906..9e87fb313a54 100644
> --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
> @@ -483,9 +483,9 @@ {
> flash@0{
> compatible = "jedec,spi-nor";
> reg = <0x0>;
> - spi-tx-bus-width = <1>;
> + spi-tx-bus-width = <8>;
> spi-rx-bus-width = <8>;
> - spi-max-frequency = <4000>;
> + spi-max-frequency = <2500>;
> cdns,tshsl-ns = <60>;
> cdns,tsd2d-ns = <60>;
> cdns,tchsh-ns = <60>;
>
Re: [PATCH v2 1/3] arm64: dts: ti: k3-j721e-som-p0: Enable 8D-8D-8D mode on OSPI
On 3/5/21 9:09 PM, Pratyush Yadav wrote:
> Set the Tx bus width to 8 so 8D-8D-8D mode can be selected. Change the
> frequency to 25 MHz. This is the frequency that the flash has been
> successfully tested with in Octal DTR mode. The total performance should
> still increase since 8D-8D-8D mode should be at least twice as fast as
> 1S-1S-8S mode.
>
> Signed-off-by: Pratyush Yadav
> ---
>
Reviewed-by: Vignesh Raghavendra
> Notes:
> No changes in v2.
>
> arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
> b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
> index 57720e6a04c5..2fee2906183d 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-som-p0.dtsi
> @@ -174,9 +174,9 @@ {
> flash@0{
> compatible = "jedec,spi-nor";
> reg = <0x0>;
> - spi-tx-bus-width = <1>;
> + spi-tx-bus-width = <8>;
> spi-rx-bus-width = <8>;
> - spi-max-frequency = <4000>;
> + spi-max-frequency = <2500>;
> cdns,tshsl-ns = <60>;
> cdns,tsd2d-ns = <60>;
> cdns,tchsh-ns = <60>;
>
Re: [PATCH v2 3/4] arm64: dts: ti: Add support for Siemens IOT2050 boards
Hi,
On 2/12/21 1:02 AM, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Add support for two Siemens SIMATIC IOT2050 variants, Basic and
> Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
> differ in their number of cores and availability of security features.
> Furthermore the Advanced version comes with more RAM, an eMMC and a few
> internal differences.
>
> Based on original version by Le Jin.
>
> Link:
> https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
> Link: https://github.com/siemens/meta-iot2050
> Signed-off-by: Jan Kiszka
Reviewed-by: Vignesh Raghavendra
Few minor comments below:
[...]
> +
> +_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + psu: tps62363@60 {
Please use generic node names:
psu: regulator@60 { ... };
> + compatible = "ti,tps62363";
> + reg = <0x60>;
> + regulator-name = "tps62363-vout";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <150>;
> + regulator-boot-on;
> + ti,vsel0-state-high;
> + ti,vsel1-state-high;
> + ti,enable-vout-discharge;
> + };
> +
> + /* D4200 */
> + pcal9535_1: gpio@20 {
> + compatible = "nxp,pcal9535";
> + reg = <0x20>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull",
> + "A5-pull", "", "",
> + "IO14-enable", "IO15-enable", "IO16-enable",
> + "IO17-enable", "IO18-enable", "IO19-enable";
> + };
> +
> + /* D4201 */
> + pcal9535_2: gpio@21 {
> + compatible = "nxp,pcal9535";
> + reg = <0x21>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "IO0-direction", "IO1-direction", "IO2-direction",
> + "IO3-direction", "IO4-direction", "IO5-direction",
> + "IO6-direction", "IO7-direction",
> + "IO8-direction", "IO9-direction", "IO10-direction",
> + "IO11-direction", "IO12-direction", "IO13-direction",
> + "IO19-direction";
> + };
> +
> + /* D4202 */
> + pcal9535_3: gpio@25 {
> + compatible = "nxp,pcal9535";
> + reg = <0x25>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + gpio-line-names =
> + "IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull",
> + "IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull",
> + "IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull",
> + "IO12-pull", "IO13-pull";
> + };
> +};
[...]
> +_0 {
> + status = "okay";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
These nodes are enabled by default right? Above is redundant.
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> + dr_mode = "host";
> +};
> +
> +_1 {
> + status = "okay";
> +};
> +
> +_phy {
> + status = "okay";
> +};
> +
Same here...
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins_default>;
> + dr_mode = "host";
> +};
> +
[...]
> +_spi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi0_pins_default>;
> +
> + #address-cells = <1>;
> + #size-cells= <0>;
> + ti,pindir-d0-out-d1-in = <1>;
> +
> + spidev@0 {
> + compatible = "rohm,dh2228fv";
> + spi-max-frequency = <2000>;
> + reg = <0>;
> + };
Is the device really dh2228fv?
> +};
> +
> + {
> + status = "disabled";
> +};
> +
> + {
Re: [PATCH v2 2/4] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
On 2/12/21 1:02 AM, Jan Kiszka wrote: > From: Jan Kiszka > > These boards are based on AM6528 GP and AM6548 HS SOCs. > > Signed-off-by: Jan Kiszka Reviewed-by: Vignesh Raghavendra > --- > Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml > b/Documentation/devicetree/bindings/arm/ti/k3.yaml > index c6e1c1e63e43..b1ab0cf4a2d6 100644 > --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml > +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml > @@ -23,6 +23,8 @@ properties: > items: >- enum: >- ti,am654-evm > + - siemens,iot2050-basic > + - siemens,iot2050-advanced >- const: ti,am654 > >- description: K3 J721E SoC >
Re: [RFC PATCH] mtd: add OTP (one-time-programmable) erase ioctl
On 3/2/21 9:49 PM, Michael Walle wrote:
> Am 2021-03-02 16:30, schrieb Vignesh Raghavendra:
>> Hi,
>>
>> On 3/2/21 4:39 PM, Michael Walle wrote:
>>> This may sound like a contradiction but some SPI-NOR flashes really
>>> support erasing their OTP region until it is finally locked. Having the
>>> possibility to erase an OTP region might come in handy during
>>> development.
>>>
>>> The ioctl argument follows the OTPLOCK style.
>>>
>>> Signed-off-by: Michael Walle
>>> ---
>>> OTP support for SPI-NOR flashes may be merged soon:
>>> https://lore.kernel.org/linux-mtd/20210216162807.13509-1-mich...@walle.cc/
>>>
>>>
>>> Tudor suggested to add support for the OTP erase operation most SPI-NOR
>>> flashes have:
>>> https://lore.kernel.org/linux-mtd/d4f74b1b-fa1b-97ec-858c-d807fe1f9...@microchip.com/
>>>
>>>
>>> Therefore, this is an RFC to get some feedback on the MTD side, once
>>> this
>>> is finished, I can post a patch for mtd-utils. Then we'll have a
>>> foundation
>>> to add the support to SPI-NOR.
>>>
>>> drivers/mtd/mtdchar.c | 7 ++-
>>> drivers/mtd/mtdcore.c | 12
>>> include/linux/mtd/mtd.h | 3 +++
>>> include/uapi/mtd/mtd-abi.h | 2 ++
>>> 4 files changed, 23 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
>>> index 323035d4f2d0..da423dd031ae 100644
>>> --- a/drivers/mtd/mtdchar.c
>>> +++ b/drivers/mtd/mtdchar.c
>>> @@ -661,6 +661,7 @@ static int mtdchar_ioctl(struct file *file, u_int
>>> cmd, u_long arg)
>>> case OTPGETREGIONCOUNT:
>>> case OTPGETREGIONINFO:
>>> case OTPLOCK:
>>> + case OTPERASE:
>>
>> This is not a Safe IOCTL. We are destroying OTP data. Need to check for
>> write permission before allowing the ioctl right?
>
> Ah yes, of course. But this makes me wonder why OTPLOCK
> is considered a safe command. As well as MEMLOCK and
> MEMUNLOCK. And MEMSETBADBLOCK. Shouldn't these also
> require write permissions?
>
Well, one argument would be that LOCK/UNLOCK in itself won't modify data
and thus does not need write permission.. Although can brick a flash
from ever being writable again and change content of flash registers.
I am fine with moving these to require write permissions as well
(probably OTPLOCK as well).
[...]
>>> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
>>> index 65b9db936557..242015f60d10 100644
>>> --- a/include/uapi/mtd/mtd-abi.h
>>> +++ b/include/uapi/mtd/mtd-abi.h
>>> @@ -205,6 +205,8 @@ struct otp_info {
>>> * without OOB, e.g., NOR flash.
>>> */
>>> #define MEMWRITE _IOWR('M', 24, struct mtd_write_req)
>>> +/* Erase a given range of user data (must be in mode
>>> %MTD_FILE_MODE_OTP_USER) */
>>> +#define OTPERASE _IOR('M', 25, struct otp_info)
>>>
>>
>> Hmm, shouldn't this be:
>>
>> #define OTPERASE _IOW('M', 25, struct otp_info)
>>
>> Userspace is writing struct otp_info to the driver. OTPLOCK should
>> probably be _IOW() as well.
>
> You're right.
>
> NB. most OTP commands have a wrong direction flag.
>
Unfortunately, yes :(
Regards
Vignesh
Re: [RFC PATCH] mtd: add OTP (one-time-programmable) erase ioctl
Hi,
On 3/2/21 4:39 PM, Michael Walle wrote:
> This may sound like a contradiction but some SPI-NOR flashes really
> support erasing their OTP region until it is finally locked. Having the
> possibility to erase an OTP region might come in handy during
> development.
>
> The ioctl argument follows the OTPLOCK style.
>
> Signed-off-by: Michael Walle
> ---
> OTP support for SPI-NOR flashes may be merged soon:
> https://lore.kernel.org/linux-mtd/20210216162807.13509-1-mich...@walle.cc/
>
> Tudor suggested to add support for the OTP erase operation most SPI-NOR
> flashes have:
> https://lore.kernel.org/linux-mtd/d4f74b1b-fa1b-97ec-858c-d807fe1f9...@microchip.com/
>
> Therefore, this is an RFC to get some feedback on the MTD side, once this
> is finished, I can post a patch for mtd-utils. Then we'll have a foundation
> to add the support to SPI-NOR.
>
> drivers/mtd/mtdchar.c | 7 ++-
> drivers/mtd/mtdcore.c | 12
> include/linux/mtd/mtd.h| 3 +++
> include/uapi/mtd/mtd-abi.h | 2 ++
> 4 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 323035d4f2d0..da423dd031ae 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -661,6 +661,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd,
> u_long arg)
> case OTPGETREGIONCOUNT:
> case OTPGETREGIONINFO:
> case OTPLOCK:
> + case OTPERASE:
This is not a Safe IOCTL. We are destroying OTP data. Need to check for
write permission before allowing the ioctl right?
> case ECCGETLAYOUT:
> case ECCGETSTATS:
> case MTDFILEMODE:
> @@ -938,6 +939,7 @@ static int mtdchar_ioctl(struct file *file, u_int cmd,
> u_long arg)
> }
>
> case OTPLOCK:
> + case OTPERASE:
> {
> struct otp_info oinfo;
>
> @@ -945,7 +947,10 @@ static int mtdchar_ioctl(struct file *file, u_int cmd,
> u_long arg)
> return -EINVAL;
> if (copy_from_user(, argp, sizeof(oinfo)))
> return -EFAULT;
> - ret = mtd_lock_user_prot_reg(mtd, oinfo.start, oinfo.length);
> + if (cmd == OTPLOCK)
> + ret = mtd_lock_user_prot_reg(mtd, oinfo.start,
> oinfo.length);
> + else
> + ret = mtd_erase_user_prot_reg(mtd, oinfo.start,
> oinfo.length);
> break;
> }
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 2d6423d89a17..d844d718ef77 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -1918,6 +1918,18 @@ int mtd_lock_user_prot_reg(struct mtd_info *mtd,
> loff_t from, size_t len)
> }
> EXPORT_SYMBOL_GPL(mtd_lock_user_prot_reg);
>
> +int mtd_erase_user_prot_reg(struct mtd_info *mtd, loff_t from, size_t len)
> +{
> + struct mtd_info *master = mtd_get_master(mtd);
> +
> + if (!master->_erase_user_prot_reg)
> + return -EOPNOTSUPP;
> + if (!len)
> + return 0;
> + return master->_erase_user_prot_reg(master, from, len);
> +}
> +EXPORT_SYMBOL_GPL(mtd_erase_user_prot_reg);
> +
> /* Chip-supported device locking */
> int mtd_lock(struct mtd_info *mtd, loff_t ofs, uint64_t len)
> {
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 157357ec1441..734ad7a8c353 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -336,6 +336,8 @@ struct mtd_info {
>size_t len, size_t *retlen, u_char *buf);
> int (*_lock_user_prot_reg) (struct mtd_info *mtd, loff_t from,
> size_t len);
> + int (*_erase_user_prot_reg) (struct mtd_info *mtd, loff_t from,
> + size_t len);
> int (*_writev) (struct mtd_info *mtd, const struct kvec *vecs,
> unsigned long count, loff_t to, size_t *retlen);
> void (*_sync) (struct mtd_info *mtd);
> @@ -517,6 +519,7 @@ int mtd_read_user_prot_reg(struct mtd_info *mtd, loff_t
> from, size_t len,
> int mtd_write_user_prot_reg(struct mtd_info *mtd, loff_t to, size_t len,
> size_t *retlen, u_char *buf);
> int mtd_lock_user_prot_reg(struct mtd_info *mtd, loff_t from, size_t len);
> +int mtd_erase_user_prot_reg(struct mtd_info *mtd, loff_t from, size_t len);
>
> int mtd_writev(struct mtd_info *mtd, const struct kvec *vecs,
> unsigned long count, loff_t to, size_t *retlen);
> diff --git a/include/uapi/mtd/mtd-abi.h b/include/uapi/mtd/mtd-abi.h
> index 65b9db936557..242015f60d10 100644
> --- a/include/uapi/mtd/mtd-abi.h
> +++ b/include/uapi/mtd/mtd-abi.h
> @@ -205,6 +205,8 @@ struct otp_info {
> * without OOB, e.g., NOR flash.
> */
> #define MEMWRITE _IOWR('M', 24, struct mtd_write_req)
> +/* Erase a given range of user data (must be in mode
> %MTD_FILE_MODE_OTP_USER) */
> +#define OTPERASE _IOR('M', 25, struct otp_info)
>
Hmm,
Re: [PATCH 3/3] arm64: dts: ti: k3-j7200-som-p0: Add nodes for OSPI0
On 3/2/21 1:28 AM, Pratyush Yadav wrote:
> +
> + mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
> + pinctrl-single,pins = <
> + J721E_WKUP_IOPAD(0x, PIN_OUTPUT, 0) /*
> MCU_OSPI0_CLK */
> + J721E_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0) /*
> MCU_OSPI0_CSn0 */
> + J721E_WKUP_IOPAD(0x000c, PIN_INPUT, 0) /* MCU_OSPI0_D0
> */
> + J721E_WKUP_IOPAD(0x0010, PIN_INPUT, 0) /* MCU_OSPI0_D1
> */
> + J721E_WKUP_IOPAD(0x0014, PIN_INPUT, 0) /* MCU_OSPI0_D2
> */
> + J721E_WKUP_IOPAD(0x0018, PIN_INPUT, 0) /* MCU_OSPI0_D3
> */
> + J721E_WKUP_IOPAD(0x001c, PIN_INPUT, 0) /* MCU_OSPI0_D4
> */
> + J721E_WKUP_IOPAD(0x0020, PIN_INPUT, 0) /* MCU_OSPI0_D5
> */
> + J721E_WKUP_IOPAD(0x0024, PIN_INPUT, 0) /* MCU_OSPI0_D6
> */
> + J721E_WKUP_IOPAD(0x0028, PIN_INPUT, 0) /* MCU_OSPI0_D7
> */
> + J721E_WKUP_IOPAD(0x0008, PIN_INPUT_PULLDOWN, 0) /*
> MCU_OSPI0_DQS */
> + >;
> + };
There is a pulldown resistor on the board right? So, internal pulldown
is unnecessary and may even cause conflicts.
Re: [PATCH v4 net-next 0/9] Cleanup in brport flags switchdev offload for DSA
Hi, On 2/12/21 8:10 PM, Vladimir Oltean wrote: > On Fri, Feb 12, 2021 at 08:01:33PM +0530, Vignesh Raghavendra wrote: >> Hi Vladimir, >> >> On 2/12/21 7:47 PM, Grygorii Strashko wrote: >>> >>> >>> On 12/02/2021 03:05, Vladimir Oltean wrote: >>>> From: Vladimir Oltean >> [...] >>> >>> Sorry, but we seems just added more work for you. >>> https://lore.kernel.org/patchwork/cover/1379380/ >>> >> >> Could you squash these when you post new version: >> Sorry for not noticing earlier. > > Hey, thanks for the fixup patch and congrats on the new driver support > for the AM65 NUSS! What's functionally different compared to the other > CPSW instantiations? > CPSW is mostly present on older TI's 32 bit SoCs and can support upto 2 external ports. AM65 NUSS is next generation multi port switch IP (up to 8 external ports) present on TI's newer 64 bit platform. It also has different DMA integration and has native HW support to work as both Multi Mac and Switch mode. > Also, do I get it right that you also tested the bridge port flags > passed in the new format and that they still work ok? May I add your > Tested-by tag? > Sorry, I have not done extensive testing but tried couple of cmds. Those worked as expected: root@evm:~# ip link set eth0 type bridge_slave flood off mcast_flood off learning off Error: bridge: bridge flag offload is not supported. root@evm:~# ip link set eth0 type bridge_slave mcast_flood off [ 65.025285] am65-cpsw-nuss 800.ethernet eth0: BR_MCAST_FLOOD: 0 port 1 Regards Vignesh
Re: [PATCH v4 net-next 0/9] Cleanup in brport flags switchdev offload for DSA
Hi Vladimir,
On 2/12/21 7:47 PM, Grygorii Strashko wrote:
>
>
> On 12/02/2021 03:05, Vladimir Oltean wrote:
>> From: Vladimir Oltean
[...]
>
> Sorry, but we seems just added more work for you.
> https://lore.kernel.org/patchwork/cover/1379380/
>
Could you squash these when you post new version:
Sorry for not noticing earlier.
-- >8 --
>From 69f3a1ff1ea0777f5deceefdb0e79ce625e6488a Mon Sep 17 00:00:00 2001
From: Vignesh Raghavendra
Date: Fri, 12 Feb 2021 19:34:46 +0530
Subject: [PATCH 1/2] fixup! net: switchdev: propagate extack to port
attributes
---
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
index 1067e7772dbf..314825acf0a0 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
@@ -81,7 +81,8 @@ static int am65_cpsw_port_attr_br_flags_pre_set(struct
net_device *netdev,
}
static int am65_cpsw_port_attr_set(struct net_device *ndev,
- const struct switchdev_attr *attr)
+ const struct switchdev_attr *attr,
+ struct netlink_ext_ack *extack)
{
struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
-- >8 --
>From 7d7fdb79a8b255a1e9fe5d205b0ff1824a16ce56 Mon Sep 17 00:00:00 2001
From: Vignesh Raghavendra
Date: Fri, 12 Feb 2021 19:40:48 +0530
Subject: [PATCH 2/2] fixup! net: switchdev: pass flags and mask to both
{PRE_,}BRIDGE_FLAGS attributes
---
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
index 314825acf0a0..03c7a012f5c5 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
@@ -55,12 +55,12 @@ static int am65_cpsw_port_stp_state_set(struct
am65_cpsw_port *port, u8 state)
static int am65_cpsw_port_attr_br_flags_set(struct am65_cpsw_port *port,
struct net_device *orig_dev,
- unsigned long brport_flags)
+ struct switchdev_brport_flags flags)
{
struct am65_cpsw_common *cpsw = port->common;
bool unreg_mcast_add = false;
- if (brport_flags & BR_MCAST_FLOOD)
+ if (flags.mask & BR_MCAST_FLOOD)
unreg_mcast_add = true;
netdev_dbg(port->ndev, "BR_MCAST_FLOOD: %d port %u\n",
unreg_mcast_add, port->port_id);
@@ -72,9 +72,9 @@ static int am65_cpsw_port_attr_br_flags_set(struct
am65_cpsw_port *port,
}
static int am65_cpsw_port_attr_br_flags_pre_set(struct net_device *netdev,
- unsigned long flags)
+ struct switchdev_brport_flags
flags)
{
- if (flags & ~(BR_LEARNING | BR_MCAST_FLOOD))
+ if (flags.mask & ~(BR_LEARNING | BR_MCAST_FLOOD))
return -EINVAL;
return 0;
--
2.30.0
[PATCH v2 4/4] docs: networking: ti: Add driver doc for AM65 NUSS switch driver
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add documentation explaining how to use
different modes.
Borrowed from:
Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst
Signed-off-by: Vignesh Raghavendra
---
.../device_drivers/ethernet/index.rst | 1 +
.../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 ++
2 files changed, 144 insertions(+)
create mode 100644
Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst
b/Documentation/networking/device_drivers/ethernet/index.rst
index cbb75a1818c0..6b5dc203da2b 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -49,6 +49,7 @@ Contents:
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
+ ti/am65_nuss_cpsw_switchdev
ti/tlan
toshiba/spider_net
diff --git
a/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
new file mode 100644
index ..f24adfab6a1b
--- /dev/null
+++
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
@@ -0,0 +1,143 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver
+===
+
+:Version: 1.0
+
+Port renaming
+=
+
+In order to rename via udev::
+
+ip -d link show dev sw0p1 | grep switchid
+
+SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
+ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+
+
+Multi mac mode
+==
+
+- The driver is operating in multi-mac mode by default, thus
+ working as N individual network interfaces.
+
+Devlink configuration parameters
+
+
+See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
+
+Enabling "switch"
+=
+
+The Switch mode can be enabled by configuring devlink driver parameter
+"switch_mode" to 1/true::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+This can be done regardless of the state of Port's netdev devices - UP/DOWN,
but
+Port's netdev devices have to be in UP before joining to the bridge to avoid
+overwriting of bridge configuration as CPSW switch driver completely reloads
its
+configuration when first port changes its state to UP.
+
+When the both interfaces joined the bridge - CPSW switch driver will enable
+marking packets with offload_fwd_mark flag.
+
+All configuration is implemented via switchdev API.
+
+Bridge setup
+
+
+::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+ ip link add name br0 type bridge
+ ip link set dev br0 type bridge ageing_time 1000
+ ip link set dev sw0p1 up
+ ip link set dev sw0p2 up
+ ip link set dev sw0p1 master br0
+ ip link set dev sw0p2 master br0
+
+ [*] bridge vlan add dev br0 vid 1 pvid untagged self
+
+ [*] if vlan_filtering=1. where default_pvid=1
+
+ Note. Steps [*] are mandatory.
+
+
+On/off STP
+==
+
+::
+
+ ip link set dev BRDEV type bridge stp_state 1/0
+
+VLAN configuration
+==
+
+::
+
+ bridge vlan add dev br0 vid 1 pvid untagged self < add cpu port to VLAN 1
+
+Note. This step is mandatory for bridge/default_pvid.
+
+Add extra VLANs
+===
+
+ 1. untagged::
+
+ bridge vlan add dev sw0p1 vid 100 pvid untagged master
+ bridge vlan add dev sw0p2 vid 100 pvid untagged master
+ bridge vlan add dev br0 vid 100 pvid untagged self < Add cpu port
to VLAN100
+
+ 2. tagged::
+
+ bridge vlan add dev sw0p1 vid 100 master
+ bridge vlan add dev sw0p2 vid 100 master
+ bridge vlan add dev br0 vid 100 pvid tagged self < Add cpu port to
VLAN100
+
+FDBs
+
+
+FDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding FDBs::
+
+bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
+bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master < Add on all VLANs
+
+MDBs
+
+
+MDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding MDBs::
+
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent < Add on all
VLANs
+
+Multicast flooding
+==
+CPU port mcast_flooding is always on
+
+Turning flooding on/off on swithch ports:
+bridge link set dev sw0p1 mcast_flood on/off
+
+Access an
[PATCH v2 0/4] net: ti: am65-cpsw-nuss: Add switchdev driver
This series adds switchdev support for AM65 CPSW NUSS driver to support multi port CPSW present on J721e and AM64 SoCs. It adds devlink hook to switch b/w switch mode and multi mac mode. v2: Rebased on latest net-next Update patch 1/4 with rationale for using devlink Vignesh Raghavendra (4): net: ti: am65-cpsw-nuss: Add devlink support net: ti: am65-cpsw-nuss: Add netdevice notifiers net: ti: am65-cpsw-nuss: Add switchdev support docs: networking: ti: Add driver doc for AM65 NUSS switch driver .../device_drivers/ethernet/index.rst | 1 + .../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 + .../devlink/am65-nuss-cpsw-switch.rst | 26 + Documentation/networking/devlink/index.rst| 1 + drivers/net/ethernet/ti/Kconfig | 10 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/am65-cpsw-nuss.c | 511 - drivers/net/ethernet/ti/am65-cpsw-nuss.h | 26 + drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 533 ++ drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++ 10 files changed, 1267 insertions(+), 19 deletions(-) create mode 100644 Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h -- 2.30.0
[PATCH v2 3/4] net: ti: am65-cpsw-nuss: Add switchdev support
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add support for configuring this HW in
switch mode using devlink and switchdev notifiers.
Support is similar to existing CPSW switchdev implementation of TI's 32 bit
platform like AM33/AM43/AM57.
To enable switch mode:
devlink dev param set platform/800.ethernet name switch_mode value true
cmode runtime
All configuration is implemented via switchdev API and notifiers.
Supported:
- SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_STP_STATE
- SWITCHDEV_OBJ_ID_PORT_VLAN
- SWITCHDEV_OBJ_ID_PORT_MDB
- SWITCHDEV_OBJ_ID_HOST_MDB
Hence AM65 CPSW switchdev driver supports:
- FDB offloading
- MDB offloading
- VLAN filtering and offloading
- STP
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 20 +-
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 533 ++
drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++
4 files changed, 587 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 6e779292545d..75f761efbea7 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -26,4 +26,5 @@ keystone_netcp_ethss-y := netcp_ethss.o netcp_sgmii.o
netcp_xgbepcsr.o cpsw_ale.
obj-$(CONFIG_TI_K3_AM65_CPSW_NUSS) += ti-am65-cpsw-nuss.o
ti-am65-cpsw-nuss-y := am65-cpsw-nuss.o cpsw_sl.o am65-cpsw-ethtool.o
cpsw_ale.o k3-cppi-desc-pool.o am65-cpsw-qos.o
+ti-am65-cpsw-nuss-$(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV) += am65-cpsw-switchdev.o
obj-$(CONFIG_TI_K3_AM65_CPTS) += am65-cpts.o
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d26228395e8d..80f3f4899f21 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -31,6 +31,7 @@
#include "cpsw_ale.h"
#include "cpsw_sl.h"
#include "am65-cpsw-nuss.h"
+#include "am65-cpsw-switchdev.h"
#include "k3-cppi-desc-pool.h"
#include "am65-cpts.h"
@@ -228,6 +229,9 @@ static int am65_cpsw_nuss_ndo_slave_add_vid(struct
net_device *ndev,
u32 port_mask, unreg_mcast = 0;
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -255,6 +259,9 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct
net_device *ndev,
struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -277,6 +284,11 @@ static void am65_cpsw_slave_set_promisc(struct
am65_cpsw_port *port,
{
struct am65_cpsw_common *common = port->common;
+ if (promisc && !common->is_emac_mode) {
+ dev_dbg(common->dev, "promisc mode requested in switch mode");
+ return;
+ }
+
if (promisc) {
/* Enable promiscuous mode */
cpsw_ale_control_set(common->ale, port->port_id,
@@ -800,12 +812,13 @@ static int am65_cpsw_nuss_rx_packets(struct
am65_cpsw_common *common,
new_skb = netdev_alloc_skb_ip_align(ndev, AM65_CPSW_MAX_PACKET_SIZE);
if (new_skb) {
+ ndev_priv = netdev_priv(ndev);
+ am65_cpsw_nuss_set_offload_fwd_mark(skb,
ndev_priv->offload_fwd_mark);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
am65_cpsw_nuss_rx_csum(skb, csum_info);
napi_gro_receive(>napi_rx, skb);
- ndev_priv = netdev_priv(ndev);
stats = this_cpu_ptr(ndev_priv->stats);
u64_stats_update_begin(>syncp);
@@ -2144,6 +2157,10 @@ static int am65_cpsw_register_notifiers(struct
am65_cpsw_common *cpsw)
return ret;
}
+ ret = am65_cpsw_switchdev_register_notifiers(cpsw);
+ if (ret)
+ unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
+
return ret;
}
@@ -2153,6 +2170,7 @@ static void am65_cpsw_unregister_notifiers(struct
am65_cpsw_common *cpsw)
!IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
return;
+ am65_cpsw_switchdev_unregister_notifiers(cpsw);
unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
}
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
new file mode 100644
index ..1067e7772dbf
--- /dev/null
[PATCH v2 1/4] net: ti: am65-cpsw-nuss: Add devlink support
AM65 NUSS ethernet switch on K3 devices can be configured to work either
in independent mac mode where each port acts as independent network
interface (multi mac) or switch mode.
Add devlink hooks to provide a way to switch b/w these modes.
Rationale to use devlink instead of defaulting to bridge mode is that
SoC use cases require to support multiple independent MAC ports with no
switching so that users can use software bridges with multi-mac
configuration (e.g: to support LAG, HSR/PRP, etc). Also, switching
between multi mac and switch mode requires significant Port and ALE
reconfiguration, therefore is easier to be made as part of mode change
devlink hooks. It also allows to keep user interface similar to what
was implemented for the previous generation of TI CPSW IP
(on AM33/AM43/AM57 SoCs).
Signed-off-by: Vignesh Raghavendra
---
.../devlink/am65-nuss-cpsw-switch.rst | 26 ++
Documentation/networking/devlink/index.rst| 1 +
drivers/net/ethernet/ti/Kconfig | 10 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 363 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 22 ++
5 files changed, 404 insertions(+), 18 deletions(-)
create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
diff --git a/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
new file mode 100644
index ..1e589c26abff
--- /dev/null
+++ b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+am65-cpsw-nuss devlink support
+==
+
+This document describes the devlink features implemented by the
``am65-cpsw-nuss``
+device driver.
+
+Parameters
+==
+
+The ``am65-cpsw-nuss`` driver implements the following driver-specific
+parameters.
+
+.. list-table:: Driver-specific parameters implemented
+ :widths: 5 5 5 85
+
+ * - Name
+ - Type
+ - Mode
+ - Description
+ * - ``switch_mode``
+ - Boolean
+ - runtime
+ - Enable switch mode
diff --git a/Documentation/networking/devlink/index.rst
b/Documentation/networking/devlink/index.rst
index aab79667f97b..8428a1220723 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -45,3 +45,4 @@ parameters, info versions, and other features it supports.
sja1105
qed
ti-cpsw-switch
+ am65-nuss-cpsw-switch
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index abfc4c435d59..affcf92cd3aa 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -92,6 +92,7 @@ config TI_CPTS
config TI_K3_AM65_CPSW_NUSS
tristate "TI K3 AM654x/J721E CPSW Ethernet driver"
depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
+ select NET_DEVLINK
select TI_DAVINCI_MDIO
imply PHY_TI_GMII_SEL
depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS
@@ -105,6 +106,15 @@ config TI_K3_AM65_CPSW_NUSS
To compile this driver as a module, choose M here: the module
will be called ti-am65-cpsw-nuss.
+config TI_K3_AM65_CPSW_SWITCHDEV
+ bool "TI K3 AM654x/J721E CPSW Switch mode support"
+ depends on TI_K3_AM65_CPSW_NUSS
+ depends on NET_SWITCHDEV
+ help
+This enables switchdev support for TI K3 CPSWxG Ethernet
+Switch. Enable this driver to support hardware switch support for AM65
+CPSW NUSS driver.
+
config TI_K3_AM65_CPTS
tristate "TI K3 AM65x CPTS"
depends on ARCH_K3 && OF
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index b18db3c8207f..75dbd9239061 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -408,6 +408,11 @@ void am65_cpsw_nuss_set_p0_ptype(struct am65_cpsw_common
*common)
writel(val, host_p->port_base + AM65_CPSW_PORT_REG_PRI_CTL);
}
+static void am65_cpsw_init_host_port_switch(struct am65_cpsw_common *common);
+static void am65_cpsw_init_host_port_emac(struct am65_cpsw_common *common);
+static void am65_cpsw_init_port_switch_ale(struct am65_cpsw_port *port);
+static void am65_cpsw_init_port_emac_ale(struct am65_cpsw_port *port);
+
static int am65_cpsw_nuss_common_open(struct am65_cpsw_common *common,
netdev_features_t features)
{
@@ -454,9 +459,6 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
ALE_DEFAULT_THREAD_ID, 0);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
ALE_DEFAULT_THREAD_ENABLE, 1);
- if (AM65_CPSW_IS_CPSW2G(common))
- cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
-ALE_PORT_NOLEARN, 1);
/* swi
[PATCH v2 2/4] net: ti: am65-cpsw-nuss: Add netdevice notifiers
Register netdevice notifiers in order to receive notification when
individual MAC ports are added to the HW bridge.
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 130 ++-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 4 +
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 75dbd9239061..d26228395e8d 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2036,6 +2036,126 @@ static void am65_cpsw_nuss_cleanup_ndev(struct
am65_cpsw_common *common)
}
}
+static void am65_cpsw_port_offload_fwd_mark_update(struct am65_cpsw_common
*common)
+{
+ int set_val = 0;
+ int i;
+
+ if (common->br_members == (GENMASK(common->port_num, 1) &
~common->disabled_ports_mask))
+ set_val = 1;
+
+ dev_dbg(common->dev, "set offload_fwd_mark %d\n", set_val);
+
+ for (i = 1; i <= common->port_num; i++) {
+ struct am65_cpsw_port *port = am65_common_get_port(common, i);
+ struct am65_cpsw_ndev_priv *priv =
am65_ndev_to_priv(port->ndev);
+
+ priv->offload_fwd_mark = set_val;
+ }
+}
+
+bool am65_cpsw_port_dev_check(const struct net_device *ndev)
+{
+ if (ndev->netdev_ops == _cpsw_nuss_netdev_ops) {
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+
+ return !common->is_emac_mode;
+ }
+
+ return false;
+}
+
+static int am65_cpsw_netdevice_port_link(struct net_device *ndev, struct
net_device *br_ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ if (!common->br_members) {
+ common->hw_bridge_dev = br_ndev;
+ } else {
+ /* This is adding the port to a second bridge, this is
+* unsupported
+*/
+ if (common->hw_bridge_dev != br_ndev)
+ return -EOPNOTSUPP;
+ }
+
+ common->br_members |= BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ return NOTIFY_DONE;
+}
+
+static void am65_cpsw_netdevice_port_unlink(struct net_device *ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ common->br_members &= ~BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ if (!common->br_members)
+ common->hw_bridge_dev = NULL;
+}
+
+/* netdev notifier */
+static int am65_cpsw_netdevice_event(struct notifier_block *unused,
+unsigned long event, void *ptr)
+{
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct netdev_notifier_changeupper_info *info;
+ int ret = NOTIFY_DONE;
+
+ if (!am65_cpsw_port_dev_check(ndev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_CHANGEUPPER:
+ info = ptr;
+
+ if (netif_is_bridge_master(info->upper_dev)) {
+ if (info->linking)
+ ret = am65_cpsw_netdevice_port_link(ndev,
info->upper_dev);
+ else
+ am65_cpsw_netdevice_port_unlink(ndev);
+ }
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return notifier_from_errno(ret);
+}
+
+static int am65_cpsw_register_notifiers(struct am65_cpsw_common *cpsw)
+{
+ int ret = 0;
+
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return 0;
+
+ cpsw->am65_cpsw_netdevice_nb.notifier_call = _cpsw_netdevice_event;
+ ret = register_netdevice_notifier(>am65_cpsw_netdevice_nb);
+ if (ret) {
+ dev_err(cpsw->dev, "can't register netdevice notifier\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static void am65_cpsw_unregister_notifiers(struct am65_cpsw_common *cpsw)
+{
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return;
+
+ unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
+}
+
static const struct devlink_ops am65_cpsw_devlink_ops = {};
static void am65_cpsw_init_stp_ale_entry(struct am65_cpsw_common *cpsw)
@@ -2379,17 +2499,24 @@ static int am65_cpsw_nuss_register_ndevs(struct
am65_cpsw_common *common)
}
}
- ret = am65_cpsw_nuss_register_devlink(common);
+ ret = am65_cpsw_register_notifiers(common);
if (ret)
goto
[PATCH] dmaengine: ti: k3-udma: Set rflow count for BCDMA split channels
BCDMA RX channels have one flow per channel, therefore set the rflow_cnt
to rchan_cnt.
Without this patch, request for BCDMA RX channel allocation fails as
rflow_cnt is 0 thus fails to reserve a rflow for the channel.
Fixes: 8844898028d4 ("dmaengine: ti: k3-udma: Add support for BCDMA channel TPL
handling")
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/k3-udma.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 298460438bb4..a1af59d901be 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -4305,6 +4305,7 @@ static int udma_get_mmrs(struct platform_device *pdev,
struct udma_dev *ud)
ud->bchan_cnt = BCDMA_CAP2_BCHAN_CNT(cap2);
ud->tchan_cnt = BCDMA_CAP2_TCHAN_CNT(cap2);
ud->rchan_cnt = BCDMA_CAP2_RCHAN_CNT(cap2);
+ ud->rflow_cnt = ud->rchan_cnt;
break;
case DMA_TYPE_PKTDMA:
cap4 = udma_read(ud->mmrs[MMR_GCFG], 0x30);
--
2.30.0
Re: [PATCH 1/2] misc: eeprom_93xx46: Fix module alias to enable module autoprobe
On 1/7/21 10:09 PM, Aswath Govindraju wrote:
> Fix module autoprobe by correcting module alias to match the string from
> /sys/class/.../spi1.0/modalias content.
>
> Fixes: 06b4501e88ad ("misc/eeprom: add driver for microwire 93xx46 EEPROMs")
> Signed-off-by: Aswath Govindraju
> ---
> drivers/misc/eeprom/eeprom_93xx46.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index a18247696ce7..890624d97774 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -526,4 +526,4 @@ module_spi_driver(eeprom_93xx46_driver);
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("Driver for 93xx46 EEPROMs");
> MODULE_AUTHOR("Anatolij Gustschin ");
> -MODULE_ALIAS("spi:93xx46");
This will break non DT users of this driver like
drivers/misc/eeprom/digsy_mtc_eeprom.c
> +MODULE_ALIAS("spi:eeprom-93xx46");
>
Can be a new entry.
Regards
Vignesh
Re: [PATCH v4 0/6] PCI: J7200/J721E PCIe bindings
Hi, On 1/5/21 8:44 PM, Kishon Vijay Abraham I wrote: > Patch series adds DT nodes in order to get PCIe working in J7200. > Also includes couple of fixes for J721e. [...] > > Kishon Vijay Abraham I (6): > arm64: dts: ti: k3-j721e-main: Fix supported max outbound regions > arm64: dts: ti: k3-j721e-main: Remove "syscon" nodes added for > pcieX_ctrl > arm64: dts: ti: k3-j7200-main: Add SERDES and WIZ device tree node > arm64: dts: ti: k3-j7200-main: Add PCIe device tree node > arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0 > arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe > > .../dts/ti/k3-j7200-common-proc-board.dts | 38 ++ > arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 111 ++ > arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 52 ++-- > 3 files changed, 157 insertions(+), 44 deletions(-) > For the series: Reviewed-by: Vignesh Raghavendra Regards Vignesh
Re: ping // [PATCH] mtd:cfi_cmdset_0002: fix atomic sleep bug when CONFIG_MTD_XIP=y
On 12/8/20 6:53 AM, Xiaoming Ni wrote: > On 2020/12/8 2:59, Vignesh Raghavendra wrote: >> Hi Xiaoming, >> [...] >>>>> --- >>>>> drivers/mtd/chips/cfi_cmdset_0002.c | 16 >>>>> 1 file changed, 16 insertions(+) >>>>> >>>>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c >>>>> b/drivers/mtd/chips/cfi_cmdset_0002.c >>>>> index a1f3e1031c3d..12c3776f093a 100644 >>>>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c >>>>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c >>>>> @@ -1682,7 +1682,11 @@ static int __xipram >>>>> do_write_oneword_once(struct map_info *map, >>>>> set_current_state(TASK_UNINTERRUPTIBLE); >>>>> add_wait_queue(>wq, ); >>>>> mutex_unlock(>mutex); >>>>> + if (IS_ENABLED(CONFIG_MTD_XIP)) >>>>> + local_irq_enable(); >>>>> schedule(); >>>>> + if (IS_ENABLED(CONFIG_MTD_XIP)) >>>>> + local_irq_disable(); >>> >>> The fix really seems strange to me. I will let Vignesh decide but I >>> think we should consider updating/fixing xip_disable instead. >> >> Agree with Miquel. Have you done any testing >> or is this purely based on code inspection? >> > I don't have the corresponding device test environment. > I found the problem through code review. > Sorry, I am not comfortable applying this patch without proper testing that given the unknowns and legacy nature of the code. > >> What about comment before xip_disable() function: >> >> /* >> * No interrupt what so ever can be serviced while the flash isn't in >> array >> * mode. This is ensured by the xip_disable() and xip_enable() >> functions >> * enclosing any code path where the flash is known not to be in >> array mode. >> * And within a XIP disabled code path, only functions marked with >> __xipram >> * may be called and nothing else (it's a good thing to inspect >> generated >> * assembly to make sure inline functions were actually inlined and >> that gcc >> * didn't emit calls to its own support functions). Also configuring >> MTD CFI >> * support to a single buswidth and a single interleave is also >> recommended. >> */ >> >> So, I don't think the fix is as simple as this patch. >> > +xip_enable(); > schedule(); > +xip_disable(); > > Do I need to change it to this? > This just narrows the window, but an IRQ is still possible just after xip_enable() but before schedule(). Regards Vignesh
[PATCH] mtd: spi-nor: sfdp: Fix SMPT parsing when 4BAIT table is before SMPT
If 4BAIT table appears before SMPT then, nor->addr_width is set to 4 before
SMPT table is parsed. This causes SMPT parser code to use addr_width of 4
for reading current sector map configuration in spi_nor_get_map_in_use()
if SMPT_CMD_ADDRESS_LEN reads SMPT_CMD_ADDRESS_LEN_USE_CURRENT (see
spi_nor_smpt_addr_width()). Instead code should be using the value
presented by BFPT_DWORD1_ADDRESS_BYTES field. On S28HS family of devices
this bug leads to selection of invalid sector mapping thus causing erase
and write failures.
Fix this by parsing 4BAIT address table at the very end after all other
parameter tables are parsed.
Fixes: b038e8e3be72 ("mtd: spi-nor: parse SFDP Sector Map Parameter Table")
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/sfdp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 22cb519efe3f..6d4dc1549cc7 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -1260,6 +1260,7 @@ static int spi_nor_parse_sccr(struct spi_nor *nor,
int spi_nor_parse_sfdp(struct spi_nor *nor,
struct spi_nor_flash_parameter *params)
{
+ const struct sfdp_parameter_header *sfdp_4bait_param_header = NULL;
const struct sfdp_parameter_header *param_header, *bfpt_header;
struct sfdp_parameter_header *param_headers = NULL;
struct sfdp_header header;
@@ -1341,7 +1342,13 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
break;
case SFDP_4BAIT_ID:
- err = spi_nor_parse_4bait(nor, param_header, params);
+ /*
+* Parse 4BAIT table at the end as this will end up
+* changing nor->addr_width obtained from BFPT.
+* But other parsers, such as SMPT parser, need to
+* know default/current addr_width of the flash.
+*/
+ sfdp_4bait_param_header = param_header;
break;
case SFDP_PROFILE1_ID:
@@ -1369,6 +1376,12 @@ int spi_nor_parse_sfdp(struct spi_nor *nor,
}
}
+ if (sfdp_4bait_param_header &&
+ spi_nor_parse_4bait(nor, sfdp_4bait_param_header, params)) {
+ dev_warn(dev, "Failed to parse optional parameter table:
%04x\n",
+SFDP_PARAM_HEADER_ID(param_header));
+ }
+
exit:
kfree(param_headers);
return err;
--
2.29.2
Re: [PATCH] serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
Hi,
On 12/10/20 11:22 AM, Alexander Sverdlin wrote:
> It has been observed that once per 300-1300 port openings the first
> transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
> as "e" on the wire). It only happened if single byte has been transmitted
> right after port open, which means, DMA is not used for this transfer and
> the corruption never happened afterwards.
>
> Therefore I've carefully re-read the MDR1 errata (link below), which says
> "when accessing the MDR1 registers that causes a dummy under-run condition
> that will freeze the UART in IrDA transmission. In UART mode, this may
> corrupt the transferred data". Strictly speaking,
> omap_8250_mdr1_errataset() performs a read access and if the value is the
> same as should be written, exits without errata-recommended FIFO reset.
>
> A brief check of the serial_omap_mdr1_errataset() from the competing
> omap-serial driver showed it has no read access of MDR1. After removing the
> read access from omap_8250_mdr1_errataset() the data corruption never
> happened any more.
>
> Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
> Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Alexander Sverdlin
Thanks for the fix.
Reviewed-by: Vignesh Raghavendra
> ---
> drivers/tty/serial/8250/8250_omap.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c
> b/drivers/tty/serial/8250/8250_omap.c
> index 562087df7d33..0cc6d35a0815 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -184,11 +184,6 @@ static void omap_8250_mdr1_errataset(struct
> uart_8250_port *up,
>struct omap8250_priv *priv)
> {
> u8 timeout = 255;
> - u8 old_mdr1;
> -
> - old_mdr1 = serial_in(up, UART_OMAP_MDR1);
> - if (old_mdr1 == priv->mdr1)
> - return;
>
> serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> udelay(2);
>
Re: [PATCH v8 0/7] mtd: spi-nor: keep lock bits if they are non-volatile
Hi Michael, On Thu, 3 Dec 2020 17:29:52 +0100, Michael Walle wrote: > I bundled this as a series, because otherwise there will be conflicts > because the "remove global protection flag" patches modify the same lines > as the main patch. > > There are now two more patches: > mtd: spi-nor: sst: fix BPn bits for the SST25VF064C > mtd: spi-nor: ignore errors in spi_nor_unlock_all() > Both are fixes and are first in this series. This will ensure that they > might be cherry-picked without conflicts as the following patches touches > the same lines. > > [...] Appreciate all the hard work! Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [1/7] mtd: spi-nor: sst: fix BPn bits for the SST25VF064C https://git.kernel.org/mtd/c/989d4b72ba [2/7] mtd: spi-nor: ignore errors in spi_nor_unlock_all() https://git.kernel.org/mtd/c/bdb1a75e4b [3/7] mtd: spi-nor: atmel: remove global protection flag https://git.kernel.org/mtd/c/e6204d4620 [4/7] mtd: spi-nor: sst: remove global protection flag https://git.kernel.org/mtd/c/a833383732 [5/7] mtd: spi-nor: intel: remove global protection flag https://git.kernel.org/mtd/c/afcf93e9d6 [6/7] mtd: spi-nor: atmel: fix unlock_all() for AT25FS010/040 https://git.kernel.org/mtd/c/8c174d1511 [7/7] mtd: spi-nor: keep lock bits if they are non-volatile https://git.kernel.org/mtd/c/31ad3eff09 -- Regards Vignesh
Re: [PATCH v3 3/3] mtd: spi-nor: spansion: Set ECC block size
On 12/1/20 3:57 PM, Pratyush Yadav wrote:
> The S28 flash family uses 2-bit ECC by default with each ECC block being
> 16 bytes. Under this scheme multi-pass programming to an ECC block is
> not allowed. Set the writesize to make sure multi-pass programming is
> not attempted on the flash.
>
> Signed-off-by: Pratyush Yadav
> Reviewed-by: Tudor Ambarus
> ---
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
spi-nor/next, thanks!
[3/3] mtd: spi-nor: spansion: Set ECC block size
https://git.kernel.org/mtd/c/294cca6ce5
>
> Notes:
> No changes in v3
>
> New in v2.
>
> drivers/mtd/spi-nor/spansion.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/spi-nor/spansion.c b/drivers/mtd/spi-nor/spansion.c
> index e487fd341a56..b0c5521c1e27 100644
> --- a/drivers/mtd/spi-nor/spansion.c
> +++ b/drivers/mtd/spi-nor/spansion.c
> @@ -109,6 +109,7 @@ static int spi_nor_cypress_octal_dtr_enable(struct
> spi_nor *nor, bool enable)
> static void s28hs512t_default_init(struct spi_nor *nor)
> {
> nor->params->octal_dtr_enable = spi_nor_cypress_octal_dtr_enable;
> + nor->params->writesize = 16;
> }
>
> static void s28hs512t_post_sfdp_fixup(struct spi_nor *nor)
>
Re: [PATCH v3 2/3] mtd: spi-nor: core: Allow flashes to specify MTD writesize
Hi Pratyush, On 12/1/20 3:57 PM, Pratyush Yadav wrote: > Some flashes like the Cypress S28 family use ECC. Under this ECC scheme, > multi-pass writes to an ECC block is not allowed. In other words, once > data is programmed to an ECC block, it can't be programmed again without > erasing it first. > > Upper layers like file systems need to be given this information so they > do not cause error conditions on the flash by attempting multi-pass > programming. This can be done by setting 'writesize' in 'struct > mtd_info'. > > Set the default to 1 but allow flashes to modify it in fixup hooks. If > more flashes show up with this constraint in the future it might be > worth it to add it to 'struct flash_info', but for now increasing its > size is not worth it. > > Signed-off-by: Pratyush Yadav > Reviewed-by: Tudor Ambarus > --- > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [2/3] mtd: spi-nor: core: Allow flashes to specify MTD writesize https://git.kernel.org/mtd/c/afd473e858 Regards Vignesh
Re: [PATCH v2] mtd: spi-nor: Fix multiple typos
On Mon, 30 Nov 2020 16:24:15 +0100, Jonathan Neuschäfer wrote: > There are a few typos in comments in the SPI NOR framework; fix them. Addressed Tudor's comments locally. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [1/1] mtd: spi-nor: Fix multiple typos https://git.kernel.org/mtd/c/c69942bda5 -- Regards Vignesh
Re: ping // [PATCH] mtd:cfi_cmdset_0002: fix atomic sleep bug when CONFIG_MTD_XIP=y
Hi Xiaoming,
On 12/7/20 4:23 PM, Miquel Raynal wrote:
> Hi Xiaoming,
>
> Xiaoming Ni wrote on Mon, 7 Dec 2020 18:48:33
> +0800:
>
>> ping
>>
>> On 2020/11/27 21:07, Xiaoming Ni wrote:
>>> When CONFIG_MTD_XIP=y, local_irq_disable() is called in xip_disable().
>>> To avoid sleep in interrupt context, we need to call local_irq_enable()
>>> before schedule().
>>>
>>> The problem call stack is as follows:
>>> bug1:
>>> do_write_oneword_retry()
>>> xip_disable()
>>> local_irq_disable()
>>> do_write_oneword_once()
>>> schedule()
>>> bug2:
>>> do_write_buffer()
>>> xip_disable()
>>> local_irq_disable()
>>> do_write_buffer_wait()
>>> schedule()
>>> bug3:
>>> do_erase_chip()
>>> xip_disable()
>>> local_irq_disable()
>>> schedule()
>>> bug4:
>>> do_erase_oneblock()
>>> xip_disable()
>>> local_irq_disable()
>>> schedule()
>>>
>>> Fixes: 02b15e343aee ("[MTD] XIP for AMD CFI flash.")
>>> Cc: sta...@vger.kernel.org # v2.6.13
>>> Signed-off-by: Xiaoming Ni
>>> ---
>>> drivers/mtd/chips/cfi_cmdset_0002.c | 16
>>> 1 file changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
>>> b/drivers/mtd/chips/cfi_cmdset_0002.c
>>> index a1f3e1031c3d..12c3776f093a 100644
>>> --- a/drivers/mtd/chips/cfi_cmdset_0002.c
>>> +++ b/drivers/mtd/chips/cfi_cmdset_0002.c
>>> @@ -1682,7 +1682,11 @@ static int __xipram do_write_oneword_once(struct
>>> map_info *map,
>>> set_current_state(TASK_UNINTERRUPTIBLE);
>>> add_wait_queue(>wq, );
>>> mutex_unlock(>mutex);
>>> + if (IS_ENABLED(CONFIG_MTD_XIP))
>>> + local_irq_enable();
>>> schedule();
>>> + if (IS_ENABLED(CONFIG_MTD_XIP))
>>> + local_irq_disable();
>
> The fix really seems strange to me. I will let Vignesh decide but I
> think we should consider updating/fixing xip_disable instead.
Agree with Miquel. Have you done any testing
or is this purely based on code inspection?
What about comment before xip_disable() function:
/*
* No interrupt what so ever can be serviced while the flash isn't in array
* mode. This is ensured by the xip_disable() and xip_enable() functions
* enclosing any code path where the flash is known not to be in array mode.
* And within a XIP disabled code path, only functions marked with __xipram
* may be called and nothing else (it's a good thing to inspect generated
* assembly to make sure inline functions were actually inlined and that gcc
* didn't emit calls to its own support functions). Also configuring MTD CFI
* support to a single buswidth and a single interleave is also recommended.
*/
So, I don't think the fix is as simple as this patch.
Regards
Vignesh
Re: [PATCH 3/4] net: ti: am65-cpsw-nuss: Add switchdev support
On 11/30/20 10:50 PM, Andrew Lunn wrote:
>> +static int am65_cpsw_port_stp_state_set(struct am65_cpsw_port *port,
>> +struct switchdev_trans *trans, u8 state)
>> +{
>> +struct am65_cpsw_common *cpsw = port->common;
>> +u8 cpsw_state;
>> +int ret = 0;
>> +
>> +if (switchdev_trans_ph_prepare(trans))
>> +return 0;
>> +
>> +switch (state) {
>> +case BR_STATE_FORWARDING:
>> +cpsw_state = ALE_PORT_STATE_FORWARD;
>> +break;
>> +case BR_STATE_LEARNING:
>> +cpsw_state = ALE_PORT_STATE_LEARN;
>> +break;
>> +case BR_STATE_DISABLED:
>> +cpsw_state = ALE_PORT_STATE_DISABLE;
>> +break;
>> +case BR_STATE_LISTENING:
>> +case BR_STATE_BLOCKING:
>> +cpsw_state = ALE_PORT_STATE_BLOCK;
>> +break;
>> +default:
>> +return -EOPNOTSUPP;
>> +}
>
> Strictly speaking, the:
>
>> +if (switchdev_trans_ph_prepare(trans))
>> +return 0;
>
> should be here. In the prepare phase, you are suppose to validate you
> can do the requested action, and return an error is not. In second
> phase, actually carrying out the action, you then never return an
> error.
>
> But in this case, you are handling all the bridge states, so it should
> not matter.
>
Yeah, since driver is interested in all STP states, I preferred to
terminate the function early for prepare phase. Adding switch statement
with just "return 0" for all states during prepare phase looked
redundant to me.
Thanks for the review!
Regards
Vignesh
Re: [PATCH 1/4] net: ti: am65-cpsw-nuss: Add devlink support
Hi Andrew, On 11/30/20 9:20 PM, Andrew Lunn wrote: > On Mon, Nov 30, 2020 at 01:50:43PM +0530, Vignesh Raghavendra wrote: >> AM65 NUSS ethernet switch on K3 devices can be configured to work either >> in independent mac mode where each port acts as independent network >> interface (multi mac) or switch mode. >> >> Add devlink hooks to provide a way to switch b/w these modes. > > Hi Vignesh > > What is not clear is why you need this? Ports are independent anyway > until you add them to a bridge when using switchdev. > Default use case is to support multiple independent ports with no switching. Users can either use software bridge with multi-mac configuration or HW bridge for switch functionality. devlink hook enables users to select Hw supported switch functionality. We don't want to enable HW based switch support unless explicitly asked by user. This also matches previous generation of devices (DRA7xx and AM57xx) supported under drivers/net/ethernet/ti/cpsw_new.c In general, devlink will also be used to configure few more parameters (in addition to switch mode) such as host port in ALE_BYPASS mode (to allow all packets to be routed to host) etc. Regards Vignesh
Re: [PATCH 5/8] i2c: omap: fix reference leak when pm_runtime_get_sync fails
On 12/1/20 3:01 PM, Qinglang Miao wrote:
> The PM reference count is not expected to be incremented on
> return in omap_i2c_probe() and omap_i2c_remove().
>
> However, pm_runtime_get_sync will increment the PM reference
> count even failed. Forgetting to putting operation will result
> in a reference leak here. I Replace it with pm_runtime_resume_and_get
> to keep usage counter balanced.
>
> What's more, error path 'err_free_mem' seems not like a proper
> name any more. So I change the name to err_disable_pm and move
> pm_runtime_disable below, for pm_runtime of 'pdev->dev' should
> be disabled when pm_runtime_resume_and_get fails.
>
> Fixes: 3b0fb97c8dc4 ("I2C: OMAP: Handle error check for pm runtime")
> Reported-by: Hulk Robot
> Signed-off-by: Qinglang Miao
> ---
Reviewed-by: Vignesh Raghavendra
> drivers/i2c/busses/i2c-omap.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 12ac4212a..d4f6c6d60 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1404,9 +1404,9 @@ omap_i2c_probe(struct platform_device *pdev)
> pm_runtime_set_autosuspend_delay(omap->dev, OMAP_I2C_PM_TIMEOUT);
> pm_runtime_use_autosuspend(omap->dev);
>
> - r = pm_runtime_get_sync(omap->dev);
> + r = pm_runtime_resume_and_get(omap->dev);
> if (r < 0)
> - goto err_free_mem;
> + goto err_disable_pm;
>
> /*
>* Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
> @@ -1513,8 +1513,8 @@ omap_i2c_probe(struct platform_device *pdev)
> omap_i2c_write_reg(omap, OMAP_I2C_CON_REG, 0);
> pm_runtime_dont_use_autosuspend(omap->dev);
> pm_runtime_put_sync(omap->dev);
> +err_disable_pm:
> pm_runtime_disable(>dev);
> -err_free_mem:
>
> return r;
> }
> @@ -1525,7 +1525,7 @@ static int omap_i2c_remove(struct platform_device *pdev)
> int ret;
>
> i2c_del_adapter(>adapter);
> - ret = pm_runtime_get_sync(>dev);
> + ret = pm_runtime_resume_and_get(>dev);
> if (ret < 0)
> return ret;
>
>
[PATCH 3/4] net: ti: am65-cpsw-nuss: Add switchdev support
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add support for configuring this HW in
switch mode using devlink and switchdev notifiers.
Support is similar to existing CPSW switchdev implementation of TI's 32 bit
platform like DRA7xx.
To enable switch mode:
devlink dev param set platform/c00.ethernet name switch_mode value true
cmode runtime
All configuration is implemented via switchdev API and notifiers.
Supported:
- SWITCHDEV_ATTR_ID_PORT_PRE_BRIDGE_FLAGS
- SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS: BR_MCAST_FLOOD
- SWITCHDEV_ATTR_ID_PORT_STP_STATE
- SWITCHDEV_OBJ_ID_PORT_VLAN
- SWITCHDEV_OBJ_ID_PORT_MDB
- SWITCHDEV_OBJ_ID_HOST_MDB
Hence AM65 CPSW switchdev driver supports:
- FDB offloading
- MDB offloading
- VLAN filtering and offloading
- STP
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 20 +-
drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 572 ++
drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++
4 files changed, 626 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c
create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 6e779292545d..75f761efbea7 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -26,4 +26,5 @@ keystone_netcp_ethss-y := netcp_ethss.o netcp_sgmii.o
netcp_xgbepcsr.o cpsw_ale.
obj-$(CONFIG_TI_K3_AM65_CPSW_NUSS) += ti-am65-cpsw-nuss.o
ti-am65-cpsw-nuss-y := am65-cpsw-nuss.o cpsw_sl.o am65-cpsw-ethtool.o
cpsw_ale.o k3-cppi-desc-pool.o am65-cpsw-qos.o
+ti-am65-cpsw-nuss-$(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV) += am65-cpsw-switchdev.o
obj-$(CONFIG_TI_K3_AM65_CPTS) += am65-cpts.o
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index a7e5a0489aec..69c0366f2beb 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -31,6 +31,7 @@
#include "cpsw_ale.h"
#include "cpsw_sl.h"
#include "am65-cpsw-nuss.h"
+#include "am65-cpsw-switchdev.h"
#include "k3-cppi-desc-pool.h"
#include "am65-cpts.h"
@@ -228,6 +229,9 @@ static int am65_cpsw_nuss_ndo_slave_add_vid(struct
net_device *ndev,
u32 port_mask, unreg_mcast = 0;
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -255,6 +259,9 @@ static int am65_cpsw_nuss_ndo_slave_kill_vid(struct
net_device *ndev,
struct am65_cpsw_port *port = am65_ndev_to_port(ndev);
int ret;
+ if (!common->is_emac_mode)
+ return 0;
+
if (!netif_running(ndev) || !vid)
return 0;
@@ -277,6 +284,11 @@ static void am65_cpsw_slave_set_promisc(struct
am65_cpsw_port *port,
{
struct am65_cpsw_common *common = port->common;
+ if (promisc && !common->is_emac_mode) {
+ dev_dbg(common->dev, "promisc mode requested in switch mode");
+ return;
+ }
+
if (promisc) {
/* Enable promiscuous mode */
cpsw_ale_control_set(common->ale, port->port_id,
@@ -796,12 +808,13 @@ static int am65_cpsw_nuss_rx_packets(struct
am65_cpsw_common *common,
new_skb = netdev_alloc_skb_ip_align(ndev, AM65_CPSW_MAX_PACKET_SIZE);
if (new_skb) {
+ ndev_priv = netdev_priv(ndev);
+ am65_cpsw_nuss_set_offload_fwd_mark(skb,
ndev_priv->offload_fwd_mark);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
am65_cpsw_nuss_rx_csum(skb, csum_info);
napi_gro_receive(>napi_rx, skb);
- ndev_priv = netdev_priv(ndev);
stats = this_cpu_ptr(ndev_priv->stats);
u64_stats_update_begin(>syncp);
@@ -2131,6 +2144,10 @@ static int am65_cpsw_register_notifiers(struct
am65_cpsw_common *cpsw)
return ret;
}
+ ret = am65_cpsw_switchdev_register_notifiers(cpsw);
+ if (ret)
+ unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
+
return ret;
}
@@ -2140,6 +2157,7 @@ static void am65_cpsw_unregister_notifiers(struct
am65_cpsw_common *cpsw)
!IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
return;
+ am65_cpsw_switchdev_unregister_notifiers(cpsw);
unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
}
diff --git a/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
b/drivers/net/ethernet/ti/am65-cpsw-switchdev.c
new file mode 100644
index ..0fd7b90e60cf
[PATCH 4/4] docs: networking: ti: Add driver doc for AM65 NUSS switch driver
J721e, J7200 and AM64 have multi port switches which can work in multi
mac mode and in switch mode. Add documentation explaining how to use
different modes.
Borrowed from:
Documentation/networking/device_drivers/ethernet/ti/cpsw_switchdev.rst
Signed-off-by: Vignesh Raghavendra
---
.../device_drivers/ethernet/index.rst | 1 +
.../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 ++
2 files changed, 144 insertions(+)
create mode 100644
Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
diff --git a/Documentation/networking/device_drivers/ethernet/index.rst
b/Documentation/networking/device_drivers/ethernet/index.rst
index cbb75a1818c0..6b5dc203da2b 100644
--- a/Documentation/networking/device_drivers/ethernet/index.rst
+++ b/Documentation/networking/device_drivers/ethernet/index.rst
@@ -49,6 +49,7 @@ Contents:
stmicro/stmmac
ti/cpsw
ti/cpsw_switchdev
+ ti/am65_nuss_cpsw_switchdev
ti/tlan
toshiba/spider_net
diff --git
a/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
new file mode 100644
index ..f24adfab6a1b
--- /dev/null
+++
b/Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst
@@ -0,0 +1,143 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+Texas Instruments K3 AM65 CPSW NUSS switchdev based ethernet driver
+===
+
+:Version: 1.0
+
+Port renaming
+=
+
+In order to rename via udev::
+
+ip -d link show dev sw0p1 | grep switchid
+
+SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
+ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+
+
+Multi mac mode
+==
+
+- The driver is operating in multi-mac mode by default, thus
+ working as N individual network interfaces.
+
+Devlink configuration parameters
+
+
+See Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
+
+Enabling "switch"
+=
+
+The Switch mode can be enabled by configuring devlink driver parameter
+"switch_mode" to 1/true::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+This can be done regardless of the state of Port's netdev devices - UP/DOWN,
but
+Port's netdev devices have to be in UP before joining to the bridge to avoid
+overwriting of bridge configuration as CPSW switch driver completely reloads
its
+configuration when first port changes its state to UP.
+
+When the both interfaces joined the bridge - CPSW switch driver will enable
+marking packets with offload_fwd_mark flag.
+
+All configuration is implemented via switchdev API.
+
+Bridge setup
+
+
+::
+
+devlink dev param set platform/c00.ethernet \
+name switch_mode value true cmode runtime
+
+ ip link add name br0 type bridge
+ ip link set dev br0 type bridge ageing_time 1000
+ ip link set dev sw0p1 up
+ ip link set dev sw0p2 up
+ ip link set dev sw0p1 master br0
+ ip link set dev sw0p2 master br0
+
+ [*] bridge vlan add dev br0 vid 1 pvid untagged self
+
+ [*] if vlan_filtering=1. where default_pvid=1
+
+ Note. Steps [*] are mandatory.
+
+
+On/off STP
+==
+
+::
+
+ ip link set dev BRDEV type bridge stp_state 1/0
+
+VLAN configuration
+==
+
+::
+
+ bridge vlan add dev br0 vid 1 pvid untagged self < add cpu port to VLAN 1
+
+Note. This step is mandatory for bridge/default_pvid.
+
+Add extra VLANs
+===
+
+ 1. untagged::
+
+ bridge vlan add dev sw0p1 vid 100 pvid untagged master
+ bridge vlan add dev sw0p2 vid 100 pvid untagged master
+ bridge vlan add dev br0 vid 100 pvid untagged self < Add cpu port
to VLAN100
+
+ 2. tagged::
+
+ bridge vlan add dev sw0p1 vid 100 master
+ bridge vlan add dev sw0p2 vid 100 master
+ bridge vlan add dev br0 vid 100 pvid tagged self < Add cpu port to
VLAN100
+
+FDBs
+
+
+FDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding FDBs::
+
+bridge fdb add aa:bb:cc:dd:ee:ff dev sw0p1 master vlan 100
+bridge fdb add aa:bb:cc:dd:ee:fe dev sw0p2 master < Add on all VLANs
+
+MDBs
+
+
+MDBs are automatically added on the appropriate switch port upon detection
+
+Manually adding MDBs::
+
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent vid 100
+ bridge mdb add dev br0 port sw0p1 grp 239.1.1.1 permanent < Add on all
VLANs
+
+Multicast flooding
+==
+CPU port mcast_flooding is always on
+
+Turning flooding on/off on swithch ports:
+bridge link set dev sw0p1 mcast_flood on/off
+
+Access an
[PATCH 2/4] net: ti: am65-cpsw-nuss: Add netdevice notifiers
Register netdevice notifiers in order to receive notification when
individual MAC ports are added to the HW bridge.
Signed-off-by: Vignesh Raghavendra
---
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 130 ++-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 4 +
2 files changed, 133 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index a635f6be7979..a7e5a0489aec 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -2023,6 +2023,126 @@ static void am65_cpsw_nuss_cleanup_ndev(struct
am65_cpsw_common *common)
}
}
+static void am65_cpsw_port_offload_fwd_mark_update(struct am65_cpsw_common
*common)
+{
+ int set_val = 0;
+ int i;
+
+ if (common->br_members == (GENMASK(common->port_num, 1) &
~common->disabled_ports_mask))
+ set_val = 1;
+
+ dev_dbg(common->dev, "set offload_fwd_mark %d\n", set_val);
+
+ for (i = 1; i <= common->port_num; i++) {
+ struct am65_cpsw_port *port = am65_common_get_port(common, i);
+ struct am65_cpsw_ndev_priv *priv =
am65_ndev_to_priv(port->ndev);
+
+ priv->offload_fwd_mark = set_val;
+ }
+}
+
+bool am65_cpsw_port_dev_check(const struct net_device *ndev)
+{
+ if (ndev->netdev_ops == _cpsw_nuss_netdev_ops) {
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+
+ return !common->is_emac_mode;
+ }
+
+ return false;
+}
+
+static int am65_cpsw_netdevice_port_link(struct net_device *ndev, struct
net_device *br_ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ if (!common->br_members) {
+ common->hw_bridge_dev = br_ndev;
+ } else {
+ /* This is adding the port to a second bridge, this is
+* unsupported
+*/
+ if (common->hw_bridge_dev != br_ndev)
+ return -EOPNOTSUPP;
+ }
+
+ common->br_members |= BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ return NOTIFY_DONE;
+}
+
+static void am65_cpsw_netdevice_port_unlink(struct net_device *ndev)
+{
+ struct am65_cpsw_common *common = am65_ndev_to_common(ndev);
+ struct am65_cpsw_ndev_priv *priv = am65_ndev_to_priv(ndev);
+
+ common->br_members &= ~BIT(priv->port->port_id);
+
+ am65_cpsw_port_offload_fwd_mark_update(common);
+
+ if (!common->br_members)
+ common->hw_bridge_dev = NULL;
+}
+
+/* netdev notifier */
+static int am65_cpsw_netdevice_event(struct notifier_block *unused,
+unsigned long event, void *ptr)
+{
+ struct net_device *ndev = netdev_notifier_info_to_dev(ptr);
+ struct netdev_notifier_changeupper_info *info;
+ int ret = NOTIFY_DONE;
+
+ if (!am65_cpsw_port_dev_check(ndev))
+ return NOTIFY_DONE;
+
+ switch (event) {
+ case NETDEV_CHANGEUPPER:
+ info = ptr;
+
+ if (netif_is_bridge_master(info->upper_dev)) {
+ if (info->linking)
+ ret = am65_cpsw_netdevice_port_link(ndev,
info->upper_dev);
+ else
+ am65_cpsw_netdevice_port_unlink(ndev);
+ }
+ break;
+ default:
+ return NOTIFY_DONE;
+ }
+
+ return notifier_from_errno(ret);
+}
+
+static int am65_cpsw_register_notifiers(struct am65_cpsw_common *cpsw)
+{
+ int ret = 0;
+
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return 0;
+
+ cpsw->am65_cpsw_netdevice_nb.notifier_call = _cpsw_netdevice_event;
+ ret = register_netdevice_notifier(>am65_cpsw_netdevice_nb);
+ if (ret) {
+ dev_err(cpsw->dev, "can't register netdevice notifier\n");
+ return ret;
+ }
+
+ return ret;
+}
+
+static void am65_cpsw_unregister_notifiers(struct am65_cpsw_common *cpsw)
+{
+ if (AM65_CPSW_IS_CPSW2G(cpsw) ||
+ !IS_REACHABLE(CONFIG_TI_K3_AM65_CPSW_SWITCHDEV))
+ return;
+
+ unregister_netdevice_notifier(>am65_cpsw_netdevice_nb);
+}
+
static const struct devlink_ops am65_cpsw_devlink_ops = {};
static void am65_cpsw_init_stp_ale_entry(struct am65_cpsw_common *cpsw)
@@ -2366,17 +2486,24 @@ static int am65_cpsw_nuss_register_ndevs(struct
am65_cpsw_common *common)
}
}
- ret = am65_cpsw_nuss_register_devlink(common);
+ ret = am65_cpsw_register_notifiers(common);
if (ret)
goto
[PATCH 0/4] net: ti: am65-cpsw-nuss: Add switchdev driver
This series adds switchdev support for AM65 CPSW NUSS driver to support multi port CPSW present on J721e and AM64 SoCs. It adds devlink hook to switch b/w switch mode and multi mac mode. Vignesh Raghavendra (4): net: ti: am65-cpsw-nuss: Add devlink support net: ti: am65-cpsw-nuss: Add netdevice notifiers net: ti: am65-cpsw-nuss: Add switchdev support docs: networking: ti: Add driver doc for AM65 NUSS switch driver .../device_drivers/ethernet/index.rst | 1 + .../ethernet/ti/am65_nuss_cpsw_switchdev.rst | 143 + .../devlink/am65-nuss-cpsw-switch.rst | 26 + Documentation/networking/devlink/index.rst| 1 + drivers/net/ethernet/ti/Kconfig | 10 + drivers/net/ethernet/ti/Makefile | 1 + drivers/net/ethernet/ti/am65-cpsw-nuss.c | 511 +++- drivers/net/ethernet/ti/am65-cpsw-nuss.h | 26 + drivers/net/ethernet/ti/am65-cpsw-switchdev.c | 572 ++ drivers/net/ethernet/ti/am65-cpsw-switchdev.h | 34 ++ 10 files changed, 1306 insertions(+), 19 deletions(-) create mode 100644 Documentation/networking/device_drivers/ethernet/ti/am65_nuss_cpsw_switchdev.rst create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.c create mode 100644 drivers/net/ethernet/ti/am65-cpsw-switchdev.h -- 2.29.2
[PATCH 1/4] net: ti: am65-cpsw-nuss: Add devlink support
AM65 NUSS ethernet switch on K3 devices can be configured to work either
in independent mac mode where each port acts as independent network
interface (multi mac) or switch mode.
Add devlink hooks to provide a way to switch b/w these modes.
Signed-off-by: Vignesh Raghavendra
---
.../devlink/am65-nuss-cpsw-switch.rst | 26 ++
Documentation/networking/devlink/index.rst| 1 +
drivers/net/ethernet/ti/Kconfig | 10 +
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 363 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.h | 22 ++
5 files changed, 404 insertions(+), 18 deletions(-)
create mode 100644 Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
diff --git a/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
new file mode 100644
index ..1e589c26abff
--- /dev/null
+++ b/Documentation/networking/devlink/am65-nuss-cpsw-switch.rst
@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+am65-cpsw-nuss devlink support
+==
+
+This document describes the devlink features implemented by the
``am65-cpsw-nuss``
+device driver.
+
+Parameters
+==
+
+The ``am65-cpsw-nuss`` driver implements the following driver-specific
+parameters.
+
+.. list-table:: Driver-specific parameters implemented
+ :widths: 5 5 5 85
+
+ * - Name
+ - Type
+ - Mode
+ - Description
+ * - ``switch_mode``
+ - Boolean
+ - runtime
+ - Enable switch mode
diff --git a/Documentation/networking/devlink/index.rst
b/Documentation/networking/devlink/index.rst
index d82874760ae2..b9064d6f4a6d 100644
--- a/Documentation/networking/devlink/index.rst
+++ b/Documentation/networking/devlink/index.rst
@@ -44,3 +44,4 @@ parameters, info versions, and other features it supports.
sja1105
qed
ti-cpsw-switch
+ am65-nuss-cpsw-switch
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index abfc4c435d59..affcf92cd3aa 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -92,6 +92,7 @@ config TI_CPTS
config TI_K3_AM65_CPSW_NUSS
tristate "TI K3 AM654x/J721E CPSW Ethernet driver"
depends on ARCH_K3 && OF && TI_K3_UDMA_GLUE_LAYER
+ select NET_DEVLINK
select TI_DAVINCI_MDIO
imply PHY_TI_GMII_SEL
depends on TI_K3_AM65_CPTS || !TI_K3_AM65_CPTS
@@ -105,6 +106,15 @@ config TI_K3_AM65_CPSW_NUSS
To compile this driver as a module, choose M here: the module
will be called ti-am65-cpsw-nuss.
+config TI_K3_AM65_CPSW_SWITCHDEV
+ bool "TI K3 AM654x/J721E CPSW Switch mode support"
+ depends on TI_K3_AM65_CPSW_NUSS
+ depends on NET_SWITCHDEV
+ help
+This enables switchdev support for TI K3 CPSWxG Ethernet
+Switch. Enable this driver to support hardware switch support for AM65
+CPSW NUSS driver.
+
config TI_K3_AM65_CPTS
tristate "TI K3 AM65x CPTS"
depends on ARCH_K3 && OF
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index 766e8866bbef..a635f6be7979 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -406,6 +406,11 @@ void am65_cpsw_nuss_set_p0_ptype(struct am65_cpsw_common
*common)
writel(val, host_p->port_base + AM65_CPSW_PORT_REG_PRI_CTL);
}
+static void am65_cpsw_init_host_port_switch(struct am65_cpsw_common *common);
+static void am65_cpsw_init_host_port_emac(struct am65_cpsw_common *common);
+static void am65_cpsw_init_port_switch_ale(struct am65_cpsw_port *port);
+static void am65_cpsw_init_port_emac_ale(struct am65_cpsw_port *port);
+
static int am65_cpsw_nuss_common_open(struct am65_cpsw_common *common,
netdev_features_t features)
{
@@ -452,9 +457,6 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
ALE_DEFAULT_THREAD_ID, 0);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
ALE_DEFAULT_THREAD_ENABLE, 1);
- if (AM65_CPSW_IS_CPSW2G(common))
- cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
-ALE_PORT_NOLEARN, 1);
/* switch to vlan unaware mode */
cpsw_ale_control_set(common->ale, HOST_PORT_NUM, ALE_VLAN_AWARE, 1);
cpsw_ale_control_set(common->ale, HOST_PORT_NUM,
@@ -468,6 +470,11 @@ static int am65_cpsw_nuss_common_open(struct
am65_cpsw_common *common,
port_mask, port_mask,
port_mask & ~ALE_PORT_HOST);
+ if (common->is_emac_mode)
+ am65_cpsw_init_host_port_emac(common);
+ else
+ am65_cpsw_init_host_port_switch(common);
+
for (i = 0; i < common-&g
Re: [PATCH 2/2] arm64: dts: ti: k3-j7200-common-proc-board: Correct the name of io expander on main_i2c1
On 11/19/20 6:56 PM, Peter Ujfalusi wrote:
> J7200 main_i2c1 is connected to the i2c bus on the CPB marked as main_i2c3
>
> The i2c1 devices on the CPB are _not_ connected to the SoC, they are not
> usable with the J7200 SOM.
>
> Correct the expander name from exp4 to exp3 and at the same time add the
> line names as well.
>
> Signed-off-by: Peter Ujfalusi
> ---
Yes, the schematics call this expander as exp3. Thanks for the fix
Reviewed-by: Vignesh Raghavendra
> arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index 2721137d8943..83e043c65f81 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -159,11 +159,14 @@ _i2c1 {
> pinctrl-0 = <_i2c1_pins_default>;
> clock-frequency = <40>;
>
> - exp4: gpio@20 {
> + exp3: gpio@20 {
> compatible = "ti,tca6408";
> reg = <0x20>;
> gpio-controller;
> #gpio-cells = <2>;
> + gpio-line-names = "CODEC_RSTz", "CODEC_SPARE1", "UB926_RESETn",
> + "UB926_LOCK", "UB926_PWR_SW_CNTRL",
> + "UB926_TUNER_RESET", "UB926_GPIO_SPARE", "";
I assume these lines have same meaning in J721e and J7200? If so, then
no issues.
> };
> };
>
>
Re: [PATCH 1/2] arm64: dts: ti: k3-j7200-som-p0: main_i2c0 have an ioexpander on the SOM
On 11/19/20 6:56 PM, Peter Ujfalusi wrote:
> It is used to control several SOM level muxes to make sure that the correct
> signals are routed to the correct pin on the SOM <-> CPB connectors.
>
> Signed-off-by: Peter Ujfalusi
> ---
Yes, there is indeed a I2C GPIO expander on SOM that's missing from DT
today. So this change looks good to me.
Reviewed-by: Vignesh Raghavendra
Regards
Vignesh
> .../dts/ti/k3-j7200-common-proc-board.dts | 11
> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi | 26 +++
> 2 files changed, 26 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index 6b3863108571..2721137d8943 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -43,13 +43,6 @@ J721E_WKUP_IOPAD(0x0098, PIN_INPUT, 0) /* (L4)
> MCU_MDIO0_MDIO */
> };
>
> _pmx0 {
> - main_i2c0_pins_default: main-i2c0-pins-default {
> - pinctrl-single,pins = <
> - J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
> */
> - J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
> */
> - >;
> - };
> -
> main_i2c1_pins_default: main-i2c1-pins-default {
> pinctrl-single,pins = <
> J721E_IOPAD(0xdc, PIN_INPUT_PULLUP, 3) /* (U3)
> ECAP0_IN_APWM_OUT.I2C1_SCL */
> @@ -146,10 +139,6 @@ _port1 {
> };
>
> _i2c0 {
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c0_pins_default>;
> - clock-frequency = <40>;
> -
> exp1: gpio@20 {
> compatible = "ti,tca6416";
> reg = <0x20>;
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> index fbd17d38f6b6..7b5e9aa0324e 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi
> @@ -48,6 +48,15 @@ J721E_WKUP_IOPAD(0x28, PIN_INPUT, 1) /* (A7)
> MCU_OSPI0_D7.MCU_HYPERBUS0_DQ7 */
> };
> };
>
> +_pmx0 {
> + main_i2c0_pins_default: main-i2c0-pins-default {
> + pinctrl-single,pins = <
> + J721E_IOPAD(0xd4, PIN_INPUT_PULLUP, 0) /* (V3) I2C0_SCL
> */
> + J721E_IOPAD(0xd8, PIN_INPUT_PULLUP, 0) /* (W2) I2C0_SDA
> */
> + >;
> + };
> +};
> +
> {
> /* OSPI and HBMC are muxed inside FSS, Bootloader will enable
>* appropriate node based on board detection
> @@ -131,3 +140,20 @@ _cluster10 {
> _cluster11 {
> status = "disabled";
> };
> +
> +_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> +
> + exp_som: gpio@21 {
> + compatible = "ti,tca6408";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "USB2.0_MUX_SEL", "CANUART_MUX1_SEL0",
> + "CANUART_MUX2_SEL0", "CANUART_MUX_SEL1",
> + "UART/LIN_MUX_SEL",
> "TRC_D17/AUDIO_REFCLK_SEL",
> + "GPIO_LIN_EN", "CAN_STB";
> + };
> +};
>
Re: [PATCH v8 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
On 11/19/20 11:25 AM, Ramuthevar,Vadivel MuruganX wrote: > Add QSPI controller support for Intel LGM SoC. > > Note from Vignesh(mtd subsystem maintainer): > This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add > support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX > that intended to move > cadence-quadspi driver to spi-mem framework > > Those patches were trying to accomplish too many things in a single set > of patches and need to split into smaller patches. This is reduced > version of above series. > > Changes that are intended to make migration easy are split into separate > patches. Patches 1 to 3 drop features that cannot be supported under > spi-mem at the moment (backward compatibility is maintained). > Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to > spi-mem and patch 7 moves the driver to drivers/spi folder. > This text no longer makes sense anymore with few patches dropped and others reordered > I have tested both INDAC mode (used by non TI platforms like Altera > SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. > > Patches to move move bindings over to > "Documentation/devicetree/bindings/spi/" directory and also conversion > of bindig doc to YAML will be posted separately. Support for Intel > platform would follow that. > > Reference: > https://lkml.org/lkml/2020/6/1/50 > > --- > v8: > - As Mark suggested to add the dt-bindings documentation patches > end of the series , so dropped. > > Ramuthevar Vadivel Murugan (6): > spi: cadence-quadspi: Add QSPI support for Intel LGM SoC > spi: cadence-quadspi: Disable the DAC for Intel LGM SoC > spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC > spi: Move cadence-quadspi.txt to Documentation/devicetree/bindings/spi > dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml > dt-bindings: spi: Add compatible for Intel LGM SoC > This is quite confusing... Summary/diffstat still shows patches 4 to 6 and so does the patch numbering in $subject while changelog says otherwise and I received only 3 patches in my Inbox? > .../devicetree/bindings/mtd/cadence-quadspi.txt| 67 -- > .../devicetree/bindings/spi/cdns,qspi-nor.yaml | 148 > + > drivers/spi/Kconfig| 2 +- > drivers/spi/spi-cadence-quadspi.c | 33 - > 4 files changed, 178 insertions(+), 72 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt > create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml > So does the diffstat...
Re: [PATCH v8 3/6] spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
On 11/19/20 11:25 AM, Ramuthevar,Vadivel MuruganX wrote:
> From: Ramuthevar Vadivel Murugan
>
> Add multiple chipselect support for Intel LGM SoCs,
> currently QSPI-NOR and QSPI-NAND supported.
>
> Signed-off-by: Ramuthevar Vadivel Murugan
>
> ---
> drivers/spi/spi-cadence-quadspi.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/spi/spi-cadence-quadspi.c
> b/drivers/spi/spi-cadence-quadspi.c
> index d12b765e87be..337778f75d5d 100644
> --- a/drivers/spi/spi-cadence-quadspi.c
> +++ b/drivers/spi/spi-cadence-quadspi.c
> @@ -38,6 +38,7 @@
>
> /* Capabilities */
> #define CQSPI_SUPPORTS_OCTAL BIT(0)
> +#define CQSPI_SUPPORTS_MULTI_CHIPSELECT BIT(1)
>
> struct cqspi_st;
>
> @@ -75,6 +76,7 @@ struct cqspi_st {
> boolis_decoded_cs;
> u32 fifo_depth;
> u32 fifo_width;
> + u32 num_chipselect;
> boolrclk_en;
> u32 trigger_address;
> u32 wr_delay;
> @@ -1049,6 +1051,7 @@ static int cqspi_of_get_flash_pdata(struct
> platform_device *pdev,
>
> static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
> {
> + const struct cqspi_driver_platdata *ddata;
Unused variable?
> struct device *dev = >pdev->dev;
> struct device_node *np = dev->of_node;
>
> @@ -1070,6 +1073,14 @@ static int cqspi_of_get_pdata(struct cqspi_st *cqspi)
> return -ENXIO;
> }
>
> + ddata = of_device_get_match_data(dev);
> + if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT) {
I don't see a need for this flag... Controller by default supports
multiple CS.
> + if (of_property_read_u32(np, "num-cs", >num_chipselect))
> {
> + dev_err(dev, "couldn't determine number of cs\n");
> + return -ENXIO;
> + }
> + }
> +
Entire hunk can be replaced with:
if (of_property_read_u32(np, "num-cs", >num_chipselect))
cqspi->num_chipselect = CQSPI_MAX_CHIPSELECT;
> cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
>
> return 0;
> @@ -1302,6 +1313,9 @@ static int cqspi_probe(struct platform_device *pdev)
> cqspi->current_cs = -1;
> cqspi->sclk = 0;
>
> + if (ddata->hwcaps_mask & CQSPI_SUPPORTS_MULTI_CHIPSELECT)
> + master->num_chipselect = cqspi->num_chipselect;
> +
And then this becomes:
master->num_chipselect = cqspi->num_chipselect;
> ret = cqspi_setup_flash(cqspi);
> if (ret) {
> dev_err(dev, "failed to setup flash parameters %d\n", ret);
> @@ -1391,6 +1405,7 @@ static const struct cqspi_driver_platdata am654_ospi = {
> };
>
> static const struct cqspi_driver_platdata intel_lgm_qspi = {
> + .hwcaps_mask = CQSPI_SUPPORTS_MULTI_CHIPSELECT,
> .quirks = CQSPI_DISABLE_DAC_MODE,
> };
>
>
Re: [PATCH v8 0/6] spi: cadence-quadspi: Add QSPI controller support for Intel LGM SoC
On 11/19/20 11:25 AM, Ramuthevar,Vadivel MuruganX wrote: > Add QSPI controller support for Intel LGM SoC. > > Note from Vignesh(mtd subsystem maintainer): > This series is a subset of "[PATCH v12 0/4] spi: cadence-quadspi: Add > support for the Cadence QSPI controller" by Ramuthevar,Vadivel MuruganX > that intended to move > cadence-quadspi driver to spi-mem framework > > Those patches were trying to accomplish too many things in a single set > of patches and need to split into smaller patches. This is reduced > version of above series. > > Changes that are intended to make migration easy are split into separate > patches. Patches 1 to 3 drop features that cannot be supported under > spi-mem at the moment (backward compatibility is maintained). > Patch 4-5 are trivial cleanups. Patch 6 does the actual conversion to > spi-mem and patch 7 moves the driver to drivers/spi folder. > > I have tested both INDAC mode (used by non TI platforms like Altera > SoCFPGA) and DAC mode (used by TI platforms) on TI EVMs. > > Patches to move move bindings over to > "Documentation/devicetree/bindings/spi/" directory and also conversion > of bindig doc to YAML will be posted separately. Support for Intel > platform would follow that. > > Reference: > https://lkml.org/lkml/2020/6/1/50 > > --- > v8: > - As Mark suggested to add the dt-bindings documentation patches > end of the series , so dropped. Suggestion was to drop patches converting legacy binding doc to YAML schema. You still need to include a patch documenting new compatible "intel,lgm-qspi" in the existing (legacy) binding doc.
Re: [PATCH v2 5/7] arm64: dts: ti: k3-j7200-main: Add PCIe device tree node
On 11/9/20 10:34 PM, Kishon Vijay Abraham I wrote: > Add PCIe device tree node (both RC and EP) for the single PCIe > instance present in j7200. > nit: s/j7200/J7200 > Signed-off-by: Kishon Vijay Abraham I > --- Reviewed-by: Vignesh Raghavendra [...]
Re: [PATCH v2 6/7] arm64: dts: ti: k3-j7200-common-proc-board: Enable SERDES0
On 11/9/20 10:34 PM, Kishon Vijay Abraham I wrote:
> Add sub-nodes to SERDES0 DT node to represent SERDES0 is connected
> to PCIe and QSGMII (multi-link SERDES).
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> .../dts/ti/k3-j7200-common-proc-board.dts | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index ef03e7636b66..65a2e5aeb050 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -8,6 +8,7 @@
> #include "k3-j7200-som-p0.dtsi"
> #include
> #include
> +#include
>
> / {
> chosen {
> @@ -213,3 +214,25 @@
> dr_mode = "otg";
> maximum-speed = "high-speed";
> };
> +
> +_refclk {
> + clock-frequency = <1>;
> +};
Since this is a reference clk from the board, should the entire node be
here instead of in k3-j7200-main.dtsi?
> +
> + {
> + serdes0_pcie_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <2>;
> + #phy-cells = <0>;
> + cdns,phy-type = ;
> + resets = <_wiz0 1>, <_wiz0 2>;
> + };
> +
> + serdes0_qsgmii_link: phy@1 {
> + reg = <2>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = ;
> + resets = <_wiz0 3>;
> + };
> +};
>
Re: [PATCH V2 5/5] arm64: dts: ti: am65/j721e/j7200: Mark firmware used uart as "reserved"
On 11/12/20 7:19 AM, Nishanth Menon wrote: > Follow the device tree standards that states to set the > status="reserved" if an device is operational, but used by a non-linux > firmware in the system. > > Signed-off-by: Nishanth Menon > --- Acked-by: Vignesh Raghavendra
Re: [PATCH v2 7/7] arm64: dts: ti: k3-j7200-common-proc-board: Enable PCIe
On 11/9/20 10:34 PM, Kishon Vijay Abraham I wrote:
> x2 lane PCIe slot in the common processor board is enabled and connected to
> j7200 SOM. Add PCIe DT node in common processor board to reflect the
> same.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
Reviewed-by: Vignesh Raghavendra
> .../boot/dts/ti/k3-j7200-common-proc-board.dts| 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> index 65a2e5aeb050..174a55a18522 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include "k3-j7200-som-p0.dtsi"
> +#include
> #include
> #include
> #include
> @@ -236,3 +237,17 @@
> resets = <_wiz0 3>;
> };
> };
> +
> +_rc {
> + reset-gpios = < 2 GPIO_ACTIVE_HIGH>;
> + phys = <_pcie_link>;
> + phy-names = "pcie-phy";
> + num-lanes = <2>;
> +};
> +
> +_ep {
> + phys = <_pcie_link>;
> + phy-names = "pcie-phy";
> + num-lanes = <2>;
> + status = "disabled";
> +};
>
Re: drivers/mtd/maps/physmap-bt1-rom.c:78:18: sparse: sparse: cast removes address space '__iomem' of expression
On 11/12/20 1:57 PM, Miquel Raynal wrote: > Hi Sergey, > > Serge Semin wrote on Wed, 11 Nov > 2020 22:22:59 +0300: > >> On Tue, Nov 10, 2020 at 04:35:56PM +0100, Miquel Raynal wrote: >>> Hi Serge, >>> >>> Serge Semin wrote on Tue, 10 Nov >>> 2020 14:38:27 +0300: >>> Hello Miquel, A situation noted by the warning below won't cause any problem because the casting is done to a non-dereferenced variable. It is utilized as a pointer bias later in that function. Shall we just ignore the warning or still fix it somehow? >>> >> >>> Do you think the cast to a !__iomem value is mandatory here? >> >> It's not mandatory to have the casting with no __iomem, but wouldn't >> doing like this: >> +shift = (ssize_t __iomem)src & 0x3; >> be looking weird? Really, is there a good way to somehow extract the first >> two bits of a __iomem pointer without getting the sparse warning? > > I asked around me, what about trying uintptr_t? > One more way is to use __force to tell sparse that this casting is intentional: shift = (__force ssize_t)src & 0x3; > Thanks, > Miquèl > > __ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ >
[PATCH 2/2] serial: 8250: 8250_omap: Fix unused variable warning
With commit 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after
DMA enable"),
below warning is seen with W=1 and CONFIG_SERIAL_8250_DMA is disabled:
drivers/tty/serial/8250/8250_omap.c:1199:42: warning: unused variable
'k3_soc_devices' [-Wunused-const-variable]
Fix this by moving the code using k3_soc_devices array to
omap_serial_fill_features_erratas() that handles other errata flags as
well.
Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA
enable")
Reported-by: kernel test robot
Signed-off-by: Vignesh Raghavendra
---
drivers/tty/serial/8250/8250_omap.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index ab18ef035659..0ab6517d389a 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -539,6 +539,11 @@ static void omap_8250_pm(struct uart_port *port, unsigned
int state,
static void omap_serial_fill_features_erratas(struct uart_8250_port *up,
struct omap8250_priv *priv)
{
+ const struct soc_device_attribute k3_soc_devices[] = {
+ { .family = "AM65X", },
+ { .family = "J721E", .revision = "SR1.0" },
+ { /* sentinel */ }
+ };
u32 mvr, scheme;
u16 revision, major, minor;
@@ -586,6 +591,14 @@ static void omap_serial_fill_features_erratas(struct
uart_8250_port *up,
default:
break;
}
+
+ /*
+* AM65x SR1.0, AM65x SR2.0 and J721e SR1.0 don't
+* don't have RHR_IT_DIS bit in IER2 register. So drop to flag
+* to enable errata workaround.
+*/
+ if (soc_device_match(k3_soc_devices))
+ priv->habit &= ~UART_HAS_RHR_IT_DIS;
}
static void omap8250_uart_qos_work(struct work_struct *work)
@@ -1196,12 +1209,6 @@ static int omap8250_no_handle_irq(struct uart_port *port)
return 0;
}
-static const struct soc_device_attribute k3_soc_devices[] = {
- { .family = "AM65X", },
- { .family = "J721E", .revision = "SR1.0" },
- { /* sentinel */ }
-};
-
static struct omap8250_dma_params am654_dma = {
.rx_size = SZ_2K,
.rx_trigger = 1,
@@ -1406,13 +1413,6 @@ static int omap8250_probe(struct platform_device *pdev)
up.dma->rxconf.src_maxburst = RX_TRIGGER;
up.dma->txconf.dst_maxburst = TX_TRIGGER;
}
-
- /*
-* AM65x SR1.0, AM65x SR2.0 and J721e SR1.0 don't
-* don't have RHR_IT_DIS bit in IER2 register
-*/
- if (soc_device_match(k3_soc_devices))
- priv->habit &= ~UART_HAS_RHR_IT_DIS;
}
#endif
ret = serial8250_register_8250_port();
--
2.29.2
[PATCH 1/2] serial: 8250: 8250_omap: Fix possible array out of bounds access
k3_soc_devices array is missing a sentinel entry which may result in out
of bounds access as reported by kernel KASAN.
Fix this by adding a sentinel entry.
Fixes: 439c7183e5b9 ("serial: 8250: 8250_omap: Disable RX interrupt after DMA
enable")
Reported-by: Naresh Kamboju
Signed-off-by: Vignesh Raghavendra
---
drivers/tty/serial/8250/8250_omap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 084e7bc51f0e..ab18ef035659 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1199,6 +1199,7 @@ static int omap8250_no_handle_irq(struct uart_port *port)
static const struct soc_device_attribute k3_soc_devices[] = {
{ .family = "AM65X", },
{ .family = "J721E", .revision = "SR1.0" },
+ { /* sentinel */ }
};
static struct omap8250_dma_params am654_dma = {
--
2.29.2
Re: BUG: KASAN: global-out-of-bounds in soc_device_match on arm
Hi Naresh, On 11/11/20 12:08 PM, Stephen Rothwell wrote: > Hi Naresh, > > On Wed, 11 Nov 2020 11:55:46 +0530 Naresh Kamboju > wrote: >> >> The following kernel warning noticed on arm KASAN enabled config while >> booting on >> TI beagleboard x15 device. >> >> [ 32.127451] BUG: KASAN: global-out-of-bounds in soc_device_match+0x64/0xe4 >> [ 32.127485] Read of size 4 at addr c21701f8 by task swapper/0/1 >> [ 32.127508] >> [ 32.127549] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW >> 5.10.0-rc3-next-20201110 #2 >> [ 32.127577] Hardware name: Generic DRA74X (Flattened Device Tree) >> [ 32.127604] Backtrace: >> [ 32.127670] [] (dump_backtrace) from [] >> (show_stack+0x20/0x24) >> [ 32.127717] r9:0080 r8:c4208000 r7:c3023060 r6:4093 >> r5: r4:c3023060 >> [ 32.127766] [] (show_stack) from [] >> (dump_stack+0xe8/0x10c) >> [ 32.127824] [] (dump_stack) from [] >> (print_address_description.constprop.0+0x3c/0x4b0) >> [ 32.127871] r10:0030 r9:c5da4010 r8:c5da4000 r7: >> r6:c0fd5c20 r5:eebf33c0 >> [ 32.127903] r4:c21701f8 r3:eebf33c4 >> [ 32.127958] [] (print_address_description.constprop.0) >> from [] (kasan_report+0x160/0x17c) >> [ 32.128000] r8:c5da4000 r7: r6:c0fd5c20 r5:0001 r4:c21701f8 >> [ 32.128053] [] (kasan_report) from [] >> (__asan_load4+0x6c/0x9c) >> [ 32.128093] r7:c3c3ede0 r6:c354dea0 r5:c0fd5b88 r4:c21701f8 >> [ 32.128144] [] (__asan_load4) from [] >> (soc_device_match+0x64/0xe4) >> [ 32.128197] [] (soc_device_match) from [] >> (omap8250_probe+0x628/0x75c) >> [ 32.128236] r7:b7841730 r6:c6db2c4e r5:0001 r4:c6db2c40 >> [ 32.128290] [] (omap8250_probe) from [] >> (platform_drv_probe+0x70/0xc8) >> [ 32.128335] r10:c5da4044 r9:c5da4048 r8:c34ff834 r7:c3c3e240 >> r6:c34ff834 r5: >> [ 32.128363] r4:c5da4010 >> [ 32.128413] [] (platform_drv_probe) from [] >> (really_probe+0x184/0x72c) >> [ 32.128452] r7:c3c3e240 r6: r5:c3c3e1c0 r4:c5da4010 >> [ 32.128499] [] (really_probe) from [] >> (driver_probe_device+0xa4/0x270) >> [ 32.128544] r10:c34ff834 r9:c416fa58 r8:c379e840 r7:c5d75a00 >> r6:c5da4034 r5:c37c01c0 >> [ 32.128572] r4:c5da4010 >> [ 32.128620] [] (driver_probe_device) from [] >> (device_driver_attach+0x94/0x9c) >> [ 32.128665] r10: r9:c416fa58 r8:c0f956b4 r7:c5d75a00 >> r6:c5da4034 r5:c34ff834 >> [ 32.128693] r4:c5da4010 >> [ 32.128741] [] (device_driver_attach) from [] >> (__driver_attach+0xe4/0x19c) >> [ 32.128780] r7:c34ff834 r6:c5da4010 r5:c34ff834 r4: >> [ 32.128826] [] (__driver_attach) from [] >> (bus_for_each_dev+0x100/0x154) >> [ 32.128865] r7:c34ff834 r6:b78417a4 r5:c420bd40 r4:c5d75a34 >> [ 32.128910] [] (bus_for_each_dev) from [] >> (driver_attach+0x38/0x3c) >> [ 32.128955] r9:c34ff87c r8:c416fa00 r7:c3541a70 r6:c3541a20 >> r5:c6db4f00 r4:c34ff834 >> [ 32.129001] [] (driver_attach) from [] >> (bus_add_driver+0x21c/0x2dc) >> [ 32.129034] r5:c6db4f00 r4:c34ff834 >> [ 32.129080] [] (bus_add_driver) from [] >> (driver_register+0xdc/0x1b0) >> [ 32.129125] r10: r9:c2b00468 r8:c378a0c0 r7:c2170360 >> r6:c34ff838 r5:c3541a20 >> [ 32.129153] r4:c34ff834 >> [ 32.129202] [] (driver_register) from [] >> (__platform_driver_register+0x7c/0x84) >> [ 32.129241] r7:c000 r6:c2bc509c r5: r4:c34ff820 >> [ 32.129300] [] (__platform_driver_register) from >> [] (omap8250_platform_driver_init+0x24/0x28) >> [ 32.129333] r5:c420bf20 r4:b78417d0 >> [ 32.129387] [] (omap8250_platform_driver_init) from >> [] (do_one_initcall+0xc4/0x400) >> [ 32.129437] [] (do_one_initcall) from [] >> (kernel_init_freeable+0x214/0x268) >> [ 32.129482] r10:c2d128a8 r9:c2b00468 r8:c2c50834 r7:c2c50854 >> r6:c2a55ac8 r5:0007 >> [ 32.129511] r4:c425a700 >> [ 32.129563] [] (kernel_init_freeable) from [] >> (kernel_init+0x18/0x140) >> [ 32.129607] r10: r9: r8: r7: >> r6: r5:c19bfd04 >> [ 32.129635] r4: >> [ 32.129684] [] (kernel_init) from [] >> (ret_from_fork+0x14/0x38) >> [ 32.129715] Exception stack(0xc420bfb0 to 0xc420bff8) >> [ 32.129753] bfa0: >> >> [ 32.129798] bfc0: >> >> [ 32.129839] bfe0: 0013 >> [ 32.129872] r5:c19bfd04 r4: >> [ 32.129894] >> [ 32.129917] The buggy address belongs to the variable: >> [ 32.129957] k3_soc_devices+0x38/0x1e0 >> [ 32.129981] The buggy address belongs to the page: >> [ 32.130018] page:(ptrval) refcount:1 mapcount:0 mapping: >> index:0x0 pfn:0x82170 >> [ 32.130051] flags: 0x1000(reserved) >> [ 32.130104] raw: 1000 eebf33c4 eebf33c4 >> 0001 >> [ 32.130133] raw: >> [ 32.130159] page dumped because: kasan: bad access detected >> [
Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver
Hi Chin-Ting, On 11/6/20 11:57 PM, Chin-Ting Kuo wrote: > Hi Boris, > >> -Original Message- >> From: Boris Brezillon >> Sent: Friday, November 6, 2020 7:30 PM >> To: Chin-Ting Kuo >> Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller >> driver >> >> +Tudor and Vignesh >> >> On Fri, 6 Nov 2020 10:21:06 + >> Chin-Ting Kuo wrote: >> >>> Hi Boris, >>> >>> Thanks for your comments and suggestions. >>> -Original Message- From: Boris Brezillon Sent: Friday, November 6, 2020 5:06 PM To: Chin-Ting Kuo Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver On Fri, 6 Nov 2020 08:58:23 + Chin-Ting Kuo wrote: > Hi Boris, > > Thanks for your quick reply. > >> -Original Message- >> From: Boris Brezillon >> Sent: Thursday, November 5, 2020 11:12 PM >> To: Cédric Le Goater ; robh...@kernel.org >> Cc: Chin-Ting Kuo ; >> broo...@kernel.org; j...@jms.id.au; and...@aj.id.au; >> bbrezil...@kernel.org; devicet...@vger.kernel.org; >> linux-kernel@vger.kernel.org; linux-asp...@lists.ozlabs.org; >> linux-...@vger.kernel.org; BMC-SW >> Subject: Re: [v3 4/4] spi: aspeed: Add ASPEED FMC/SPI memory >> controller driver >> >> Hi, >> >> On Thu, 5 Nov 2020 15:09:11 +0100 Cédric Le Goater >> wrote: >> >>> Hello Chin-Ting, >>> >>> Thanks for this driver. It's much cleaner than the previous >>> and we should try adding support for the AST2500 SoC also. I >>> guess we can keep the old driver for the AST2400 which has a >> different register layout. >>> >>> On the patchset, I think we should split this patch in three : >>> >>> - basic support >>> - AHB window calculation depending on the flash size >>> - read training support >> >> I didn't look closely at the implementation, but if the read >> training tries to read a section of the NOR, I'd recommend >> exposing that feature through spi-mem and letting the SPI-NOR >> framework trigger the training instead of doing that at dirmap >> creation time (remember that spi-mem is also used for SPI NANDs >> which use the dirmap API too, and this training is unlikely to work there). >> >> The SPI-NOR framework could pass a read op template and a >> reference pattern such that all the spi-mem driver has to do is >> execute the template op and compare the output to the reference >> buffer. >> > > I agree it. Before, I were not able to find a suitable location to > implement read training feature. > I think that I can add a SPI timing training function in > "spi_controller_mem_ops" struct and call it by a wrapper function > called at the bottom of spi_nor_probe() in spi-nor.c. > Maybe, SPI-NOR framework does not need to pass reference buffer > since calibration method depends on each SoC itself and buffer > size may be variant. > The detail calibration method may be implemented in each SoC SPI >> driver. That's a real problem IMO. What makes this pattern SoC specific? I can see why the location in flash could be *board* specific, but the pattern should be pretty common, right? As for the spi-mem operation to be executed, it's definitely memory specific (I can imagine some flash vendors providing a specific command returning a fixed pattern that's not actually stored on a visible portion of the flash). >>> >>> You are right, the pattern should be pretty common. The thing I was >>> worried about is the size of that buffer since, maybe, some >>> controllers need to read more data than others in order to get good training >> result. >> >> It would be good to see how other controllers implement that. I know that the >> Cadence controller had something similar. Vignesh might be able to share his >> thoughts on this. > Cadence controllers requires to read fixed length calibration pattern multiple times (while tuning PHY registers) from non zero address location. Pattern is Flash independent and SoC independent. Hence, can be hard coded in driver (no need to read at slower speed). > Oh, maybe, I misunderstood your meaning and I did not describe clearly early. > As you mentioned before, for some SPI-NOR flashes, there indeed exists a > command used for > read timing training with high SPI clock frequency. > When this specific command is sent, an almost common pattern with fixed > length will be outputted to controller. > (This pattern is not stored on a normal read/write area.) > > But, unfortunately, many flash parts we used did not support this feature. > Thus, our read timing training strategy is: > Step 1: Use the lowest SPI clock frequency to read normal flash content with > specific length as reference data. > Step 2: With a fixed high SPI clock frequency, adjust different timing delay > cycle,
Re: [PATCH] mtd: spi-nor: Fix multiple typos
Hi,
On 11/7/20 7:11 PM, Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer
Thanks for the patch, but a commit msg is expected however trivial the
patch maybe. scripts/checkpatch.pl --strict complains about the same:
WARNING: Missing commit description - Add an appropriate one
Regards
Vignesh
> ---
> drivers/mtd/spi-nor/core.c | 4 ++--
> drivers/mtd/spi-nor/sfdp.c | 2 +-
> include/linux/mtd/spi-nor.h | 2 +-
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index 0369d98b2d12e..85c0704945259 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -1447,7 +1447,7 @@ static int spi_nor_erase_multi_sectors(struct spi_nor
> *nor, u64 addr, u32 len)
>
> /*
> * Erase an address range on the nor chip. The address range may extend
> - * one or more erase sectors. Return an error is there is a problem erasing.
> + * one or more erase sectors. Return an error if there is a problem erasing.
> */
> static int spi_nor_erase(struct mtd_info *mtd, struct erase_info *instr)
> {
> @@ -2537,7 +2537,7 @@ spi_nor_select_uniform_erase(struct spi_nor_erase_map
> *map,
> }
>
> /*
> - * Otherwise, the current erase size is still a valid canditate.
> + * Otherwise, the current erase size is still a valid candidate.
>* Select the biggest valid candidate.
>*/
> if (!erase && tested_erase->size)
> diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
> index e2a43d39eb5f4..05b22c6576832 100644
> --- a/drivers/mtd/spi-nor/sfdp.c
> +++ b/drivers/mtd/spi-nor/sfdp.c
> @@ -59,7 +59,7 @@ struct sfdp_bfpt_read {
>
> struct sfdp_bfpt_erase {
> /*
> - * The half-word at offset in DWORD encodes the
> + * The half-word at offset in DWORD encodes the
>* op code and erase sector size to be used by Sector Erase commands.
>*/
> u32 dword;
> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
> index 60bac2c0ec456..582ee04eeea20 100644
> --- a/include/linux/mtd/spi-nor.h
> +++ b/include/linux/mtd/spi-nor.h
> @@ -406,7 +406,7 @@ static inline struct device_node
> *spi_nor_get_flash_node(struct spi_nor *nor)
> * @name:the chip type name
> * @hwcaps: the hardware capabilities supported by the controller driver
> *
> - * The drivers can use this fuction to scan the SPI NOR.
> + * The drivers can use this function to scan the SPI NOR.
> * In the scanning, it will try to get all the necessary information to
> * fill the mtd_info{} and the spi_nor{}.
> *
> --
> 2.28.0
>
Re: [PATCH v5 0/3] mtd: spi-nor: keep lock bits if they are non-volatile
On 10/28/20 3:56 AM, Michael Walle wrote: > Am 2020-10-03 17:32, schrieb Michael Walle: >> I bundled this as a series, because otherwise there will be conflicts >> because the "remove global protection flag" patches modify the same lines >> as the main patch. >> >> See invdividual patches for the version history. > > any news here? > LGTM, thanks!... Will wait for Tudor's Ack before applying. Regards Vignesh
Re: [PATCH] mtd: spi-nor: winbond: Add support for w25m512jw
On 10/16/20 5:25 PM, Lad Prabhakar wrote:
> This chip is (nearly) identical to the Winbond w25m512jv which is
> already supported by Linux. Compared to the w25m512jv, the 'jw'
> has a different JEDEC ID.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Biju Das
I believe this was tested on a real HW? Including Quad mode?
> ---
> drivers/mtd/spi-nor/winbond.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/winbond.c b/drivers/mtd/spi-nor/winbond.c
> index 6dcde15fb1aa..b5dfc09fef30 100644
> --- a/drivers/mtd/spi-nor/winbond.c
> +++ b/drivers/mtd/spi-nor/winbond.c
> @@ -88,6 +88,8 @@ static const struct flash_info winbond_parts[] = {
>SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> { "w25m512jv", INFO(0xef7119, 0, 64 * 1024, 1024,
> SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
> + { "w25m512jw", INFO(0xef6119, 0, 64 * 1024, 1024,
> + SECT_4K | SPI_NOR_QUAD_READ | SPI_NOR_DUAL_READ) },
> };
>
> /**
>
Re: [PATCH v16 00/15] mtd: spi-nor: add xSPI Octal DTR support
On Mon, 5 Oct 2020 21:01:23 +0530, Pratyush Yadav wrote:
> This series adds support for Octal DTR flashes in the SPI NOR framework,
> and then adds hooks for the Cypress Semper and Micron Xcella flashes to
> allow running them in Octal DTR mode. This series assumes that the flash
> is handed to the kernel in Legacy SPI mode.
>
> Tested on Micron MT35X and S28HS flashes for Octal DTR. Tested on Micron
> MT25Q, and Cypress S25FL for regressions. All flashes were tested by
> running a read/write stress test on top of UBIFS. On the Cypress S28HS
> flash 1-bit ECC had to be used to allow UBIFS to work since partial page
> writes don't work with 2-bit ECC.
>
> [...]
With comments on 14/15 addressed:
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
spi-nor/next, thanks!
[01/15] mtd: spi-nor: core: use EOPNOTSUPP instead of ENOTSUPP
https://git.kernel.org/mtd/c/39bdfb789b
[02/15] mtd: spi-nor: add spi_nor_controller_ops_{read_reg, write_reg, erase}()
https://git.kernel.org/mtd/c/6e1bf55d72
[03/15] mtd: spi-nor: add support for DTR protocol
https://git.kernel.org/mtd/c/0e30f47232
[04/15] mtd: spi-nor: sfdp: get command opcode extension type from BFPT
https://git.kernel.org/mtd/c/0e1b2fc4e5
[05/15] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
https://git.kernel.org/mtd/c/fb27f19897
[06/15] mtd: spi-nor: core: use dummy cycle and address width info from SFDP
https://git.kernel.org/mtd/c/6c6a2b2b8e
[07/15] mtd: spi-nor: core: do 2 byte reads for SR and FSR in DTR mode
https://git.kernel.org/mtd/c/354b412967
[08/15] mtd: spi-nor: Introduce SNOR_F_IO_MODE_EN_VOLATILE
https://git.kernel.org/mtd/c/c6908077b1
[09/15] mtd: spi-nor: Parse SFDP SCCR Map
https://git.kernel.org/mtd/c/981a8d60e0
[10/15] mtd: spi-nor: core: enable octal DTR mode when possible
https://git.kernel.org/mtd/c/a33c89db4c
[11/15] mtd: spi-nor: sfdp: detect Soft Reset sequence support from BFPT
https://git.kernel.org/mtd/c/1131324aa5
[12/15] mtd: spi-nor: core: perform a Soft Reset on shutdown
https://git.kernel.org/mtd/c/d73ee7534c
[13/15] mtd: spi-nor: core: disable Octal DTR mode on suspend.
https://git.kernel.org/mtd/c/1b65c43f70
[14/15] mtd: spi-nor: spansion: add support for Cypress Semper flash
https://git.kernel.org/mtd/c/c3266af101
[15/15] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
https://git.kernel.org/mtd/c/ad624dfd7b
--
Regards
Vignesh
Re: [PATCH v16 14/15] mtd: spi-nor: spansion: add support for Cypress Semper flash
Hi,
[...]
On 10/5/20 9:01 PM, Pratyush Yadav wrote:
> +static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor, bool enable)
> +{
> + struct spi_mem_op op;
> + u8 *buf = nor->bouncebuf;
> + int ret;
> +
> + if (enable) {
> + /* Use 24 dummy cycles for memory array reads. */
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + *buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
> +SPI_MEM_OP_ADDR(3, SPINOR_REG_CYPRESS_CFR2V,
> +1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + if (ret)
> + return ret;
> +
> + ret = spi_nor_wait_till_ready(nor);
> + if (ret)
> + return ret;
> +
> + nor->read_dummy = 24;
> + }
> +
> + /* Set/unset the octal and DTR enable bits. */
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + if (enable)
> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
> + else
> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS;
> +
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
> +SPI_MEM_OP_ADDR(enable ? 3 : 4,
> +SPINOR_REG_CYPRESS_CFR5V,
> +1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + if (!enable)
> + spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + if (ret)
> + return ret;
> +
> + /* Give some time for the mode change to take place. */
> + usleep_range(1000, 1500);
> +
This delay is no longer needed right? I can drop it while applying, if
you confirm.
Tudor: Could you provide your R-by?
Regards
Vignesh
Re: [PATCH 07/23] mtd: spi-nor: controllers: hisi-sfc: Demote non-conformant kernel-doc
On 11/2/20 5:23 PM, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter
> or member 'np' not described in 'hisi_spi_nor_register'
> drivers/mtd/spi-nor/controllers/hisi-sfc.c:328: warning: Function parameter
> or member 'host' not described in 'hisi_spi_nor_register'
>
> Cc: Tudor Ambarus
> Cc: Miquel Raynal
> Cc: Richard Weinberger
> Cc: Vignesh Raghavendra
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-...@lists.infradead.org
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Lee Jones
> ---
> drivers/mtd/spi-nor/controllers/hisi-sfc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> b/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> index 95c502173cbda..7c26f8f565cba 100644
> --- a/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> +++ b/drivers/mtd/spi-nor/controllers/hisi-sfc.c
> @@ -320,7 +320,7 @@ static const struct spi_nor_controller_ops
> hisi_controller_ops = {
> .write = hisi_spi_nor_write,
> };
>
> -/**
> +/*
> * Get spi flash device information and register it as a mtd device.
> */
> static int hisi_spi_nor_register(struct device_node *np,
>
Reviewed-by: Vignesh Raghavendra
Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it
On 11/3/20 6:15 PM, Pratyush Yadav wrote: > On 03/11/20 05:05PM, Vignesh Raghavendra wrote: >> >> >> On 11/1/20 3:14 AM, Richard Weinberger wrote: >>> On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav wrote: >>>>> [0] >>>>> https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.ya...@ti.com/ >>>> >>>> Ping. Any comments on the series? >>> >>> From the UBIFS point of view I'd like to avoid as many device specific >>> settings as possible. >>> We check already for NOR flash, checking for NOR *and* >>> SPI_NOR_NO_MULTI_PASS_PP >>> feels a bit clumsy. >>> >>> Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP? >>> This kind of NOR seems to be a little NAND'ish. Maybe we can hide this >>> detail >>> in the mtd framework? >>> >> >> Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From >> MTD point of view setting mtd->writesize to be equal to pagesize should >> be enough. Its upto clients of MTD devices to ensure there is no multi >> pass programming within a "writesize" block. > > That is what I initially thought too but then I realized that multi-pass > programming is completely different from page-size programming. Instead > of writing 4 bytes twice, you can zero out the entire page in one single > operation. You would be compliant with the write size requirement but > you still do multi-pass programming because you did not erase the page > before this operation. > Right... > It is also not completely correct to say the Cypress S28 flash has a > write size of 256. You _can_ write one byte if you want. You just can't > write to that page again without erasing it first. For example, if a > file system only wants to write 128 bytes on a page, it can do so > without having to write the whole page. It just needs to make sure it > doesn't write to it again without erasing first. > As per documentation: mtd_info::writesize: "In case of ECC-ed NOR it is of ECC block size" This means, it is block on which ECC is calculated on ECC-ed NOR and thus needs to be erased every time before being updated. Looking at flash datasheet, this seems to be 16 bytes. So mtd->writesize = 16 and not 256 (or pagesize) Also, It does not imply length of data being written has to be multiple of it. At least NAND subsystem does not seem to care that during writes len < mtd->writesize[1]. > nor_erase_prepare() was written to handle quirks of some specific > devices. Not every device starts filling zeroes from the end of a page. > So we have device-specific code in UBIFS already. You will obviously > need device-specific settings to have control over that code. > UBIFS intends to be robust against rogue power cuts and therefore would need to ensure some consistency during erase which explains flash specific quirk here. > One might argue that we should move nor_erase_prepare() out of UBIFS. > But requiring a flash to start erasing from the start of the page is a > UBIFS-specific requirement. Other users of a flash might not care about > it at all. > Yes. But I don't see much harm done. > And so we have ourselves a bit of a conundrum. Adding > SPI_NOR_NO_MULTI_PASS_PP is IMHO the least disruptive answer. If the > file system wants to do multi-pass page programming on NOR flashes, how > else do we tell it not to do it for this specific flash? > I see don't see need for SPI_NOR_NO_MULTI_PASS_PP as SPI_NOR_NO_MULTI_PASS_PP is implied within a ECC block and writesize is supposed to represent the same. >> If this is not clear in the current documentation of struct mtd, then >> that can be updated. > [1] https://elixir.bootlin.com/linux/latest/source/drivers/mtd/nand/raw/nand_base.c#L4166
Re: [PATCH 2/3] UBI: Do not zero out EC and VID when multi-pass writes are not supported
On 10/12/20 11:34 PM, Pratyush Yadav wrote:
> For NOR flashes EC and VID are zeroed out before an erase is issued to
> make sure UBI does not mistakenly treat the PEB as used and associate it
> with an LEB.
>
> But on some flashes, like the Cypress Semper S28 SPI NOR flash family,
> multi-pass page programming is not allowed on the default ECC scheme.
> This means zeroing out these magic numbers will result in the flash
> throwing a page programming error.
>
> Do not zero out EC and VID when multi-pass writes are not supported.
>
> Signed-off-by: Pratyush Yadav
> ---
> drivers/mtd/ubi/io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/ubi/io.c b/drivers/mtd/ubi/io.c
> index 14d890b00d2c..4023fc4886e3 100644
> --- a/drivers/mtd/ubi/io.c
> +++ b/drivers/mtd/ubi/io.c
> @@ -535,7 +535,7 @@ int ubi_io_sync_erase(struct ubi_device *ubi, int pnum,
> int torture)
> return -EROFS;
> }
>
> - if (ubi->nor_flash) {
> + if (ubi->nor_flash && !(ubi->mtd->flags & MTD_NO_MULTI_PASS_WRITE)) {
> err = nor_erase_prepare(ubi, pnum);
> if (err)
> return err;
>
You may want to get rid of assertion for mtd->writesize != 1 in case of
MTD_NORFLASH.
See drivers/mtd/ubi/build.c::631
if (ubi->mtd->type == MTD_NORFLASH) {
ubi_assert(ubi->mtd->writesize == 1);
ubi->nor_flash = 1;
}
Regards
Vignesh
Re: [PATCH 0/3] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it
On 11/1/20 3:14 AM, Richard Weinberger wrote: > On Tue, Oct 27, 2020 at 12:24 PM Pratyush Yadav wrote: >>> [0] https://lore.kernel.org/linux-mtd/20201005153138.6437-1-p.ya...@ti.com/ >> >> Ping. Any comments on the series? > > From the UBIFS point of view I'd like to avoid as many device specific > settings as possible. > We check already for NOR flash, checking for NOR *and* > SPI_NOR_NO_MULTI_PASS_PP > feels a bit clumsy. > > Tudor, what do you think about SPI_NOR_NO_MULTI_PASS_PP? > This kind of NOR seems to be a little NAND'ish. Maybe we can hide this detail > in the mtd framework? > Agree with Richard. I don't see need for SPI_NOR_NO_MULTI_PASS_PP. From MTD point of view setting mtd->writesize to be equal to pagesize should be enough. Its upto clients of MTD devices to ensure there is no multi pass programming within a "writesize" block. If this is not clear in the current documentation of struct mtd, then that can be updated. Regards Vignesh
Re: [PATCH] pwm: tiehrpwm: handle deferred probe with dev_err_probe()
On 10/31/20 1:42 AM, Grygorii Strashko wrote:
> The devm_clk_get() may return -EPROBE_DEFER which is not handled properly
> by TI EHRPWM driver and causes unnecessary boot log messages.
>
> Hence, add proper deferred probe handling with new dev_err_probe() API.
>
> Signed-off-by: Grygorii Strashko
> ---
Reviewed-by: Vignesh Raghavendra
> drivers/pwm/pwm-tiehrpwm.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
> index 0846917ff2d2..14c8fdcfd607 100644
> --- a/drivers/pwm/pwm-tiehrpwm.c
> +++ b/drivers/pwm/pwm-tiehrpwm.c
> @@ -437,10 +437,8 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
> }
> }
>
> - if (IS_ERR(clk)) {
> - dev_err(>dev, "failed to get clock\n");
> - return PTR_ERR(clk);
> - }
> + if (IS_ERR(clk))
> + return dev_err_probe(>dev, PTR_ERR(clk), "Failed to get
> fck\n");
>
> pc->clk_rate = clk_get_rate(clk);
> if (!pc->clk_rate) {
> @@ -462,10 +460,8 @@ static int ehrpwm_pwm_probe(struct platform_device *pdev)
>
> /* Acquire tbclk for Time Base EHRPWM submodule */
> pc->tbclk = devm_clk_get(>dev, "tbclk");
> - if (IS_ERR(pc->tbclk)) {
> - dev_err(>dev, "Failed to get tbclk\n");
> - return PTR_ERR(pc->tbclk);
> - }
> + if (IS_ERR(pc->tbclk))
> + return dev_err_probe(>dev, PTR_ERR(pc->tbclk), "Failed to
> get tbclk\n");
>
> ret = clk_prepare(pc->tbclk);
> if (ret < 0) {
>
Re: [PATCH] mtd: spi-nor: Don't copy self-pointing struct around
On Mon, 5 Oct 2020 10:48:03 +0200, Alexander A Sverdlin wrote: > spi_nor_parse_sfdp() modifies the passed structure so that it points to > itself (params.erase_map.regions to params.erase_map.uniform_region). This > makes it impossible to copy the local struct anywhere else. > > Therefore only use memcpy() in backup-restore scenario. The bug may show up > like below: > > [...] Updated Fixes tag as suggested by Tudor. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/fixes, thanks! [1/1] mtd: spi-nor: Don't copy self-pointing struct around https://git.kernel.org/mtd/c/69a8eed58c -- Regards Vignesh
Re: [RESEND PATCH v2] mtd: spi-nor: Fix address width on flash chips > 16MB
On Tue, 6 Oct 2020 15:23:46 +0200, Bert Vermeulen wrote: > If a flash chip has more than 16MB capacity but its BFPT reports > BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3. > > The check in spi_nor_set_addr_width() doesn't catch it because addr_width > did get set. This fixes that check. Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git mtd/fixes, thanks! [1/1] mtd: spi-nor: Fix address width on flash chips > 16MB https://git.kernel.org/mtd/c/324f78dfb4 -- Regards Vignesh
[PATCH] serial: 8250: 8250_omap: Disable RX interrupt after DMA enable
UARTs on TI SoCs prior to J7200 don't provide independent control over
RX FIFO not empty interrupt (RHR_IT) and RX timeout interrupt.
Starting with J7200 SoC, its possible to disable RHR_IT independent of
RX timeout interrupt using bit 2 of IER2 register. So disable RHR_IT
once RX DMA is started so as to avoid spurious interrupt being raised
when data is in the RX FIFO but is yet to be drained by DMA (a known
errata in older SoCs).
Signed-off-by: Vignesh Raghavendra
---
drivers/tty/serial/8250/8250_omap.c | 42 -
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 562087df7d33..084e7bc51f0e 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "8250.h"
@@ -41,6 +42,7 @@
*/
#define UART_ERRATA_CLOCK_DISABLE (1 << 3)
#defineUART_HAS_EFR2 BIT(4)
+#define UART_HAS_RHR_IT_DISBIT(5)
#define OMAP_UART_FCR_RX_TRIG 6
#define OMAP_UART_FCR_TX_TRIG 4
@@ -94,6 +96,10 @@
#define OMAP_UART_REV_52 0x0502
#define OMAP_UART_REV_63 0x0603
+/* Interrupt Enable Register 2 */
+#define UART_OMAP_IER2 0x1B
+#define UART_OMAP_IER2_RHR_IT_DIS BIT(2)
+
/* Enhanced features register 2 */
#define UART_OMAP_EFR2 0x23
#define UART_OMAP_EFR2_TIMEOUT_BEHAVE BIT(6)
@@ -761,17 +767,27 @@ static void __dma_rx_do_complete(struct uart_8250_port *p)
{
struct uart_8250_dma*dma = p->dma;
struct tty_port *tty_port = >port.state->port;
+ struct omap8250_priv*priv = p->port.private_data;
struct dma_chan *rxchan = dma->rxchan;
dma_cookie_tcookie;
struct dma_tx_state state;
int count;
int ret;
+ u32 reg;
if (!dma->rx_running)
goto out;
cookie = dma->rx_cookie;
dma->rx_running = 0;
+
+ /* Re-enable RX FIFO interrupt now that transfer is complete */
+ if (priv->habit & UART_HAS_RHR_IT_DIS) {
+ reg = serial_in(p, UART_OMAP_IER2);
+ reg &= ~UART_OMAP_IER2_RHR_IT_DIS;
+ serial_out(p, UART_OMAP_IER2, UART_OMAP_IER2_RHR_IT_DIS);
+ }
+
dmaengine_tx_status(rxchan, cookie, );
count = dma->rx_size - state.residue + state.in_flight_bytes;
@@ -867,6 +883,7 @@ static int omap_8250_rx_dma(struct uart_8250_port *p)
int err = 0;
struct dma_async_tx_descriptor *desc;
unsigned long flags;
+ u32 reg;
if (priv->rx_dma_broken)
return -EINVAL;
@@ -902,6 +919,17 @@ static int omap_8250_rx_dma(struct uart_8250_port *p)
dma->rx_cookie = dmaengine_submit(desc);
+ /*
+* Disable RX FIFO interrupt while RX DMA is enabled, else
+* spurious interrupt may be raised when data is in the RX FIFO
+* but is yet to be drained by DMA.
+*/
+ if (priv->habit & UART_HAS_RHR_IT_DIS) {
+ reg = serial_in(p, UART_OMAP_IER2);
+ reg |= UART_OMAP_IER2_RHR_IT_DIS;
+ serial_out(p, UART_OMAP_IER2, UART_OMAP_IER2_RHR_IT_DIS);
+ }
+
dma_async_issue_pending(dma->rxchan);
out:
spin_unlock_irqrestore(>rx_dma_lock, flags);
@@ -1168,6 +1196,11 @@ static int omap8250_no_handle_irq(struct uart_port *port)
return 0;
}
+static const struct soc_device_attribute k3_soc_devices[] = {
+ { .family = "AM65X", },
+ { .family = "J721E", .revision = "SR1.0" },
+};
+
static struct omap8250_dma_params am654_dma = {
.rx_size = SZ_2K,
.rx_trigger = 1,
@@ -1182,7 +1215,7 @@ static struct omap8250_dma_params am33xx_dma = {
static struct omap8250_platdata am654_platdata = {
.dma_params = _dma,
- .habit = UART_HAS_EFR2,
+ .habit = UART_HAS_EFR2 | UART_HAS_RHR_IT_DIS,
};
static struct omap8250_platdata am33xx_platdata = {
@@ -1372,6 +1405,13 @@ static int omap8250_probe(struct platform_device *pdev)
up.dma->rxconf.src_maxburst = RX_TRIGGER;
up.dma->txconf.dst_maxburst = TX_TRIGGER;
}
+
+ /*
+* AM65x SR1.0, AM65x SR2.0 and J721e SR1.0 don't
+* don't have RHR_IT_DIS bit in IER2 register
+*/
+ if (soc_device_match(k3_soc_devices))
+ priv->habit &= ~UART_HAS_RHR_IT_DIS;
}
#endif
ret = serial8250_register_8250_port();
--
2.29.0
[RESEND PATCH] arm64: dts: ti: k3-j7200-mcu-wakeup: Enable ADC support
J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node
for the same.
Signed-off-by: Vignesh Raghavendra
---
Resending, after rebasing and testing on top of 5.10-rc1. No code
change.
v1: https://lore.kernel.org/r/20201013081650.26090-1-vigne...@ti.com
.../dts/ti/k3-j7200-common-proc-board.dts | 6 ++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 19 +++
2 files changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index ef03e7636b66..7d2ff1c3b50f 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -213,3 +213,9 @@ {
dr_mode = "otg";
maximum-speed = "high-speed";
};
+
+ {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index eb2a78a53512..bb1fe9c12e44 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -270,4 +270,23 @@ hbmc: hyperbus@47034000 {
mux-controls = <_mux 0>;
};
};
+
+ tscadc0: tscadc@4020 {
+ compatible = "ti,am3359-tscadc";
+ reg = <0x00 0x4020 0x00 0x1000>;
+ interrupts = ;
+ power-domains = <_pds 0 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 0 1>;
+ assigned-clocks = <_clks 0 3>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+ dmas = <_udmap 0x7400>,
+ <_udmap 0x7401>;
+ dma-names = "fifo0", "fifo1";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am3359-adc";
+ };
+ };
};
--
2.29.0
Re: [PATCH v16 00/15] mtd: spi-nor: add xSPI Octal DTR support
On 10/28/20 8:51 PM, tudor.amba...@microchip.com wrote: > On 10/28/20 2:49 PM, Pratyush Yadav wrote: >> EXTERNAL EMAIL: Do not click links or open attachments unless you know the >> content is safe >> >> Hi Tudor, >> >> On 28/10/20 07:53AM, tudor.amba...@microchip.com wrote: >>> Hi, Pratyush, >>> >>> On 10/5/20 6:31 PM, Pratyush Yadav wrote: Tested on Micron MT35X and S28HS flashes for Octal DTR. >>> >>> Do these flashes define the "Command Sequences to Change to >>> Octal DDR (8D-8D-8D) mode" table? Can't we use that table >>> instead of defining our own octal dtr enable functions? >> >> The Micron flash does not have this table. The Cypress flash does. The >> problem is that one of the samples of the Cypress flash I tested on had >> incorrect data in that table which meant the sequence would fail. The >> newer samples of the flash have the correct data. > > Can we differentiate the Cypress flashes? Do you remember what > was the incorrect data? > >> >> I don't know how many of those faulty flashes are out there in the wild. >> IMO, to be on the safe side spi_nor_cypress_octal_dtr_enable() needs to >> be implemented. So from the point of view of this series there is no >> need to parse the Octal DDR enable table. > > Meh, we cover manufacturer's mistakes. On the long run, our aim should be > to follow the SFDP standard and if a flash implements it wrong, to either > fix it via a fixup hook (if the fix is minimal), or to skip the faulty > table. > > Regarding "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" > table. Have you looked over > https://patchwork.ozlabs.org/project/linux-mtd/patch/1590737775-4798-4-git-send-email-masonccy...@mxic.com.tw/ > ? > Is there a standard way to determine the offsets of opcode, addr and > data in the cmd seq? > There is no standard way of doing this and I recommend against it. Each cmd seq has 0 to 7 Bytes. So the sequence maybe: 1 cmd byte-3 addr bytes- 3 data bytes or 1 cmd byte-0 address bytes-6 data bytes We could just assume first byte to be command and rest to be data bytes always, but one problem maybe that controller may not support data length to be so long when address phase is absent. Eg.: Cadence OSPI controller supports only upto 8 bytes length transfers in absence of address phase but other controllers may limit the length further? One more drawback of using "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table is that it not only switches flash to 8D mode but also configures flash to be in: - 50 ohm I/O driver strength (Driver Type 0, mandatory for xSPI devices) - 20 dummy cycles for Read Fast commands - Operation at 100MHz (or higher, if supported) Note that 20 dummy cycles may not be enough for flashes to operate at 166/200MHz or higher and thus requiring flash specific fixups. So, I am beginning to doubt if parsing "Command Sequences to Change to Octal DDR (8D-8D-8D) mode" table is worth it. Not to mention we still need flash specific code to "verify" that mode switch is indeed successful. Regards Vignesh
[PATCH] dt-bindings: serial: 8250_omap: Add compatible for UART controller on AM64 SoC
AM64 uses a UART controller that is compatible with AM654 UART. Introduce a specific compatible to help handle the differences if necessary. Signed-off-by: Vignesh Raghavendra --- Documentation/devicetree/bindings/serial/omap_serial.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index dcba86b0a0d0..c2db8cabf2ab 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -1,6 +1,7 @@ OMAP UART controller Required properties: +- compatible : should be "ti,am64-uart", "ti,am654-uart" for AM64 controllers - compatible : should be "ti,j721e-uart", "ti,am654-uart" for J721E controllers - compatible : should be "ti,am654-uart" for AM654 controllers - compatible : should be "ti,omap2-uart" for OMAP2 controllers -- 2.29.0
[PATCH] arm64: dts: ti: k3-j7200-mcu-wakeup: Enable ADC support
J7200 has a single instance of 8 channel ADC in MCU domain. Add DT node
for the same.
Signed-off-by: Vignesh Raghavendra
---
.../dts/ti/k3-j7200-common-proc-board.dts | 6 ++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 19 +++
2 files changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index ef03e7636b66..7d2ff1c3b50f 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -213,3 +213,9 @@ {
dr_mode = "otg";
maximum-speed = "high-speed";
};
+
+ {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5 6 7>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
index eb2a78a53512..bb1fe9c12e44 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
@@ -270,4 +270,23 @@ hbmc: hyperbus@47034000 {
mux-controls = <_mux 0>;
};
};
+
+ tscadc0: tscadc@4020 {
+ compatible = "ti,am3359-tscadc";
+ reg = <0x00 0x4020 0x00 0x1000>;
+ interrupts = ;
+ power-domains = <_pds 0 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <_clks 0 1>;
+ assigned-clocks = <_clks 0 3>;
+ assigned-clock-rates = <6000>;
+ clock-names = "adc_tsc_fck";
+ dmas = <_udmap 0x7400>,
+ <_udmap 0x7401>;
+ dma-names = "fifo0", "fifo1";
+
+ adc {
+ #io-channel-cells = <1>;
+ compatible = "ti,am3359-adc";
+ };
+ };
};
--
2.28.0
[PATCH] mtd: hyperbus: Fix build failure when only RPCIF_HYPERBUS is enabled
commit 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") leads
to build failure[1] with COMPILE_TEST and RPCIF_HYPERBUS enabled. This
is because driver needs functions RENESAS_RPCIF which is only buildable
for CONFIG_ARCH_RENESAS.
Fix this by dropping COMPILE_TEST from RPCIF_HYPERBUS Kconfig entry.
This ensures driver can be built only when RENESAS_RPCIF is also
selected.
[1]:
rpc-if.c:(.text+0x20): undefined reference to `rpcif_disable_rpm' ld:
drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_prepare_read':
rpc-if.c:(.text+0xd6): undefined reference to `rpcif_prepare' ld:
drivers/mtd/hyperbus/rpc-if.o: in function `rpcif_hb_read16':
[...]
Fixes: 5de15b610f78 ("mtd: hyperbus: add Renesas RPC-IF driver") leads
Reported-by: Richard Weinberger
Signed-off-by: Vignesh Raghavendra
---
Based on mtd/next
Richard,
Could you please pull this into mtd/next?
drivers/mtd/hyperbus/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig
index 35b3ab4c8b94..46c7e407e378 100644
--- a/drivers/mtd/hyperbus/Kconfig
+++ b/drivers/mtd/hyperbus/Kconfig
@@ -24,7 +24,7 @@ config HBMC_AM654
config RPCIF_HYPERBUS
tristate "Renesas RPC-IF HyperBus driver"
- depends on RENESAS_RPCIF || COMPILE_TEST
+ depends on RENESAS_RPCIF
depends on MTD_CFI_BE_BYTE_SWAP
help
This option includes Renesas RPC-IF HyperBus support.
--
2.28.0
Re: [RESEND PATCH v2] mtd: spi-nor: Fix address width on flash chips > 16MB
On 10/6/20 8:48 PM, Pratyush Yadav wrote:
> On 06/10/20 03:23PM, Bert Vermeulen wrote:
>> If a flash chip has more than 16MB capacity but its BFPT reports
>> BFPT_DWORD1_ADDRESS_BYTES_3_OR_4, the spi-nor framework defaults to 3.
>>
>> The check in spi_nor_set_addr_width() doesn't catch it because addr_width
>> did get set. This fixes that check.
>>
>> Fixes: f9acd7fa80be ("mtd: spi-nor: sfdp: default to addr_width of 3 for
>> configurable widths")
>> Signed-off-by: Bert Vermeulen
>> Reviewed-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/core.c | 8 +---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index 0369d98b2d12..a2c35ad9645c 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -3009,13 +3009,15 @@ static int spi_nor_set_addr_width(struct spi_nor
>> *nor)
>> /* already configured from SFDP */
>> } else if (nor->info->addr_width) {
>> nor->addr_width = nor->info->addr_width;
>> -} else if (nor->mtd.size > 0x100) {
>> -/* enable 4-byte addressing if the device exceeds 16MiB */
>> -nor->addr_width = 4;
>> } else {
>> nor->addr_width = 3;
>> }
>>
>> +if (nor->addr_width == 3 && nor->mtd.size > 0x100) {
> Nitpick: you can drop this part. But its
> fine either way.
>
I don't think its a good idea to drop nor->addr_width == 3 check as
nor->info->addr_width is permitted to have a value > 4 (although there
is no such flash today)...
> Reviewed-by: Pratyush Yadav
>
>> +/* enable 4-byte addressing if the device exceeds 16MiB */
>> +nor->addr_width = 4;
>> +}
>> +
>> if (nor->addr_width > SPI_NOR_MAX_ADDR_WIDTH) {
>> dev_dbg(nor->dev, "address width is too large: %u\n",
>> nor->addr_width);
>
Regards
Vignesh
Re: [PATCH] Revert "mtd: spi-nor: Prefer asynchronous probe"
On Mon, 5 Oct 2020 14:33:21 +0530, Vignesh Raghavendra wrote: > This reverts commit 03edda0e1edaa3c2e99239c66e3c14d749318fd6. > > This leads to warn dump like [1] on some platforms and reorders MTD > devices thus may break user space expectations. So revert the change. > > [1]: > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git spi-nor/next, thanks! [1/1] Revert "mtd: spi-nor: Prefer asynchronous probe" https://git.kernel.org/mtd/c/9a3422a110 -- Regards Vignesh
Re: [PATCH] mtd: spi-nor: Prefer asynchronous probe
Hi Michael, On 10/3/20 10:24 PM, Michael Walle wrote: > Hi Douglas, > > Am 2020-10-03 18:27, schrieb Doug Anderson: >> Hi, >> >> On Sat, Oct 3, 2020 at 8:22 AM Michael Walle wrote: >>> >>> Hi Douglas, >>> >>> > On my system the spi_nor_probe() took ~6 ms at bootup. That's not a >>> > lot, but every little bit adds up to a slow bootup. While we can get >>> > this out of the boot path by making it a module, there are times where >>> > it is convenient (or even required) for this to be builtin the kernel. >>> > Let's set that we prefer async probe so that we don't block other >>> > drivers from probing while we are probing. >>> > >>> > This is a tiny little change that is almost guaranteed to be safe for >>> > anything that is able to run as a module, which SPI_NOR is. >>> > Specifically modules are already probed asynchronously. Also: since >>> > other things in the system may have enabled asynchronous probe the >>> > system may already be doing other things during our probe. >>> > >>> > There is a small possibility that some other driver that was a client >>> > of SPI_NOR didn't handle -EPROBE_DEFER and was relying on probe >>> > ordering and only worked when the SPI_NOR and the SPI bus were >>> > builtin. In that case the other driver has a bug that's waiting to >>> > hit and the other driver should be fixed. >>> >>> linux-next now triggers the following warning in kernel/kmod.c:136 on my >>> board. I've bisected this to this patch. >>> [...] >> >> Thanks for your report! My vote would be to revert my patch and then >> this would need to be resolved before it could be added back in. >> Without doing tons of research, maybe the right answer here is that >> mtd_device_parse_register() should be moved into a separate task so >> it's not blocking probe? I probably won't try to tackle this >> immediately, but the eventual goal is that async is default, so I >> think this would need to be resolved before then. > > Ok. Vignesh, will you take care of that? Thanks for the report! I have posted a patch reverting this commit. Will merge into spi-nor/next shortly Regards Vignesh
[PATCH] Revert "mtd: spi-nor: Prefer asynchronous probe"
This reverts commit 03edda0e1edaa3c2e99239c66e3c14d749318fd6.
This leads to warn dump like [1] on some platforms and reorders MTD
devices thus may break user space expectations. So revert the change.
[1]:
[1.849801] [ cut here ]
[1.854271] mscc_felix :00:00.5: device is disabled, skipping
[1.858753] WARNING: CPU: 1 PID: 7 at kernel/kmod.c:136
__request_module+0x3a4/0x568
[...]
Reported-by: Michael Walle
Signed-off-by: Vignesh Raghavendra
---
drivers/mtd/spi-nor/core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index 2add4a01fce2..0369d98b2d12 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3451,7 +3451,6 @@ static struct spi_mem_driver spi_nor_driver = {
.driver = {
.name = "spi-nor",
.of_match_table = spi_nor_of_table,
- .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.id_table = spi_nor_dev_ids,
},
--
2.28.0
Re: [PATCH v15 14/15] mtd: spi-nor: spansion: add support for Cypress Semper flash
Hi Pratyush,
On 10/2/20 1:50 AM, Pratyush Yadav wrote:
> +
> +/**
> + * spi_nor_cypress_octal_dtr_enable() - Enable octal DTR on Cypress flashes.
> + * @nor: pointer to a 'struct spi_nor'
> + * @enable: whether to enable or disable Octal DTR
> + *
> + * This also sets the memory access latency cycles to 24 to allow the flash
> to
> + * run at up to 200MHz.
> + *
> + * Return: 0 on success, -errno otherwise.
> + */
> +static int spi_nor_cypress_octal_dtr_enable(struct spi_nor *nor, bool enable)
> +{
> + struct spi_mem_op op;
> + u8 *buf = nor->bouncebuf;
> + int ret;
> +
> + if (enable) {
> + /* Use 24 dummy cycles for memory array reads. */
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + *buf = SPINOR_REG_CYPRESS_CFR2V_MEMLAT_11_24;
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
> +SPI_MEM_OP_ADDR(3, SPINOR_REG_CYPRESS_CFR2V,
> +1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + if (ret)
> + return ret;
> +
> + ret = spi_nor_wait_till_ready(nor);
> + if (ret)
> + return ret;
> +
> + nor->read_dummy = 24;
> + }
> +
> + /* Set/unset the octal and DTR enable bits. */
> + ret = spi_nor_write_enable(nor);
> + if (ret)
> + return ret;
> +
> + if (enable)
> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_EN;
> + else
> + *buf = SPINOR_REG_CYPRESS_CFR5V_OCT_DTR_DS;
> +
> + op = (struct spi_mem_op)
> + SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WR_ANY_REG, 1),
> +SPI_MEM_OP_ADDR(enable ? 3 : 4,
> +SPINOR_REG_CYPRESS_CFR5V,
> +1),
> +SPI_MEM_OP_NO_DUMMY,
> +SPI_MEM_OP_DATA_OUT(1, buf, 1));
> +
> + if (!enable)
> + spi_nor_spimem_setup_op(nor, , SNOR_PROTO_8_8_8_DTR);
> +
> + ret = spi_mem_exec_op(nor->spimem, );
> + if (ret)
> + return ret;
> +
> + /* Give some time for the mode change to take place. */
> + usleep_range(1000, 1500);
> +
According to datasheet, it seems switch to Octal DTR mode is immediate.
So, I don't think this delay is necessary. Instead as a confirmation
that mode switch is successful can we just read back
SPINOR_REG_CYPRESS_CFR5V in Octal DTR mode and see if value reflects
what was written?
Same applies for 15/15 as well.
> + return 0;
> +}
> +
Re: [PATCH v14 01/15] mtd: spi-nor: core: use EOPNOTSUPP instead of ENOTSUPP
Hi, On 10/1/20 1:20 PM, Miquel Raynal wrote: > Hello, > > Pratyush Yadav wrote on Thu, 1 Oct 2020 13:04:27 +0530: > >> On 01/10/20 07:19AM, tudor.amba...@microchip.com wrote: >>> On 9/30/20 9:57 PM, Pratyush Yadav wrote: EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > It seems that your mailer/server introduced that line automatically, > can you do something to avoid it? > ENOTSUPP is not a SUSV4 error code. Using EOPNOTSUPP is preferred in its stead. > > I ran into this checkpatch.pl error recently, I count 80+ iterations in > drivers/mtd/ so perhaps having a subsystem wide replacement will be > nice. I'm fine with this patch though as it is addressing all SPI-NOR > cases already. > Yeah, since this is SPI NOR wide I will go ahead and apply. Also, this would avoid confusion for ppl adding new code on whether to address the checkpatch warning or follow the existing convention. Regards Vignesh > Cheers, > Miquèl > [...]
Re: [PATCH v3] mtd: spi-nor: keep lock bits if they are non-volatile
On 10/1/20 4:21 AM, Michael Walle wrote: > Am 2020-09-30 12:35, schrieb Vignesh Raghavendra: > [..] >>> Signed-off-by: Michael Walle >>> --- >>> changes since v2: >>> - add Kconfig option to be able to retain legacy behaviour >>> - rebased the patch due to the spi-nor rewrite >>> - dropped the Fixes: tag, it doens't make sense after the spi-nor >>> rewrite >>> - mention commit 3e0930f109e76 which further modified the unlock >>> behaviour. >>> >>> changes since v1: >>> - completely rewrote patch, the first version used a device tree flag >>> >>> drivers/mtd/spi-nor/Kconfig | 35 + >>> drivers/mtd/spi-nor/atmel.c | 24 +--- >>> drivers/mtd/spi-nor/core.c | 44 - >>> drivers/mtd/spi-nor/core.h | 6 + >>> drivers/mtd/spi-nor/esmt.c | 6 ++--- >>> drivers/mtd/spi-nor/intel.c | 6 ++--- >>> drivers/mtd/spi-nor/sst.c | 21 +- >>> include/linux/mtd/spi-nor.h | 6 + >>> 8 files changed, 114 insertions(+), 34 deletions(-) >>> >>> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig >>> index 6e816eafb312..647de17c81e2 100644 >>> --- a/drivers/mtd/spi-nor/Kconfig >>> +++ b/drivers/mtd/spi-nor/Kconfig >>> @@ -24,6 +24,41 @@ config MTD_SPI_NOR_USE_4K_SECTORS >>> Please note that some tools/drivers/filesystems may not work with >>> 4096 B erase size (e.g. UBIFS requires 15 KiB as a minimum). >>> >>> +choice >>> + prompt "Write protection at boot" >>> + default MTD_SPI_NOR_WP_DISABLE >> >> These choice control how BP0-X bits are manipulated on boot. Hence, to >> be consistent should use Block Protection (BP) terminology throughout. >> >> This would also be inline with most flash datasheets which also use >> term BP > > Where should I mention the BP bits? In the choice or in the help text. choice prompt and in help text. > I tried to keep the choice prompt as easy to understand as possible, so an > user who doesn't know anything about how the write protection actually > works > can still make that choice (without first reading a datasheet). Also > keep in > mind, that there is also the per sector locking. Wouldn't this option also > apply to that? > But, there is more than one way of achieving write protection in addition to BP bits such as Advanced Sector Protection which may be added in future. So we should be as specific as possible while making it easy for user. How about prompt "Write Protection (Legacy Block Protection based) at boot" > Therefore, I'd mention in the help text, that (currently) the BP bits are > affected. > >>> + >>> +config MTD_SPI_NOR_WP_DISABLE >>> + bool "Disable WP on any flashes (legacy behaviour)" >>> + help >>> + This option disables the write protection on any SPI flashes at >>> + boot-up. >>> + >>> + Don't use this if you intent to use the write protection of your >>> + SPI flash. This is only to keep backwards compatibility. >>> + >>> +config MTD_SPI_NOR_WP_DISABLE_ON_VOLATILE >>> + bool "Disable WP on flashes w/ volatile protection bits" >>> + help >>> + Some SPI flashes have volatile block protection bits, ie. after a >>> + power-up or a reset the flash is write protected by default. >>> + >>> + This option disables the write protection for these kind of >>> flashes >>> + while keeping it enabled for any other SPI flashes which have >>> + non-volatile block protection bits. >>> + >>> + If you are unsure, select this option. >>> + >>> +config MTD_SPI_NOR_WP_KEEP >>> + bool "Keep write protection as is" >>> + help >>> + If you select this option the write protection of any SPI flashes >>> + will not be changed. If your flash is write protected or will be >>> + automatically write protected after power-up you have to manually >>> + unlock it before you are able to write to it. >>> + >>> +endchoice >>> + >>> source "drivers/mtd/spi-nor/controllers/Kconfig" >>> >>> endif # MTD_SPI_NOR >> >> [...] >> >>> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h >>> index 6f2f6b27173f..9a33c023717f 100644
