* [PATCH 2/4] ata: Add DT bindings for the Gemini SATA bridge
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: Janos Laube, Paulius Zaleckas, openwrt-devel, linux-arm-kernel,
Hans Ulli Kroll, Florian Fainelli, Linus Walleij, devicetree,
John Feng-Hsin Chiang, Greentime Hu
In-Reply-To: <20170506121053.11554-1-linus.walleij@linaro.org>
This adds device tree bindings for the Cortina Systems Gemini
PATA to SATA bridge.
Cc: devicetree@vger.kernel.org
Cc: John Feng-Hsin Chiang <john453@faraday-tech.com>
Cc: Greentime Hu <green.hu@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../bindings/ata/cortina,gemini-sata-bridge.txt | 55 ++++++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
new file mode 100644
index 000000000000..9fe92818b2fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt
@@ -0,0 +1,55 @@
+* Cortina Systems Gemini SATA Bridge
+
+The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that
+takes two Faraday Technology FTIDE010 PATA controllers and bridges
+them in different configurations to two SATA ports.
+
+Required properties:
+- compatible: should be
+ "cortina,gemini-sata-bridge"
+- reg: registers and size for the block
+- resets: phandles to the reset lines for both SATA bridges
+- reset-names: must be "sata0", "sata1"
+- clocks: phandles to the compulsory peripheral clocks
+- clock-names: must be "SATA0_PCLK", "SATA1_PCLK"
+- syscon: a phandle to the global Gemini system controller
+- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for
+ the ATA controller and SATA bridges. Values 0..3:
+ Mode 0: ata0 master <-> sata0
+ ata1 master <-> sata1
+ ata0 slave interface brought out on IDE pads
+ Mode 1: ata0 master <-> sata0
+ ata1 master <-> sata1
+ ata1 slave interface brought out on IDE pads
+ Mode 2: ata1 master <-> sata1
+ ata1 slave <-> sata0
+ ata0 master and slave interfaces brought out
+ on IDE pads
+ Mode 3: ata0 master <-> sata0
+ ata1 slave <-> sata1
+ ata1 master and slave interfaces brought out
+ on IDE pads
+
+Optional boolean properties:
+- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection.
+ The muxmode setting decides whether ATA0 or ATA1 is brought out,
+ and whether master, slave or both interfaces get brought out.
+- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge
+ inside the Gemnini SoC. The Muxmode decides what PATA blocks will
+ be muxed out and how.
+
+Example:
+
+sata: sata@46000000 {
+ compatible = "cortina,gemini-sata-bridge";
+ reg = <0x46000000 0x100>;
+ resets = <&rcon 26>, <&rcon 27>;
+ reset-names = "sata0", "sata1";
+ clocks = <&gcc GEMINI_CLK_GATE_SATA0>,
+ <&gcc GEMINI_CLK_GATE_SATA1>;
+ clock-names = "SATA0_PCLK", "SATA1_PCLK";
+ syscon = <&syscon>;
+ cortina,gemini-ata-muxmode = <3>;
+ cortina,gemini-enable-ide-pins;
+ cortina,gemini-enable-sata-bridge;
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 1/4] ata: Add DT bindings for Faraday Technology FTIDE010
From: Linus Walleij @ 2017-05-06 12:10 UTC (permalink / raw)
To: Tejun Heo, Bartlomiej Zolnierkiewicz, linux-ide
Cc: openwrt-devel, devicetree, John Feng-Hsin Chiang,
Paulius Zaleckas, Greentime Hu, Janos Laube, linux-arm-kernel
This adds device tree bindings for the Faraday Technology
FTIDE010 found in the Storlink/Storm/Cortina Systems Gemini SoC.
I am not 100% sure that this part if from Faraday Technology but
a lot points in that direction:
- A later IDE interface called FTIDE020 exist and share some
properties.
- The SATA bridge has the same Built In Self Test (BIST) that the
Faraday FTSATA100 seems to have, and it has version number 0100
in the device ID register, so this is very likely a FTSATA100
bundled with the FTIDE010.
Cc: devicetree@vger.kernel.org
Cc: John Feng-Hsin Chiang <john453@faraday-tech.com>
Cc: Greentime Hu <green.hu@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Greentime: I think this may be interesting to you since the
FTIDE020 will need the same bindings so we can probably
just reuse them and maybe make the parser a library if you
want to upstream the FTIDE020.
Faraday people: I do not have it from a source that this
hardware is really FTIDE010 but I would be VERY surprised
if it is not. U-Boot has an FTIDE020 IDE controller
synthesized in the Andestech platform, and it has a similar
yet different register layout, featuring similar timing
set-ups:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.h
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/block/ftide020.c
---
.../devicetree/bindings/ata/faraday,ftide010.txt | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/faraday,ftide010.txt
diff --git a/Documentation/devicetree/bindings/ata/faraday,ftide010.txt b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt
new file mode 100644
index 000000000000..5048408c07c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/faraday,ftide010.txt
@@ -0,0 +1,63 @@
+* Faraday Technology FTIDE010 PATA controller
+
+This controller is the first Faraday IDE interface block, used in the
+StorLink SL2312 and SL3516, later known as the Cortina Systems Gemini
+platform. The controller can do PIO modes 0 through 4, Multi-word DMA
+(MWDM)modes 0 through 2 and Ultra DMA modes 0 through 6.
+
+On the Gemini platform, this PATA block is accompanied by a PATA to
+SATA bridge in order to support SATA. This is why a phandle to that
+controller is compulsory on that platform.
+
+The timing properties are unique per-SoC, not per-board.
+
+Required properties:
+- compatible: should be one of
+ "cortina,gemini-pata", "faraday,ftide010"
+ "faraday,ftide010"
+- interrupts: interrupt for the block
+- reg: registers and size for the block
+
+ The unit of the below required timings is two clock periods of the ATA
+ reference clock which is 30 nanoseconds per unit at 66MHz and 20 nanoseconds
+ per unit at 50 MHz.
+
+- faraday,pio-active-time: array of 5 elements for T2 timing for Mode 0,
+ 1, 2, 3 and 4. Range 0..15.
+- faraday,pio-recovery-time: array of 5 elements for T2l timing for Mode 0,
+ 1, 2, 3 and 4. Range 0..15.
+- faraday,mdma-50-active-time: array of 4 elements for Td timing for multi
+ word DMA, Mode 0, 1, and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-50-recovery-time: array of 4 elements for Tk timing for
+ multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-66-active-time: array of 4 elements for Td timing for multi
+ word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,mdma-66-recovery-time: array of 4 elements for Tk timing for
+ multi word DMA, Mode 0, 1 and 2 at 50 MHz. Range 0..15.
+- faraday,udma-50-setup-time: array of 4 elements for Tvds timing for ultra
+ DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz. Range 0..7.
+- faraday,udma-50-hold-time: array of 4 elements for Tdvh timing for
+ multi word DMA, Mode 0, 1, 2, 3, 4 and 5 at 50 MHz, Range 0..7.
+- faraday,udma-66-setup-time: array of 4 elements for Tvds timing for multi
+ word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+- faraday,udma-66-hold-time: array of 4 elements for Tdvh timing for
+ multi word DMA, Mode 0, 1, 2, 3, 4, 5 and 6 at 50 MHz. Range 0..7.
+
+Optional properties:
+- clocks: a SoC clock running the peripheral.
+- clock-names: should be set to "PCLK" for the peripheral clock.
+
+Required properties for "cortina,gemini-pata" compatible:
+- sata: a phande to the Gemini PATA to SATA bridge, see
+ cortina,gemini-sata-bridge.txt for details.
+
+Example:
+
+ata@63000000 {
+ compatible = "cortina,gemini-pata", "faraday,ftide010";
+ reg = <0x63000000 0x100>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&gcc GEMINI_CLK_GATE_IDE>;
+ clock-names = "PCLK";
+ sata = <&sata>;
+};
--
2.9.3
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
^ permalink raw reply related
* Re: [PATCH v2] ata-sff: always map page before data transfer
From: Tejun Heo @ 2017-05-05 16:16 UTC (permalink / raw)
To: Tycho Andersen
Cc: Juerg Haefliger, Christoph Hellwig, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170504221551.6458-1-tycho@docker.com>
On Thu, May 04, 2017 at 04:15:51PM -0600, Tycho Andersen wrote:
> The XPFO [1] patchset may unmap pages from physmap if they happened to be
> destined for userspace. If such a page is unmapped, it needs to be
> remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
> Christoph suggested [2] that we simply always map the page.
>
> v2: * drop comment about bounce buffer
> * don't save IRQs before kmap/unmap
> * formatting
>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Tycho Andersen <tycho@docker.com>
> CC: Juerg Haefliger <juerg.haefliger@hpe.com>
> CC: Tejun Heo <tj@kernel.org>
>
> [1]: https://lkml.org/lkml/2016/11/4/245
> [2]: https://lkml.org/lkml/2016/11/4/253
Yeah, it's a nice cleanup.
Applied to libata/for-4.13.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v2] ata-sff: always map page before data transfer
From: Christoph Hellwig @ 2017-05-05 6:31 UTC (permalink / raw)
To: Tycho Andersen
Cc: Tejun Heo, Juerg Haefliger, Christoph Hellwig, linux-ide,
linux-kernel, kernel-hardening
In-Reply-To: <20170504221551.6458-1-tycho@docker.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-04 22:18 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Tejun Heo, Juerg Haefliger, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170504095134.GA14372@infradead.org>
On Thu, May 04, 2017 at 02:51:34AM -0700, Christoph Hellwig wrote:
> And we should be fine.
Great, I just sent a v2. Thanks!
Tycho
^ permalink raw reply
* [PATCH v2] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-04 22:15 UTC (permalink / raw)
To: Tejun Heo, Juerg Haefliger
Cc: Christoph Hellwig, linux-ide, linux-kernel, kernel-hardening,
Tycho Andersen
The XPFO [1] patchset may unmap pages from physmap if they happened to be
destined for userspace. If such a page is unmapped, it needs to be
remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
Christoph suggested [2] that we simply always map the page.
v2: * drop comment about bounce buffer
* don't save IRQs before kmap/unmap
* formatting
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Tycho Andersen <tycho@docker.com>
CC: Juerg Haefliger <juerg.haefliger@hpe.com>
CC: Tejun Heo <tj@kernel.org>
[1]: https://lkml.org/lkml/2016/11/4/245
[2]: https://lkml.org/lkml/2016/11/4/253
---
v1: https://lkml.org/lkml/2017/5/2/404
---
drivers/ata/libata-sff.c | 44 ++++++++------------------------------------
1 file changed, 8 insertions(+), 36 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 2bd92dca3e62..01cf07c919bc 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -716,24 +716,10 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use a bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
-
- /* do the actual data transfer */
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
-
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
- }
+ /* do the actual data transfer */
+ buf = kmap_atomic(page);
+ ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size, do_write);
+ kunmap_atomic(buf);
if (!do_write && !PageSlab(page))
flush_dcache_page(page);
@@ -861,24 +847,10 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
-
- /* do the actual data transfer */
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
-
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
- }
+ /* do the actual data transfer */
+ buf = kmap_atomic(page);
+ consumed = ap->ops->sff_data_xfer(qc, buf + offset, count, rw);
+ kunmap_atomic(buf);
bytes -= min(bytes, consumed);
qc->curbytes += count;
--
2.11.0
^ permalink raw reply related
* RE: Donation Award
From: Mayrhofer Family @ 2017-05-04 11:16 UTC (permalink / raw)
To: Recipients
Good Day,
My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from part of our Jackpot Lottery of 50 Million Dollars, respond with your details for claims.
We await your earliest response and God Bless you.
Friedrich And Annand Mayrhofer.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH] ata-sff: always map page before data transfer
From: Christoph Hellwig @ 2017-05-04 9:51 UTC (permalink / raw)
To: Tycho Andersen
Cc: Tejun Heo, Juerg Haefliger, linux-ide, linux-kernel,
kernel-hardening
In-Reply-To: <20170502162932.12578-1-tycho@docker.com>
> I don't understand all the factors at play here, so thoughts are definitely
> welcome.
I don't fully understand the old code either. One thing that is weird
is the "use a bounce buffer comment" which doesn't make any sense.
The other is the local_irq_save, which isn't really needed for
kmap_atomic to start with, but maybe that's the reason why the original
author didn't want to do it unconditionally?
So based on that:
> + /* FIXME: use a bounce buffer */
drop this comment..
> + local_irq_save(flags);
.. remove the local_irq_save/local_irq_restore ..
> + /* do the actual data transfer */
> + ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
> + do_write);
.. and a nice alittle cleanup move the do_write onto the previous line.
> + /* FIXME: use bounce buffer */
> + local_irq_save(flags);
> + buf = kmap_atomic(page);
>
> + /* do the actual data transfer */
> + consumed = ap->ops->sff_data_xfer(qc, buf + offset,
> + count, rw);
And same here.
And we should be fine.
^ permalink raw reply
* Re:
From: H.A @ 2017-05-03 6:23 UTC (permalink / raw)
To: Recipients
With profound love in my heart, I Kindly Oblige your interest to very important proposal.. It is Truly Divine and require your utmost attention..........
S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.
Kontaktujte me prímo pres: helenaroberts99@gmail.com pro úplné podrobnosti.complete.
HELINA .A ROBERTS
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
^ permalink raw reply
* [PATCH] ata-sff: always map page before data transfer
From: Tycho Andersen @ 2017-05-02 16:29 UTC (permalink / raw)
To: Tejun Heo, Juerg Haefliger
Cc: linux-ide, linux-kernel, kernel-hardening, Tycho Andersen
The XPFO [1] patchset may unmap pages from physmap if they happened to be
destined for userspace. If such a page is unmapped, it needs to be
remapped. Rather than test if a page is in the highmem/xpfo unmapped state,
Christoph suggested [2] that we simply always map the page.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Tycho Andersen <tycho@docker.com>
CC: Juerg Haefliger <juerg.haefliger@hpe.com>
CC: Tejun Heo <tj@kernel.org>
[1]: https://lkml.org/lkml/2016/11/4/245
[2]: https://lkml.org/lkml/2016/11/4/253
---
I don't understand all the factors at play here, so thoughts are definitely
welcome.
---
drivers/ata/libata-sff.c | 50 +++++++++++++++++-------------------------------
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index 2bd92dc..8da2572 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -703,6 +703,7 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
struct page *page;
unsigned int offset;
unsigned char *buf;
+ unsigned long flags;
if (qc->curbytes == qc->nbytes - qc->sect_size)
ap->hsm_task_state = HSM_ST_LAST;
@@ -716,24 +717,16 @@ static void ata_pio_sector(struct ata_queued_cmd *qc)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use a bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
+ /* FIXME: use a bounce buffer */
+ local_irq_save(flags);
+ buf = kmap_atomic(page);
- /* do the actual data transfer */
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
+ /* do the actual data transfer */
+ ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
+ do_write);
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- ap->ops->sff_data_xfer(qc, buf + offset, qc->sect_size,
- do_write);
- }
+ kunmap_atomic(buf);
+ local_irq_restore(flags);
if (!do_write && !PageSlab(page))
flush_dcache_page(page);
@@ -836,6 +829,7 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
struct page *page;
unsigned char *buf;
unsigned int offset, count, consumed;
+ unsigned long flags;
next_sg:
sg = qc->cursg;
@@ -861,24 +855,16 @@ static int __atapi_pio_bytes(struct ata_queued_cmd *qc, unsigned int bytes)
DPRINTK("data %s\n", qc->tf.flags & ATA_TFLAG_WRITE ? "write" : "read");
- if (PageHighMem(page)) {
- unsigned long flags;
-
- /* FIXME: use bounce buffer */
- local_irq_save(flags);
- buf = kmap_atomic(page);
+ /* FIXME: use bounce buffer */
+ local_irq_save(flags);
+ buf = kmap_atomic(page);
- /* do the actual data transfer */
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
+ /* do the actual data transfer */
+ consumed = ap->ops->sff_data_xfer(qc, buf + offset,
+ count, rw);
- kunmap_atomic(buf);
- local_irq_restore(flags);
- } else {
- buf = page_address(page);
- consumed = ap->ops->sff_data_xfer(qc, buf + offset,
- count, rw);
- }
+ kunmap_atomic(buf);
+ local_irq_restore(flags);
bytes -= min(bytes, consumed);
qc->curbytes += count;
--
2.9.3
^ permalink raw reply related
* [GIT PULL] libata changes for v4.12-rc1
From: Tejun Heo @ 2017-05-01 19:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-ide, Bartlomiej Zolnierkiewicz
Hello, Linus.
The biggest core change is removal of SCT WRITE SAME support, which
never worked properly. Other than that, trivial updates in core code
and specific embedded driver updates.
Thanks.
The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.12
for you to fetch changes up to 63ccc191649eb0f14a761074291551d0d2f85389:
libata: remove SCT WRITE SAME support (2017-04-28 18:09:59 -0400)
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
ata: allow subsystem to be used on m32r and s390 archs
Bartosz Golaszewski (2):
ata: ahci: add support for DaVinci DM816 SATA controller
dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller
Belen Sarabia (1):
Delete redundant return value check of platform_get_resource()
Bhumika Goyal (1):
ata: constify of_device_id structures
Boris Brezillon (1):
pata: remove the at91 driver
Christoph Hellwig (2):
libata: reject passthrough WRITE SAME requests
libata: remove SCT WRITE SAME support
Geliang Tang (1):
libata: use setup_deferrable_timer
Jason Yan (1):
libata: make ata_sg_clean static over again
.../devicetree/bindings/ata/ahci-dm816.txt | 21 +
drivers/ata/Kconfig | 18 +-
drivers/ata/Makefile | 2 +-
drivers/ata/ahci_dm816.c | 200 ++++++++
drivers/ata/ahci_octeon.c | 5 -
drivers/ata/libata-core.c | 8 +-
drivers/ata/libata-scsi.c | 140 ++----
drivers/ata/pata_at91.c | 503 ---------------------
drivers/ata/pata_macio.c | 2 +-
drivers/ata/pata_mpc52xx.c | 2 +-
drivers/ata/pata_of_platform.c | 2 +-
drivers/ata/sata_fsl.c | 2 +-
drivers/ata/sata_mv.c | 2 +-
include/linux/ata.h | 5 -
14 files changed, 277 insertions(+), 635 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-dm816.txt
create mode 100644 drivers/ata/ahci_dm816.c
delete mode 100644 drivers/ata/pata_at91.c
--
tejun
^ permalink raw reply
* Re: SATA: Fine-tuning for two function implementations
From: SF Markus Elfring @ 2017-04-29 8:30 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Hans de Goede, LKML, kernel-janitors
In-Reply-To: <20170428215334.GH22354@htj.duckdns.org>
> Hmmm, allocs -> callocs. Are these actually beneficial? If so, why?
> Because one multiplication is rolled into the call?
Did the previous size calculations contain the general possibility for
integer overflows?
https://cwe.mitre.org/data/definitions/190.html
* Will the computed values usually stay within the limits of the used
data types so far?
* How much do you care for corresponding checks and source code annotations
by functions like “devm_kcalloc”?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] libata: remove SCT WRITE SAME support
From: Tejun Heo @ 2017-04-28 22:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide
In-Reply-To: <20170425122652.31763-1-hch@lst.de>
On Tue, Apr 25, 2017 at 02:26:52PM +0200, Christoph Hellwig wrote:
> This was already disabled a while ago because it caused I/O errors,
> and it's severly getting into the way of the discard / write zeroes
> rework.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Applied to libata/for-4.12.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] libata: reject passthrough WRITE SAME requests
From: Tejun Heo @ 2017-04-28 22:09 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, stable
In-Reply-To: <20170425113954.23121-1-hch@lst.de>
On Tue, Apr 25, 2017 at 01:39:54PM +0200, Christoph Hellwig wrote:
> The WRITE SAME to TRIM translation rewrites the DATA OUT buffer. While
> the SCSI code accomodates for this by passing a read-writable buffer
> userspace applications don't cater for this behavior. In fact it can
> be used to rewrite e.g. a readonly file through mmap and should be
> considered as a security fix.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
Applied to libata/for-4.12, assuming we aren't doing rc9.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations
From: Tejun Heo @ 2017-04-28 21:53 UTC (permalink / raw)
To: SF Markus Elfring; +Cc: linux-ide, Hans de Goede, LKML, kernel-janitors
In-Reply-To: <df754c7a-2100-7169-0d40-b981ccd952a1@users.sourceforge.net>
Hello,
On Tue, Apr 18, 2017 at 10:00:37PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Apr 2017 21:54:32 +0200
>
> A few update suggestions were taken into account
> from static source code analysis.
Hmmm, allocs -> callocs. Are these actually beneficial? If so, why?
Because one multiplication is rolled into the call?
Thanks.
--
tejun
^ permalink raw reply
* Re: PROBLEM: sil24: transfer errors causing data corruption or very low performance
From: Tejun Heo @ 2017-04-28 21:36 UTC (permalink / raw)
To: mtths; +Cc: linux-ide
In-Reply-To: <1605874.IPVSbxyx3P@c21>
Hello,
On Sat, Apr 22, 2017 at 05:33:56PM +0200, mtths@nurfuerspam.de wrote:
> A SATA PCI-controller card using the kernel module sata_sil24 has problems
> transferring big files.
>
>
> First of all a description of the situation:
>
> -- Hardware:
> - mainboard Gigabyte GA-MA69GM-S2H; chipset AMD 690G / SB600; 2 PCI slots
> (32 bit); 1 PCIe 4x slot; 1 PCIe 16 x slot; 8 GiB RAM; AMD Phenom(tm) II X4
> 955 Processor
> - SATA controller card Dawicontrol DC-3410 RAID, 32 bit PCI; chipset
> SiI3124ACBHU; BIOS message: running at 32 bit / 33 MHz
> - with hard disks: HDS721616PLA380 (twice), ST3000DM001-9YN166 (temporary)
> - q.v. attachment lspci; (dmidecode (v 3.0) finds no SMBIOS nor DMI entry
> point)
...
> 1st test setting:
> Reading from the disks to /dev/null with
> dd if=/dev/sde of=/dev/null bs=4k count=2304k
> one after the other. (Disk ST3000DM001 was temporarily directly connected to
> the card's external SATA port.)
> Result: After some MB, but before 470 MiB errors occurred:
> failed command: READ FPDMA QUEUED
> [cf. attachment dmesg]
> failed command: READ DMA
> [cf. attachment dmesg_tmpHD]
> The errors were reproducible - however, they started after different amounts
> of data.
>
> 2nd test setting:
> Using Debian's kernel and patching the driver to not use 64 bit DMA [cf.
> attachment sata_sil24.c.diff].
> Doing the same tests as above.
> Result: Repeatedly no errors occurred.
>
>
> N.B.: 1) There is a Windows Vista (32 bit) installation that uses two of the
> ports of the controller card as a fake RAID 1: There are no problems with the
> internal directly connected drives nor with an external drive.
> 2) Prior to this controller card there was a PCI Express card using SiI 3132,
> that - if I remember rightly - also had such problems, but they started after
> a greater amount of data. (At that time a Windows XP x64 installation had no
> problems, too.)
That's interesting, so you're seeing similar host bus errors whether
the controller is attached to PCI or PCIe.
The controller itself is known to be okay with 64bit addressing and
restricting it to 32bit addressing means that you'd be bouncing pages
(DMA to low pages and then copy using CPU), which slows down things a
bit. It could be that the slowing down in timing is what's helping,
not necessarily forcing 32bit DMA.
I don't know. Host bus errors are rarely reported and the controller
is definitely known to be okay with 64bit DMAs. Given this didn't get
reported at all in the haydays of SB600, it could actually be faulty
hardware.
I'm not sure what we can do at the moment.
Thanks.
--
tejun
^ permalink raw reply
* 56151 linux-ide
From: mitch_128 @ 2017-04-28 10:09 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 29159603466.zip --]
[-- Type: application/zip, Size: 2876 bytes --]
^ permalink raw reply
* 14306 linux-ide
From: obsexitos @ 2017-04-28 6:17 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 6.zip --]
[-- Type: application/zip, Size: 2805 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset
From: David Miller @ 2017-04-26 14:39 UTC (permalink / raw)
To: hch; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-4-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 26 Apr 2017 09:34:22 +0200
> The caller only looks at the scsi_request result field anyway.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all
From: David Miller @ 2017-04-26 14:39 UTC (permalink / raw)
To: hch; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-3-hch@lst.de>
From: Christoph Hellwig <hch@lst.de>
Date: Wed, 26 Apr 2017 09:34:21 +0200
> ide_pm_execute_rq exectures a PM request synchronously, and in the failure
> case where it calls __blk_end_request_all it never checks the error field
> passed to the end_io callback, so don't bother setting it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: three little req->errors follow ups
From: Jens Axboe @ 2017-04-26 13:54 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-1-hch@lst.de>
On 04/26/2017 12:34 AM, Christoph Hellwig wrote:
> While moving forward with the block error work I noticed three more
> places that pass non-errno values to the end_request variants, and
> never actually check those return values. This little series fixes
> those up to always pass 0.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset
From: Bartlomiej Zolnierkiewicz @ 2017-04-26 10:33 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-4-hch@lst.de>
On Wednesday, April 26, 2017 09:34:22 AM Christoph Hellwig wrote:
> The caller only looks at the scsi_request result field anyway.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all
From: Bartlomiej Zolnierkiewicz @ 2017-04-26 10:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: axboe, linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-3-hch@lst.de>
On Wednesday, April 26, 2017 09:34:21 AM Christoph Hellwig wrote:
> ide_pm_execute_rq exectures a PM request synchronously, and in the failure
> case where it calls __blk_end_request_all it never checks the error field
> passed to the end_io callback, so don't bother setting it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH 2/3] ide-pm: always pass 0 error to __blk_end_request_all
From: Christoph Hellwig @ 2017-04-26 7:34 UTC (permalink / raw)
To: axboe; +Cc: linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-1-hch@lst.de>
ide_pm_execute_rq exectures a PM request synchronously, and in the failure
case where it calls __blk_end_request_all it never checks the error field
passed to the end_io callback, so don't bother setting it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/ide/ide-pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/ide-pm.c b/drivers/ide/ide-pm.c
index 277c2bb7616f..0977fc1f40ce 100644
--- a/drivers/ide/ide-pm.c
+++ b/drivers/ide/ide-pm.c
@@ -57,7 +57,7 @@ static int ide_pm_execute_rq(struct request *rq)
if (unlikely(blk_queue_dying(q))) {
rq->rq_flags |= RQF_QUIET;
scsi_req(rq)->result = -ENXIO;
- __blk_end_request_all(rq, scsi_req(rq)->result);
+ __blk_end_request_all(rq, 0);
spin_unlock_irq(q->queue_lock);
return -ENXIO;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 3/3] ide-pm: always pass 0 error to ide_complete_rq in ide_do_devset
From: Christoph Hellwig @ 2017-04-26 7:34 UTC (permalink / raw)
To: axboe; +Cc: linux-ide, linux-scsi, linux-block
In-Reply-To: <20170426073422.14511-1-hch@lst.de>
The caller only looks at the scsi_request result field anyway.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
drivers/ide/ide-devsets.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ide/ide-devsets.c b/drivers/ide/ide-devsets.c
index b1223234037d..9b69c32ee560 100644
--- a/drivers/ide/ide-devsets.c
+++ b/drivers/ide/ide-devsets.c
@@ -187,6 +187,6 @@ ide_startstop_t ide_do_devset(ide_drive_t *drive, struct request *rq)
err = setfunc(drive, *(int *)&scsi_req(rq)->cmd[1]);
if (err)
scsi_req(rq)->result = err;
- ide_complete_rq(drive, err, blk_rq_bytes(rq));
+ ide_complete_rq(drive, 0, blk_rq_bytes(rq));
return ide_stopped;
}
--
2.11.0
^ permalink raw reply related
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