December 2023 - Linux-stable-mirror

FAILED: patch "[PATCH] scsi: core: Always send batch on reset or error handling" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123000-cornmeal-magnesium-abc7@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 066c5b46b6ea ("scsi: core: Always send batch on reset or error handling command") bf23e619039d ("scsi: core: Use a structure member to track the SCSI command submitter") aa8e25e5006a ("scsi: core: Use scsi_cmd_to_rq() instead of scsi_cmnd.request") d2c945f01d23 ("scsi: core: Make scsi_get_lba() return the LBA") f0f214fe8cd3 ("scsi: core: Introduce scsi_get_sector()") 7ba46799d346 ("scsi: core: Add scsi_prot_ref_tag() helper") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 066c5b46b6eaf2f13f80c19500dbb3b84baabb33 Mon Sep 17 00:00:00 2001 From: Alexander Atanasov <alexander.atanasov(a)virtuozzo.com> Date: Fri, 15 Dec 2023 14:10:08 +0200 Subject: [PATCH] scsi: core: Always send batch on reset or error handling command In commit 8930a6c20791 ("scsi: core: add support for request batching") the block layer bd->last flag was mapped to SCMD_LAST and used as an indicator to send the batch for the drivers that implement this feature. However, the error handling code was not updated accordingly. scsi_send_eh_cmnd() is used to send error handling commands and request sense. The problem is that request sense comes as a single command that gets into the batch queue and times out. As a result the device goes offline after several failed resets. This was observed on virtio_scsi during a device resize operation. [ 496.316946] sd 0:0:4:0: [sdd] tag#117 scsi_eh_0: requesting sense [ 506.786356] sd 0:0:4:0: [sdd] tag#117 scsi_send_eh_cmnd timeleft: 0 [ 506.787981] sd 0:0:4:0: [sdd] tag#117 abort To fix this always set SCMD_LAST flag in scsi_send_eh_cmnd() and scsi_reset_ioctl(). Fixes: 8930a6c20791 ("scsi: core: add support for request batching") Cc: <stable(a)vger.kernel.org> Signed-off-by: Alexander Atanasov <alexander.atanasov(a)virtuozzo.com> Link: https://lore.kernel.org/r/20231215121008.2881653-1-alexander.atanasov@virtu… Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index c67cdcdc3ba8..1223d34c04da 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1152,6 +1152,7 @@ static enum scsi_disposition scsi_send_eh_cmnd(struct scsi_cmnd *scmd, scsi_log_send(scmd); scmd->submitter = SUBMITTED_BY_SCSI_ERROR_HANDLER; + scmd->flags |= SCMD_LAST; /* * Lock sdev->state_mutex to avoid that scsi_device_quiesce() can @@ -2459,6 +2460,7 @@ scsi_ioctl_reset(struct scsi_device *dev, int __user *arg) scsi_init_command(dev, scmd); scmd->submitter = SUBMITTED_BY_SCSI_RESET_IOCTL; + scmd->flags |= SCMD_LAST; memset(&scmd->sdb, 0, sizeof(scmd->sdb)); scmd->cmd_len = 0;

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] nvmem: brcm_nvram: store a copy of NVRAM content" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 1e37bf84afacd5ba17b7a13a18ca2bc78aff05c0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123025-coming-unlawful-c79b@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 1e37bf84afac ("nvmem: brcm_nvram: store a copy of NVRAM content") cfadd0e7d922 ("nvmem: brcm_nvram: Use devm_platform_get_and_ioremap_resource()") 73bcd133c910 ("nvmem: brcm_nvram: add .read_post_process() for MACs") b0576ade3aaf ("nvmem: brcm_nvram: Add check for kzalloc") a5be5ce0e254 ("firmware/nvram: bcm47xx: support init from IO memory") a06d9e5a63b7 ("nvmem: sort config symbols alphabetically") 28fc7c986f01 ("nvmem: prefix all symbols with NVMEM_") d3524bb5b9a0 ("nvmem: brcm_nvram: Use kzalloc for allocating only one element") d5542923f200 ("nvmem: add driver handling U-Boot environment variables") 228dfe98a313 ("Merge tag 'char-misc-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e37bf84afacd5ba17b7a13a18ca2bc78aff05c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal(a)milecki.pl> Date: Fri, 15 Dec 2023 11:13:58 +0000 Subject: [PATCH] nvmem: brcm_nvram: store a copy of NVRAM content MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This driver uses MMIO access for reading NVRAM from a flash device. Underneath there is a flash controller that reads data and provides mapping window. Using MMIO interface affects controller configuration and may break real controller driver. It was reported by multiple users of devices with NVRAM stored on NAND. Modify driver to read & cache NVRAM content during init and use that copy to provide NVMEM data when requested. On NAND flashes due to their alignment NVRAM partitions can be quite big (1 MiB and more) while actual NVRAM content stays quite small (usually 16 to 32 KiB). To avoid allocating so much memory check for actual data length. Link: https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO… Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM") Cc: <Stable(a)vger.kernel.org> Cc: Arınç ÜNAL <arinc.unal(a)arinc9.com> Cc: Florian Fainelli <florian.fainelli(a)broadcom.com> Cc: Scott Branden <scott.branden(a)broadcom.com> Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> Acked-by: Arınç ÜNAL <arinc.unal(a)arinc9.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Link: https://lore.kernel.org/r/20231215111358.316727-3-srinivas.kandagatla@linar… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c index 9737104f3b76..5cdf339cfbec 100644 --- a/drivers/nvmem/brcm_nvram.c +++ b/drivers/nvmem/brcm_nvram.c @@ -17,9 +17,23 @@ #define NVRAM_MAGIC "FLSH" +/** + * struct brcm_nvram - driver state internal struct + * + * @dev: NVMEM device pointer + * @nvmem_size: Size of the whole space available for NVRAM + * @data: NVRAM data copy stored to avoid poking underlaying flash controller + * @data_len: NVRAM data size + * @padding_byte: Padding value used to fill remaining space + * @cells: Array of discovered NVMEM cells + * @ncells: Number of elements in cells + */ struct brcm_nvram { struct device *dev; - void __iomem *base; + size_t nvmem_size; + uint8_t *data; + size_t data_len; + uint8_t padding_byte; struct nvmem_cell_info *cells; int ncells; }; @@ -36,10 +50,47 @@ static int brcm_nvram_read(void *context, unsigned int offset, void *val, size_t bytes) { struct brcm_nvram *priv = context; - u8 *dst = val; + size_t to_copy; + + if (offset + bytes > priv->data_len) + to_copy = max_t(ssize_t, (ssize_t)priv->data_len - offset, 0); + else + to_copy = bytes; + + memcpy(val, priv->data + offset, to_copy); + + memset((uint8_t *)val + to_copy, priv->padding_byte, bytes - to_copy); + + return 0; +} + +static int brcm_nvram_copy_data(struct brcm_nvram *priv, struct platform_device *pdev) +{ + struct resource *res; + void __iomem *base; + + base = devm_platform_get_and_ioremap_resource(pdev, 0, &res); + if (IS_ERR(base)) + return PTR_ERR(base); + + priv->nvmem_size = resource_size(res); + + priv->padding_byte = readb(base + priv->nvmem_size - 1); + for (priv->data_len = priv->nvmem_size; + priv->data_len; + priv->data_len--) { + if (readb(base + priv->data_len - 1) != priv->padding_byte) + break; + } + WARN(priv->data_len > SZ_128K, "Unexpected (big) NVRAM size: %zu B\n", priv->data_len); + + priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL); + if (!priv->data) + return -ENOMEM; + + memcpy_fromio(priv->data, base, priv->data_len); - while (bytes--) - *dst++ = readb(priv->base + offset++); + bcm47xx_nvram_init_from_iomem(base, priv->data_len); return 0; } @@ -67,8 +118,13 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data, size_t len) { struct device *dev = priv->dev; - char *var, *value, *eq; + char *var, *value; + uint8_t tmp; int idx; + int err = 0; + + tmp = priv->data[len - 1]; + priv->data[len - 1] = '\0'; priv->ncells = 0; for (var = data + sizeof(struct brcm_nvram_header); @@ -78,67 +134,68 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data, } priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL); - if (!priv->cells) - return -ENOMEM; + if (!priv->cells) { + err = -ENOMEM; + goto out; + } for (var = data + sizeof(struct brcm_nvram_header), idx = 0; var < (char *)data + len && *var; var = value + strlen(value) + 1, idx++) { + char *eq, *name; + eq = strchr(var, '='); if (!eq) break; *eq = '\0'; + name = devm_kstrdup(dev, var, GFP_KERNEL); + *eq = '='; + if (!name) { + err = -ENOMEM; + goto out; + } value = eq + 1; - priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL); - if (!priv->cells[idx].name) - return -ENOMEM; + priv->cells[idx].name = name; priv->cells[idx].offset = value - (char *)data; priv->cells[idx].bytes = strlen(value); priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name); - if (!strcmp(var, "et0macaddr") || - !strcmp(var, "et1macaddr") || - !strcmp(var, "et2macaddr")) { + if (!strcmp(name, "et0macaddr") || + !strcmp(name, "et1macaddr") || + !strcmp(name, "et2macaddr")) { priv->cells[idx].raw_len = strlen(value); priv->cells[idx].bytes = ETH_ALEN; priv->cells[idx].read_post_process = brcm_nvram_read_post_process_macaddr; } } - return 0; +out: + priv->data[len - 1] = tmp; + return err; } static int brcm_nvram_parse(struct brcm_nvram *priv) { + struct brcm_nvram_header *header = (struct brcm_nvram_header *)priv->data; struct device *dev = priv->dev; - struct brcm_nvram_header header; - uint8_t *data; size_t len; int err; - memcpy_fromio(&header, priv->base, sizeof(header)); - - if (memcmp(header.magic, NVRAM_MAGIC, 4)) { + if (memcmp(header->magic, NVRAM_MAGIC, 4)) { dev_err(dev, "Invalid NVRAM magic\n"); return -EINVAL; } - len = le32_to_cpu(header.len); - - data = kzalloc(len, GFP_KERNEL); - if (!data) - return -ENOMEM; - - memcpy_fromio(data, priv->base, len); - data[len - 1] = '\0'; - - err = brcm_nvram_add_cells(priv, data, len); - if (err) { - dev_err(dev, "Failed to add cells: %d\n", err); - return err; + len = le32_to_cpu(header->len); + if (len > priv->nvmem_size) { + dev_err(dev, "NVRAM length (%zd) exceeds mapped size (%zd)\n", len, + priv->nvmem_size); + return -EINVAL; } - kfree(data); + err = brcm_nvram_add_cells(priv, priv->data, len); + if (err) + dev_err(dev, "Failed to add cells: %d\n", err); return 0; } @@ -150,7 +207,6 @@ static int brcm_nvram_probe(struct platform_device *pdev) .reg_read = brcm_nvram_read, }; struct device *dev = &pdev->dev; - struct resource *res; struct brcm_nvram *priv; int err; @@ -159,21 +215,19 @@ static int brcm_nvram_probe(struct platform_device *pdev) return -ENOMEM; priv->dev = dev; - priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res); - if (IS_ERR(priv->base)) - return PTR_ERR(priv->base); + err = brcm_nvram_copy_data(priv, pdev); + if (err) + return err; err = brcm_nvram_parse(priv); if (err) return err; - bcm47xx_nvram_init_from_iomem(priv->base, resource_size(res)); - config.dev = dev; config.cells = priv->cells; config.ncells = priv->ncells; config.priv = priv; - config.size = resource_size(res); + config.size = priv->nvmem_size; return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config)); }

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] nvmem: brcm_nvram: store a copy of NVRAM content" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 1e37bf84afacd5ba17b7a13a18ca2bc78aff05c0 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123024-disliking-irritably-814a@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 1e37bf84afac ("nvmem: brcm_nvram: store a copy of NVRAM content") cfadd0e7d922 ("nvmem: brcm_nvram: Use devm_platform_get_and_ioremap_resource()") 73bcd133c910 ("nvmem: brcm_nvram: add .read_post_process() for MACs") b0576ade3aaf ("nvmem: brcm_nvram: Add check for kzalloc") a5be5ce0e254 ("firmware/nvram: bcm47xx: support init from IO memory") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e37bf84afacd5ba17b7a13a18ca2bc78aff05c0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal(a)milecki.pl> Date: Fri, 15 Dec 2023 11:13:58 +0000 Subject: [PATCH] nvmem: brcm_nvram: store a copy of NVRAM content MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This driver uses MMIO access for reading NVRAM from a flash device. Underneath there is a flash controller that reads data and provides mapping window. Using MMIO interface affects controller configuration and may break real controller driver. It was reported by multiple users of devices with NVRAM stored on NAND. Modify driver to read & cache NVRAM content during init and use that copy to provide NVMEM data when requested. On NAND flashes due to their alignment NVRAM partitions can be quite big (1 MiB and more) while actual NVRAM content stays quite small (usually 16 to 32 KiB). To avoid allocating so much memory check for actual data length. Link: https://lore.kernel.org/linux-mtd/CACna6rwf3_9QVjYcM+847biTX=K0EoWXuXcSMkJO… Fixes: 3fef9ed0627a ("nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM") Cc: <Stable(a)vger.kernel.org> Cc: Arınç ÜNAL <arinc.unal(a)arinc9.com> Cc: Florian Fainelli <florian.fainelli(a)broadcom.com> Cc: Scott Branden <scott.branden(a)broadcom.com> Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> Acked-by: Arınç ÜNAL <arinc.unal(a)arinc9.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Link: https://lore.kernel.org/r/20231215111358.316727-3-srinivas.kandagatla@linar… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/nvmem/brcm_nvram.c b/drivers/nvmem/brcm_nvram.c index 9737104f3b76..5cdf339cfbec 100644 --- a/drivers/nvmem/brcm_nvram.c +++ b/drivers/nvmem/brcm_nvram.c @@ -17,9 +17,23 @@ #define NVRAM_MAGIC "FLSH" +/** + * struct brcm_nvram - driver state internal struct + * + * @dev: NVMEM device pointer + * @nvmem_size: Size of the whole space available for NVRAM + * @data: NVRAM data copy stored to avoid poking underlaying flash controller + * @data_len: NVRAM data size + * @padding_byte: Padding value used to fill remaining space + * @cells: Array of discovered NVMEM cells + * @ncells: Number of elements in cells + */ struct brcm_nvram { struct device *dev; - void __iomem *base; + size_t nvmem_size; + uint8_t *data; + size_t data_len; + uint8_t padding_byte; struct nvmem_cell_info *cells; int ncells; }; @@ -36,10 +50,47 @@ static int brcm_nvram_read(void *context, unsigned int offset, void *val, size_t bytes) { struct brcm_nvram *priv = context; - u8 *dst = val; + size_t to_copy; + + if (offset + bytes > priv->data_len) + to_copy = max_t(ssize_t, (ssize_t)priv->data_len - offset, 0); + else + to_copy = bytes; + + memcpy(val, priv->data + offset, to_copy); + + memset((uint8_t *)val + to_copy, priv->padding_byte, bytes - to_copy); + + return 0; +} + +static int brcm_nvram_copy_data(struct brcm_nvram *priv, struct platform_device *pdev) +{ + struct resource *res; + void __iomem *base; + + base = devm_platform_get_and_ioremap_resource(pdev, 0, &res); + if (IS_ERR(base)) + return PTR_ERR(base); + + priv->nvmem_size = resource_size(res); + + priv->padding_byte = readb(base + priv->nvmem_size - 1); + for (priv->data_len = priv->nvmem_size; + priv->data_len; + priv->data_len--) { + if (readb(base + priv->data_len - 1) != priv->padding_byte) + break; + } + WARN(priv->data_len > SZ_128K, "Unexpected (big) NVRAM size: %zu B\n", priv->data_len); + + priv->data = devm_kzalloc(priv->dev, priv->data_len, GFP_KERNEL); + if (!priv->data) + return -ENOMEM; + + memcpy_fromio(priv->data, base, priv->data_len); - while (bytes--) - *dst++ = readb(priv->base + offset++); + bcm47xx_nvram_init_from_iomem(base, priv->data_len); return 0; } @@ -67,8 +118,13 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data, size_t len) { struct device *dev = priv->dev; - char *var, *value, *eq; + char *var, *value; + uint8_t tmp; int idx; + int err = 0; + + tmp = priv->data[len - 1]; + priv->data[len - 1] = '\0'; priv->ncells = 0; for (var = data + sizeof(struct brcm_nvram_header); @@ -78,67 +134,68 @@ static int brcm_nvram_add_cells(struct brcm_nvram *priv, uint8_t *data, } priv->cells = devm_kcalloc(dev, priv->ncells, sizeof(*priv->cells), GFP_KERNEL); - if (!priv->cells) - return -ENOMEM; + if (!priv->cells) { + err = -ENOMEM; + goto out; + } for (var = data + sizeof(struct brcm_nvram_header), idx = 0; var < (char *)data + len && *var; var = value + strlen(value) + 1, idx++) { + char *eq, *name; + eq = strchr(var, '='); if (!eq) break; *eq = '\0'; + name = devm_kstrdup(dev, var, GFP_KERNEL); + *eq = '='; + if (!name) { + err = -ENOMEM; + goto out; + } value = eq + 1; - priv->cells[idx].name = devm_kstrdup(dev, var, GFP_KERNEL); - if (!priv->cells[idx].name) - return -ENOMEM; + priv->cells[idx].name = name; priv->cells[idx].offset = value - (char *)data; priv->cells[idx].bytes = strlen(value); priv->cells[idx].np = of_get_child_by_name(dev->of_node, priv->cells[idx].name); - if (!strcmp(var, "et0macaddr") || - !strcmp(var, "et1macaddr") || - !strcmp(var, "et2macaddr")) { + if (!strcmp(name, "et0macaddr") || + !strcmp(name, "et1macaddr") || + !strcmp(name, "et2macaddr")) { priv->cells[idx].raw_len = strlen(value); priv->cells[idx].bytes = ETH_ALEN; priv->cells[idx].read_post_process = brcm_nvram_read_post_process_macaddr; } } - return 0; +out: + priv->data[len - 1] = tmp; + return err; } static int brcm_nvram_parse(struct brcm_nvram *priv) { + struct brcm_nvram_header *header = (struct brcm_nvram_header *)priv->data; struct device *dev = priv->dev; - struct brcm_nvram_header header; - uint8_t *data; size_t len; int err; - memcpy_fromio(&header, priv->base, sizeof(header)); - - if (memcmp(header.magic, NVRAM_MAGIC, 4)) { + if (memcmp(header->magic, NVRAM_MAGIC, 4)) { dev_err(dev, "Invalid NVRAM magic\n"); return -EINVAL; } - len = le32_to_cpu(header.len); - - data = kzalloc(len, GFP_KERNEL); - if (!data) - return -ENOMEM; - - memcpy_fromio(data, priv->base, len); - data[len - 1] = '\0'; - - err = brcm_nvram_add_cells(priv, data, len); - if (err) { - dev_err(dev, "Failed to add cells: %d\n", err); - return err; + len = le32_to_cpu(header->len); + if (len > priv->nvmem_size) { + dev_err(dev, "NVRAM length (%zd) exceeds mapped size (%zd)\n", len, + priv->nvmem_size); + return -EINVAL; } - kfree(data); + err = brcm_nvram_add_cells(priv, priv->data, len); + if (err) + dev_err(dev, "Failed to add cells: %d\n", err); return 0; } @@ -150,7 +207,6 @@ static int brcm_nvram_probe(struct platform_device *pdev) .reg_read = brcm_nvram_read, }; struct device *dev = &pdev->dev; - struct resource *res; struct brcm_nvram *priv; int err; @@ -159,21 +215,19 @@ static int brcm_nvram_probe(struct platform_device *pdev) return -ENOMEM; priv->dev = dev; - priv->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res); - if (IS_ERR(priv->base)) - return PTR_ERR(priv->base); + err = brcm_nvram_copy_data(priv, pdev); + if (err) + return err; err = brcm_nvram_parse(priv); if (err) return err; - bcm47xx_nvram_init_from_iomem(priv->base, resource_size(res)); - config.dev = dev; config.cells = priv->cells; config.ncells = priv->ncells; config.priv = priv; - config.size = resource_size(res); + config.size = priv->nvmem_size; return PTR_ERR_OR_ZERO(devm_nvmem_register(dev, &config)); }

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: adc: MCP3564: fix calib_bias and calib_scale range" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 85ac6d92fdfd6097a16d9c61363fe1d0272c1604 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123005-crewman-clock-3db0@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 85ac6d92fdfd ("iio: adc: MCP3564: fix calib_bias and calib_scale range checks") 33ec3e5fc1ea ("iio: adc: adding support for MCP3564 ADC") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 85ac6d92fdfd6097a16d9c61363fe1d0272c1604 Mon Sep 17 00:00:00 2001 From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Date: Fri, 1 Dec 2023 10:48:03 +0100 Subject: [PATCH] iio: adc: MCP3564: fix calib_bias and calib_scale range checks The current implementation uses the AND (&&) operator to check if the value to write for IIO_CHAN_INFO_CALIBBIAS and IIO_CHAN_INFO_CALIBSCALE is within the valid ranges. The evaluated values are the lower and upper limits of the ranges, so this operation always evaluates to false. The OR (||) operator must be used instead. Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Reviewed-by: Marius Cristea <marius.cristea(a)microchip.com> Link: https://lore.kernel.org/r/20231201-mcp3564_range_checks-v1-1-68f4436e22b0@g… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/mcp3564.c b/drivers/iio/adc/mcp3564.c index e3f1de5fcc5a..d5fb1cae8aeb 100644 --- a/drivers/iio/adc/mcp3564.c +++ b/drivers/iio/adc/mcp3564.c @@ -918,7 +918,7 @@ static int mcp3564_write_raw(struct iio_dev *indio_dev, mutex_unlock(&adc->lock); return ret; case IIO_CHAN_INFO_CALIBBIAS: - if (val < mcp3564_calib_bias[0] && val > mcp3564_calib_bias[2]) + if (val < mcp3564_calib_bias[0] || val > mcp3564_calib_bias[2]) return -EINVAL; mutex_lock(&adc->lock); @@ -928,7 +928,7 @@ static int mcp3564_write_raw(struct iio_dev *indio_dev, mutex_unlock(&adc->lock); return ret; case IIO_CHAN_INFO_CALIBSCALE: - if (val < mcp3564_calib_scale[0] && val > mcp3564_calib_scale[2]) + if (val < mcp3564_calib_scale[0] || val > mcp3564_calib_scale[2]) return -EINVAL; if (adc->calib_scale == val)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: adc: MCP3564: fix calib_bias and calib_scale range" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 85ac6d92fdfd6097a16d9c61363fe1d0272c1604 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123004-hangup-empirical-5092@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 85ac6d92fdfd ("iio: adc: MCP3564: fix calib_bias and calib_scale range checks") 33ec3e5fc1ea ("iio: adc: adding support for MCP3564 ADC") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 85ac6d92fdfd6097a16d9c61363fe1d0272c1604 Mon Sep 17 00:00:00 2001 From: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Date: Fri, 1 Dec 2023 10:48:03 +0100 Subject: [PATCH] iio: adc: MCP3564: fix calib_bias and calib_scale range checks The current implementation uses the AND (&&) operator to check if the value to write for IIO_CHAN_INFO_CALIBBIAS and IIO_CHAN_INFO_CALIBSCALE is within the valid ranges. The evaluated values are the lower and upper limits of the ranges, so this operation always evaluates to false. The OR (||) operator must be used instead. Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> Reviewed-by: Marius Cristea <marius.cristea(a)microchip.com> Link: https://lore.kernel.org/r/20231201-mcp3564_range_checks-v1-1-68f4436e22b0@g… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/mcp3564.c b/drivers/iio/adc/mcp3564.c index e3f1de5fcc5a..d5fb1cae8aeb 100644 --- a/drivers/iio/adc/mcp3564.c +++ b/drivers/iio/adc/mcp3564.c @@ -918,7 +918,7 @@ static int mcp3564_write_raw(struct iio_dev *indio_dev, mutex_unlock(&adc->lock); return ret; case IIO_CHAN_INFO_CALIBBIAS: - if (val < mcp3564_calib_bias[0] && val > mcp3564_calib_bias[2]) + if (val < mcp3564_calib_bias[0] || val > mcp3564_calib_bias[2]) return -EINVAL; mutex_lock(&adc->lock); @@ -928,7 +928,7 @@ static int mcp3564_write_raw(struct iio_dev *indio_dev, mutex_unlock(&adc->lock); return ret; case IIO_CHAN_INFO_CALIBSCALE: - if (val < mcp3564_calib_scale[0] && val > mcp3564_calib_scale[2]) + if (val < mcp3564_calib_scale[0] || val > mcp3564_calib_scale[2]) return -EINVAL; if (adc->calib_scale == val)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: imu: adis16475: use bit numbers in assign_bit()" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123053-stimulant-zealous-f9eb@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 1cd2fe4fd63e ("iio: imu: adis16475: use bit numbers in assign_bit()") 8f6bc87d67c0 ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") c1f10bff1619 ("iio: imu: adis16475.c: Add has_burst32 flag to adis16477 devices") a216d411b547 ("iio: imu: adis16475.c: Remove unused enum elements") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Mon, 6 Nov 2023 16:07:30 +0100 Subject: [PATCH] iio: imu: adis16475: use bit numbers in assign_bit() assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <error27(a)gmail.com> Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/adis16475.c b/drivers/iio/imu/adis16475.c index 04153a2725d5..64be656f0b80 100644 --- a/drivers/iio/imu/adis16475.c +++ b/drivers/iio/imu/adis16475.c @@ -70,8 +70,8 @@ #define ADIS16475_MAX_SCAN_DATA 20 /* spi max speed in brust mode */ #define ADIS16475_BURST_MAX_SPEED 1000000 -#define ADIS16475_LSB_DEC_MASK BIT(0) -#define ADIS16475_LSB_FIR_MASK BIT(1) +#define ADIS16475_LSB_DEC_MASK 0 +#define ADIS16475_LSB_FIR_MASK 1 #define ADIS16500_BURST_DATA_SEL_0_CHN_MASK GENMASK(5, 0) #define ADIS16500_BURST_DATA_SEL_1_CHN_MASK GENMASK(12, 7)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: imu: adis16475: use bit numbers in assign_bit()" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123052-scribble-rust-9d03@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: 1cd2fe4fd63e ("iio: imu: adis16475: use bit numbers in assign_bit()") 8f6bc87d67c0 ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") c1f10bff1619 ("iio: imu: adis16475.c: Add has_burst32 flag to adis16477 devices") a216d411b547 ("iio: imu: adis16475.c: Remove unused enum elements") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Mon, 6 Nov 2023 16:07:30 +0100 Subject: [PATCH] iio: imu: adis16475: use bit numbers in assign_bit() assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <error27(a)gmail.com> Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/adis16475.c b/drivers/iio/imu/adis16475.c index 04153a2725d5..64be656f0b80 100644 --- a/drivers/iio/imu/adis16475.c +++ b/drivers/iio/imu/adis16475.c @@ -70,8 +70,8 @@ #define ADIS16475_MAX_SCAN_DATA 20 /* spi max speed in brust mode */ #define ADIS16475_BURST_MAX_SPEED 1000000 -#define ADIS16475_LSB_DEC_MASK BIT(0) -#define ADIS16475_LSB_FIR_MASK BIT(1) +#define ADIS16475_LSB_DEC_MASK 0 +#define ADIS16475_LSB_FIR_MASK 1 #define ADIS16500_BURST_DATA_SEL_0_CHN_MASK GENMASK(5, 0) #define ADIS16500_BURST_DATA_SEL_1_CHN_MASK GENMASK(12, 7)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: imu: adis16475: use bit numbers in assign_bit()" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123051-duckbill-coping-e6ae@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: 1cd2fe4fd63e ("iio: imu: adis16475: use bit numbers in assign_bit()") 8f6bc87d67c0 ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") c1f10bff1619 ("iio: imu: adis16475.c: Add has_burst32 flag to adis16477 devices") a216d411b547 ("iio: imu: adis16475.c: Remove unused enum elements") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Mon, 6 Nov 2023 16:07:30 +0100 Subject: [PATCH] iio: imu: adis16475: use bit numbers in assign_bit() assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <error27(a)gmail.com> Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/adis16475.c b/drivers/iio/imu/adis16475.c index 04153a2725d5..64be656f0b80 100644 --- a/drivers/iio/imu/adis16475.c +++ b/drivers/iio/imu/adis16475.c @@ -70,8 +70,8 @@ #define ADIS16475_MAX_SCAN_DATA 20 /* spi max speed in brust mode */ #define ADIS16475_BURST_MAX_SPEED 1000000 -#define ADIS16475_LSB_DEC_MASK BIT(0) -#define ADIS16475_LSB_FIR_MASK BIT(1) +#define ADIS16475_LSB_DEC_MASK 0 +#define ADIS16475_LSB_FIR_MASK 1 #define ADIS16500_BURST_DATA_SEL_0_CHN_MASK GENMASK(5, 0) #define ADIS16500_BURST_DATA_SEL_1_CHN_MASK GENMASK(12, 7)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] iio: imu: adis16475: use bit numbers in assign_bit()" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.6.y git checkout FETCH_HEAD git cherry-pick -x 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123050-margarita-embargo-94bc@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: 1cd2fe4fd63e ("iio: imu: adis16475: use bit numbers in assign_bit()") 8f6bc87d67c0 ("iio: imu: adis16475.c: Add delta angle and delta velocity channels") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1cd2fe4fd63e54b799a68c0856bda18f2e40caa8 Mon Sep 17 00:00:00 2001 From: Nuno Sa <nuno.sa(a)analog.com> Date: Mon, 6 Nov 2023 16:07:30 +0100 Subject: [PATCH] iio: imu: adis16475: use bit numbers in assign_bit() assign_bit() expects a bit number and not a mask like BIT(x). Hence, just remove the BIT() macro from the #defines. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Dan Carpenter <error27(a)gmail.com> Closes: https://lore.kernel.org/r/202311060647.i9XyO4ej-lkp@intel.com/ Fixes: fff7352bf7a3ce ("iio: imu: Add support for adis16475") Signed-off-by: Nuno Sa <nuno.sa(a)analog.com> Link: https://lore.kernel.org/r/20231106150730.945-1-nuno.sa@analog.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/imu/adis16475.c b/drivers/iio/imu/adis16475.c index 04153a2725d5..64be656f0b80 100644 --- a/drivers/iio/imu/adis16475.c +++ b/drivers/iio/imu/adis16475.c @@ -70,8 +70,8 @@ #define ADIS16475_MAX_SCAN_DATA 20 /* spi max speed in brust mode */ #define ADIS16475_BURST_MAX_SPEED 1000000 -#define ADIS16475_LSB_DEC_MASK BIT(0) -#define ADIS16475_LSB_FIR_MASK BIT(1) +#define ADIS16475_LSB_DEC_MASK 0 +#define ADIS16475_LSB_FIR_MASK 1 #define ADIS16500_BURST_DATA_SEL_0_CHN_MASK GENMASK(5, 0) #define ADIS16500_BURST_DATA_SEL_1_CHN_MASK GENMASK(12, 7)

1 year, 3 months

1
0
0 0

FAILED: patch "[PATCH] spi: atmel: Fix clock issue when using devices with different" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y git checkout FETCH_HEAD git cherry-pick -x fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023123045-comfy-crouch-3a6d@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^.. Possible dependencies: fc70d643a2f6 ("spi: atmel: Fix clock issue when using devices with different polarities") 69e1818ad27b ("spi: atmel: Fix CS and initialization bug") 5fa5e6dec762 ("spi: atmel: Switch to transfer_one transfer method") ca4196aa1008 ("Merge branch 'spi-5.5' into spi-next") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From fc70d643a2f6678cbe0f5c86433c1aeb4d613fcc Mon Sep 17 00:00:00 2001 From: Louis Chauvet <louis.chauvet(a)bootlin.com> Date: Mon, 4 Dec 2023 16:49:03 +0100 Subject: [PATCH] spi: atmel: Fix clock issue when using devices with different polarities The current Atmel SPI controller driver (v2) behaves incorrectly when using two SPI devices with different clock polarities and GPIO CS. When switching from one device to another, the controller driver first enables the CS and then applies whatever configuration suits the targeted device (typically, the polarities). The side effect of such order is the apparition of a spurious clock edge after enabling the CS when the clock polarity needs to be inverted wrt. the previous configuration of the controller. This parasitic clock edge is problematic when the SPI device uses that edge for internal processing, which is perfectly legitimate given that its CS was asserted. Indeed, devices such as HVS8080 driven by driver gpio-sr in the kernel are shift registers and will process this first clock edge to perform a first register shift. In this case, the first bit gets lost and the whole data block that will later be read by the kernel is all shifted by one. Current behavior: The actual switching of the clock polarity only occurs after the CS when the controller sends the first message: CLK ------------\ /-\ /-\ | | | | | . . . \---/ \-/ \ CS -----\ | \------------------ ^ ^ ^ | | | | | Actual clock of the message sent | | | Change of clock polarity, which occurs with the first | write to the bus. This edge occurs when the CS is | already asserted, and can be interpreted as | the first clock edge by the receiver. | GPIO CS toggle This issue is specific to this controller because while the SPI core performs the operations in the right order, the controller however does not. In practice, the controller only applies the clock configuration right before the first transmission. So this is not a problem when using the controller's dedicated CS, as the controller does things correctly, but it becomes a problem when you need to change the clock polarity and use an external GPIO for the CS. One possible approach to solve this problem is to send a dummy message before actually activating the CS, so that the controller applies the clock polarity beforehand. New behavior: CLK ------\ /-\ /-\ /-\ /-\ | | | ... | | | | ... | | \------/ \- -/ \------/ \- -/ \------ CS -\/-----------------------\ || | \/ \--------------------- ^ ^ ^ ^ ^ | | | | | | | | | Expected clock cycles when | | | | sending the message | | | | | | | Actual GPIO CS activation, occurs inside | | | the driver | | | | | Dummy message, to trigger clock polarity | | reconfiguration. This message is not received and | | processed by the device because CS is low. | | | Change of clock polarity, forced by the dummy message. This | time, the edge is not detected by the receiver. | This small spike in CS activation is due to the fact that the spi-core activates the CS gpio before calling the driver's set_cs callback, which deactivates this gpio again until the clock polarity is correct. To avoid having to systematically send a dummy packet, the driver keeps track of the clock's current polarity. In this way, it only sends the dummy packet when necessary, ensuring that the clock will have the correct polarity when the CS is toggled. There could be two hardware problems with this patch: 1- Maybe the small CS activation peak can confuse SPI devices 2- If on a design, a single wire is used to select two devices depending on its state, the dummy message may disturb them. Fixes: 5ee36c989831 ("spi: atmel_spi update chipselect handling") Cc: <stable(a)vger.kernel.org> Signed-off-by: Louis Chauvet <louis.chauvet(a)bootlin.com> Link: https://msgid.link/r/20231204154903.11607-1-louis.chauvet@bootlin.com Signed-off-by: Mark Brown <broonie(a)kernel.org> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 54277de30161..bad34998454a 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -22,6 +22,7 @@ #include <linux/gpio/consumer.h> #include <linux/pinctrl/consumer.h> #include <linux/pm_runtime.h> +#include <linux/iopoll.h> #include <trace/events/spi.h> /* SPI register offsets */ @@ -276,6 +277,7 @@ struct atmel_spi { bool keep_cs; u32 fifo_size; + bool last_polarity; u8 native_cs_free; u8 native_cs_for_gpio; }; @@ -288,6 +290,22 @@ struct atmel_spi_device { #define SPI_MAX_DMA_XFER 65535 /* true for both PDC and DMA */ #define INVALID_DMA_ADDRESS 0xffffffff +/* + * This frequency can be anything supported by the controller, but to avoid + * unnecessary delay, the highest possible frequency is chosen. + * + * This frequency is the highest possible which is not interfering with other + * chip select registers (see Note for Serial Clock Bit Rate configuration in + * Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16, page 1283) + */ +#define DUMMY_MSG_FREQUENCY 0x02 +/* + * 8 bits is the minimum data the controller is capable of sending. + * + * This message can be anything as it should not be treated by any SPI device. + */ +#define DUMMY_MSG 0xAA + /* * Version 2 of the SPI controller has * - CR.LASTXFER @@ -301,6 +319,43 @@ static bool atmel_spi_is_v2(struct atmel_spi *as) return as->caps.is_spi2; } +/* + * Send a dummy message. + * + * This is sometimes needed when using a CS GPIO to force clock transition when + * switching between devices with different polarities. + */ +static void atmel_spi_send_dummy(struct atmel_spi *as, struct spi_device *spi, int chip_select) +{ + u32 status; + u32 csr; + + /* + * Set a clock frequency to allow sending message on SPI bus. + * The frequency here can be anything, but is needed for + * the controller to send the data. + */ + csr = spi_readl(as, CSR0 + 4 * chip_select); + csr = SPI_BFINS(SCBR, DUMMY_MSG_FREQUENCY, csr); + spi_writel(as, CSR0 + 4 * chip_select, csr); + + /* + * Read all data coming from SPI bus, needed to be able to send + * the message. + */ + spi_readl(as, RDR); + while (spi_readl(as, SR) & SPI_BIT(RDRF)) { + spi_readl(as, RDR); + cpu_relax(); + } + + spi_writel(as, TDR, DUMMY_MSG); + + readl_poll_timeout_atomic(as->regs + SPI_SR, status, + (status & SPI_BIT(TXEMPTY)), 1, 1000); +} + + /* * Earlier SPI controllers (e.g. on at91rm9200) have a design bug whereby * they assume that spi slave device state will not change on deselect, so @@ -317,11 +372,17 @@ static bool atmel_spi_is_v2(struct atmel_spi *as) * Master on Chip Select 0.") No workaround exists for that ... so for * nCS0 on that chip, we (a) don't use the GPIO, (b) can't support CS_HIGH, * and (c) will trigger that first erratum in some cases. + * + * When changing the clock polarity, the SPI controller waits for the next + * transmission to enforce the default clock state. This may be an issue when + * using a GPIO as Chip Select: the clock level is applied only when the first + * packet is sent, once the CS has already been asserted. The workaround is to + * avoid this by sending a first (dummy) message before toggling the CS state. */ - static void cs_activate(struct atmel_spi *as, struct spi_device *spi) { struct atmel_spi_device *asd = spi->controller_state; + bool new_polarity; int chip_select; u32 mr; @@ -350,6 +411,25 @@ static void cs_activate(struct atmel_spi *as, struct spi_device *spi) } mr = spi_readl(as, MR); + + /* + * Ensures the clock polarity is valid before we actually + * assert the CS to avoid spurious clock edges to be + * processed by the spi devices. + */ + if (spi_get_csgpiod(spi, 0)) { + new_polarity = (asd->csr & SPI_BIT(CPOL)) != 0; + if (new_polarity != as->last_polarity) { + /* + * Need to disable the GPIO before sending the dummy + * message because it is already set by the spi core. + */ + gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 0); + atmel_spi_send_dummy(as, spi, chip_select); + as->last_polarity = new_polarity; + gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0), 1); + } + } } else { u32 cpol = (spi->mode & SPI_CPOL) ? SPI_BIT(CPOL) : 0; int i;

1 year, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2023