[PATCH 0/2 v3] mmc: dw_mmc: Fix DTO/STO timeout overflow calculation
For some 32-bit architectures calculation of DTO and STO timeout can be incorrect due to multiply overflow. Lets prevent this by casting multiply and result to u64. Suggested by Jisheng Zhang. Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable because overflow happens on multiply and DIV_ROUND_UP_ULL helps with sum overflow. --- Changes since v2: -add fix for cto_ms Evgeniy Didin (2): mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems drivers/mmc/host/dw_mmc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) -- 2.11.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems
In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have
been made
changes which cause multiply overflow for 32-bit systems.
The broken timeout calculations caused false interrupt latency warnings
and stacktrace splat (such as below) when accessing the SD Card.
| Running : 4M-check-reassembly-tcp-cmykw2-rotatew2.out -v0 -w1
| - Info: Finished target initialization.
| mmcblk0: error -110 transferring data, sector 320544, nr 2048, cmd response
| 0x900, card status 0x0
| mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 40Hz, actual
| 396825HZ div = 63)
| mmc_host mmc0: Bus speed (slot 0) = 5000Hz (slot req 2500Hz, actual
| 2500HZ div = 1)
| [ cut here ]
| softirq: huh, entered softirq 6 TASKLET 6f6a9412 with preempt_count 0101,
| exited with 0100?
| WARNING: CPU: 2 PID: 0 at ../lib/scatterlist.c:652 sg_miter_next+0x28/0x20c
| Modules linked in:
| CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.15.0 #57
|
| Stack Trace:
| arc_unwind_core.constprop.1+0xd0/0xf4
| dump_stack+0x68/0x80
| warn_slowpath_null+0x4e/0xec
| sg_miter_next+0x28/0x20c
| dw_mci_read_data_pio+0x44/0x190
| dw_mmc f000a000.mmc: Unexpected interrupt latency
| dw_mci_interrupt+0x3ee/0x530
| __handle_irq_event_percpu+0x56/0x150
| handle_irq_event+0x34/0x78
| handle_level_irq+0x8e/0x120
| generic_handle_irq+0x1c/0x2c
| idu_cascade_isr+0x30/0x6c
| __handle_domain_irq+0x72/0xc8
| ret_from_exception+0x0/0x8
|---[ end trace 2a58c9af6c25fe51 ]---
Lets cast this multiply to u64 type which prevents overflow.
Tested-by: Vineet Gupta
Fixes: ARC STAR 9001306872 HSDK, sdio: board crashes when copying big files
Signed-off-by: Evgeniy Didin
CC: Alexey Brodkin
CC: Eugeniy Paltsev
CC: Douglas Anderson
CC: Ulf Hansson
CC: linux-ker...@vger.kernel.org
CC: linux-snps-arc@lists.infradead.org
Cc: # 9d9491a7da2a mmc: dw_mmc: Fix the DTO timeout
calculation
---
Nothing changed since v2.
drivers/mmc/host/dw_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 0aa39975f33b..194159219b32 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1944,7 +1944,8 @@ static void dw_mci_set_drto(struct dw_mci *host)
drto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
if (drto_div == 0)
drto_div = 1;
- drto_ms = DIV_ROUND_UP(MSEC_PER_SEC * drto_clks * drto_div,
+
+ drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
host->bus_hz);
/* add a bit spare time */
--
2.11.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
have been made changes which can cause multiply overflow for 32-bit systems.
The value of cto_ms is lower the drto_ms, but nevertheless overflow can occur.
Lets cast this multiply to u64 type which prevents overflow.
Signed-off-by: Evgeniy Didin
CC: Alexey Brodkin
CC: Eugeniy Paltsev
CC: Douglas Anderson
CC: Ulf Hansson
CC: linux-ker...@vger.kernel.org
CC: linux-snps-arc@lists.infradead.org
Cc: # 4c2357f57dd5 mmc: dw_mmc: Fix the CTO timeout
calculation
---
drivers/mmc/host/dw_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 194159219b32..775fb3ae1443 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -409,7 +409,8 @@ static inline void dw_mci_set_cto(struct dw_mci *host)
cto_div = (mci_readl(host, CLKDIV) & 0xff) * 2;
if (cto_div == 0)
cto_div = 1;
- cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div, host->bus_hz);
+
+ cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
host->bus_hz);
/* add a bit spare time */
cto_ms += 10;
--
2.11.0
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
wrote:
> In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
> have been made changes which can cause multiply overflow for 32-bit systems.
> The value of cto_ms is lower the drto_ms, but nevertheless overflow can occur.
> Lets cast this multiply to u64 type which prevents overflow.
> - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
> host->bus_hz);
> +
> + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
> host->bus_hz);
IIRC, someone commented on this or similar, i.e.
DIV_ROUND_UP_ULL() ?
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 1/2 v3] mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit systems
On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
wrote:
> In commit 9d9491a7da2a ("mmc: dw_mmc: Fix the DTO timeout calculation") have
> been made
> changes which cause multiply overflow for 32-bit systems.
> The broken timeout calculations caused false interrupt latency warnings
> and stacktrace splat (such as below) when accessing the SD Card.
> + drto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * drto_clks * drto_div,
>host->bus_hz);
Same as per patch 2.
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 2/2] dt-bindings: Document the Synopsys DW AXI DMA bindings
This patch adds documentation of device tree bindings for the Synopsys
DesignWare AXI DMA controller.
Signed-off-by: Eugeniy Paltsev
---
.../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
new file mode 100644
index 000..f237b79
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
@@ -0,0 +1,41 @@
+Synopsys DesignWare AXI DMA Controller
+
+Required properties:
+- compatible: "snps,axi-dma-1.01a"
+- reg: Address range of the DMAC registers. This should include
+ all of the per-channel registers.
+- interrupt: Should contain the DMAC interrupt number.
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device.
+- dma-channels: Number of channels supported by hardware.
+- snps,dma-masters: Number of AXI masters supported by the hardware.
+- snps,data-width: Maximum AXI data width supported by hardware.
+ (0 - 8bits, 1 - 16bits, 2 - 32bits, ..., 6 - 512bits)
+- snps,priority: Priority of channel. Array size is equal to the number of
+ dma-channels. Priority value must be programmed within [0:dma-channels-1]
+ range. (0 - minimum priority)
+- snps,block-size: Maximum block size supported by the controller channel.
+ Array size is equal to the number of dma-channels.
+
+Optional properties:
+- snps,axi-max-burst-len: Restrict master AXI burst length by value specified
+ in this property. If this property is missing the maximum AXI burst length
+ supported by DMAC is used. [1:256]
+
+Example:
+
+dmac: dma-controller@8 {
+ compatible = "snps,axi-dma-1.01a";
+ reg = <0x8 0x400>;
+ clocks = <&core_clk>, <&cfgr_clk>;
+ clock-names = "core-clk", "cfgr-clk";
+ interrupt-parent = <&intc>;
+ interrupts = <27>;
+
+ dma-channels = <4>;
+ snps,dma-masters = <2>;
+ snps,data-width = <3>;
+ snps,block-size = <4096 4096 4096 4096>;
+ snps,priority = <0 1 2 3>;
+ snps,axi-max-burst-len = <16>;
+};
--
2.9.3
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 1/2] dmaengine: Introduce DW AXI DMAC driver
This patch adds support for the DW AXI DMAC controller.
DW AXI DMAC is a part of HSDK development board from Synopsys.
In this driver implementation only DMA_MEMCPY transfers are
supported.
Signed-off-by: Eugeniy Paltsev
---
MAINTAINERS|6 +
drivers/dma/Kconfig| 10 +
drivers/dma/Makefile |1 +
drivers/dma/dw-axi-dmac/Makefile |1 +
drivers/dma/dw-axi-dmac/axi_dma_platform.c | 1016
drivers/dma/dw-axi-dmac/axi_dma_platform.h | 334 +
6 files changed, 1368 insertions(+)
create mode 100644 drivers/dma/dw-axi-dmac/Makefile
create mode 100644 drivers/dma/dw-axi-dmac/axi_dma_platform.c
create mode 100644 drivers/dma/dw-axi-dmac/axi_dma_platform.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260..b31bfdb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13336,6 +13336,12 @@ S: Maintained
F: drivers/gpio/gpio-dwapb.c
F: Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+SYNOPSYS DESIGNWARE AXI DMAC DRIVER
+M: Eugeniy Paltsev
+S: Maintained
+F: drivers/dma/dwi-axi-dmac/
+F: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt
+
SYNOPSYS DESIGNWARE DMAC DRIVER
M: Viresh Kumar
R: Andy Shevchenko
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 27df3e2..c36272a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -187,6 +187,16 @@ config DMA_SUN6I
help
Support for the DMA engine first found in Allwinner A31 SoCs.
+config DW_AXI_DMAC
+ tristate "Synopsys DesignWare AXI DMA support"
+ depends on OF || COMPILE_TEST
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Enable support for Synopsys DesignWare AXI DMA controller.
+ NOTE: This driver wasn't tested on 64 bit platform because
+ of lack 64 bit platform with Synopsys DW AXI DMAC.
+
config EP93XX_DMA
bool "Cirrus Logic EP93xx DMA support"
depends on ARCH_EP93XX || COMPILE_TEST
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index b9dca8a..c242a5e 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_DMA_OMAP) += omap-dma.o
obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
obj-$(CONFIG_DMA_SUN4I) += sun4i-dma.o
obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+obj-$(CONFIG_DW_AXI_DMAC) += dw-axi-dmac/
obj-$(CONFIG_DW_DMAC_CORE) += dw/
obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
obj-$(CONFIG_FSL_DMA) += fsldma.o
diff --git a/drivers/dma/dw-axi-dmac/Makefile b/drivers/dma/dw-axi-dmac/Makefile
new file mode 100644
index 000..4ba81ec
--- /dev/null
+++ b/drivers/dma/dw-axi-dmac/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_DW_AXI_DMAC) += axi_dma_platform.o
diff --git a/drivers/dma/dw-axi-dmac/axi_dma_platform.c
b/drivers/dma/dw-axi-dmac/axi_dma_platform.c
new file mode 100644
index 000..fd8a3f1
--- /dev/null
+++ b/drivers/dma/dw-axi-dmac/axi_dma_platform.c
@@ -0,0 +1,1016 @@
+/*
+ * Synopsys DesignWare AXI DMA Controller driver.
+ *
+ * Copyright (C) 2017-2018 Synopsys, Inc. (www.synopsys.com)
+ * Author: Eugeniy Paltsev
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "axi_dma_platform.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
+
+#define DRV_NAME "axi_dw_dmac"
+
+/*
+ * The set of bus widths supported by the DMA controller. DW AXI DMAC supports
+ * master data bus width up to 512 bits (for both AXI master interfaces), but
+ * it depends on IP block configurarion.
+ */
+#define AXI_DMA_BUSWIDTHS\
+ (DMA_SLAVE_BUSWIDTH_1_BYTE | \
+ DMA_SLAVE_BUSWIDTH_2_BYTES | \
+ DMA_SLAVE_BUSWIDTH_4_BYTES | \
+ DMA_SLAVE_BUSWIDTH_8_BYTES | \
+ DMA_SLAVE_BUSWIDTH_16_BYTES | \
+ DMA_SLAVE_BUSWIDTH_32_BYTES | \
+ DMA_SLAVE_BUSWIDTH_64_BYTES)
+
+static inline void
+axi_dma_iowrite32(struct axi_dma_chip *chip, u32 reg, u32 val)
+{
+ iowrite32(val, chip->regs + reg);
+}
+
+static inline u32 axi_dma_ioread32(struct axi_dma_chip *chip, u32 reg)
+{
+ return ioread32(chip->regs + reg);
+}
+
+static inline void
+axi_chan_iowrite32(struct axi_dma_chan *chan, u32 reg, u32 val)
+{
+ iowrite32(val, chan->chan_regs + reg);
+}
+
+static inline u32 axi_chan_ioread32(struct axi_dma_chan *chan, u32 reg)
+{
+ return ioread32(chan->chan_regs + reg);
+}
+
+static inline void
+axi_chan_iowrite64(struct axi_dma_chan *chan, u32 reg, u64 val)
+{
+ /*
+* We split one 64 bit write for two 32 bit write as some HW doesn't
+* support 64 bit access.
+*/
+ iowrite32((u32)val, chan->chan_regs + reg);
+ iowrite32(val >> 32, chan->chan_regs + reg + 4);
+}
+
+static inline void axi_dma_disable(struct axi_dma_chip *chip)
+{
+
[PATCH v2 0/2] Introduce DW AXI DMAC driver
This patch series add support for the DW AXI DMAC controller. DW AXI DMAC is a part of HSDK development board from Synopsys. In this driver implementation only DMA_MEMCPY transfers are supported. Changes v1->v2 (suggested by Andy Shevchenko): * Use SPDX licence identifier. * Refactor axi_chan_get_xfer_width function. * Fix timeout calculation in dma_chan_pause. * Add record to MAINTAINERS in correct alphabetical order. Eugeniy Paltsev (2): dmaengine: Introduce DW AXI DMAC driver dt-bindings: Document the Synopsys DW AXI DMA bindings .../devicetree/bindings/dma/snps,dw-axi-dmac.txt | 41 + MAINTAINERS|6 + drivers/dma/Kconfig| 10 + drivers/dma/Makefile |1 + drivers/dma/dw-axi-dmac/Makefile |1 + drivers/dma/dw-axi-dmac/axi_dma_platform.c | 1010 drivers/dma/dw-axi-dmac/axi_dma_platform.h | 342 +++ 7 files changed, 1411 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.txt create mode 100644 drivers/dma/dw-axi-dmac/Makefile create mode 100644 drivers/dma/dw-axi-dmac/axi_dma_platform.c create mode 100644 drivers/dma/dw-axi-dmac/axi_dma_platform.h -- 2.9.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
> wrote:
> > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
> > have been made changes which can cause multiply overflow for 32-bit systems.
> > The value of cto_ms is lower the drto_ms, but nevertheless overflow can
> > occur.
> > Lets cast this multiply to u64 type which prevents overflow.
> > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
> > host->bus_hz);
> > +
> > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
> > host->bus_hz);
>
> IIRC, someone commented on this or similar, i.e.
>
> DIV_ROUND_UP_ULL() ?
Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
because overflow happens on multiply and DIV_ROUND_UP_ULL helps
with sum overflow.
--
Best regards,
Evgeniy Didin
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 1/2] dmaengine: Introduce DW AXI DMAC driver
On Mon, Feb 26, 2018 at 4:56 PM, Eugeniy Paltsev
wrote:
> This patch adds support for the DW AXI DMAC controller.
> DW AXI DMAC is a part of HSDK development board from Synopsys.
>
> In this driver implementation only DMA_MEMCPY transfers are
> supported.
> +/*
> + * Synopsys DesignWare AXI DMA Controller driver.
> + *
> + * Copyright (C) 2017-2018 Synopsys, Inc. (www.synopsys.com)
> + * Author: Eugeniy Paltsev
> + *
> + * SPDX-License-Identifier:GPL-2.0
According to license-rules.rst it should be first line in the file
with C++ style comment.
> + */
> +static inline void
> +axi_chan_iowrite64(struct axi_dma_chan *chan, u32 reg, u64 val)
> +{
> + /*
> +* We split one 64 bit write for two 32 bit write as some HW doesn't
> +* support 64 bit access.
> +*/
> + iowrite32((u32)val, chan->chan_regs + reg);
> + iowrite32(val >> 32, chan->chan_regs + reg + 4);
upper_32_bits()
lower_32_bits()
?
> +}
> +static int dma_chan_pause(struct dma_chan *dchan)
> +{
> + struct axi_dma_chan *chan = dchan_to_axi_dma_chan(dchan);
> + unsigned long flags;
> + unsigned int timeout = 20; /* timeout iterations */
> + int ret = -EAGAIN;
Perhaps,
int ret;
...
> + u32 val;
> +
> + spin_lock_irqsave(&chan->vc.lock, flags);
> +
> + val = axi_dma_ioread32(chan->chip, DMAC_CHEN);
> + val |= BIT(chan->id) << DMAC_CHAN_SUSP_SHIFT |
> + BIT(chan->id) << DMAC_CHAN_SUSP_WE_SHIFT;
> + axi_dma_iowrite32(chan->chip, DMAC_CHEN, val);
> +
> + do {
> + if (axi_chan_irq_read(chan) & DWAXIDMAC_IRQ_SUSPENDED) {
> + ret = 0;
> + break;
> + }
...
if (...)
break;
...
> + udelay(2);
> + } while (--timeout);
...
ret = timeout ? 0 : -EAGAIN;
?
> +
> + axi_chan_irq_clear(chan, DWAXIDMAC_IRQ_SUSPENDED);
> +
> + chan->is_paused = true;
> +
> + spin_unlock_irqrestore(&chan->vc.lock, flags);
> +
> + return ret;
> +}
> +/* pm_runtime callbacks */
Noise.
> +#ifdef CONFIG_PM
__maybe_unused
> +static int axi_dma_runtime_suspend(struct device *dev)
> +{
> + struct axi_dma_chip *chip = dev_get_drvdata(dev);
> +
> + return axi_dma_suspend(chip);
> +}
> +
> +static int axi_dma_runtime_resume(struct device *dev)
> +{
> + struct axi_dma_chip *chip = dev_get_drvdata(dev);
> +
> + return axi_dma_resume(chip);
> +}
> +#endif
> +static int parse_device_properties(struct axi_dma_chip *chip)
> +{
> + ret = device_property_read_u32(dev, "snps,dma-masters", &tmp);
Why it has prefix?
> + ret = device_property_read_u32(dev, "snps,data-width", &tmp);
Ditto.
> + ret = device_property_read_u32_array(dev, "snps,block-size", carr,
> +chip->dw->hdata->nr_channels);
(perhaps this one can be moved outside of local namespace)
> + ret = device_property_read_u32_array(dev, "snps,priority", carr,
> +chip->dw->hdata->nr_channels);
Can you use just "priority"?
> + /* axi-max-burst-len is optional property */
> + ret = device_property_read_u32(dev, "snps,axi-max-burst-len", &tmp);
"dma-burst-sz" ?
> + chip->core_clk = devm_clk_get(chip->dev, "core-clk");
Does the name come from datasheet?
> + chip->cfgr_clk = devm_clk_get(chip->dev, "cfgr-clk");
Ditto?
> + for (i = 0; i < hdata->nr_channels; i++) {
> + chan->id = (u8)i;
Hmm... Do you need explicit casting?
> + }
> + /* Enable clk before accessing to registers */
> + clk_prepare_enable(chip->cfgr_clk);
> + clk_prepare_enable(chip->core_clk);
Each of them may fail. Is it okay?
> +static const struct dev_pm_ops dw_axi_dma_pm_ops = {
> + SET_RUNTIME_PM_OPS(axi_dma_runtime_suspend, axi_dma_runtime_resume,
> NULL)
> +};
No system suspend?
> +/*
> + * Synopsys DesignWare AXI DMA Controller driver.
> + *
> + * Copyright (C) 2017-2018 Synopsys, Inc. (www.synopsys.com)
> + * Author: Eugeniy Paltsev
> + *
> + * SPDX-License-Identifier:GPL-2.0
First line, but C style of the comment.
> + */
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
wrote:
> On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
>> wrote:
>> > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
>> > have been made changes which can cause multiply overflow for 32-bit
>> > systems.
>> > The value of cto_ms is lower the drto_ms, but nevertheless overflow can
>> > occur.
>> > Lets cast this multiply to u64 type which prevents overflow.
>> > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
>> > host->bus_hz);
>> > +
>> > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
>> > host->bus_hz);
>>
>> IIRC, someone commented on this or similar, i.e.
>>
>> DIV_ROUND_UP_ULL() ?
> Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
> because overflow happens on multiply and DIV_ROUND_UP_ULL helps
> with sum overflow.
Did you try to compile your code for 32-bit target?
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
> wrote:
> > On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
> > > wrote:
> > > > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
> > > > have been made changes which can cause multiply overflow for 32-bit
> > > > systems.
> > > > The value of cto_ms is lower the drto_ms, but nevertheless overflow can
> > > > occur.
> > > > Lets cast this multiply to u64 type which prevents overflow.
> > > > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
> > > > host->bus_hz);
> > > > +
> > > > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
> > > > host->bus_hz);
> > >
> > > IIRC, someone commented on this or similar, i.e.
> > >
> > > DIV_ROUND_UP_ULL() ?
> >
> > Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
> > because overflow happens on multiply and DIV_ROUND_UP_ULL helps
> > with sum overflow.
>
> Did you try to compile your code for 32-bit target?
Yes, we have compiled code for 32-bit system.
I am wondering why are you asking that?
--
Best regards,
Evgeniy Didin
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
wrote:
> On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
>> On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
>> wrote:
>> > On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
>> > > On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
>> > > wrote:
>> > > > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout calculation")
>> > > > have been made changes which can cause multiply overflow for 32-bit
>> > > > systems.
>> > > > The value of cto_ms is lower the drto_ms, but nevertheless overflow
>> > > > can occur.
>> > > > Lets cast this multiply to u64 type which prevents overflow.
>> > > > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
>> > > > host->bus_hz);
>> > > > +
>> > > > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
>> > > > host->bus_hz);
>> > >
>> > > IIRC, someone commented on this or similar, i.e.
>> > >
>> > > DIV_ROUND_UP_ULL() ?
>> >
>> > Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
>> > because overflow happens on multiply and DIV_ROUND_UP_ULL helps
>> > with sum overflow.
>>
>> Did you try to compile your code for 32-bit target?
> Yes, we have compiled code for 32-bit system.
> I am wondering why are you asking that?
Because I simple didn't believe you.
ERROR: "__udivdi3" [drivers/mmc/host/dw_mmc.ko] undefined!
...scripts/Makefile.modpost:92: recipe for target '__modpost' failed
make[2]: *** [__modpost] Error 1
+++ b/drivers/mmc/host/dw_mmc.c
@@ -409,7 +409,7 @@ static inline void dw_mci_set_cto(struct dw_mci *host)
- cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div, host->bus_hz);
+ cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks * cto_div,
host->bus_hz);
--
With Best Regards,
Andy Shevchenko
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
Hi Andy,
On Mon, 2018-02-26 at 20:30 +0200, Andy Shevchenko wrote:
> On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
> wrote:
> > On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
> > > On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
> > > wrote:
> > > > On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
> > > > > On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
> > > > > wrote:
> > > > > > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout
> > > > > > calculation")
> > > > > > have been made changes which can cause multiply overflow for 32-bit
> > > > > > systems.
> > > > > > The value of cto_ms is lower the drto_ms, but nevertheless overflow
> > > > > > can occur.
> > > > > > Lets cast this multiply to u64 type which prevents overflow.
> > > > > > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
> > > > > > host->bus_hz);
> > > > > > +
> > > > > > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks *
> > > > > > cto_div, host->bus_hz);
> > > > >
> > > > > IIRC, someone commented on this or similar, i.e.
> > > > >
> > > > > DIV_ROUND_UP_ULL() ?
> > > >
> > > > Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
> > > > because overflow happens on multiply and DIV_ROUND_UP_ULL helps
> > > > with sum overflow.
> > >
> > > Did you try to compile your code for 32-bit target?
> >
> > Yes, we have compiled code for 32-bit system.
> > I am wondering why are you asking that?
>
> Because I simple didn't believe you.
Well world around us is much more complicated than it sometimes looks like :)
> ERROR: "__udivdi3" [drivers/mmc/host/dw_mmc.ko] undefined!
> ...scripts/Makefile.modpost:92: recipe for target '__modpost' failed
> make[2]: *** [__modpost] Error 1
That's right __udivdi3() is not defined for some architectures but it is
defined for
some others including ARC, Xtensa etc, see
https://elixir.bootlin.com/linux/latest/ident/__udivdi3
What happens __udivdi3() is implemented in libgcc in one form or another form
be it pure assembly or generic implementation written in C.
So maybe we need to add export of __udivdi3() for other arches, what do you
think?
-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: arc: mm->mmap_sem gets locked in do_page_fault() in case of OOM killer invocation
Hi Vineet, all
On Fri, 2018-02-16 at 15:40 +0300, Alexey Brodkin wrote:
> Hi Vineet,
>
> While playing with OOM killer I bumped in a pure software deadlock on ARC
> which is even observed in simulation (i.e. it has nothing to do with HW
> peculiarities).
>
> What's nice kernel even sees that lock-up if "Lock Debugging" is enabled.
> That's what I see:
> >8---
> # /home/oom-test 450 & /home/oom-test 450
> oom-test invoked oom-killer: gfp_mask=0x14200ca(GFP_HIGHUSER_MOVABLE),
> nodemask=(null), order=0, oom_score_adj=0
> CPU: 0 PID: 67 Comm: oom-test Not tainted 4.14.19 #2
>
> Stack Trace:
> arc_unwind_core.constprop.1+0xd4/0xf8
> dump_header.isra.6+0x84/0x2f8
> oom_kill_process+0x258/0x7c8
> out_of_memory+0xb8/0x5e0
> __alloc_pages_nodemask+0x922/0xd28
> handle_mm_fault+0x284/0xd90
> do_page_fault+0xf6/0x2a0
> ret_from_exception+0x0/0x8
> Mem-Info:
> active_anon:62276 inactive_anon:341 isolated_anon:0
> active_file:0 inactive_file:0 isolated_file:0
> unevictable:0 dirty:0 writeback:0 unstable:0
> slab_reclaimable:26 slab_unreclaimable:196
> mapped:105 shmem:578 pagetables:263 bounce:0
> free:344 free_pcp:39 free_cma:0
> Node 0 active_anon:498208kB inactive_anon:2728kB active_file:0kB
> inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB
> mapped:840kB
> dirty:
> 0kB writeback:0kB shmem:4624kB writeback_tmp:0kB unstable:0kB
> all_unreclaimable? no
> Normal free:2752kB min:2840kB low:3544kB high:4248kB active_anon:498208kB
> inactive_anon:2728kB active_file:0kB inactive_file:0kB unevictable:0kB
> writependin
> g:0kB present:524288kB managed:508584kB mlocked:0kB kernel_stack:240kB
> pagetables:2104kB bounce:0kB free_pcp:312kB local_pcp:312kB free_cma:0kB
> lowmem_reserve[]: 0 0
> Normal: 0*8kB 0*16kB 0*32kB 1*64kB (M) 1*128kB (M) 0*256kB 1*512kB (M)
> 0*1024kB 1*2048kB (M) 0*4096kB 0*8192kB = 2752kB
> 578 total pagecache pages
> 65536 pages RAM
> 0 pages HighMem/MovableOnly
> 1963 pages reserved
> [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj
> name
> [ 41] 041 157 103 3 00 0
> syslogd
> [ 43] 043 156 106 3 00 0
> klogd
> [ 63] 063 157 99 3 00 0
> getty
> [ 64] 064 159 118 3 00 0
> sh
> [ 66] 066 11529131094 124 00 0
> oom-test
> [ 67] 067 11529131004 124 00 0
> oom-test
> Out of memory: Kill process 66 (oom-test) score 476 or sacrifice child
> Killed process 66 (oom-test) total-vm:922328kB, anon-rss:248328kB,
> file-rss:0kB, shmem-rss:424kB
>
>
> WARNING: possible recursive locking detected
> 4.14.19 #2 Not tainted
>
> oom-test/66 is trying to acquire lock:
> (&mm->mmap_sem){}, at: [<80217d50>] do_exit+0x444/0x7f8
>
> but task is already holding lock:
> (&mm->mmap_sem){}, at: [<8021028a>] do_page_fault+0x9e/0x2a0
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
>CPU0
>
> lock(&mm->mmap_sem);
> lock(&mm->mmap_sem);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 1 lock held by oom-test/66:
> #0: (&mm->mmap_sem){}, at: [<8021028a>] do_page_fault+0x9e/0x2a0
>
> stack backtrace:
> CPU: 0 PID: 66 Comm: oom-test Not tainted 4.14.19 #2
>
> Stack Trace:
> arc_unwind_core.constprop.1+0xd4/0xf8
> __lock_acquire+0x582/0x1494
> lock_acquire+0x3c/0x58
> down_read+0x1a/0x28
> do_exit+0x444/0x7f8
> do_group_exit+0x26/0x8c
> get_signal+0x1aa/0x7d4
> do_signal+0x30/0x220
> resume_user_mode_begin+0x90/0xd8
> >8---
>
> Looking at our code in "arch/arc/mm/fault.c" I may see why "mm->mmap_sem" is
> not released:
> 1. fatal_signal_pending(current) returns non-zero value
> 2. ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY)) is false thus
> up_read(&mm->mmap_sem)
>is not executed.
> 3. It was a user-space process thus we simply return [with "mm->mmap_sem"
> still held].
>
> See the code snippet below:
> >8---
> /* If Pagefault was interrupted by SIGKILL, exit page fault "early" */
> if (unlikely(fatal_signal_pending(current))) {
> if ((fault & VM_FAULT_ERROR) && !(fault & VM_FAULT_RETRY))
> up_read(&mm->mmap_sem);
> if (user_mode(regs))
> return;
> }
> >8---
So I decided to give a trivial fix a tr
Re: uClibc-ng testsuite failures
On 02/26/2018 11:59 AM, Waldemar Brodkorb wrote: The syscall cancellation failures are still there with gcc 7.3.0 and binutils 2.30. Do you have any patches on top of it? Are you talking about these results? https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_1.0.28_REPORT.arcv2.libc.uClibc-2Dng-2D1.0.28&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=BGT84AxTG_-ymRw4CytOO7g6kTy7PXKYBrHbGF_pTR4&e= No. But the link above points to stuff built with gcc 7.2 but not 7.3. Could you please share your results with gcc 7.2 and binutils 2.30? Here with gcc 7.3.0 and binutils 2.30: https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_git_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=Ni7_rqZq4c0mvnYsOyvZoZEIddMnIOEsSmopG9m9LwU&e= I ran into similar issues with glibc test suite. It seems gcc 7.x released won't cut it - it misses tons of upstream patches including 2017-11-03 e892f4fac605 [ARC] Fix to unwinding. So your best bet is to use upstream gcc master ! -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: uClibc-ng testsuite failures
Hi Vineet, Vineet Gupta wrote, > On 02/26/2018 11:59 AM, Waldemar Brodkorb wrote: > >>>The syscall cancellation failures are still there with gcc 7.3.0 and > >>>binutils 2.30. Do you have any patches on top of it? > >>Are you talking about these results? > >>https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_1.0.28_REPORT.arcv2.libc.uClibc-2Dng-2D1.0.28&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=BGT84AxTG_-ymRw4CytOO7g6kTy7PXKYBrHbGF_pTR4&e= > >No. > >>But the link above points to stuff built with gcc 7.2 but not 7.3. > >>Could you please share your results with gcc 7.2 and binutils 2.30? > >Here with gcc 7.3.0 and binutils 2.30: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_git_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=Ni7_rqZq4c0mvnYsOyvZoZEIddMnIOEsSmopG9m9LwU&e= > > I ran into similar issues with glibc test suite. It seems gcc 7.x released > won't cut it - it misses tons of upstream patches including > > 2017-11-03 e892f4fac605 [ARC] Fix to unwinding. > > So your best bet is to use upstream gcc master ! gcc 7 branch or gcc 8 latest greatest? Last time there was some issue with gcc8 and you told me to use gcc7 with some patches. /me is confused. best regards Waldemar ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: uClibc-ng testsuite failures
On 02/26/2018 12:50 PM, Waldemar Brodkorb wrote: Hi Vineet, Vineet Gupta wrote, On 02/26/2018 11:59 AM, Waldemar Brodkorb wrote: The syscall cancellation failures are still there with gcc 7.3.0 and binutils 2.30. Do you have any patches on top of it? Are you talking about these results? https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_1.0.28_REPORT.arcv2.libc.uClibc-2Dng-2D1.0.28&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=BGT84AxTG_-ymRw4CytOO7g6kTy7PXKYBrHbGF_pTR4&e= No. But the link above points to stuff built with gcc 7.2 but not 7.3. Could you please share your results with gcc 7.2 and binutils 2.30? Here with gcc 7.3.0 and binutils 2.30: https://urldefense.proofpoint.com/v2/url?u=https-3A__downloads.uclibc-2Dng.org_reports_git_&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=7FgpX6o3vAhwMrMhLh-4ZJey5kjdNUwOL2CWsFwR4T8&m=TsxZS2Izf4LUrQfQCh9Iw8-L0zYXeJLdRhvUfyiWw2A&s=Ni7_rqZq4c0mvnYsOyvZoZEIddMnIOEsSmopG9m9LwU&e= I ran into similar issues with glibc test suite. It seems gcc 7.x released won't cut it - it misses tons of upstream patches including 2017-11-03 e892f4fac605 [ARC] Fix to unwinding. So your best bet is to use upstream gcc master ! gcc 7 branch or gcc 8 latest greatest? AFAIK gcc 8 is not released yet, so upstream/master ! Last time there was some issue with gcc8 and you told me to use gcc7 with some patches. Right there was yet another code gen issue / ICE at the time, which is likely gone now. But gcc upstream/master works for me. /me is confused. Sorry if I steered you the wrong way. At that time upstream was practically not usable, so more unwinder tests failing were kind of secondary on priority ;-) -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 0/2 v3] mmc: dw_mmc: Fix DTO/STO timeout overflow calculation
On Mon, 26 Feb 2018 17:34:11 +0300 Evgeniy Didin wrote: > For some 32-bit architectures calculation of DTO and STO timeout can be > incorrect > due to multiply overflow. Lets prevent this by casting multiply and result to > u64. > > Suggested by Jisheng Zhang. > Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable > because overflow happens on multiply and DIV_ROUND_UP_ULL helps > with sum overflow. hmmm, I mean something as below: -cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div, host->bus_hz); +cto_ms = DIV_ROUND_UP_ULL((u64)MSEC_PER_SEC * cto_clks * cto_div, host->bus_hz); This could avoid build error in arm case. > > --- > Changes since v2: > -add fix for cto_ms > > Evgeniy Didin (2): > mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit > systems > mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems These two patches could be folded into one patch? Thanks ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 2/2 v3] mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
On Mon, 26 Feb 2018 20:27:22 + Alexey Brodkin wrote:
> Hi Andy,
>
> On Mon, 2018-02-26 at 20:30 +0200, Andy Shevchenko wrote:
> > On Mon, Feb 26, 2018 at 7:14 PM, Evgeniy Didin
> > wrote:
> > > On Mon, 2018-02-26 at 18:53 +0200, Andy Shevchenko wrote:
> > > > On Mon, Feb 26, 2018 at 5:14 PM, Evgeniy Didin
> > > > wrote:
> > > > > On Mon, 2018-02-26 at 16:39 +0200, Andy Shevchenko wrote:
> > > > > > On Mon, Feb 26, 2018 at 4:34 PM, Evgeniy Didin
> > > > > > wrote:
> > > > > > > In commit 4c2357f57dd5 ("mmc: dw_mmc: Fix the CTO timeout
> > > > > > > calculation")
> > > > > > > have been made changes which can cause multiply overflow for
> > > > > > > 32-bit systems.
> > > > > > > The value of cto_ms is lower the drto_ms, but nevertheless
> > > > > > > overflow can occur.
> > > > > > > Lets cast this multiply to u64 type which prevents overflow.
> > > > > > > - cto_ms = DIV_ROUND_UP(MSEC_PER_SEC * cto_clks * cto_div,
> > > > > > > host->bus_hz);
> > > > > > > +
> > > > > > > + cto_ms = DIV_ROUND_UP((u64)MSEC_PER_SEC * cto_clks *
> > > > > > > cto_div, host->bus_hz);
> > > > > >
> > > > > > IIRC, someone commented on this or similar, i.e.
> > > > > >
> > > > > > DIV_ROUND_UP_ULL() ?
> > > > >
> > > > > Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
> > > > > because overflow happens on multiply and DIV_ROUND_UP_ULL helps
> > > > > with sum overflow.
> > > >
> > > > Did you try to compile your code for 32-bit target?
> > >
> > > Yes, we have compiled code for 32-bit system.
> > > I am wondering why are you asking that?
> >
> > Because I simple didn't believe you.
>
> Well world around us is much more complicated than it sometimes looks like :)
>
> > ERROR: "__udivdi3" [drivers/mmc/host/dw_mmc.ko] undefined!
> > ...scripts/Makefile.modpost:92: recipe for target '__modpost' failed
> > make[2]: *** [__modpost] Error 1
>
> That's right __udivdi3() is not defined for some architectures but it is
> defined for
> some others including ARC, Xtensa etc, see
> https://elixir.bootlin.com/linux/latest/ident/__udivdi3
>
> What happens __udivdi3() is implemented in libgcc in one form or another form
> be it pure assembly or generic implementation written in C.
>
> So maybe we need to add export of __udivdi3() for other arches, what do you
> think?
Per my understanding, Linux kernel prefer to make use of do_div or
implementations
in for 64bit divide
Thanks
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
