* [PATCH v2 2/5] scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered yet
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
There are some chances that link enters hibern8 lately by auto-hibern8
scheme during the clock-gating flow. Clocks shall not be gated if link
is still active otherwise host or device may hang.
Fix this by returning error code to the caller __ufshcd_setup_clocks()
to skip gating clocks there if link is not confirmed in hibern8
state yet.
Also allow some waiting time for the hibern8 state transition.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 36 ++++++++++++++++++++++++---------
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 523ee5573921..3c85f5e97dea 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -178,15 +178,30 @@ static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
host->ref_clk_ungating_wait_us = ungating_us;
}
-static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
+int ufs_mtk_wait_link_state(struct ufs_hba *hba, u32 state,
+ unsigned long max_wait_ms)
{
+ ktime_t timeout, time_checked;
u32 val;
- ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
- val = ufshcd_readl(hba, REG_UFS_PROBE);
- val = val >> 28;
+ timeout = ktime_add_us(ktime_get(), ms_to_ktime(max_wait_ms));
+ do {
+ time_checked = ktime_get();
+ ufshcd_writel(hba, 0x20, REG_UFS_DEBUG_SEL);
+ val = ufshcd_readl(hba, REG_UFS_PROBE);
+ val = val >> 28;
+
+ if (val == state)
+ return 0;
- return val;
+ /* Sleep for max. 200us */
+ usleep_range(100, 200);
+ } while (ktime_before(time_checked, timeout));
+
+ if (val == state)
+ return 0;
+
+ return -ETIMEDOUT;
}
/**
@@ -221,10 +236,13 @@ static int ufs_mtk_setup_clocks(struct ufs_hba *hba, bool on,
* triggered by Auto-Hibern8.
*/
if (!ufshcd_can_hibern8_during_gating(hba) &&
- ufshcd_is_auto_hibern8_enabled(hba) &&
- ufs_mtk_link_get_state(hba) ==
- VS_LINK_HIBERN8)
- ufs_mtk_setup_ref_clk(hba, on);
+ ufshcd_is_auto_hibern8_enabled(hba)) {
+ ret = ufs_mtk_wait_link_state(hba,
+ VS_LINK_HIBERN8,
+ 15);
+ if (!ret)
+ ufs_mtk_setup_ref_clk(hba, on);
+ }
}
} else if (on && status == POST_CHANGE) {
ret = phy_power_on(host->mphy);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/5] scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Currently ref-clk control timeout is implemented by Jiffies. However
jiffies is not accurate enough thus "false timeout" may happen.
Use more accurate delay mechanism instead, for example, ktime.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Andy Teng <andy.teng@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 7 ++++---
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index d56ce8d97d4e..523ee5573921 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -120,7 +120,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
struct arm_smccc_res res;
- unsigned long timeout;
+ ktime_t timeout, time_checked;
u32 value;
if (host->ref_clk_enabled == on)
@@ -135,8 +135,9 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
}
/* Wait for ack */
- timeout = jiffies + msecs_to_jiffies(REFCLK_REQ_TIMEOUT_MS);
+ timeout = ktime_add_us(ktime_get(), REFCLK_REQ_TIMEOUT_US);
do {
+ time_checked = ktime_get();
value = ufshcd_readl(hba, REG_UFS_REFCLK_CTRL);
/* Wait until ack bit equals to req bit */
@@ -144,7 +145,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
goto out;
usleep_range(100, 200);
- } while (time_before(jiffies, timeout));
+ } while (ktime_before(time_checked, timeout));
dev_err(hba->dev, "missing ack of refclk req, reg: 0x%x\n", value);
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 5bbd3e9cbae2..fc42dcbfd800 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -28,7 +28,7 @@
#define REFCLK_REQUEST BIT(0)
#define REFCLK_ACK BIT(1)
-#define REFCLK_REQ_TIMEOUT_MS 3
+#define REFCLK_REQ_TIMEOUT_US 3000
/*
* Vendor specific pre-defined parameters
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 5/5] scsi: ufs-mediatek: Allow unbound mphy
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Allow unbound MPHY module since not every MediaTek UFS platform
needs specific MPHY control.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index de9e643fb8dd..d587b3276aa8 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -113,6 +113,12 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
if (err)
host->mphy = NULL;
+ /*
+ * Allow unbound mphy because not every platform needs specific
+ * mphy control.
+ */
+ if (err == -ENODEV)
+ err = 0;
return err;
}
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/5] scsi: ufs-mediatek: Fix clk-gating and introduce low-power mode for vccq2
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
Hi,
This series fixes clk-gating issues and introduces low-power mode for vccq2 in MediaTek platforms.
v1 -> v2:
- Add patch [4] and [5]
Stanley Chu (5):
scsi: ufs-mediatek: Fix imprecise waiting time for ref-clk control
scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is not entered
yet
scsi: ufs-mediatek: Introduce low-power mode for device power supply
scsi: ufs-mediatek: Fix unbalanced clock on/off
scsi: ufs-mediatek: Allow unbound mphy
drivers/scsi/ufs/ufs-mediatek.c | 112 +++++++++++++++++++++++---------
drivers/scsi/ufs/ufs-mediatek.h | 2 +-
2 files changed, 84 insertions(+), 30 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/5] scsi: ufs-mediatek: Introduce low-power mode for device power supply
From: Stanley Chu @ 2020-05-29 9:23 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: pengshun.zhao, Stanley Chu, bvanassche, andy.teng, cc.chou,
chun-hung.wu, kuohong.wang, linux-kernel, cang, linux-mediatek,
peter.wang, matthias.bgg, beanhuo, chaotian.jing,
linux-arm-kernel, asutoshd
In-Reply-To: <20200529092310.1106-1-stanley.chu@mediatek.com>
Allow device power supply to enter low-power mode if device will
do nothing to save more power.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Reviewed-by: Pengshun Zhao <pengshun.zhao@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 3c85f5e97dea..5f41b7b7db8f 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -12,6 +12,7 @@
#include <linux/of_address.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
#include <linux/soc/mediatek/mtk_sip_svc.h>
#include "ufshcd.h"
@@ -521,6 +522,19 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba *hba)
return 0;
}
+static void ufs_mtk_vreg_set_lpm(struct ufs_hba *hba, bool lpm)
+{
+ if (!hba->vreg_info.vccq2)
+ return;
+
+ if (lpm & !hba->vreg_info.vcc->enabled)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_IDLE);
+ else if (!lpm)
+ regulator_set_mode(hba->vreg_info.vccq2->reg,
+ REGULATOR_MODE_NORMAL);
+}
+
static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
{
int err;
@@ -537,6 +551,12 @@ static int ufs_mtk_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op)
ufshcd_set_link_off(hba);
return -EAGAIN;
}
+ /*
+ * Make sure no error will be returned to prevent
+ * ufshcd_suspend() re-enabling regulators while vreg is still
+ * in low-power mode.
+ */
+ ufs_mtk_vreg_set_lpm(hba, true);
}
if (!ufshcd_is_link_active(hba))
@@ -554,6 +574,7 @@ static int ufs_mtk_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op)
phy_power_on(host->mphy);
if (ufshcd_is_link_hibern8(hba)) {
+ ufs_mtk_vreg_set_lpm(hba, false);
err = ufs_mtk_link_set_hpm(hba);
if (err) {
err = ufshcd_link_recovery(hba);
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v7 04/24] iommu: Add a page fault handler
From: Xiang Zheng @ 2020-05-29 9:18 UTC (permalink / raw)
To: Jean-Philippe Brucker, iommu, devicetree, linux-arm-kernel,
linux-pci, linux-mm
Cc: fenghua.yu, kevin.tian, jacob.jun.pan, will, catalin.marinas,
joro, christian.koenig, hch, jgg, Wang Haibin, Jonathan.Cameron,
zhangfei.gao, xuzaibo, robin.murphy, felix.kuehling, baolu.lu
In-Reply-To: <20200519175502.2504091-5-jean-philippe@linaro.org>
Hi,
On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
> Some systems allow devices to handle I/O Page Faults in the core mm. For
> example systems implementing the PCIe PRI extension or Arm SMMU stall
> model. Infrastructure for reporting these recoverable page faults was
> added to the IOMMU core by commit 0c830e6b3282 ("iommu: Introduce device
> fault report API"). Add a page fault handler for host SVA.
>
> IOMMU driver can now instantiate several fault workqueues and link them
> to IOPF-capable devices. Drivers can choose between a single global
> workqueue, one per IOMMU device, one per low-level fault queue, one per
> domain, etc.
>
> When it receives a fault event, supposedly in an IRQ handler, the IOMMU
> driver reports the fault using iommu_report_device_fault(), which calls
> the registered handler. The page fault handler then calls the mm fault
> handler, and reports either success or failure with iommu_page_response().
> When the handler succeeded, the IOMMU retries the access.
>
> The iopf_param pointer could be embedded into iommu_fault_param. But
> putting iopf_param into the iommu_param structure allows us not to care
> about ordering between calls to iopf_queue_add_device() and
> iommu_register_device_fault_handler().
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> ---
> v6->v7: Fix leak in iopf_queue_discard_partial()
> ---
> drivers/iommu/Kconfig | 4 +
> drivers/iommu/Makefile | 1 +
> include/linux/iommu.h | 51 +++++
> drivers/iommu/io-pgfault.c | 459 +++++++++++++++++++++++++++++++++++++
> 4 files changed, 515 insertions(+)
> create mode 100644 drivers/iommu/io-pgfault.c
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index d9fa5b410015..15e9dc4e503c 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -107,6 +107,10 @@ config IOMMU_SVA
> bool
> select IOASID
>
> +config IOMMU_PAGE_FAULT
> + bool
> + select IOMMU_SVA
> +
> config FSL_PAMU
> bool "Freescale IOMMU support"
> depends on PCI
> diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
> index 40c800dd4e3e..bf5cb4ee8409 100644
> --- a/drivers/iommu/Makefile
> +++ b/drivers/iommu/Makefile
> @@ -4,6 +4,7 @@ obj-$(CONFIG_IOMMU_API) += iommu-traces.o
> obj-$(CONFIG_IOMMU_API) += iommu-sysfs.o
> obj-$(CONFIG_IOMMU_DEBUGFS) += iommu-debugfs.o
> obj-$(CONFIG_IOMMU_DMA) += dma-iommu.o
> +obj-$(CONFIG_IOMMU_PAGE_FAULT) += io-pgfault.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE) += io-pgtable.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_ARMV7S) += io-pgtable-arm-v7s.o
> obj-$(CONFIG_IOMMU_IO_PGTABLE_LPAE) += io-pgtable-arm.o
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index b62525747bd9..a462157c855b 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -46,6 +46,7 @@ struct iommu_domain;
> struct notifier_block;
> struct iommu_sva;
> struct iommu_fault_event;
> +struct iopf_queue;
>
> /* iommu fault flags */
> #define IOMMU_FAULT_READ 0x0
> @@ -347,6 +348,7 @@ struct iommu_fault_param {
> * struct dev_iommu - Collection of per-device IOMMU data
> *
> * @fault_param: IOMMU detected device fault reporting data
> + * @iopf_param: I/O Page Fault queue and data
> * @fwspec: IOMMU fwspec data
> * @priv: IOMMU Driver private data
> *
> @@ -356,6 +358,7 @@ struct iommu_fault_param {
> struct dev_iommu {
> struct mutex lock;
> struct iommu_fault_param *fault_param;
> + struct iopf_device_param *iopf_param;
> struct iommu_fwspec *fwspec;
> void *priv;
> };
[...]
> #endif /* __LINUX_IOMMU_H */
> diff --git a/drivers/iommu/io-pgfault.c b/drivers/iommu/io-pgfault.c
> new file mode 100644
> index 000000000000..1f61c1bc05da
> --- /dev/null
> +++ b/drivers/iommu/io-pgfault.c
> @@ -0,0 +1,459 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Handle device page faults
> + *
> + * Copyright (C) 2020 ARM Ltd.
> + */
> +
> +#include <linux/iommu.h>
> +#include <linux/list.h>
> +#include <linux/sched/mm.h>
> +#include <linux/slab.h>
> +#include <linux/workqueue.h>
> +
> +#include "iommu-sva.h"
> +
> +/**
> + * struct iopf_queue - IO Page Fault queue
> + * @wq: the fault workqueue
> + * @devices: devices attached to this queue
> + * @lock: protects the device list
> + */
> +struct iopf_queue {
> + struct workqueue_struct *wq;
> + struct list_head devices;
> + struct mutex lock;
> +};
> +
> +/**
> + * struct iopf_device_param - IO Page Fault data attached to a device
> + * @dev: the device that owns this param
> + * @queue: IOPF queue
> + * @queue_list: index into queue->devices
> + * @partial: faults that are part of a Page Request Group for which the last
> + * request hasn't been submitted yet.
> + */
> +struct iopf_device_param {
> + struct device *dev;
> + struct iopf_queue *queue;
> + struct list_head queue_list;
> + struct list_head partial;
> +};
> +
> +struct iopf_fault {
> + struct iommu_fault fault;
> + struct list_head list;
> +};
> +
> +struct iopf_group {
> + struct iopf_fault last_fault;
> + struct list_head faults;
> + struct work_struct work;
> + struct device *dev;
> +};
> +
>
[...]
> +
> +static void iopf_handle_group(struct work_struct *work)
> +{
> + struct iopf_group *group;
> + struct iopf_fault *iopf, *next;
> + enum iommu_page_response_code status = IOMMU_PAGE_RESP_SUCCESS;
> +
> + group = container_of(work, struct iopf_group, work);
> +
> + list_for_each_entry_safe(iopf, next, &group->faults, list) {
> + /*
> + * For the moment, errors are sticky: don't handle subsequent
> + * faults in the group if there is an error.
> + */
> + if (status == IOMMU_PAGE_RESP_SUCCESS)
> + status = iopf_handle_single(iopf);
> +
> + if (!(iopf->fault.prm.flags &
> + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> + kfree(iopf);
> + }
> +
> + iopf_complete_group(group->dev, &group->last_fault, status);
> + kfree(group);
> +}
> +
> +/**
> + * iommu_queue_iopf - IO Page Fault handler
> + * @evt: fault event
> + * @cookie: struct device, passed to iommu_register_device_fault_handler.
> + *
> + * Add a fault to the device workqueue, to be handled by mm.
> + *
> + * This module doesn't handle PCI PASID Stop Marker; IOMMU drivers must discard
> + * them before reporting faults. A PASID Stop Marker (LRW = 0b100) doesn't
> + * expect a response. It may be generated when disabling a PASID (issuing a
> + * PASID stop request) by some PCI devices.
> + *
> + * The PASID stop request is issued by the device driver before unbind(). Once
> + * it completes, no page request is generated for this PASID anymore and
> + * outstanding ones have been pushed to the IOMMU (as per PCIe 4.0r1.0 - 6.20.1
> + * and 10.4.1.2 - Managing PASID TLP Prefix Usage). Some PCI devices will wait
> + * for all outstanding page requests to come back with a response before
> + * completing the PASID stop request. Others do not wait for page responses, and
> + * instead issue this Stop Marker that tells us when the PASID can be
> + * reallocated.
> + *
> + * It is safe to discard the Stop Marker because it is an optimization.
> + * a. Page requests, which are posted requests, have been flushed to the IOMMU
> + * when the stop request completes.
> + * b. We flush all fault queues on unbind() before freeing the PASID.
> + *
> + * So even though the Stop Marker might be issued by the device *after* the stop
> + * request completes, outstanding faults will have been dealt with by the time
> + * we free the PASID.
> + *
> + * Return: 0 on success and <0 on error.
> + */
> +int iommu_queue_iopf(struct iommu_fault *fault, void *cookie)
> +{
> + int ret;
> + struct iopf_group *group;
> + struct iopf_fault *iopf, *next;
> + struct iopf_device_param *iopf_param;
> +
> + struct device *dev = cookie;
> + struct dev_iommu *param = dev->iommu;
> +
> + lockdep_assert_held(¶m->lock);
> +
> + if (fault->type != IOMMU_FAULT_PAGE_REQ)
> + /* Not a recoverable page fault */
> + return -EOPNOTSUPP;
> +
> + /*
> + * As long as we're holding param->lock, the queue can't be unlinked
> + * from the device and therefore cannot disappear.
> + */
> + iopf_param = param->iopf_param;
> + if (!iopf_param)
> + return -ENODEV;
> +
> + if (!(fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE)) {
> + iopf = kzalloc(sizeof(*iopf), GFP_KERNEL);
> + if (!iopf)
> + return -ENOMEM;
> +
> + iopf->fault = *fault;
> +
> + /* Non-last request of a group. Postpone until the last one */
> + list_add(&iopf->list, &iopf_param->partial);
> +
> + return 0;
> + }
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group) {
> + /*
> + * The caller will send a response to the hardware. But we do
> + * need to clean up before leaving, otherwise partial faults
> + * will be stuck.
> + */
> + ret = -ENOMEM;
> + goto cleanup_partial;
> + }
> +
> + group->dev = dev;
> + group->last_fault.fault = *fault;
> + INIT_LIST_HEAD(&group->faults);
> + list_add(&group->last_fault.list, &group->faults);
> + INIT_WORK(&group->work, iopf_handle_group);
> +
> + /* See if we have partial faults for this group */
> + list_for_each_entry_safe(iopf, next, &iopf_param->partial, list) {
> + if (iopf->fault.prm.grpid == fault->prm.grpid)
> + /* Insert *before* the last fault */
> + list_move(&iopf->list, &group->faults);
> + }
> +
> + queue_work(iopf_param->queue->wq, &group->work);
> + return 0;
> +
> +cleanup_partial:
> + list_for_each_entry_safe(iopf, next, &iopf_param->partial, list) {
> + if (iopf->fault.prm.grpid == fault->prm.grpid) {
> + list_del(&iopf->list);
> + kfree(iopf);
> + }
> + }
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_queue_iopf);
[...]
> +/**
> + * iopf_queue_remove_device - Remove producer from fault queue
> + * @queue: IOPF queue
> + * @dev: device to remove
> + *
> + * Caller makes sure that no more faults are reported for this device.
> + *
> + * Return: 0 on success and <0 on error.
> + */
> +int iopf_queue_remove_device(struct iopf_queue *queue, struct device *dev)
> +{
> + int ret = 0;
> + struct iopf_fault *iopf, *next;
> + struct iopf_device_param *iopf_param;
> + struct dev_iommu *param = dev->iommu;
> +
> + if (!param || !queue)
> + return -EINVAL;
> +
> + mutex_lock(&queue->lock);
> + mutex_lock(¶m->lock);
> + iopf_param = param->iopf_param;
> + if (iopf_param && iopf_param->queue == queue) {
> + list_del(&iopf_param->queue_list);
> + param->iopf_param = NULL;
> + } else {
> + ret = -EINVAL;
> + }
> + mutex_unlock(¶m->lock);
> + mutex_unlock(&queue->lock);
> + if (ret)
> + return ret;
> +
> + /* Just in case some faults are still stuck */
> + list_for_each_entry_safe(iopf, next, &iopf_param->partial, list)
> + kfree(iopf);
> +
> + kfree(iopf_param);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_remove_device);
> +
> +/**
> + * iopf_queue_alloc - Allocate and initialize a fault queue
> + * @name: a unique string identifying the queue (for workqueue)
> + *
> + * Return: the queue on success and NULL on error.
> + */
> +struct iopf_queue *iopf_queue_alloc(const char *name)
> +{
> + struct iopf_queue *queue;
> +
> + queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> + if (!queue)
> + return NULL;
> +
> + /*
> + * The WQ is unordered because the low-level handler enqueues faults by
> + * group. PRI requests within a group have to be ordered, but once
> + * that's dealt with, the high-level function can handle groups out of
> + * order.
> + */
> + queue->wq = alloc_workqueue("iopf_queue/%s", WQ_UNBOUND, 0, name);
> + if (!queue->wq) {
> + kfree(queue);
> + return NULL;
> + }
> +
> + INIT_LIST_HEAD(&queue->devices);
> + mutex_init(&queue->lock);
> +
> + return queue;
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_alloc);
> +
> +/**
> + * iopf_queue_free - Free IOPF queue
> + * @queue: queue to free
> + *
> + * Counterpart to iopf_queue_alloc(). The driver must not be queuing faults or
> + * adding/removing devices on this queue anymore.
> + */
> +void iopf_queue_free(struct iopf_queue *queue)
> +{
> + struct iopf_device_param *iopf_param, *next;
> +
> + if (!queue)
> + return;
> +
> + list_for_each_entry_safe(iopf_param, next, &queue->devices, queue_list)
> + iopf_queue_remove_device(queue, iopf_param->dev);
> +
> + destroy_workqueue(queue->wq);
Do we need to free iopf_group(s) here in case the work queue of the group(s) are not
scheduled yet? If that occurs, we might leak memory here.
If the caller can ensure that would never occur or I miss something, please ignore
my noise. :)
> + kfree(queue);
> +}
> +EXPORT_SYMBOL_GPL(iopf_queue_free);
>
--
Thanks,
Xiang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 17/20] mtd: rawnand: Hide the generic OOB layout objects behind helpers
From: Miquel Raynal @ 2020-05-29 9:17 UTC (permalink / raw)
To: Boris Brezillon
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529104640.1997434f@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Fri, 29 May
2020 10:46:40 +0200:
> On Fri, 29 May 2020 10:45:48 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > On Fri, 29 May 2020 02:25:14 +0200
> > Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > > +const struct mtd_ooblayout_ops *nand_get_large_page_layout(void)
> >
> > nand_get_large_page_ooblayout() (same for the other helpers).
> >
>
> And sorry if I got it wrong in my previous review :-/.
Haha, no pb ;)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 17/20] mtd: rawnand: Hide the generic OOB layout objects behind helpers
From: Boris Brezillon @ 2020-05-29 8:46 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529104548.0038bbe7@collabora.com>
On Fri, 29 May 2020 10:45:48 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Fri, 29 May 2020 02:25:14 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > +const struct mtd_ooblayout_ops *nand_get_large_page_layout(void)
>
> nand_get_large_page_ooblayout() (same for the other helpers).
>
And sorry if I got it wrong in my previous review :-/.
> > +{
> > + return &nand_ooblayout_lp_ops;
> > +}
> > +EXPORT_SYMBOL_GPL(nand_get_large_page_layout);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 17/20] mtd: rawnand: Hide the generic OOB layout objects behind helpers
From: Boris Brezillon @ 2020-05-29 8:45 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529002517.3546-18-miquel.raynal@bootlin.com>
On Fri, 29 May 2020 02:25:14 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> +const struct mtd_ooblayout_ops *nand_get_large_page_layout(void)
nand_get_large_page_ooblayout() (same for the other helpers).
> +{
> + return &nand_ooblayout_lp_ops;
> +}
> +EXPORT_SYMBOL_GPL(nand_get_large_page_layout);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 16/20] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Boris Brezillon @ 2020-05-29 8:35 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529002517.3546-17-miquel.raynal@bootlin.com>
On Fri, 29 May 2020 02:25:13 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> - * struct_nand_device->memorg and struct_nand_device->eccreq should be filled
> - * at device detection time to reflect the NAND device
> + * struct_nand_device->memorg and struct_nand_device->ecc.ctx.conf should
> + * be filled at device detection time to reflect the NAND device
Is it not struct_nand_device->ecc.requirements?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v3-its: Don't try to move a disabled irq
From: Marc Zyngier @ 2020-05-29 8:32 UTC (permalink / raw)
To: Ali Saidi
Cc: benh, Jason Cooper, zorik, linux-kernel, zeev, Thomas Gleixner,
linux-arm-kernel, dwmw
In-Reply-To: <20200529015501.15771-1-alisaidi@amazon.com>
Hi Ali,
On 2020-05-29 02:55, Ali Saidi wrote:
> If an interrupt is disabled the ITS driver has sent a discard removing
> the DeviceID and EventID from the ITT. After this occurs it can't be
> moved to another collection with a MOVI and a command error occurs if
> attempted. Before issuing the MOVI command make sure that the IRQ isn't
> disabled and change the activate code to try and use the previous
> affinity.
>
> Signed-off-by: Ali Saidi <alisaidi@amazon.com>
> ---
> drivers/irqchip/irq-gic-v3-its.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c
> b/drivers/irqchip/irq-gic-v3-its.c
> index 124251b0ccba..1235dd9a2fb2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -1540,7 +1540,11 @@ static int its_set_affinity(struct irq_data *d,
> const struct cpumask *mask_val,
> /* don't set the affinity when the target cpu is same as current one
> */
> if (cpu != its_dev->event_map.col_map[id]) {
> target_col = &its_dev->its->collections[cpu];
> - its_send_movi(its_dev, target_col, id);
> +
> + /* If the IRQ is disabled a discard was sent so don't move */
> + if (!irqd_irq_disabled(d))
> + its_send_movi(its_dev, target_col, id);
> +
This looks wrong. What you are testing here is whether the interrupt
is masked, not that there isn't a valid translation.
In the commit message, you're saying that we've issued a discard. This
hints at doing a set_affinity on an interrupt that has been deactivated
(mapping removed). Is that actually the case? If so, why was it
deactivated
the first place?
> its_dev->event_map.col_map[id] = cpu;
> irq_data_update_effective_affinity(d, cpumask_of(cpu));
> }
> @@ -3439,8 +3443,16 @@ static int its_irq_domain_activate(struct
> irq_domain *domain,
> if (its_dev->its->numa_node >= 0)
> cpu_mask = cpumask_of_node(its_dev->its->numa_node);
>
> - /* Bind the LPI to the first possible CPU */
> - cpu = cpumask_first_and(cpu_mask, cpu_online_mask);
> + /* If the cpu set to a different CPU that is still online use it */
> + cpu = its_dev->event_map.col_map[event];
> +
> + cpumask_and(cpu_mask, cpu_mask, cpu_online_mask);
> +
> + if (!cpumask_test_cpu(cpu, cpu_mask)) {
> + /* Bind the LPI to the first possible CPU */
> + cpu = cpumask_first(cpu_mask);
> + }
> +
> if (cpu >= nr_cpu_ids) {
> if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144)
> return -EINVAL;
So you deactivate an interrupt, do a set_affinity that doesn't issue
a MOVI but preserves the affinity, then reactivate it and hope that
the new mapping will target the "right" CPU.
That seems a bit mad, but I presume this isn't the whole story...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 16/20] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Boris Brezillon @ 2020-05-29 8:32 UTC (permalink / raw)
To: Miquel Raynal
Cc: Mark Rutland, devicetree, Vignesh Raghavendra, Tudor Ambarus,
Julien Su, Richard Weinberger, Weijie Gao, Paul Cercueil,
Rob Herring, linux-mtd, Thomas Petazzoni, Mason Yang,
Chuanhong Guo, linux-arm-kernel
In-Reply-To: <20200529002517.3546-17-miquel.raynal@bootlin.com>
On Fri, 29 May 2020 02:25:13 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Embed a generic NAND ECC high-level object in the nand_device
> structure to carry all the ECC engine configuration/data. Adapt the
> raw NAND and SPI-NAND cores to fit the change.
In order to split that one, and make future re-organizations less
painful (hope we won't have to do that again, but who knows), I would
recommend doing things in this order:
1/ create a nanddev_get_ecc_requirements() helper that returns a
const struct nand_ecc_props *
2/ patch spinand to use this helper
3/ introduce nand_ecc
4/ patch rawnand to use the new ecc layer
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/raw/atmel/nand-controller.c | 9 +++--
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 7 ++--
> drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 12 +++---
> drivers/mtd/nand/raw/marvell_nand.c | 7 ++--
> drivers/mtd/nand/raw/mtk_nand.c | 4 +-
> drivers/mtd/nand/raw/nand_base.c | 25 ++++++------
> drivers/mtd/nand/raw/nand_esmt.c | 11 +++---
> drivers/mtd/nand/raw/nand_hynix.c | 41 ++++++++++----------
> drivers/mtd/nand/raw/nand_jedec.c | 4 +-
> drivers/mtd/nand/raw/nand_micron.c | 14 ++++---
> drivers/mtd/nand/raw/nand_onfi.c | 8 ++--
> drivers/mtd/nand/raw/nand_samsung.c | 19 ++++-----
> drivers/mtd/nand/raw/nand_toshiba.c | 11 +++---
> drivers/mtd/nand/raw/sunxi_nand.c | 5 ++-
> drivers/mtd/nand/raw/tegra_nand.c | 9 +++--
> drivers/mtd/nand/spi/core.c | 8 ++--
> drivers/mtd/nand/spi/macronix.c | 6 +--
> drivers/mtd/nand/spi/toshiba.c | 6 +--
> include/linux/mtd/nand.h | 8 ++--
> 19 files changed, 114 insertions(+), 100 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index 85cf396731ce..2ebcf3087d8d 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -1043,6 +1043,7 @@ static int atmel_hsmc_nand_pmecc_read_page_raw(struct nand_chip *chip,
>
> static int atmel_nand_pmecc_init(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct atmel_nand *nand = to_atmel_nand(chip);
> struct atmel_nand_controller *nc;
> @@ -1072,15 +1073,15 @@ static int atmel_nand_pmecc_init(struct nand_chip *chip)
> req.ecc.strength = ATMEL_PMECC_MAXIMIZE_ECC_STRENGTH;
> else if (chip->ecc.strength)
> req.ecc.strength = chip->ecc.strength;
> - else if (chip->base.eccreq.strength)
> - req.ecc.strength = chip->base.eccreq.strength;
> + else if (requirements->strength)
> + req.ecc.strength = requirements->strength;
> else
> req.ecc.strength = ATMEL_PMECC_MAXIMIZE_ECC_STRENGTH;
>
> if (chip->ecc.size)
> req.ecc.sectorsize = chip->ecc.size;
> - else if (chip->base.eccreq.step_size)
> - req.ecc.sectorsize = chip->base.eccreq.step_size;
> + else if (requirements->step_size)
> + req.ecc.sectorsize = requirements->step_size;
> else
> req.ecc.sectorsize = ATMEL_PMECC_SECTOR_SIZE_AUTO;
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> index 164617b33942..40f6d107ffa2 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -2563,10 +2563,11 @@ static int brcmnand_setup_dev(struct brcmnand_host *host)
>
> if (chip->ecc.engine_type != NAND_ECC_ENGINE_TYPE_NONE &&
> (!chip->ecc.size || !chip->ecc.strength)) {
> - if (chip->base.eccreq.step_size && chip->base.eccreq.strength) {
> + if (chip->base.ecc.requirements.step_size &&
> + chip->base.ecc.requirements.strength) {
> /* use detected ECC parameters */
> - chip->ecc.size = chip->base.eccreq.step_size;
> - chip->ecc.strength = chip->base.eccreq.strength;
> + chip->ecc.size = chip->base.ecc.requirements.step_size;
> + chip->ecc.strength = chip->base.ecc.requirements.strength;
> dev_info(ctrl->dev, "Using ECC step-size %d, strength %d\n",
> chip->ecc.size, chip->ecc.strength);
> }
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index d1ea6df9fd64..5f56570ce04d 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -272,8 +272,8 @@ static int set_geometry_by_ecc_info(struct gpmi_nand_data *this,
> default:
> dev_err(this->dev,
> "unsupported nand chip. ecc bits : %d, ecc size : %d\n",
> - chip->base.eccreq.strength,
> - chip->base.eccreq.step_size);
> + chip->base.ecc.requirements.strength,
> + chip->base.ecc.requirements.step_size);
> return -EINVAL;
> }
> geo->ecc_chunk_size = ecc_step;
> @@ -517,13 +517,13 @@ static int common_nfc_set_geometry(struct gpmi_nand_data *this)
>
> if ((of_property_read_bool(this->dev->of_node, "fsl,use-minimum-ecc"))
> || legacy_set_geometry(this)) {
> - if (!(chip->base.eccreq.strength > 0 &&
> - chip->base.eccreq.step_size > 0))
> + if (!(chip->base.ecc.requirements.strength > 0 &&
> + chip->base.ecc.requirements.step_size > 0))
> return -EINVAL;
>
> return set_geometry_by_ecc_info(this,
> - chip->base.eccreq.strength,
> - chip->base.eccreq.step_size);
> + chip->base.ecc.requirements.strength,
> + chip->base.ecc.requirements.step_size);
> }
>
> return 0;
> diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c
> index f9cc03c11deb..e7a269461a6d 100644
> --- a/drivers/mtd/nand/raw/marvell_nand.c
> +++ b/drivers/mtd/nand/raw/marvell_nand.c
> @@ -2244,14 +2244,15 @@ static int marvell_nand_ecc_init(struct mtd_info *mtd,
> struct nand_ecc_ctrl *ecc)
> {
> struct nand_chip *chip = mtd_to_nand(mtd);
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct marvell_nfc *nfc = to_marvell_nfc(chip->controller);
> int ret;
>
> if (ecc->engine_type != NAND_ECC_ENGINE_TYPE_NONE &&
> (!ecc->size || !ecc->strength)) {
> - if (chip->base.eccreq.step_size && chip->base.eccreq.strength) {
> - ecc->size = chip->base.eccreq.step_size;
> - ecc->strength = chip->base.eccreq.strength;
> + if (requirements->step_size && requirements->strength) {
> + ecc->size = requirements->step_size;
> + ecc->strength = requirements->strength;
> } else {
> dev_info(nfc->dev,
> "No minimum ECC strength, using 1b/512B\n");
> diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c
> index a0294c9161dd..1f8dbae38286 100644
> --- a/drivers/mtd/nand/raw/mtk_nand.c
> +++ b/drivers/mtd/nand/raw/mtk_nand.c
> @@ -1234,8 +1234,8 @@ static int mtk_nfc_ecc_init(struct device *dev, struct mtd_info *mtd)
> /* if optional dt settings not present */
> if (!nand->ecc.size || !nand->ecc.strength) {
> /* use datasheet requirements */
> - nand->ecc.strength = nand->base.eccreq.strength;
> - nand->ecc.size = nand->base.eccreq.step_size;
> + nand->ecc.strength = nand->base.ecc.requirements.strength;
> + nand->ecc.size = nand->base.ecc.requirements.step_size;
>
> /*
> * align eccstrength and eccsize
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 1ce2cbe72e4c..bc2d5d2e8f4c 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -4746,8 +4746,8 @@ static bool find_full_id_nand(struct nand_chip *chip,
> memorg->pagesize *
> memorg->pages_per_eraseblock);
> chip->options |= type->options;
> - chip->base.eccreq.strength = NAND_ECC_STRENGTH(type);
> - chip->base.eccreq.step_size = NAND_ECC_STEP(type);
> + chip->base.ecc.requirements.strength = NAND_ECC_STRENGTH(type);
> + chip->base.ecc.requirements.step_size = NAND_ECC_STEP(type);
> chip->onfi_timing_mode_default =
> type->onfi_timing_mode_default;
>
> @@ -5485,8 +5485,8 @@ nand_match_ecc_req(struct nand_chip *chip,
> {
> struct mtd_info *mtd = nand_to_mtd(chip);
> const struct nand_ecc_step_info *stepinfo;
> - int req_step = chip->base.eccreq.step_size;
> - int req_strength = chip->base.eccreq.strength;
> + int req_step = chip->base.ecc.requirements.step_size;
> + int req_strength = chip->base.ecc.requirements.strength;
> int req_corr, step_size, strength, nsteps, ecc_bytes, ecc_bytes_total;
> int best_step, best_strength, best_ecc_bytes;
> int best_ecc_bytes_total = INT_MAX;
> @@ -5677,9 +5677,10 @@ static bool nand_ecc_strength_good(struct nand_chip *chip)
> {
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct nand_ecc_ctrl *ecc = &chip->ecc;
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> int corr, ds_corr;
>
> - if (ecc->size == 0 || chip->base.eccreq.step_size == 0)
> + if (ecc->size == 0 || requirements->step_size == 0)
> /* Not enough information */
> return true;
>
> @@ -5688,10 +5689,10 @@ static bool nand_ecc_strength_good(struct nand_chip *chip)
> * the correction density.
> */
> corr = (mtd->writesize * ecc->strength) / ecc->size;
> - ds_corr = (mtd->writesize * chip->base.eccreq.strength) /
> - chip->base.eccreq.step_size;
> + ds_corr = (mtd->writesize * requirements->strength) /
> + requirements->step_size;
>
> - return corr >= ds_corr && ecc->strength >= chip->base.eccreq.strength;
> + return corr >= ds_corr && ecc->strength >= requirements->strength;
> }
>
> static int rawnand_erase(struct nand_device *nand, const struct nand_pos *pos)
> @@ -5977,9 +5978,11 @@ static int nand_scan_tail(struct nand_chip *chip)
> /* ECC sanity check: warn if it's too weak */
> if (!nand_ecc_strength_good(chip))
> pr_warn("WARNING: %s: the ECC used on your system (%db/%dB) is too weak compared to the one required by the NAND chip (%db/%dB)\n",
> - mtd->name, chip->ecc.strength, chip->ecc.size,
> - chip->base.eccreq.strength,
> - chip->base.eccreq.step_size);
> + mtd->name,
> + chip->base.ecc.ctx.conf.strength,
> + chip->base.ecc.ctx.conf.step_size,
> + chip->base.ecc.requirements.strength,
> + chip->base.ecc.requirements.step_size);
>
> /* Allow subpage writes up to ecc.steps. Not possible for MLC flash */
> if (!(chip->options & NAND_NO_SUBPAGE_WRITE) && nand_is_slc(chip)) {
> diff --git a/drivers/mtd/nand/raw/nand_esmt.c b/drivers/mtd/nand/raw/nand_esmt.c
> index 3338c68aaaf1..11f25ec3e4fc 100644
> --- a/drivers/mtd/nand/raw/nand_esmt.c
> +++ b/drivers/mtd/nand/raw/nand_esmt.c
> @@ -10,24 +10,25 @@
>
> static void esmt_nand_decode_id(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> nand_decode_ext_id(chip);
>
> /* Extract ECC requirements from 5th id byte. */
> if (chip->id.len >= 5 && nand_is_slc(chip)) {
> - chip->base.eccreq.step_size = 512;
> + requirements->step_size = 512;
> switch (chip->id.data[4] & 0x3) {
> case 0x0:
> - chip->base.eccreq.strength = 4;
> + requirements->strength = 4;
> break;
> case 0x1:
> - chip->base.eccreq.strength = 2;
> + requirements->strength = 2;
> break;
> case 0x2:
> - chip->base.eccreq.strength = 1;
> + requirements->strength = 1;
> break;
> default:
> WARN(1, "Could not get ECC info");
> - chip->base.eccreq.step_size = 0;
> + requirements->step_size = 0;
> break;
> }
> }
> diff --git a/drivers/mtd/nand/raw/nand_hynix.c b/drivers/mtd/nand/raw/nand_hynix.c
> index 7caedaa5b9e5..bac7732a86e9 100644
> --- a/drivers/mtd/nand/raw/nand_hynix.c
> +++ b/drivers/mtd/nand/raw/nand_hynix.c
> @@ -495,34 +495,35 @@ static void hynix_nand_extract_oobsize(struct nand_chip *chip,
> static void hynix_nand_extract_ecc_requirements(struct nand_chip *chip,
> bool valid_jedecid)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> u8 ecc_level = (chip->id.data[4] >> 4) & 0x7;
>
> if (valid_jedecid) {
> /* Reference: H27UCG8T2E datasheet */
> - chip->base.eccreq.step_size = 1024;
> + requirements->step_size = 1024;
>
> switch (ecc_level) {
> case 0:
> - chip->base.eccreq.step_size = 0;
> - chip->base.eccreq.strength = 0;
> + requirements->step_size = 0;
> + requirements->strength = 0;
> break;
> case 1:
> - chip->base.eccreq.strength = 4;
> + requirements->strength = 4;
> break;
> case 2:
> - chip->base.eccreq.strength = 24;
> + requirements->strength = 24;
> break;
> case 3:
> - chip->base.eccreq.strength = 32;
> + requirements->strength = 32;
> break;
> case 4:
> - chip->base.eccreq.strength = 40;
> + requirements->strength = 40;
> break;
> case 5:
> - chip->base.eccreq.strength = 50;
> + requirements->strength = 50;
> break;
> case 6:
> - chip->base.eccreq.strength = 60;
> + requirements->strength = 60;
> break;
> default:
> /*
> @@ -543,14 +544,14 @@ static void hynix_nand_extract_ecc_requirements(struct nand_chip *chip,
> if (nand_tech < 3) {
> /* > 26nm, reference: H27UBG8T2A datasheet */
> if (ecc_level < 5) {
> - chip->base.eccreq.step_size = 512;
> - chip->base.eccreq.strength = 1 << ecc_level;
> + requirements->step_size = 512;
> + requirements->strength = 1 << ecc_level;
> } else if (ecc_level < 7) {
> if (ecc_level == 5)
> - chip->base.eccreq.step_size = 2048;
> + requirements->step_size = 2048;
> else
> - chip->base.eccreq.step_size = 1024;
> - chip->base.eccreq.strength = 24;
> + requirements->step_size = 1024;
> + requirements->strength = 24;
> } else {
> /*
> * We should never reach this case, but if that
> @@ -563,14 +564,14 @@ static void hynix_nand_extract_ecc_requirements(struct nand_chip *chip,
> } else {
> /* <= 26nm, reference: H27UBG8T2B datasheet */
> if (!ecc_level) {
> - chip->base.eccreq.step_size = 0;
> - chip->base.eccreq.strength = 0;
> + requirements->step_size = 0;
> + requirements->strength = 0;
> } else if (ecc_level < 5) {
> - chip->base.eccreq.step_size = 512;
> - chip->base.eccreq.strength = 1 << (ecc_level - 1);
> + requirements->step_size = 512;
> + requirements->strength = 1 << (ecc_level - 1);
> } else {
> - chip->base.eccreq.step_size = 1024;
> - chip->base.eccreq.strength = 24 +
> + requirements->step_size = 1024;
> + requirements->strength = 24 +
> (8 * (ecc_level - 5));
> }
> }
> diff --git a/drivers/mtd/nand/raw/nand_jedec.c b/drivers/mtd/nand/raw/nand_jedec.c
> index b15c42f48755..5ed3656d88dd 100644
> --- a/drivers/mtd/nand/raw/nand_jedec.c
> +++ b/drivers/mtd/nand/raw/nand_jedec.c
> @@ -120,8 +120,8 @@ int nand_jedec_detect(struct nand_chip *chip)
> ecc = &p->ecc_info[0];
>
> if (ecc->codeword_size >= 9) {
> - chip->base.eccreq.strength = ecc->ecc_bits;
> - chip->base.eccreq.step_size = 1 << ecc->codeword_size;
> + chip->base.ecc.requirements.strength = ecc->ecc_bits;
> + chip->base.ecc.requirements.step_size = 1 << ecc->codeword_size;
> } else {
> pr_warn("Invalid codeword size\n");
> }
> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
> index c8ebfd8c77a1..d1dc684ecd6c 100644
> --- a/drivers/mtd/nand/raw/nand_micron.c
> +++ b/drivers/mtd/nand/raw/nand_micron.c
> @@ -413,6 +413,7 @@ enum {
> */
> static int micron_supports_on_die_ecc(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> u8 id[5];
> int ret;
>
> @@ -425,7 +426,7 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
> /*
> * We only support on-die ECC of 4/512 or 8/512
> */
> - if (chip->base.eccreq.strength != 4 && chip->base.eccreq.strength != 8)
> + if (requirements->strength != 4 && requirements->strength != 8)
> return MICRON_ON_DIE_UNSUPPORTED;
>
> /* 0x2 means on-die ECC is available. */
> @@ -466,7 +467,7 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
> /*
> * We only support on-die ECC of 4/512 or 8/512
> */
> - if (chip->base.eccreq.strength != 4 && chip->base.eccreq.strength != 8)
> + if (requirements->strength != 4 && requirements->strength != 8)
> return MICRON_ON_DIE_UNSUPPORTED;
>
> return MICRON_ON_DIE_SUPPORTED;
> @@ -474,6 +475,7 @@ static int micron_supports_on_die_ecc(struct nand_chip *chip)
>
> static int micron_nand_init(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct micron_nand *micron;
> int ondie;
> @@ -523,7 +525,7 @@ static int micron_nand_init(struct nand_chip *chip)
> * That's not needed for 8-bit ECC, because the status expose
> * a better approximation of the number of bitflips in a page.
> */
> - if (chip->base.eccreq.strength == 4) {
> + if (requirements->strength == 4) {
> micron->ecc.rawbuf = kmalloc(mtd->writesize +
> mtd->oobsize,
> GFP_KERNEL);
> @@ -533,16 +535,16 @@ static int micron_nand_init(struct nand_chip *chip)
> }
> }
>
> - if (chip->base.eccreq.strength == 4)
> + if (requirements->strength == 4)
> mtd_set_ooblayout(mtd,
> µn_nand_on_die_4_ooblayout_ops);
> else
> mtd_set_ooblayout(mtd,
> µn_nand_on_die_8_ooblayout_ops);
>
> - chip->ecc.bytes = chip->base.eccreq.strength * 2;
> + chip->ecc.bytes = requirements->strength * 2;
> chip->ecc.size = 512;
> - chip->ecc.strength = chip->base.eccreq.strength;
> + chip->ecc.strength = requirements->strength;
> chip->ecc.algo = NAND_ECC_ALGO_BCH;
> chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
> chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
> diff --git a/drivers/mtd/nand/raw/nand_onfi.c b/drivers/mtd/nand/raw/nand_onfi.c
> index be3456627288..c9ae29774c1f 100644
> --- a/drivers/mtd/nand/raw/nand_onfi.c
> +++ b/drivers/mtd/nand/raw/nand_onfi.c
> @@ -94,8 +94,8 @@ static int nand_flash_detect_ext_param_page(struct nand_chip *chip,
> goto ext_out;
> }
>
> - chip->base.eccreq.strength = ecc->ecc_bits;
> - chip->base.eccreq.step_size = 1 << ecc->codeword_size;
> + chip->base.ecc.requirements.strength = ecc->ecc_bits;
> + chip->base.ecc.requirements.step_size = 1 << ecc->codeword_size;
> ret = 0;
>
> ext_out:
> @@ -265,8 +265,8 @@ int nand_onfi_detect(struct nand_chip *chip)
> chip->options |= NAND_BUSWIDTH_16;
>
> if (p->ecc_bits != 0xff) {
> - chip->base.eccreq.strength = p->ecc_bits;
> - chip->base.eccreq.step_size = 512;
> + chip->base.ecc.requirements.strength = p->ecc_bits;
> + chip->base.ecc.requirements.step_size = 512;
> } else if (onfi_version >= 21 &&
> (le16_to_cpu(p->features) & ONFI_FEATURE_EXT_PARAM_PAGE)) {
>
> diff --git a/drivers/mtd/nand/raw/nand_samsung.c b/drivers/mtd/nand/raw/nand_samsung.c
> index 3a4a19e808f6..0ee85e88aeb5 100644
> --- a/drivers/mtd/nand/raw/nand_samsung.c
> +++ b/drivers/mtd/nand/raw/nand_samsung.c
> @@ -10,6 +10,7 @@
>
> static void samsung_nand_decode_id(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct nand_memory_organization *memorg;
>
> @@ -71,23 +72,23 @@ static void samsung_nand_decode_id(struct nand_chip *chip)
> /* Extract ECC requirements from 5th id byte*/
> extid = (chip->id.data[4] >> 4) & 0x07;
> if (extid < 5) {
> - chip->base.eccreq.step_size = 512;
> - chip->base.eccreq.strength = 1 << extid;
> + requirements->step_size = 512;
> + requirements->strength = 1 << extid;
> } else {
> - chip->base.eccreq.step_size = 1024;
> + requirements->step_size = 1024;
> switch (extid) {
> case 5:
> - chip->base.eccreq.strength = 24;
> + requirements->strength = 24;
> break;
> case 6:
> - chip->base.eccreq.strength = 40;
> + requirements->strength = 40;
> break;
> case 7:
> - chip->base.eccreq.strength = 60;
> + requirements->strength = 60;
> break;
> default:
> WARN(1, "Could not decode ECC info");
> - chip->base.eccreq.step_size = 0;
> + requirements->step_size = 0;
> }
> }
> } else {
> @@ -97,8 +98,8 @@ static void samsung_nand_decode_id(struct nand_chip *chip)
> switch (chip->id.data[1]) {
> /* K9F4G08U0D-S[I|C]B0(T00) */
> case 0xDC:
> - chip->base.eccreq.step_size = 512;
> - chip->base.eccreq.strength = 1;
> + requirements->step_size = 512;
> + requirements->strength = 1;
> break;
>
> /* K9F1G08U0E 21nm chips do not support subpage write */
> diff --git a/drivers/mtd/nand/raw/nand_toshiba.c b/drivers/mtd/nand/raw/nand_toshiba.c
> index 436ed90a90ad..1180068007a9 100644
> --- a/drivers/mtd/nand/raw/nand_toshiba.c
> +++ b/drivers/mtd/nand/raw/nand_toshiba.c
> @@ -145,6 +145,7 @@ static void toshiba_nand_benand_init(struct nand_chip *chip)
>
> static void toshiba_nand_decode_id(struct nand_chip *chip)
> {
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct mtd_info *mtd = nand_to_mtd(chip);
> struct nand_memory_organization *memorg;
>
> @@ -175,20 +176,20 @@ static void toshiba_nand_decode_id(struct nand_chip *chip)
> * - 24nm: 8 bit ECC for each 512Byte is required.
> */
> if (chip->id.len >= 6 && nand_is_slc(chip)) {
> - chip->base.eccreq.step_size = 512;
> + requirements->step_size = 512;
> switch (chip->id.data[5] & 0x7) {
> case 0x4:
> - chip->base.eccreq.strength = 1;
> + requirements->strength = 1;
> break;
> case 0x5:
> - chip->base.eccreq.strength = 4;
> + requirements->strength = 4;
> break;
> case 0x6:
> - chip->base.eccreq.strength = 8;
> + requirements->strength = 8;
> break;
> default:
> WARN(1, "Could not get ECC info");
> - chip->base.eccreq.step_size = 0;
> + requirements->step_size = 0;
> break;
> }
> }
> diff --git a/drivers/mtd/nand/raw/sunxi_nand.c b/drivers/mtd/nand/raw/sunxi_nand.c
> index c6dd2e6d9ef8..a5eefdf89660 100644
> --- a/drivers/mtd/nand/raw/sunxi_nand.c
> +++ b/drivers/mtd/nand/raw/sunxi_nand.c
> @@ -1732,6 +1732,7 @@ static void sunxi_nand_ecc_cleanup(struct nand_ecc_ctrl *ecc)
>
> static int sunxi_nand_attach_chip(struct nand_chip *nand)
> {
> + struct nand_ecc_props *requirements = &nand->base.ecc.requirements;
> struct nand_ecc_ctrl *ecc = &nand->ecc;
> struct device_node *np = nand_get_flash_node(nand);
> int ret;
> @@ -1745,8 +1746,8 @@ static int sunxi_nand_attach_chip(struct nand_chip *nand)
> nand->options |= NAND_SUBPAGE_READ;
>
> if (!ecc->size) {
> - ecc->size = nand->base.eccreq.step_size;
> - ecc->strength = nand->base.eccreq.strength;
> + ecc->size = requirements->step_size;
> + ecc->strength = requirements->strength;
> }
>
> if (!ecc->size || !ecc->strength)
> diff --git a/drivers/mtd/nand/raw/tegra_nand.c b/drivers/mtd/nand/raw/tegra_nand.c
> index 2325b06ccc9a..8264bb991d03 100644
> --- a/drivers/mtd/nand/raw/tegra_nand.c
> +++ b/drivers/mtd/nand/raw/tegra_nand.c
> @@ -855,7 +855,7 @@ static int tegra_nand_get_strength(struct nand_chip *chip, const int *strength,
> } else {
> strength_sel = strength[i];
>
> - if (strength_sel < chip->base.eccreq.strength)
> + if (strength_sel < chip->base.ecc.requirements.strength)
> continue;
> }
>
> @@ -908,6 +908,7 @@ static int tegra_nand_select_strength(struct nand_chip *chip, int oobsize)
> static int tegra_nand_attach_chip(struct nand_chip *chip)
> {
> struct tegra_nand_controller *ctrl = to_tegra_ctrl(chip->controller);
> + struct nand_ecc_props *requirements = &chip->base.ecc.requirements;
> struct tegra_nand_chip *nand = to_tegra_chip(chip);
> struct mtd_info *mtd = nand_to_mtd(chip);
> int bits_per_step;
> @@ -919,9 +920,9 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
> chip->ecc.engine_type = NAND_ECC_ENGINE_TYPE_ON_HOST;
> chip->ecc.size = 512;
> chip->ecc.steps = mtd->writesize / chip->ecc.size;
> - if (chip->base.eccreq.step_size != 512) {
> + if (requirements->step_size != 512) {
> dev_err(ctrl->dev, "Unsupported step size %d\n",
> - chip->base.eccreq.step_size);
> + requirements->step_size);
> return -EINVAL;
> }
>
> @@ -952,7 +953,7 @@ static int tegra_nand_attach_chip(struct nand_chip *chip)
> if (ret < 0) {
> dev_err(ctrl->dev,
> "No valid strength found, minimum %d\n",
> - chip->base.eccreq.strength);
> + requirements->strength);
> return ret;
> }
>
> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
> index 6f6ec8aa143d..edc8ec2923d5 100644
> --- a/drivers/mtd/nand/spi/core.c
> +++ b/drivers/mtd/nand/spi/core.c
> @@ -419,7 +419,7 @@ static int spinand_check_ecc_status(struct spinand_device *spinand, u8 status)
> * fixed, so let's return the maximum possible value so that
> * wear-leveling layers move the data immediately.
> */
> - return nand->eccreq.strength;
> + return nand->ecc.ctx.conf.strength;
>
> case STATUS_ECC_UNCOR_ERROR:
> return -EBADMSG;
> @@ -903,7 +903,7 @@ int spinand_match_and_init(struct spinand_device *spinand,
> continue;
>
> nand->memorg = table[i].memorg;
> - nand->eccreq = table[i].eccreq;
> + nand->ecc.requirements = table[i].eccreq;
> spinand->eccinfo = table[i].eccinfo;
> spinand->flags = table[i].flags;
> spinand->id.len = 1 + table[i].devid.len;
> @@ -1091,8 +1091,8 @@ static int spinand_init(struct spinand_device *spinand)
> mtd->oobavail = ret;
>
> /* Propagate ECC information to mtd_info */
> - mtd->ecc_strength = nand->eccreq.strength;
> - mtd->ecc_step_size = nand->eccreq.step_size;
> + mtd->ecc_strength = nand->ecc.ctx.conf.strength;
> + mtd->ecc_step_size = nand->ecc.ctx.conf.step_size;
>
> return 0;
>
> diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c
> index 0f900f3aa21a..9db55828a995 100644
> --- a/drivers/mtd/nand/spi/macronix.c
> +++ b/drivers/mtd/nand/spi/macronix.c
> @@ -84,10 +84,10 @@ static int mx35lf1ge4ab_ecc_get_status(struct spinand_device *spinand,
> * data around if it's not necessary.
> */
> if (mx35lf1ge4ab_get_eccsr(spinand, &eccsr))
> - return nand->eccreq.strength;
> + return nand->ecc.ctx.conf.strength;
>
> - if (WARN_ON(eccsr > nand->eccreq.strength || !eccsr))
> - return nand->eccreq.strength;
> + if (WARN_ON(eccsr > nand->ecc.ctx.conf.strength || !eccsr))
> + return nand->ecc.ctx.conf.strength;
>
> return eccsr;
>
> diff --git a/drivers/mtd/nand/spi/toshiba.c b/drivers/mtd/nand/spi/toshiba.c
> index bc801d83343e..c3e5b1a85e3e 100644
> --- a/drivers/mtd/nand/spi/toshiba.c
> +++ b/drivers/mtd/nand/spi/toshiba.c
> @@ -90,12 +90,12 @@ static int tx58cxgxsxraix_ecc_get_status(struct spinand_device *spinand,
> * data around if it's not necessary.
> */
> if (spi_mem_exec_op(spinand->spimem, &op))
> - return nand->eccreq.strength;
> + return nand->ecc.ctx.conf.strength;
>
> mbf >>= 4;
>
> - if (WARN_ON(mbf > nand->eccreq.strength || !mbf))
> - return nand->eccreq.strength;
> + if (WARN_ON(mbf > nand->ecc.ctx.conf.strength || !mbf))
> + return nand->ecc.ctx.conf.strength;
>
> return mbf;
>
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2f838394b5f7..975ddf26ac8c 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -290,7 +290,7 @@ struct nand_ecc {
> * struct nand_device - NAND device
> * @mtd: MTD instance attached to the NAND device
> * @memorg: memory layout
> - * @eccreq: ECC requirements
> + * @ecc: NAND ECC object attached to the NAND device
> * @rowconv: position to row address converter
> * @bbt: bad block table info
> * @ops: NAND operations attached to the NAND device
> @@ -298,8 +298,8 @@ struct nand_ecc {
> * Generic NAND object. Specialized NAND layers (raw NAND, SPI NAND, OneNAND)
> * should declare their own NAND object embedding a nand_device struct (that's
> * how inheritance is done).
> - * struct_nand_device->memorg and struct_nand_device->eccreq should be filled
> - * at device detection time to reflect the NAND device
> + * struct_nand_device->memorg and struct_nand_device->ecc.ctx.conf should
> + * be filled at device detection time to reflect the NAND device
> * capabilities/requirements. Once this is done nanddev_init() can be called.
> * It will take care of converting NAND information into MTD ones, which means
> * the specialized NAND layers should never manually tweak
> @@ -308,7 +308,7 @@ struct nand_ecc {
> struct nand_device {
> struct mtd_info mtd;
> struct nand_memory_organization memorg;
> - struct nand_ecc_props eccreq;
> + struct nand_ecc ecc;
> struct nand_row_converter rowconv;
> struct nand_bbt bbt;
> const struct nand_ops *ops;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] PCI: aardvark: Don't touch PCIe registers if no card connected
From: Pali Rohár @ 2020-05-29 8:30 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tomasz Maciej Nowak, Lorenzo Pieralisi, linux-pci, Xogium,
linux-kernel, Marek Behún, Remi Pommarel, Thomas Petazzoni,
Bjorn Helgaas, linux-arm-kernel, Andrew Murray
In-Reply-To: <20200528164938.GA325239@bjorn-Precision-5520>
On Thursday 28 May 2020 11:49:38 Bjorn Helgaas wrote:
> On Thu, May 28, 2020 at 06:38:09PM +0200, Pali Rohár wrote:
> > On Thursday 28 May 2020 11:26:04 Bjorn Helgaas wrote:
> > > On Thu, May 28, 2020 at 04:31:41PM +0200, Pali Rohár wrote:
> > > > When there is no PCIe card connected and advk_pcie_rd_conf() or
> > > > advk_pcie_wr_conf() is called for PCI bus which doesn't belong to emulated
> > > > root bridge, the aardvark driver throws the following error message:
> > > >
> > > > advk-pcie d0070000.pcie: config read/write timed out
> > > >
> > > > Obviously accessing PCIe registers of disconnected card is not possible.
> > > >
> > > > Extend check in advk_pcie_valid_device() function for validating
> > > > availability of PCIe bus. If PCIe link is down, then the device is marked
> > > > as Not Found and the driver does not try to access these registers.
> > > >
> > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > ---
> > > > drivers/pci/controller/pci-aardvark.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > > > index 90ff291c24f0..53a4cfd7d377 100644
> > > > --- a/drivers/pci/controller/pci-aardvark.c
> > > > +++ b/drivers/pci/controller/pci-aardvark.c
> > > > @@ -644,6 +644,9 @@ static bool advk_pcie_valid_device(struct advk_pcie *pcie, struct pci_bus *bus,
> > > > if ((bus->number == pcie->root_bus_nr) && PCI_SLOT(devfn) != 0)
> > > > return false;
> > > >
> > > > + if (bus->number != pcie->root_bus_nr && !advk_pcie_link_up(pcie))
> > > > + return false;
> > >
> > > I don't think this is the right fix. This makes it racy because the
> > > link may go down after we call advk_pcie_valid_device() but before we
> > > perform the config read.
> >
> > Yes, it is racy, but I do not think it cause problems. Trying to read
> > PCIe registers when device is not connected cause just those timeouts,
> > printing error message and increased delay in advk_pcie_wait_pio() due
> > to polling loop. This patch reduce unnecessary access to PCIe registers
> > when advk_pcie_wait_pio() polling just fail.
> >
> > I think it is a good idea to not call blocking advk_pcie_wait_pio() when
> > it is not needed. We could have faster enumeration of PCIe buses when
> > card is not connected.
>
> Maybe advk_pcie_check_pio_status() and advk_pcie_wait_pio() could be
> combined so we could get the correct error status as soon as it's
> available, without waiting for a timeout?
Any idea how to achieve it?
First call is polling function advk_pcie_wait_pio() and second call is
advk_pcie_check_pio_status() which just reads status register and prints
error message to dmesg.
So for me it looks like that combining these two functions into one does
not change anything. We always need to call polling code prior to
checking status register. And therefore need to wait for timeout. Unless
something like in this proposed patch is not used (to skip whole
register access if it would fail).
> In any event, the "return PCIBIOS_SET_FAILED" needs to be fixed. Most
> callers of config read do not check for failure, but most of the ones
> that do, check for "val == ~0". Only a few check for a status of
> other than PCIBIOS_SUCCESSFUL.
>
> > > I have no objection to removing the "config read/write timed out"
> > > message. The "return PCIBIOS_SET_FAILED" in the read case probably
> > > should be augmented by setting "*val = 0xffffffff".
Now I see, "*val = 0xffffffff" should be really set when function
advk_pcie_rd_conf() fails.
> > > > return true;
> > > > }
> > > >
> > > > --
> > > > 2.20.1
> > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 0/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
From: Dragan Cvetic @ 2020-05-29 8:29 UTC (permalink / raw)
To: John Hubbard, LKML
Cc: Arnd Bergmann, Greg Kroah-Hartman, Michal Simek, Souptick Joarder,
Derek Kiernan, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200527012628.1100649-1-jhubbard@nvidia.com>
Hi John,
Thank you for the suggestion, please find my comment below:
> -----Original Message-----
> From: John Hubbard <jhubbard@nvidia.com>
> Sent: Wednesday 27 May 2020 02:26
> To: LKML <linux-kernel@vger.kernel.org>
> Cc: Souptick Joarder <jrdr.linux@gmail.com>; John Hubbard <jhubbard@nvidia.com>; Derek Kiernan <dkiernan@xilinx.com>; Dragan
> Cvetic <draganc@xilinx.com>; Arnd Bergmann <arnd@arndb.de>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>; Michal Simek
> <michals@xilinx.com>; linux-arm-kernel@lists.infradead.org
> Subject: [PATCH 0/3] misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
>
> Hi,
>
> There are also a couple of tiny cleanup patches, just to fix up a few
> minor issues that I spotted while converting from get_user_pages_fast()
> to pin_user_pages_fast().
>
> Note that I have only compile-tested these patches, although that does
> also include cross-compiling for a few other arches. Any run-time
> testing would be greatly appreciated!
>
> Cc: Derek Kiernan <derek.kiernan@xilinx.com>
> Cc: Dragan Cvetic <dragan.cvetic@xilinx.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: linux-arm-kernel@lists.infradead.org
>
> John Hubbard (3):
> misc: xilinx-sdfec: improve get_user_pages_fast() error handling
> misc: xilinx-sdfec: cleanup return value in xsdfec_table_write()
> misc: xilinx-sdfec: convert get_user_pages() --> pin_user_pages()
Reviewed-by:
Technically there is no problem in this patch, but as you said this should be tested.
Currently due to Covid-19 I'm not able to access the HW and I cannot validate this suggestion.
>
> drivers/misc/xilinx_sdfec.c | 30 +++++++++++++++++-------------
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
>
> base-commit: 9cb1fd0efd195590b828b9b865421ad345a4a145
> --
> 2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] net: ethernet: mtk-star-emac: remove unused variable
From: Bartosz Golaszewski @ 2020-05-29 8:27 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger
Cc: kbuild test robot, Stephane Le Provost, Bartosz Golaszewski,
netdev, Linux Kernel Mailing List, Fabien Parent,
moderated list:ARM/Mediatek SoC..., Andrew Perepech, Pedro Tsai,
Linux ARM
In-Reply-To: <20200529082648.19677-1-brgl@bgdev.pl>
pt., 29 maj 2020 o 10:26 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The desc pointer is set but not used. Remove it.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/net/ethernet/mediatek/mtk_star_emac.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> index 8596ca0e60eb..7df35872c107 100644
> --- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
> +++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
> @@ -746,15 +746,12 @@ mtk_star_ring_free_skbs(struct mtk_star_priv *priv, struct mtk_star_ring *ring,
> struct mtk_star_ring_desc_data *))
> {
> struct mtk_star_ring_desc_data desc_data;
> - struct mtk_star_ring_desc *desc;
> int i;
>
> for (i = 0; i < MTK_STAR_RING_NUM_DESCS; i++) {
> if (!ring->dma_addrs[i])
> continue;
>
> - desc = &ring->descs[i];
> -
> desc_data.dma_addr = ring->dma_addrs[i];
> desc_data.skb = ring->skbs[i];
>
> --
> 2.26.1
>
Cr*p I forgot to tag it for net-next. David let me know if you want me
to resend it.
Bartosz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] net: ethernet: mtk-star-emac: remove unused variable
From: Bartosz Golaszewski @ 2020-05-29 8:26 UTC (permalink / raw)
To: John Crispin, Sean Wang, Mark Lee, David S . Miller,
Jakub Kicinski, Matthias Brugger
Cc: kbuild test robot, Stephane Le Provost, Bartosz Golaszewski,
netdev, linux-kernel, Fabien Parent, linux-mediatek,
Andrew Perepech, Pedro Tsai, linux-arm-kernel
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The desc pointer is set but not used. Remove it.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
drivers/net/ethernet/mediatek/mtk_star_emac.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_star_emac.c b/drivers/net/ethernet/mediatek/mtk_star_emac.c
index 8596ca0e60eb..7df35872c107 100644
--- a/drivers/net/ethernet/mediatek/mtk_star_emac.c
+++ b/drivers/net/ethernet/mediatek/mtk_star_emac.c
@@ -746,15 +746,12 @@ mtk_star_ring_free_skbs(struct mtk_star_priv *priv, struct mtk_star_ring *ring,
struct mtk_star_ring_desc_data *))
{
struct mtk_star_ring_desc_data desc_data;
- struct mtk_star_ring_desc *desc;
int i;
for (i = 0; i < MTK_STAR_RING_NUM_DESCS; i++) {
if (!ring->dma_addrs[i])
continue;
- desc = &ring->descs[i];
-
desc_data.dma_addr = ring->dma_addrs[i];
desc_data.skb = ring->skbs[i];
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Ard Biesheuvel @ 2020-05-29 8:20 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric Biggers, Stephan Mueller, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <20200529080508.GA2880@gondor.apana.org.au>
On Fri, 29 May 2020 at 10:05, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, May 28, 2020 at 10:33:25AM +0200, Ard Biesheuvel wrote:
> >
> > The reason we return output IVs for CBC is because our generic
> > implementation of CTS can wrap any CBC implementation, and relies on
> > this output IV rather than grabbing it from the ciphertext directly
> > (which may be tricky and is best left up to the CBC code)
>
> No that's not the main reason. The main user of chaining is
> algif_skcipher.
>
But many implementation do not return an output IV at all. The only
mode that requires it (for the selftests to pass) is CBC.
> > So if you are saying that we should never split up algif_skcipher
> > requests into multiple calls into the underlying skcipher, then I
> > agree with you. Even if the generic CTS seems to work more or less as
> > expected by, e.g., the NIST validation tool, this is unspecified
> > behavior, and definitely broken in various other places.
>
> I was merely suggesting that requests to CTS/XTS shouldn't be
> split up. Doing it for others would be a serious regression.
>
Given that in these cases, doing so will give incorrect results even
if the input size is a whole multiple of the block size, I agree that
adding this restriction will not break anything that is working
consistently at the moment.
But could you elaborate on the serious regression for other cases? Do
you have anything particular in mind?
> However, having looked at this it would seem that the effort
> in marking CTS/XTS is not that different to just adding support
> to hold the last two blocks of data so that CTS/XTS can support
> chaining.
>
For XTS, we would have to carry some metadata around that tells you
whether the initial encryption of the IV has occurred or not. In the
CTS case, you need two swap the last two blocks of ciphertext at the
very end.
So does that mean some kind of init/update/final model for skcipher? I
can see how that could address these issues (init() would encrypt the
IV for XTS, and final() would do the final block handling for CTS).
Just holding two blocks of data does not seem sufficient to me to
handle these issues.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: dts: Xilinx DT changes for v5.8
From: Michal Simek @ 2020-05-29 8:20 UTC (permalink / raw)
To: arm-soc, SoC Team; +Cc: git, linux-arm
[-- Attachment #1.1.1: Type: text/plain, Size: 1450 bytes --]
Hi,
please pull these two small fixed to your tree. The branch is based on
v5.6-rc1 but I didn't wanted to rebase it on v5.7-rc1 because then dates
will be changed.
Anyway tried to merge it with Linus's and linux-next trees and I can't
see any collisions that's why it shouldn't be a problem for you too.
Thanks,
Michal
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
https://github.com/Xilinx/linux-xlnx.git tags/zynqmp-dt-for-v5.8
for you to fetch changes up to 818227321d331c583c4563a8275eb187b98475df:
arm64: zynqmp: Fix GIC compatible property (2020-04-15 10:39:21 +0200)
----------------------------------------------------------------
arm64: dt: ZynqMP DT fixes for v5.8
- Add AES mode and fix GIC node
----------------------------------------------------------------
Kalyani Akula (1):
arm64: zynqmp: Add Xilinx AES node
Michal Simek (1):
arm64: zynqmp: Fix GIC compatible property
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE
From: Michal Simek @ 2020-05-29 8:09 UTC (permalink / raw)
To: Arnd Bergmann, Rob Herring
Cc: Anders Roxell, Stephen Boyd, Michael Turquette, Michal Simek,
linux-clk, SoC Team, Linus Walleij, Linux ARM
In-Reply-To: <CAK8P3a2S-8fvyiKTk+o876r1XMV6C=HipiRutSWSe0P2rdL4Xg@mail.gmail.com>
On 29. 05. 20 9:38, Arnd Bergmann wrote:
> On Thu, May 28, 2020 at 11:29 PM Rob Herring <robh@kernel.org> wrote:
>> On Thu, May 28, 2020 at 5:57 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> On Wed, May 27, 2020 at 8:13 PM Rob Herring <robh@kernel.org> wrote:
>>>> diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
>>>> index a0ed412e8396..8c1b0e8e8d32 100644
>>>> --- a/drivers/clk/versatile/Kconfig
>>>> +++ b/drivers/clk/versatile/Kconfig
>>>> @@ -1,11 +1,8 @@
>>>> # SPDX-License-Identifier: GPL-2.0-only
>>>>
>>>> -menuconfig COMMON_CLK_VERSATILE
>>>> - bool "Clock driver for ARM Reference designs" if COMPILE_TEST
>>>> - default y if ARCH_INTEGRATOR || ARCH_REALVIEW || \
>>>> - ARCH_VERSATILE || ARCH_VEXPRESS
>>>> -
>>>> -if COMMON_CLK_VERSATILE
>>>> +menu "Clock driver for ARM Reference designs"
>>>> + depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
>>>> + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
>>>>
>>>
>>> I've applied this version now but added ARCH_ZYNQ as an additional
>>> dependency to work around one of the warnings we got earlier.
>>
>> That's just spreading a copy-n-paste error. Why don't you apply the
>> Zynq patch I referenced if Michal never did?
>
> Sorry I completely missed the reference from your previous email.
> I've applied that patch on top now, reverting the change I did in the
> process.
>
> I had noticed that the Zynq Kconfig seemed rather odd, by my interpretation
> was that it had been added intentionally in order to use an existing clk
> controller driver for configurable logic on Zynq that was not part of the
> main DT file. As Michal already confirmed that it was just a mistake, I
> agree it should be removed.
Sorry I didn't sent PR yet but I have your ICST patch in next branch.
Arnd has applied it already that's why won't be sending PR just for this.
Thanks,
Michal
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v10 10/10] arm64: dts: Add node for ufs exynos7
From: Krzysztof Kozlowski @ 2020-05-29 8:05 UTC (permalink / raw)
To: Alim Akhtar
Cc: robh, linux-samsung-soc, linux-scsi, martin.petersen, devicetree,
linux-kernel, kwmad.kim, avri.altman, cang, stanley.chu,
linux-arm-kernel
In-Reply-To: <20200528011658.71590-11-alim.akhtar@samsung.com>
On Thu, May 28, 2020 at 06:46:58AM +0530, Alim Akhtar wrote:
> Adding dt node foe UFS and UFS-PHY for exynos7 SoC.
>
> Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
> Tested-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
> ---
> .../boot/dts/exynos/exynos7-espresso.dts | 4 ++
> arch/arm64/boot/dts/exynos/exynos7.dtsi | 43 ++++++++++++++++++-
Thanks, applied to next/dt-late. It might miss this merge
window and in such case I will keep it for v5.9 cycle.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Will Deacon @ 2020-05-29 8:05 UTC (permalink / raw)
To: John Donnelly
Cc: horms, devicetree, arnd, Baoquan He, linux-doc, Chen Zhou,
catalin.marinas, kexec, linux-kernel, robh+dt, mingo, james.morse,
guohanjun, tglx, pkushwaha, dyoung, linux-arm-kernel
In-Reply-To: <897ea1b9-a68c-8544-6532-a21be135ce01@oracle.com>
[+James Morse]
On Thu, May 28, 2020 at 05:20:34PM -0500, John Donnelly wrote:
> On 5/25/20 8:42 PM, Baoquan He wrote:
> > On 05/21/20 at 05:38pm, Chen Zhou wrote:
> > > This patch series enable reserving crashkernel above 4G in arm64.
[...]
> > > Chen Zhou (5):
> > > x86: kdump: move reserve_crashkernel_low() into crash_core.c
> > > arm64: kdump: reserve crashkenel above 4G for crash dump kernel
> > > arm64: kdump: add memory for devices by DT property, low-memory-range
> > > kdump: update Documentation about crashkernel on arm64
> > > dt-bindings: chosen: Document linux,low-memory-range for arm64 kdump
> > >
> > > Documentation/admin-guide/kdump/kdump.rst | 13 ++-
> > > .../admin-guide/kernel-parameters.txt | 12 ++-
> > > Documentation/devicetree/bindings/chosen.txt | 25 ++++++
> > > arch/arm64/kernel/setup.c | 8 +-
> > > arch/arm64/mm/init.c | 61 ++++++++++++-
> > > arch/x86/kernel/setup.c | 66 ++------------
> > > include/linux/crash_core.h | 3 +
> > > include/linux/kexec.h | 2 -
> > > kernel/crash_core.c | 85 +++++++++++++++++++
> > > kernel/kexec_core.c | 17 ----
> > > 10 files changed, 208 insertions(+), 84 deletions(-)
> > >
> This proposal to improve vmcore creation on Arm has been going on for
> almost a year now.
>
> Who is the final maintainer that needs to approve and except these ?
>
> What are the lingering issues that are remaining so we get these accepted
> into a upstream commit ?
The arm64 bits need an Ack from James Morse, but he's not on CC despite
offering feedback on earlier versions.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC/RFT PATCH 0/2] crypto: add CTS output IVs for arm64 and testmgr
From: Herbert Xu @ 2020-05-29 8:05 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, Stephan Mueller, Linux Crypto Mailing List,
Linux ARM
In-Reply-To: <CAMj1kXGkvLP1YnDimdLOM6xMXSQKXPKCEBGRCGBRsWKAQR5Stg@mail.gmail.com>
On Thu, May 28, 2020 at 10:33:25AM +0200, Ard Biesheuvel wrote:
>
> The reason we return output IVs for CBC is because our generic
> implementation of CTS can wrap any CBC implementation, and relies on
> this output IV rather than grabbing it from the ciphertext directly
> (which may be tricky and is best left up to the CBC code)
No that's not the main reason. The main user of chaining is
algif_skcipher.
> So if you are saying that we should never split up algif_skcipher
> requests into multiple calls into the underlying skcipher, then I
> agree with you. Even if the generic CTS seems to work more or less as
> expected by, e.g., the NIST validation tool, this is unspecified
> behavior, and definitely broken in various other places.
I was merely suggesting that requests to CTS/XTS shouldn't be
split up. Doing it for others would be a serious regression.
However, having looked at this it would seem that the effort
in marking CTS/XTS is not that different to just adding support
to hold the last two blocks of data so that CTS/XTS can support
chaining.
I'll work on this.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE
From: Arnd Bergmann @ 2020-05-29 7:38 UTC (permalink / raw)
To: Rob Herring
Cc: Anders Roxell, Stephen Boyd, Michael Turquette, Michal Simek,
linux-clk, SoC Team, Linus Walleij, Linux ARM
In-Reply-To: <CAL_JsqJ83UJ0Roy_NJBLXuvhPG2zBDod8ZgSGrEtpKSnYPtowQ@mail.gmail.com>
On Thu, May 28, 2020 at 11:29 PM Rob Herring <robh@kernel.org> wrote:
> On Thu, May 28, 2020 at 5:57 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Wed, May 27, 2020 at 8:13 PM Rob Herring <robh@kernel.org> wrote:
> > > diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
> > > index a0ed412e8396..8c1b0e8e8d32 100644
> > > --- a/drivers/clk/versatile/Kconfig
> > > +++ b/drivers/clk/versatile/Kconfig
> > > @@ -1,11 +1,8 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > >
> > > -menuconfig COMMON_CLK_VERSATILE
> > > - bool "Clock driver for ARM Reference designs" if COMPILE_TEST
> > > - default y if ARCH_INTEGRATOR || ARCH_REALVIEW || \
> > > - ARCH_VERSATILE || ARCH_VEXPRESS
> > > -
> > > -if COMMON_CLK_VERSATILE
> > > +menu "Clock driver for ARM Reference designs"
> > > + depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
> > > + ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
> > >
> >
> > I've applied this version now but added ARCH_ZYNQ as an additional
> > dependency to work around one of the warnings we got earlier.
>
> That's just spreading a copy-n-paste error. Why don't you apply the
> Zynq patch I referenced if Michal never did?
Sorry I completely missed the reference from your previous email.
I've applied that patch on top now, reverting the change I did in the
process.
I had noticed that the Zynq Kconfig seemed rather odd, by my interpretation
was that it had been added intentionally in order to use an existing clk
controller driver for configurable logic on Zynq that was not part of the
main DT file. As Michal already confirmed that it was just a mistake, I
agree it should be removed.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dt-bindings: clock: Convert i.MX8QXP LPCG to json-schema
From: Anson Huang @ 2020-05-29 6:21 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, shawnguo, s.hauer, kernel, festevam,
aisheng.dong, linux-clk, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Convert the i.MX8QXP LPCG binding to DT schema format using json-schema.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/clock/imx8qxp-lpcg.txt | 51 ---------------
.../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 72 ++++++++++++++++++++++
2 files changed, 72 insertions(+), 51 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
deleted file mode 100644
index 965cfa4..0000000
--- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.txt
+++ /dev/null
@@ -1,51 +0,0 @@
-* NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
-
-The Low-Power Clock Gate (LPCG) modules contain a local programming
-model to control the clock gates for the peripherals. An LPCG module
-is used to locally gate the clocks for the associated peripheral.
-
-Note:
-This level of clock gating is provided after the clocks are generated
-by the SCU resources and clock controls. Thus even if the clock is
-enabled by these control bits, it might still not be running based
-on the base resource.
-
-Required properties:
-- compatible: Should be one of:
- "fsl,imx8qxp-lpcg-adma",
- "fsl,imx8qxp-lpcg-conn",
- "fsl,imx8qxp-lpcg-dc",
- "fsl,imx8qxp-lpcg-dsp",
- "fsl,imx8qxp-lpcg-gpu",
- "fsl,imx8qxp-lpcg-hsio",
- "fsl,imx8qxp-lpcg-img",
- "fsl,imx8qxp-lpcg-lsio",
- "fsl,imx8qxp-lpcg-vpu"
-- reg: Address and length of the register set
-- #clock-cells: Should be <1>
-
-The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell.
-See the full list of clock IDs from:
-include/dt-bindings/clock/imx8qxp-clock.h
-
-Examples:
-
-#include <dt-bindings/clock/imx8qxp-clock.h>
-
-conn_lpcg: clock-controller@5b200000 {
- compatible = "fsl,imx8qxp-lpcg-conn";
- reg = <0x5b200000 0xb0000>;
- #clock-cells = <1>;
-};
-
-usdhc1: mmc@5b010000 {
- compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
- interrupt-parent = <&gic>;
- interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0x5b010000 0x10000>;
- clocks = <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_IPG_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_PER_CLK>,
- <&conn_lpcg IMX8QXP_CONN_LPCG_SDHC0_HCLK>;
- clock-names = "ipg", "per", "ahb";
-};
diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
new file mode 100644
index 0000000..d5b6825
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/imx8qxp-lpcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP i.MX8QXP LPCG (Low-Power Clock Gating) Clock bindings
+
+maintainers:
+ - Aisheng Dong <aisheng.dong@nxp.com>
+
+description: |
+ The Low-Power Clock Gate (LPCG) modules contain a local programming
+ model to control the clock gates for the peripherals. An LPCG module
+ is used to locally gate the clocks for the associated peripheral.
+
+ This level of clock gating is provided after the clocks are generated
+ by the SCU resources and clock controls. Thus even if the clock is
+ enabled by these control bits, it might still not be running based
+ on the base resource.
+
+ The clock consumer should specify the desired clock by having the clock
+ ID in its "clocks" phandle cell. See the full list of clock IDs from:
+ include/dt-bindings/clock/imx8-clock.h
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx8qxp-lpcg-adma
+ - fsl,imx8qxp-lpcg-conn
+ - fsl,imx8qxp-lpcg-dc
+ - fsl,imx8qxp-lpcg-dsp
+ - fsl,imx8qxp-lpcg-gpu
+ - fsl,imx8qxp-lpcg-hsio
+ - fsl,imx8qxp-lpcg-img
+ - fsl,imx8qxp-lpcg-lsio
+ - fsl,imx8qxp-lpcg-vpu
+
+ reg:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#clock-cells'
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx8-clock.h>
+ #include <dt-bindings/firmware/imx/rsrc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ clock-controller@5b200000 {
+ compatible = "fsl,imx8qxp-lpcg-conn";
+ reg = <0x5b200000 0xb0000>;
+ #clock-cells = <1>;
+ };
+
+ mmc@5b010000 {
+ compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc";
+ interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x5b010000 0x10000>;
+ clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>,
+ <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>;
+ clock-names = "ipg", "per", "ahb";
+ power-domains = <&pd IMX_SC_R_SDHC_0>;
+ status = "disabled";
+ };
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Viresh Kumar @ 2020-05-29 6:27 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Arnd Bergmann, Devicetree List,
Linux Kernel Mailing List, Bjorn Andersson, Sudeep Holla,
Frank Rowand, linux-arm-kernel
In-Reply-To: <CABb+yY3KKpDHTsTBescW_rXmqmLzJh-Ogaotk2n=nYRkfHy2cg@mail.gmail.com>
On 29-05-20, 00:20, Jassi Brar wrote:
> The fact that all these bits are backed by one physical signal makes
I believe that within the IP itself, there must be 32 signals, just
that only one comes out of it all OR'd together. Maybe that can be
verified by writing 0x01 to it multiple times and it should generate
the interrupt only once on the first instance. i.e. writing 1 to any
big again won't raise the interrupt.
> the firmware implement its own mux-demux'ing scheme.
Similar to how the interrupt controllers do it in the kernel, they
receive a single interrupt and then go check its registers/bits to see
which peripheral raised it.
> So the choice was
> between demux and single signal at a time.
Well, the demux is on the firmware side and the kernel may not need to
worry about that, let the platform do it ?
> Had there been one signal
> per bit, the implementation would have definitely been 'efficient'.
I will say 'More efficient', it will still be 'efficient' if we
implement doorbell.
> And the first platform the driver was developed on, required message
> passing over the registers.
I think it was correctly done at that point of time. No doubt about
that.
> So now my approach is to make do with what
> we have...unless it shows in numbers.
ARM's office is closed (lock-down) and he doesn't have remote access
to the board and so was unable to do it until now.
Numbers or no numbers, I don't think there is a question here about
what is the most efficient way of doing it. Doing it in parallel (when
the hardware allows) is surely going to be more efficient. Sending a
signal, getting it processed by the firmware, doing something with it
and then sending an Ack and that being received by kernel will take
time. Why make a queue on the kernel side when we don't have to. :)
> Anyways, if it comes to that, I'd rather a separate "doorbell' driver
> than a driver working in two s/w modes.
I think that would be fine with everyone, if you are fine with that
now (based on plain logic and no numbers), maybe we can get that done
now?
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox