Linux ATA/IDE development
 help / color / mirror / Atom feed
* Re: [PATCH 1/1] libata: Fix ATA request sense
From: Sergei Shtylyov @ 2016-12-19 12:19 UTC (permalink / raw)
  To: Damien Le Moal, Tejun Heo; +Cc: linux-ide, Hannes Reinecke
In-Reply-To: <1482110260-14551-1-git-send-email-damien.lemoal@wdc.com>

Hello!

On 12/19/2016 4:17 AM, Damien Le Moal wrote:

> For an ATA device supporting the sense data reporting feature set,
> a failed command will trigger the execution of ata_eh_request_sense if
> the result task file of the failed command has the ATA_SENSE bit set
> (sense data available bit). ata_eh_request_sense executes the
> REQUEST SENSE DATA EXT command to retrieve the sense data of the failed
> command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
> NOT be set (the command succeeded) but ata_eh_request_sense
> nevertheless tests the availability of sense data by testing that bit
> presence in the result tf of the REQUEST SENSE DATA EXT command.
> This leads to a falsy assume that request sense data failed and to the

    False assumption?

> warning message:
>
> atax.xx: request sense failed stat 50 emask 0
>
> Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
> result task file command so that sense data can be returned by
> ata_eh_request_sense.
>
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
[...]

MBR, Sergei


^ permalink raw reply

* Re: [PATCH 1/1] libata: Fix ATA request sense
From: Hannes Reinecke @ 2016-12-19  7:01 UTC (permalink / raw)
  To: Damien Le Moal, Tejun Heo; +Cc: linux-ide
In-Reply-To: <1482110260-14551-1-git-send-email-damien.lemoal@wdc.com>

On 12/19/2016 02:17 AM, Damien Le Moal wrote:
> For an ATA device supporting the sense data reporting feature set,
> a failed command will trigger the execution of ata_eh_request_sense if
> the result task file of the failed command has the ATA_SENSE bit set
> (sense data available bit). ata_eh_request_sense executes the
> REQUEST SENSE DATA EXT command to retrieve the sense data of the failed
> command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
> NOT be set (the command succeeded) but ata_eh_request_sense
> nevertheless tests the availability of sense data by testing that bit
> presence in the result tf of the REQUEST SENSE DATA EXT command.
> This leads to a falsy assume that request sense data failed and to the
> warning message:
> 
> atax.xx: request sense failed stat 50 emask 0
> 
> Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
> result task file command so that sense data can be returned by
> ata_eh_request_sense.
> 
> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
> ---
>  drivers/ata/libata-core.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 9cd0a2d..366a380 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -1702,6 +1702,8 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
>  
>  		if (qc->err_mask & ~AC_ERR_OTHER)
>  			qc->err_mask &= ~AC_ERR_OTHER;
> +	} else if (qc->tf.command == ATA_CMD_REQ_SENSE_DATA) {
> +		qc->result_tf.command |= ATA_SENSE;
>  	}
>  
>  	/* finish up */
> 
D'oh.

Of course.

Reviewed-by: Hannes Reinecke <hare@suse.com>

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

^ permalink raw reply

* [PATCH 1/1] libata: Fix ATA request sense
From: Damien Le Moal @ 2016-12-19  1:17 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-ide, Hannes Reinecke, Damien Le Moal

For an ATA device supporting the sense data reporting feature set,
a failed command will trigger the execution of ata_eh_request_sense if
the result task file of the failed command has the ATA_SENSE bit set
(sense data available bit). ata_eh_request_sense executes the
REQUEST SENSE DATA EXT command to retrieve the sense data of the failed
command. On success of REQUEST SENSE DATA EXT, the ATA_SENSE bit will
NOT be set (the command succeeded) but ata_eh_request_sense
nevertheless tests the availability of sense data by testing that bit
presence in the result tf of the REQUEST SENSE DATA EXT command.
This leads to a falsy assume that request sense data failed and to the
warning message:

atax.xx: request sense failed stat 50 emask 0

Upon success of REQUEST SENSE DATA EXT, set the ATA_SENSE bit in the
result task file command so that sense data can be returned by
ata_eh_request_sense.

Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
---
 drivers/ata/libata-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 9cd0a2d..366a380 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1702,6 +1702,8 @@ unsigned ata_exec_internal_sg(struct ata_device *dev,
 
 		if (qc->err_mask & ~AC_ERR_OTHER)
 			qc->err_mask &= ~AC_ERR_OTHER;
+	} else if (qc->tf.command == ATA_CMD_REQ_SENSE_DATA) {
+		qc->result_tf.command |= ATA_SENSE;
 	}
 
 	/* finish up */
-- 
2.7.4


^ permalink raw reply related

* Errors on Marvell
From: Emilio Lazo Zaia @ 2016-12-14 21:00 UTC (permalink / raw)
  To: tj; +Cc: linux-ide

Hello!

I have a 4xSATA PCI-E card (SYBA brand, Marvell chipset) which behaves
bad on some circumstances that aren't clear to me, so I call that
behavior random.

My mobo is a Gigabyte GA-A75-UD4H/GA-A75-UD4H. The problem consists in
the quoted errors/debug info. I can't write DVD and sometimes
reading/writing to hard disks is slow.

I've disabled the Native Command Queue via kernel parameters
(libata.force=noncq); also I've lowered the speed of all ATA controllers
to 1,5Gbps. There is no difference. The issue persists.

--- lspci -v:

01:00.0 SATA controller: Marvell Technology Group Ltd. Device 9215 (rev
11) (prog-if 01 [AHCI 1.0])
        Subsystem: Marvell Technology Group Ltd. Device 9215
        Flags: bus master, fast devsel, latency 0, IRQ 38
        I/O ports at bf00 [size=8]
        I/O ports at be00 [size=4]
        I/O ports at bd00 [size=8]
        I/O ports at bc00 [size=4]
        I/O ports at bb00 [size=32]
        Memory at fdbff000 (32-bit, non-prefetchable) [size=2K]
        [virtual] Expansion ROM at fdb00000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [70] Express Legacy Endpoint, MSI 00
        Capabilities: [e0] SATA HBA v0.0
        Capabilities: [100] Advanced Error Reporting
        Kernel driver in use: ahci
        Kernel modules: ahci

---

I don't have more options to test. Do you have one? If I can help
improving something I'll do whatever steps necessary to provide debug
information to the kernel developers regarding this problem.

Kind regards

Emilio.


--- dmesg info

[434967.722795] ata9: exception Emask 0x10 SAct 0x0 SErr 0x4050000
action 0xe frozen
[434967.722807] ata9: irq_stat 0x80400040, connection status changed
[434967.722815] ata9: SError: { PHYRdyChg CommWake DevExch }
[434967.722827] ata9: hard resetting link
[434969.192373] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[434969.193014] ata9.00: FORCE: horkage modified (noncq)
[434969.215990] ata9.00: ATA-7: WDC WD3200AAJS-22RYA0, 12.01B01, max
UDMA/133
[434969.215997] ata9.00: 625142448 sectors, multi 0: LBA48 NCQ (not used)
[434969.216882] ata9.00: configured for UDMA/133
[434969.216903] ata9: EH complete
[434970.126924] ata9: exception Emask 0x10 SAct 0x0 SErr 0x190002 action
0xe frozen
[434970.126934] ata9: irq_stat 0x80400000, PHY RDY changed
[434970.126940] ata9: SError: { RecovComm PHYRdyChg 10B8B Dispar }
[434970.126949] ata9: hard resetting link
[434970.836345] ata9: SATA link down (SStatus 0 SControl 300)
[434970.916242] ata9: hard resetting link
[434974.892261] ata9: SATA link down (SStatus 0 SControl 300)
[434974.892269] ata9.00: link offline, clearing class 1 to NONE
[434974.892277] ata9: limiting SATA link speed to 1.5 Gbps
[434975.320012] ata9: hard resetting link
[434977.432186] ata9: SATA link down (SStatus 0 SControl 310)
[434977.432194] ata9.00: link offline, clearing class 1 to NONE
[434977.432201] ata9.00: disabled
[434977.432226] ata9: EH complete
[434977.432327] ata9.00: detaching (SCSI 8:0:0:0)
[434977.898235] ata9: exception Emask 0x10 SAct 0x0 SErr 0x4000000
action 0xe frozen
[434977.898248] ata9: irq_stat 0x80000040, connection status changed
[434977.898255] ata9: SError: { DevExch }
[434977.898267] ata9: hard resetting link
[434983.748063] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[434983.748703] ata9.00: FORCE: horkage modified (noncq)
[434983.771571] ata9.00: ATA-7: WDC WD3200AAJS-22RYA0, 12.01B01, max
UDMA/133
[434983.771579] ata9.00: 625142448 sectors, multi 0: LBA48 NCQ (not used)
[434983.772480] ata9.00: configured for UDMA/133
[434983.772501] ata9: EH complete
[435061.615367] ata9: exception Emask 0x10 SAct 0x0 SErr 0x190002 action
0xe frozen
[435061.615378] ata9: irq_stat 0x80400000, PHY RDY changed
[435061.615386] ata9: SError: { RecovComm PHYRdyChg 10B8B Dispar }
[435061.615396] ata9: hard resetting link
[435062.326353] ata9: SATA link down (SStatus 0 SControl 300)
[435067.386234] ata9: hard resetting link
[435067.702284] ata9: SATA link down (SStatus 0 SControl 300)
[435067.702297] ata9: limiting SATA link speed to 1.5 Gbps
[435072.762107] ata9: hard resetting link
[435073.078040] ata9: SATA link down (SStatus 0 SControl 310)
[435073.078052] ata9.00: disabled
[435073.078078] ata9: EH complete
[435073.078105] ata9.00: detaching (SCSI 8:0:0:0)
[435101.716072] ata8: exception Emask 0x10 SAct 0x0 SErr 0x4050000
action 0xe frozen
[435101.716084] ata8: irq_stat 0x80400040, connection status changed
[435101.716091] ata8: SError: { PHYRdyChg CommWake DevExch }
[435101.716104] ata8: hard resetting link
[435102.585464] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[435102.586086] ata8.00: FORCE: horkage modified (noncq)
[435102.607691] ata8.00: ATA-7: WDC WD3200AAJS-22RYA0, 12.01B01, max
UDMA/133
[435102.607699] ata8.00: 625142448 sectors, multi 0: LBA48 NCQ (not used)
[435102.608621] ata8.00: configured for UDMA/133
[435102.608642] ata8: EH complete
[435205.123301] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action
0x6 frozen
[435205.123328] ata7.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 24
pio 16388 in
[435205.123335] ata7.00: status: { DRDY }
[435205.123342] ata7: hard resetting link
[435205.599244] ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[435205.605549] ata7.00: configured for UDMA/100
[435205.607873] ata7: EH complete
[435471.690523] ata8: exception Emask 0x10 SAct 0x0 SErr 0x190002 action
0xe frozen
[435471.690534] ata8: irq_stat 0x80400000, PHY RDY changed
[435471.690542] ata8: SError: { RecovComm PHYRdyChg 10B8B Dispar }
[435471.690552] ata8: hard resetting link
[435472.401447] ata8: SATA link down (SStatus 0 SControl 300)
[435477.489306] ata8: hard resetting link
[435477.805479] ata8: SATA link down (SStatus 0 SControl 300)
[435477.805492] ata8: limiting SATA link speed to 1.5 Gbps
[435482.865194] ata8: hard resetting link
[435483.181208] ata8: SATA link down (SStatus 0 SControl 310)
[435483.181216] ata8.00: disabled
[435483.181240] ata8: EH complete
[435483.181310] ata8.00: detaching (SCSI 7:0:0:0)
[435484.957529] ata9: exception Emask 0x10 SAct 0x0 SErr 0x4040000
action 0xe frozen
[435484.957541] ata9: irq_stat 0x80000040, connection status changed
[435484.957548] ata9: SError: { CommWake DevExch }
[435484.957560] ata9: hard resetting link
[435485.829144] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[435485.829757] ata9.00: FORCE: horkage modified (noncq)
[435485.852091] ata9.00: ATA-7: WDC WD3200AAJS-22RYA0, 12.01B01, max
UDMA/133
[435485.852097] ata9.00: 625142448 sectors, multi 0: LBA48 NCQ (not used)
[435485.852972] ata9.00: configured for UDMA/133
[435485.853104] ata9: EH complete
[435491.987610] ata9: exception Emask 0x10 SAct 0x0 SErr 0x190002 action
0xe frozen
[435491.987622] ata9: irq_stat 0x80400000, PHY RDY changed
[435491.987629] ata9: SError: { RecovComm PHYRdyChg 10B8B Dispar }
[435491.987639] ata9: hard resetting link
[435492.696998] ata9: SATA link down (SStatus 0 SControl 300)
[435497.712883] ata9: hard resetting link
[435498.028521] ata9: SATA link down (SStatus 0 SControl 300)
[435498.028534] ata9: limiting SATA link speed to 1.5 Gbps
[435503.088781] ata9: hard resetting link
[435503.404705] ata9: SATA link down (SStatus 0 SControl 310)
[435503.404717] ata9.00: disabled
[435503.404744] ata9: EH complete
[435503.404862] ata9.00: detaching (SCSI 8:0:0:0)


^ permalink raw reply

* (unknown), 
From: robert.berry @ 2016-12-14 13:00 UTC (permalink / raw)
  To: linux-ide

[-- Attachment #1: MICROSOFT_06124793158_linux-ide.zip --]
[-- Type: application/zip, Size: 16553 bytes --]

^ permalink raw reply

* (unknown), 
From: Mr Friedrich Mayrhofer @ 2016-12-14  2:45 UTC (permalink / raw)



Good Day,

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me
personally for more details.

Regards.
Friedrich Mayrhofer







^ permalink raw reply

* [GIT PULL UPDATED] libata changes for v4.10-rc1
From: Tejun Heo @ 2016-12-13 22:24 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-ide, linux-kernel
In-Reply-To: <20161212183209.GE13864@htj.duckdns.org>

Hello,

One more patch from Adam added.  It makes libata skip probing for NCQ
prio unless the feature is explicitly requested by the user.  This is
necessary because some controllers lock up after the optional feature
is probed.

* Adam added opt-in ATA command priority support.

* There are machines which hide multiple nvme devices behind an ahci
  BAR.  Dan Williams proposed a solution to force-switch the mode but
  deemed too hackishd.  People are gonna discuss the proper way to
  handle the situation in nvme standard meetings.  For now, detect and
  warn about the situation.

* Low level driver specific changes.

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.10

for you to fetch changes up to 9f56eca3aeeab699a7dbfb397661d2eca4430e94:

  ata: avoid probing NCQ Prio Support if not explicitly requested (2016-12-13 17:20:17 -0500)

----------------------------------------------------------------
Adam Manzanares (5):
      block: Add iocontext priority to request
      ata: Enabling ATA Command Priorities
      ata: ATA Command Priority Disabled By Default
      ata: set ncq_prio_enabled iff device has support
      ata: avoid probing NCQ Prio Support if not explicitly requested

Christoph Hellwig (2):
      nvme: move NVMe class code to pci_ids.h
      ahci: warn about remapped NVMe devices

Dan Williams (1):
      ahci-remap.h: add ahci remapping definitions

Tang Yuantian (1):
      ahci: qoriq: added ls1046a platform support

Vladimir Zapolskiy (4):
      pata: imx: sort headers out
      pata: imx: set controller PIO mode with .set_piomode callback
      pata: imx: add support of setting timings for PIO modes
      pata: imx: support controller modes up to PIO4

 block/blk-core.c           |  4 ++-
 drivers/ata/ahci.c         | 39 +++++++++++++++++++++
 drivers/ata/ahci_qoriq.c   | 16 +++++++--
 drivers/ata/libahci.c      |  1 +
 drivers/ata/libata-core.c  | 42 ++++++++++++++++++++++-
 drivers/ata/libata-scsi.c  | 84 +++++++++++++++++++++++++++++++++++++++++++++-
 drivers/ata/libata.h       |  2 +-
 drivers/ata/pata_imx.c     | 82 ++++++++++++++++++++++++++++++--------------
 drivers/nvme/host/pci.c    |  3 --
 include/linux/ahci-remap.h | 28 ++++++++++++++++
 include/linux/ata.h        |  6 ++++
 include/linux/blkdev.h     | 14 ++++++++
 include/linux/libata.h     |  5 +++
 include/linux/pci_ids.h    |  2 ++
 14 files changed, 293 insertions(+), 35 deletions(-)
 create mode 100644 include/linux/ahci-remap.h

^ permalink raw reply

* DO YOU NEED A LOAN??
From: bancoleite @ 2016-12-13  5:27 UTC (permalink / raw)
  To: Recipients

Are you in need of a loan? Apply for more details.

^ permalink raw reply

* Re: [GIT PULL] libata changes for v4.10-rc1
From: Tejun Heo @ 2016-12-12 19:27 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Linus Torvalds, linux-ide, linux-kernel
In-Reply-To: <20161212190402.GA8592@infradead.org>

On Mon, Dec 12, 2016 at 11:04:02AM -0800, Christoph Hellwig wrote:
> I wish that was the case.  We've pretty much agreed that we'll want
> to implement it as a virtual PCIe root bridge, similar to Intels other
> "innovation" VMD that we work around that way.  But Intel management
> has apparently decided that they don't want to spend more cycles on
> this now that Lenovo has an optional BIOS that doesn't force this
> broken mode anymore, and no one outside of Intel has enough information
> to implement something like this.
> 
> So for now I guess this warning is it, until Intel reconsideres and
> spends resources on fixing up the damage their Chipset people caused.

Dang, ah well, this is it then.

Thanks for explaining the situation.

-- 
tejun

^ permalink raw reply

* Re: [GIT PULL] libata changes for v4.10-rc1
From: Christoph Hellwig @ 2016-12-12 19:04 UTC (permalink / raw)
  To: Tejun Heo; +Cc: Linus Torvalds, linux-ide, linux-kernel
In-Reply-To: <20161212183209.GE13864@htj.duckdns.org>

On Mon, Dec 12, 2016 at 01:32:09PM -0500, Tejun Heo wrote:
> Hello, Linus.
> 
> * Adam added opt-in ATA command priority support.
> 
> * There are machines which hide multiple nvme devices behind an ahci
>   BAR.  Dan Williams proposed a solution to force-switch the mode but
>   deemed too hackishd.  People are gonna discuss the proper way to
>   handle the situation in nvme standard meetings.  For now, detect and
>   warn about the situation.

I wish that was the case.  We've pretty much agreed that we'll want
to implement it as a virtual PCIe root bridge, similar to Intels other
"innovation" VMD that we work around that way.  But Intel management
has apparently decided that they don't want to spend more cycles on
this now that Lenovo has an optional BIOS that doesn't force this
broken mode anymore, and no one outside of Intel has enough information
to implement something like this.

So for now I guess this warning is it, until Intel reconsideres and
spends resources on fixing up the damage their Chipset people caused.

^ permalink raw reply

* [GIT PULL] libata changes for v4.10-rc1
From: Tejun Heo @ 2016-12-12 18:32 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-ide, linux-kernel

Hello, Linus.

* Adam added opt-in ATA command priority support.

* There are machines which hide multiple nvme devices behind an ahci
  BAR.  Dan Williams proposed a solution to force-switch the mode but
  deemed too hackishd.  People are gonna discuss the proper way to
  handle the situation in nvme standard meetings.  For now, detect and
  warn about the situation.

* Low level driver specific changes.

Thanks.

The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:

  Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.10

for you to fetch changes up to aecec8b60422118b52e3347430ba9382e57d6d76:

  ahci: warn about remapped NVMe devices (2016-12-05 14:31:24 -0500)

----------------------------------------------------------------
Adam Manzanares (4):
      block: Add iocontext priority to request
      ata: Enabling ATA Command Priorities
      ata: ATA Command Priority Disabled By Default
      ata: set ncq_prio_enabled iff device has support

Christoph Hellwig (2):
      nvme: move NVMe class code to pci_ids.h
      ahci: warn about remapped NVMe devices

Dan Williams (1):
      ahci-remap.h: add ahci remapping definitions

Tang Yuantian (1):
      ahci: qoriq: added ls1046a platform support

Vladimir Zapolskiy (4):
      pata: imx: sort headers out
      pata: imx: set controller PIO mode with .set_piomode callback
      pata: imx: add support of setting timings for PIO modes
      pata: imx: support controller modes up to PIO4

 block/blk-core.c           |  4 ++-
 drivers/ata/ahci.c         | 39 ++++++++++++++++++++++
 drivers/ata/ahci_qoriq.c   | 16 +++++++--
 drivers/ata/libahci.c      |  1 +
 drivers/ata/libata-core.c  | 35 +++++++++++++++++++-
 drivers/ata/libata-scsi.c  | 80 +++++++++++++++++++++++++++++++++++++++++++-
 drivers/ata/libata.h       |  2 +-
 drivers/ata/pata_imx.c     | 82 ++++++++++++++++++++++++++++++++--------------
 drivers/nvme/host/pci.c    |  3 --
 include/linux/ahci-remap.h | 28 ++++++++++++++++
 include/linux/ata.h        |  6 ++++
 include/linux/blkdev.h     | 14 ++++++++
 include/linux/libata.h     |  5 +++
 include/linux/pci_ids.h    |  2 ++
 14 files changed, 282 insertions(+), 35 deletions(-)
 create mode 100644 include/linux/ahci-remap.h

^ permalink raw reply

* [V1] ata: sata_mv:- Handle return value of devm_ioremap.
From: Arvind Yadav @ 2016-12-12 17:43 UTC (permalink / raw)
  To: tj; +Cc: linux-ide, linux-kernel

Here, If devm_ioremap will fail. It will return NULL.
Then hpriv->base = NULL - 0x20000; Kernel can run into
a NULL-pointer dereference. This error check will avoid
NULL pointer dereference.

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
---
 drivers/ata/sata_mv.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index efc48bf..9d0cdad 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -4119,6 +4119,9 @@ static int mv_platform_probe(struct platform_device *pdev)
 	host->iomap = NULL;
 	hpriv->base = devm_ioremap(&pdev->dev, res->start,
 				   resource_size(res));
+	if (!hpriv->base)
+		return -ENOMEM;
+
 	hpriv->base -= SATAHC0_REG_BASE;
 
 	hpriv->clk = clk_get(&pdev->dev, NULL);
-- 
2.7.4


^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Tejun Heo @ 2016-12-12 17:01 UTC (permalink / raw)
  To: whiteheadm; +Cc: One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_becq+h2=-g7t-6Pp1psmkCCvdB0YUcg+wYPocUP4dYdw@mail.gmail.com>

Hello,

On Fri, Dec 09, 2016 at 12:57:02PM -0500, tedheadster wrote:
> ​Tejun,
>   here is the patch I applied:
> 
> diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
> index 4fe9d21..5c6c578 100644
> --- a/drivers/ata/pata_legacy.c
> +++ b/drivers/ata/pata_legacy.c
> @@ -963,6 +963,9 @@ static __init int legacy_init_one(struct legacy_probe
> *probe)
>         if (IS_ERR(pdev))
>                 return PTR_ERR(pdev);
> 
> +       if (!devres_open_group(&pdev->dev, legacy_init_one, GFP_KERNEL))
> +               return -ENOMEM;

Can you please drop the explicit group open/remove/release?

>         ret = -EBUSY;
>         if (devm_request_region(&pdev->dev, io, 8, "pata_legacy") == NULL ||
>             devm_request_region(&pdev->dev, io + 0x0206, 1,
> @@ -1009,11 +1012,14 @@ static __init int legacy_init_one(struct
> legacy_probe *probe)
>                 if (!ata_dev_absent(dev)) {
>                         legacy_host[probe->slot] = host;
>                         ld->platform_dev = pdev;
> +                       devres_remove_group(&pdev->dev, legacy_init_one);
>                         return 0;
>                 }
>         }
>         ata_host_detach(host);
>  fail:
> +       devres_release_group(&pdev->dev, legacy_init_one);
> +       printk("XXX pata_legacy: unregistering platform dev %p\n", pdev);
>         platform_device_unregister(pdev);

So, the thing is that when the platform device is released here, it
should automatically trigger release of all resources attached to it
through...

>         return ret;
>  }
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index a235085..8e8948e 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -214,6 +214,7 @@ static void device_release(struct kobject *kobj)
>          * is deleted but alive, so release devres here to avoid
>          * possible memory leak.
>          */
> +       printk("XXX device_release: invoking devres_release_all\n");
>         devres_release_all(dev);

the devres_release_all() call here.

Can you please try to verify that devres_release_all() is being
invoked from platform device release?  I'll try to see if I can repro
the problem here.

thanks.

-- 
tejun

^ permalink raw reply

* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Sekhar Nori @ 2016-12-12 13:54 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Kevin Hilman, Arnd Bergmann, linux-arm-kernel, Russell King,
	Dmitry Eremin-Solenikov, linux-kernel, linux-ide, Olof Johansson
In-Reply-To: <5370936.ZbqF1HU8Jz@amdc3058>

Hi Bartlomiej,

On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
>> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>
>>>> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
>>>>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
>>>>>>> (no IDE host drivers are selected in this config so there is no
>>>>>>> valid reason to enable IDE subsystem itself).
>>>>>>>
>>>>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>
>>>>>> I think the series makes a lot of sense. I have checked your assertions
>>>>>> in the changelogs and found no flaws in your logic, so I think we should
>>>>>> take them all through arm-soc unless there are other concerns.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Should I resend everything or just patches that were not reposted yet
>>>>> (the ones that were marked as RFT initially and got no feedback)?
>>>>
>>>> I'd be fine with just getting a pull request with all the patches that
>>>> had no negative feedback and that were not already applied (if any).
>>>>
>>>>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
>>>>>> how you determined that they need it?
>>>>>
>>>>> The only such defconfig is davinci_all_defconfig which uses
>>>>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
>>>>>
>>>>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
>>>>>> have no libata replacement, are there any others like that, or are
>>>>>> they all platforms that should in theory work with libata but need
>>>>>> testing?
>>>>>
>>>>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
>>>>> with libata.
>>>>
>>>> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
>>>> fairly straightforward (meaning someone has to do a few day's work)
>>>> to convert into a libata driver.
>>>>
>>>> As this is on on-chip controller that is part of a dm644x and dm646x,
>>>> it should also not be hard to test (as long as someone can find
>>>> a hard drive to plug in).
>>>
>>> I have a hard drive, but don't have any dm64xx hardware anymore to test
>>> this.  My last working dm644x board died last year.
>>
>> I have a working DM6446 EVM. I was able to connect a hard drive to it
>> and do some basic tests with v4.6 kernel.
>>
>> I will look into converting the driver to libata. Might take some time
>> because this is unfamiliar territory for me.
> 
> Do you need some help with it?
> 
> I can provide you with draft driver patch if you want.

A draft driver patch will really help. I can test/debug. Otherwise, not
sure when I will really be able to get to this.

Regards,
Sekhar

^ permalink raw reply

* Re: [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:45 UTC (permalink / raw)
  To: Sekhar Nori
  Cc: Russell King, Arnd Bergmann, Dmitry Eremin-Solenikov,
	Kevin Hilman, linux-kernel, linux-ide, Olof Johansson,
	linux-arm-kernel
In-Reply-To: <578CEB74.2080002@ti.com>


Hi,

On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> > 
> >> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>
> >>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> >>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> >>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
> >>>>> (no IDE host drivers are selected in this config so there is no
> >>>>> valid reason to enable IDE subsystem itself).
> >>>>>
> >>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> >>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>>>
> >>>> I think the series makes a lot of sense. I have checked your assertions
> >>>> in the changelogs and found no flaws in your logic, so I think we should
> >>>> take them all through arm-soc unless there are other concerns.
> >>>
> >>> Thank you.
> >>>
> >>> Should I resend everything or just patches that were not reposted yet
> >>> (the ones that were marked as RFT initially and got no feedback)?
> >>
> >> I'd be fine with just getting a pull request with all the patches that
> >> had no negative feedback and that were not already applied (if any).
> >>
> >>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
> >>>> how you determined that they need it?
> >>>
> >>> The only such defconfig is davinci_all_defconfig which uses
> >>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
> >>>
> >>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
> >>>> have no libata replacement, are there any others like that, or are
> >>>> they all platforms that should in theory work with libata but need
> >>>> testing?
> >>>
> >>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
> >>> with libata.
> >>
> >> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
> >> fairly straightforward (meaning someone has to do a few day's work)
> >> to convert into a libata driver.
> >>
> >> As this is on on-chip controller that is part of a dm644x and dm646x,
> >> it should also not be hard to test (as long as someone can find
> >> a hard drive to plug in).
> > 
> > I have a hard drive, but don't have any dm64xx hardware anymore to test
> > this.  My last working dm644x board died last year.
> 
> I have a working DM6446 EVM. I was able to connect a hard drive to it
> and do some basic tests with v4.6 kernel.
> 
> I will look into converting the driver to libata. Might take some time
> because this is unfamiliar territory for me.

Do you need some help with it?

I can provide you with draft driver patch if you want.

I'm also on #kernel IRC channel in case you have some questions..

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

^ permalink raw reply

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 12:21 UTC (permalink / raw)
  To: whiteheadm; +Cc: Tejun Heo, One Thousand Gnomes, Sergei Shtylyov, linux-ide
In-Reply-To: <CAP8WD_bUW9cAAQpvenL73sxvpoxNYwZdRqpj92YWEyanK51+0g@mail.gmail.com>


Hi,

On Monday, December 05, 2016 09:19:35 AM tedheadster wrote:
> Tejun,
>   that new patch worked better.
> 
> Here is the dmesg output:
> 
> [   34.347350] scsi0 : pata_legacy
> [   34.367366] ata1: PATA max PIO4 cmd 0x1f0 ctl 0x3f6 irq 14
> [   34.523330] ata1.00: ATA-4: QUANTUM FIREBALL CR8.4A, A5U.1200, max UDMA/66
> [   34.524804] ata1.00: 16514064 sectors, multi 0: LBA
> [   34.525747] ata1.00: configured for PIO
> [   34.569330] scsi 0:0:0:0: Direct-Access     ATA      QUANTUM
> FIREBALL A5U. PQ: 0 ANSI: 5
> [   34.655313] sd 0:0:0:0: [sda] 16514064 512-byte logical blocks:
> (8.45 GB/7.87 GiB)
> [   34.674309] sd 0:0:0:0: [sda] Write Protect is off
> [   34.675683] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [   34.689347] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [   34.691283] sd 0:0:0:0: Attached scsi generic sg0 type 0
> [   34.800293]  sda: sda1 sda2 sda3 sda4
> [   34.890325] sd 0:0:0:0: [sda] Attached SCSI disk
> [   34.976270] scsi1 : pata_legacy
> [   34.999263] ata2: PATA max PIO4 cmd 0x170 ctl 0x376 irq 15
> [   35.448191] scsi2 : pata_legacy
> [   35.486192] ata3: PATA max PIO4 cmd 0x1e8 ctl 0x3ee irq 11
> [   35.997114] scsi3 : pata_legacy
> [   36.051103] ata4: PATA max PIO4 cmd 0x168 ctl 0x36e irq 10
> [   36.384057] genirq: Flags mismatch irq 8. 00000000 (platform) vs.
> 00000000 (rtc0)
> [   36.571024] scsi4 : pata_legacy
> [   36.626014] ata5: PATA max PIO4 cmd 0x160 ctl 0x366 irq 12
> [   42.143223] EXT4-fs (sda4): mounting ext3 file system using the
> ext4 subsystem
> 
> and /proc/interrupts looks good:
> 
>            CPU0
>   0:     558552    XT-PIC-XT-PIC    timer
>   1:        337    XT-PIC-XT-PIC    i8042
>   2:          0    XT-PIC-XT-PIC    cascade
>   4:          1    XT-PIC-XT-PIC
>   8:          0    XT-PIC-XT-PIC    rtc0
>  14:      51538    XT-PIC-XT-PIC    platform

Thank you for testing.

Tejun, is this information sufficient to fix the issue or do you still
want Matthew to test your last debug patch?

[ http://marc.info/?l=linux-ide&m=148096582017930&w=2 ]

> I would still like to get my patch in. If you have a motherboard where
> you cannot disable the secondary hard drive controllers, the
> pata_legacy driver will detect them and allocate the interrupt. Some

If there are no devices attached to the controller, the driver will
free the resources so I don't quite get what would be the issue here.
Could you please explain it more?

> way to disable this behavior is useful.
> 
> - Matthew

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


^ permalink raw reply

* [GIT PULL] libata fixes for v4.9-rc8
From: Tejun Heo @ 2016-12-09 14:22 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, linux-ide

Hello, Linus.

This is quite late but SCT Write Same support added during this cycle
is broken subtly but seriously and it'd be best to disable it before
v4.9 gets released.

This pull request contains two commits - one low impact sata_mv fix
and the mentioned disabling of SCT Write Same.

Thanks.

The following changes since commit 6929ef385e09c0065b87fda3e7b872a5070ac783:

  ahci: always fall back to single-MSI mode (2016-11-21 11:06:57 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.9-fixes

for you to fetch changes up to e185934ff94466b4a449165e5f1c164a44d005f2:

  libata-scsi: disable SCT Write Same for the moment (2016-12-07 16:29:09 -0500)

----------------------------------------------------------------
Nicolai Stange (1):
      libata-scsi: disable SCT Write Same for the moment

Uwe Kleine-König (1):
      ata: sata_mv: check for errors when parsing nr-ports from dt

 drivers/ata/libata-scsi.c |  1 +
 drivers/ata/sata_mv.c     | 15 ++++++++++++++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index c4eb4ae..8e575fb 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1159,6 +1159,7 @@ static void ata_scsi_sdev_config(struct scsi_device *sdev)
 {
 	sdev->use_10_for_rw = 1;
 	sdev->use_10_for_ms = 1;
+	sdev->no_write_same = 1;
 
 	/* Schedule policy is determined by ->qc_defer() callback and
 	 * it needs to see every deferred qc.  Set dev_blocked to 1 to
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index efc48bf..823e938 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -4090,7 +4090,20 @@ static int mv_platform_probe(struct platform_device *pdev)
 
 	/* allocate host */
 	if (pdev->dev.of_node) {
-		of_property_read_u32(pdev->dev.of_node, "nr-ports", &n_ports);
+		rc = of_property_read_u32(pdev->dev.of_node, "nr-ports",
+					   &n_ports);
+		if (rc) {
+			dev_err(&pdev->dev,
+				"error parsing nr-ports property: %d\n", rc);
+			return rc;
+		}
+
+		if (n_ports <= 0) {
+			dev_err(&pdev->dev, "nr-ports must be positive: %d\n",
+				n_ports);
+			return -EINVAL;
+		}
+
 		irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
 	} else {
 		mv_platform_data = dev_get_platdata(&pdev->dev);


^ permalink raw reply related

* Re: [RFC PATCH 00/19] ide: remove deprecated host drivers (part 1)
From: David Miller @ 2016-12-08 17:58 UTC (permalink / raw)
  To: b.zolnierkie; +Cc: linux-ide, linux-kernel, tj, gnomes, sergei.shtylyov
In-Reply-To: <1861504.e0fxpIs7Qv@amdc3058>

From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date: Thu, 08 Dec 2016 18:14:33 +0100

> I asked you about this in private mail in August 2015, you told me to
> bring this on the list.  I did it (with these patches) in February
> 2016.  After two pings and months of waiting for a reply all I get is
> is a quick NAK?

Yep, that's how much effort, consideration, and time a deprecated
subsystem deserves.

^ permalink raw reply

* Re: [RFC PATCH 00/19] ide: remove deprecated host drivers (part 1)
From: Bartlomiej Zolnierkiewicz @ 2016-12-08 17:14 UTC (permalink / raw)
  To: David Miller; +Cc: linux-ide, linux-kernel, tj, gnomes, sergei.shtylyov
In-Reply-To: <20161208.113957.686350007074631834.davem@davemloft.net>

On Thursday, December 08, 2016 11:39:57 AM David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Date: Thu, 08 Dec 2016 17:15:16 +0100
> 
> > On Thursday, December 08, 2016 10:23:08 AM David Miller wrote:
> >> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >> Date: Thu, 08 Dec 2016 14:42:12 +0100
> >> 
> >> > Ping.. since there was no negative (or any other) feedback I think that
> >> > this can be put into -next for some wider exposure..
> >> 
> >> I'm not going to apply this and break things on people, sorry.
> > 
> > People building their own kernels with their own kernel config files
> > and still using IDE drivers (deprecated in 2009 BTW) will have to
> > update their setups to libata but otherwise nothing is supposed to
> > break.  So could you please explain in more detail what do you mean
> > by "break things on people"?
> 
> There is no proof that the PATA drivers work %100 reliably as well as
> the IDE driver they replace for every possible chip and architecture.

This is why only some IDE host drivers were nominated for removal.

Please see cover-letter and patch descriptions for details.

> Therefore the only safe thing is to keep the IDE drivers around
> forever.

Uh...

> They are not a maintainence burdon, I rarely get more than 1 patch
> each merge window and most of the time those are cleanups or for the
> handling of a kernel wide API change rather than bug fixes.

In the long-term perspective having two drivers for the same hardware
is not good for the whole kernel as:

- testing efforts are divided (while number of PATA systems goes down)

- bugs/missing features in the new subsystem are not getting reported
  and fixed (since it is easier to just switch back to the old stack)

- having duplicated support for the same hardware confuses users

I was hoping for incremental removal of IDE host drivers and keeping
only these that are really needed (while at the same time migrating
them slowly to libata).

I asked you about this in private mail in August 2015, you told me to
bring this on the list.  I did it (with these patches) in February
2016.  After two pings and months of waiting for a reply all I get is
is a quick NAK?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


^ permalink raw reply

* Re: [RFC PATCH 00/19] ide: remove deprecated host drivers (part 1)
From: Christoph Hellwig @ 2016-12-08 17:11 UTC (permalink / raw)
  To: David Miller
  Cc: b.zolnierkie, linux-ide, linux-kernel, tj, gnomes,
	sergei.shtylyov
In-Reply-To: <20161208.113957.686350007074631834.davem@davemloft.net>

On Thu, Dec 08, 2016 at 11:39:57AM -0500, David Miller wrote:
> They are not a maintainence burdon, I rarely get more than 1 patch
> each merge window and most of the time those are cleanups or for the
> handling of a kernel wide API change rather than bug fixes.

They are a major maintainence burden for the block layer due to horrible
abuse of all kinds of block layer APIs.

^ permalink raw reply

* -  -  Re
From: richard @ 2016-12-08  7:23 UTC (permalink / raw)


Please confirm receipt of my previous mail? What time and when can i call you?

^ permalink raw reply

* Re: [RFC PATCH 00/19] ide: remove deprecated host drivers (part 1)
From: David Miller @ 2016-12-08 16:39 UTC (permalink / raw)
  To: b.zolnierkie; +Cc: linux-ide, linux-kernel, tj, gnomes, sergei.shtylyov
In-Reply-To: <5007114.YSRHeGyTgl@amdc3058>

From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date: Thu, 08 Dec 2016 17:15:16 +0100

> On Thursday, December 08, 2016 10:23:08 AM David Miller wrote:
>> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>> Date: Thu, 08 Dec 2016 14:42:12 +0100
>> 
>> > Ping.. since there was no negative (or any other) feedback I think that
>> > this can be put into -next for some wider exposure..
>> 
>> I'm not going to apply this and break things on people, sorry.
> 
> People building their own kernels with their own kernel config files
> and still using IDE drivers (deprecated in 2009 BTW) will have to
> update their setups to libata but otherwise nothing is supposed to
> break.  So could you please explain in more detail what do you mean
> by "break things on people"?

There is no proof that the PATA drivers work %100 reliably as well as
the IDE driver they replace for every possible chip and architecture.

Therefore the only safe thing is to keep the IDE drivers around
forever.

They are not a maintainence burdon, I rarely get more than 1 patch
each merge window and most of the time those are cleanups or for the
handling of a kernel wide API change rather than bug fixes.

^ permalink raw reply

* Re: [RFC PATCH 00/19] ide: remove deprecated host drivers (part 1)
From: Bartlomiej Zolnierkiewicz @ 2016-12-08 16:15 UTC (permalink / raw)
  To: David Miller; +Cc: linux-ide, linux-kernel, tj, gnomes, sergei.shtylyov
In-Reply-To: <20161208.102308.460750923427290066.davem@davemloft.net>

On Thursday, December 08, 2016 10:23:08 AM David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Date: Thu, 08 Dec 2016 14:42:12 +0100
> 
> > Ping.. since there was no negative (or any other) feedback I think that
> > this can be put into -next for some wider exposure..
> 
> I'm not going to apply this and break things on people, sorry.

People building their own kernels with their own kernel config files
and still using IDE drivers (deprecated in 2009 BTW) will have to
update their setups to libata but otherwise nothing is supposed to
break.  So could you please explain in more detail what do you mean
by "break things on people"?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics


^ permalink raw reply

* Re: LSF/MM 2017: Call for Proposals
From: Michal Hocko @ 2016-12-08 15:37 UTC (permalink / raw)
  To: James Bottomley
  Cc: Jeff Layton, linux-block, linux-btrfs, linux-cifs, linux-ext4,
	linux-fsdevel, linux-ide, linux-kernel, linux-mm, linux-nfs,
	linux-scsi, xfs@oss.sgi.com, ceph-devel, linux-nvme,
	lsf-pc@lists.linux-foundation.org
In-Reply-To: <1481211043.2361.1.camel@HansenPartnership.com>

On Thu 08-12-16 07:30:43, James Bottomley wrote:
> On Thu, 2016-12-08 at 13:26 +0100, Michal Hocko wrote:
> > On Wed 07-12-16 06:57:06, James Bottomley wrote:
> > [...]
> > > Just on this point, since there seems to be a lot of confusion: lsf
> > > -pc
> > > is the list for contacting the programme committee, so you cannot
> > > subscribe to it.
> > > 
> > > There is no -discuss equivalent, like kernel summit has, because we
> > > expect you to cc the relevant existing mailing list and have the
> > > discussion there instead rather than expecting people to subscribe
> > > to a
> > > new list.
> > 
> > There used to be lsf@lists.linux-foundation.org. Is it not active
> > anymore?
> 
> Not until we get the list of invitees sorted out.  And then it's only
> for stuff actually to do with lsf (like logistics, bof or session
> requests or other meetups).  Any technical stuff should still be cc'd
> to the relevant mailing list.

OK, I tend to forget about that. Thanks for the clarification!
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply

* Re: LSF/MM 2017: Call for Proposals
From: James Bottomley @ 2016-12-08 15:30 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Jeff Layton, linux-block, linux-btrfs, linux-cifs, linux-ext4,
	linux-fsdevel, linux-ide, linux-kernel, linux-mm, linux-nfs,
	linux-scsi, xfs@oss.sgi.com, ceph-devel, linux-nvme,
	lsf-pc@lists.linux-foundation.org
In-Reply-To: <20161208122619.GA26535@dhcp22.suse.cz>

On Thu, 2016-12-08 at 13:26 +0100, Michal Hocko wrote:
> On Wed 07-12-16 06:57:06, James Bottomley wrote:
> [...]
> > Just on this point, since there seems to be a lot of confusion: lsf
> > -pc
> > is the list for contacting the programme committee, so you cannot
> > subscribe to it.
> > 
> > There is no -discuss equivalent, like kernel summit has, because we
> > expect you to cc the relevant existing mailing list and have the
> > discussion there instead rather than expecting people to subscribe
> > to a
> > new list.
> 
> There used to be lsf@lists.linux-foundation.org. Is it not active
> anymore?

Not until we get the list of invitees sorted out.  And then it's only
for stuff actually to do with lsf (like logistics, bof or session
requests or other meetups).  Any technical stuff should still be cc'd
to the relevant mailing list.

James

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox