Linux ATA/IDE development
 help / color / mirror / Atom feed
* Re: [PATCH] libata: transport: Remove circular dependency at free time
From: Tejun Heo @ 2017-03-03 18:36 UTC (permalink / raw)
  To: Sergei Shtylyov; +Cc: Gwendal Grignou, gregkh, linux-ide
In-Reply-To: <faa6496f-f72e-733a-f7a4-3e2587cd8e61@cogentembedded.com>

On Fri, Mar 03, 2017 at 09:28:45PM +0300, Sergei Shtylyov wrote:
> > Reported-by: Matthew Whitehead <tedheadster@gmail.com>
> > Tested-by: Matthew Whitehead <tedheadster@gmail.com>
> > Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> 
>    You're saying it's Tejun's patch but there's no sign-off from him?

It probably should have sth like Patch-originally-by: from me but
Gwendal as the author.  I'll address the review points when applying.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH] libata: transport: Remove circular dependency at free time
From: Sergei Shtylyov @ 2017-03-03 18:28 UTC (permalink / raw)
  To: Gwendal Grignou, tj, gregkh, linux-ide, htejun
In-Reply-To: <20170303170009.36744-1-gwendal@chromium.org>

Hello!

On 03/03/2017 08:00 PM, Gwendal Grignou wrote:

> From: Tejun Heo <tj@kernel.org>
>
> Without this patch, failed probe would not free resources like irq.
>
> ata port tdev object currently hold a reference to the ata port object.
> Therefore the ata port object release function will not get called until
> the ata_tport_release is called. But that would never happen, releasing
> the last reference of ata port dev is done by scsi_host_release, which
> is called by ata_host_release when the ata port object is released.
>
> The ata tranport device objects actually do not need to explicitly hold

    Not ata_transport.

> a reference to their real counterpart, given the transport objects are
> the children of these objects and device_add() is call for each child.
> We know the parent will not be deleted until we call the child

    Child's?

> device_del().
>
> Reported-by: Matthew Whitehead <tedheadster@gmail.com>
> Tested-by: Matthew Whitehead <tedheadster@gmail.com>
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>

    You're saying it's Tejun's patch but there's no sign-off from him?

MBR, Sergei


^ permalink raw reply

* [PATCH] libata: transport: Remove circular dependency at free time
From: Gwendal Grignou @ 2017-03-03 17:00 UTC (permalink / raw)
  To: tj, gregkh, sergei.shtylyov, linux-ide, htejun
In-Reply-To: <CAP8WD_ZJ9EgssJgTu8EOtKodtnfxO8tqhN6iAnuMHq2VQ7MoaQ@mail.gmail.com>

From: Tejun Heo <tj@kernel.org>

Without this patch, failed probe would not free resources like irq.

ata port tdev object currently hold a reference to the ata port object.
Therefore the ata port object release function will not get called until
the ata_tport_release is called. But that would never happen, releasing
the last reference of ata port dev is done by scsi_host_release, which
is called by ata_host_release when the ata port object is released.

The ata tranport device objects actually do not need to explicitly hold
a reference to their real counterpart, given the transport objects are
the children of these objects and device_add() is call for each child.
We know the parent will not be deleted until we call the child
device_del().

Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
---
 drivers/ata/libata-transport.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/libata-transport.c b/drivers/ata/libata-transport.c
index 46698232e6bf..19e6e539a061 100644
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -224,7 +224,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_class,
 
 static void ata_tport_release(struct device *dev)
 {
-	put_device(dev->parent);
 }
 
 /**
@@ -284,7 +283,7 @@ int ata_tport_add(struct device *parent,
 	device_initialize(dev);
 	dev->type = &ata_port_type;
 
-	dev->parent = get_device(parent);
+	dev->parent = parent;
 	dev->release = ata_tport_release;
 	dev_set_name(dev, "ata%d", ap->print_id);
 	transport_setup_device(dev);
@@ -348,7 +347,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_class,
 
 static void ata_tlink_release(struct device *dev)
 {
-	put_device(dev->parent);
 }
 
 /**
@@ -410,7 +408,7 @@ int ata_tlink_add(struct ata_link *link)
 	int error;
 
 	device_initialize(dev);
-	dev->parent = get_device(&ap->tdev);
+	dev->parent = &ap->tdev;
 	dev->release = ata_tlink_release;
 	if (ata_is_host_link(link))
 		dev_set_name(dev, "link%d", ap->print_id);
@@ -589,7 +587,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_class,
 
 static void ata_tdev_release(struct device *dev)
 {
-	put_device(dev->parent);
 }
 
 /**
@@ -662,7 +659,7 @@ static int ata_tdev_add(struct ata_device *ata_dev)
 	int error;
 
 	device_initialize(dev);
-	dev->parent = get_device(&link->tdev);
+	dev->parent = &link->tdev;
 	dev->release = ata_tdev_release;
 	if (ata_is_host_link(link))
 		dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
-- 
2.12.0.rc1.440.g5b76565f74-goog


^ permalink raw reply related

* [PATCH] ata: constify of_device_id structures
From: Bhumika Goyal @ 2017-03-01 19:33 UTC (permalink / raw)
  To: julia.lawall, b.zolnierkie, tj, linux-ide, linux-kernel; +Cc: Bhumika Goyal

Declare of_device_id structures as const as they are either passed to
the macro MODULE_DEVICE_TABLE or stored in the of_match_table field of a
device_driver structure. This field is of type const, so of_device_id
structures having this property can be made const too.

Cross compiled the files drivers/ata/pata_macio.c and
drivers/ata/pata_mpc52xx.c for powerpc architecture.

Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
---
 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 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index e347e7a..0adcb40 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -1328,7 +1328,7 @@ static int pata_macio_pci_resume(struct pci_dev *pdev)
 }
 #endif /* CONFIG_PM_SLEEP */
 
-static struct of_device_id pata_macio_match[] =
+static const struct of_device_id pata_macio_match[] =
 {
 	{
 	.name 		= "IDE",
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index 252ba27..9730125 100644
--- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -847,7 +847,7 @@ static int mpc52xx_ata_probe(struct platform_device *op)
 }
 #endif
 
-static struct of_device_id mpc52xx_ata_of_match[] = {
+static const struct of_device_id mpc52xx_ata_of_match[] = {
 	{ .compatible = "fsl,mpc5200-ata", },
 	{ .compatible = "mpc5200-ata", },
 	{},
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index 201a32d..01161c1 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -67,7 +67,7 @@ static int pata_of_platform_probe(struct platform_device *ofdev)
 				     reg_shift, pio_mask, &pata_platform_sht);
 }
 
-static struct of_device_id pata_of_platform_match[] = {
+static const struct of_device_id pata_of_platform_match[] = {
 	{ .compatible = "ata-generic", },
 	{ },
 };
diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index a723ae9..01734d5 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -1612,7 +1612,7 @@ static int sata_fsl_resume(struct platform_device *op)
 }
 #endif
 
-static struct of_device_id fsl_sata_match[] = {
+static const struct of_device_id fsl_sata_match[] = {
 	{
 		.compatible = "fsl,pq-sata",
 	},
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 00ce26d..b66bcda 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -4286,7 +4286,7 @@ static int mv_platform_resume(struct platform_device *pdev)
 #endif
 
 #ifdef CONFIG_OF
-static struct of_device_id mv_sata_dt_ids[] = {
+static const struct of_device_id mv_sata_dt_ids[] = {
 	{ .compatible = "marvell,armada-370-sata", },
 	{ .compatible = "marvell,orion-sata", },
 	{},
-- 
1.9.1


^ permalink raw reply related

* PLEASE YOUR CO-OPERATION FROM MS SAFI KABORE
From: Ms Safi Kabore @ 2017-03-01  4:10 UTC (permalink / raw)

In-Reply-To: <1243900486.5264576.1488341440898.ref@mail.yahoo.com>



Dear Friend,

I need your help to stand for  claim of (US$1.5M DOLLARS) abandon fund in the bank with my advice I have every enquiries’ details to make the bank believed you and release the fund in within 6 banking working days with your full co-operation with me for success.
Send the below requirement to enable me details on how to apply to the Bank for the claim.
1)Full names.
2)country of origin.
3)Your Mobile No.
4)Your Age.
5)occupation.

Thanks.
Ms Safi kabore

^ permalink raw reply

* Re: ata: WARNING in ata_sff_qc_issue
From: Tejun Heo @ 2017-02-28 19:23 UTC (permalink / raw)
  To: Dmitry Vyukov; +Cc: linux-ide, LKML, syzkaller
In-Reply-To: <CACT4Y+bXkvevNZU8uP6X0QVqsj6wNoUA_1exfTSOzc+SmUtMOA@mail.gmail.com>

Hello,

On Tue, Feb 28, 2017 at 03:33:48PM +0100, Dmitry Vyukov wrote:
> If the WARNING is merely to inform user about invalid protocol, please
> issue a single line pr_err without the stack trace (invalid protocol
> value may be more interesting).

Yeah, the warning is harmless.  The code was written before
passthrough support and just assumed that nobody higher up in the
stack should be issuing unsupported protocols and warned on such cases
as a precaution.  I'm just gonna drop the WARN.  The error code to sg
command should be enough to indicate the failure.

Thanks.

-- 
tejun

^ permalink raw reply

* Re: [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Sergei Shtylyov @ 2017-02-28 17:25 UTC (permalink / raw)
  To: Luiz Carlos Ramos
  Cc: linux-ide, Bartlomiej Zolnierkiewicz, David Miller, petkovbb
In-Reply-To: <20170222003831.GA14251@giustizia>

On 02/22/2017 03:38 AM, Luiz Carlos Ramos wrote:

>> On 02/21/2017 05:22 PM, Luiz Carlos Ramos wrote:
>>
>>> Two messages are now displayed (at "warn" level) to make sure the user
>>> is aware that PCI IDE devices were detected at common addresses (0x1f0
>>> and 0x170) and that they will not be managed by ide-generic, but rather
>>> delegated to its specific driver.
>>>
>>> Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
>>> ---
>>> drivers/ide/ide-generic.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
>>> index ee11edcdba3170c077381d603918498d79ffa3bb..2204819ef73612deed4ebfe58c69cdadb40fa53b 100644
>>> --- a/drivers/ide/ide-generic.c
>>> +++ b/drivers/ide/ide-generic.c
>>> @@ -125,9 +125,19 @@ static int __init ide_generic_init(void)
>>>
>>> 		if (primary == 0)
>>> 			probe_mask |= 0x1;
>>> +		else {
>>> +			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
>>
>>    Also, please use pr_warn().
>>
>
> This code is quite old, and it is in deep maintenance phase.
>
> Every other message in ide-generic.c is implemented as printk(...),
> but to be fair, there are not so many of them.
>
> Given that fact, would it be better to change these two ones to be
> inserted to pr_warn() as suggested (and then having a mix of printk()
> and pr_warn() in the code), or to "allow" two more printk() in the code
> and having checkpatck.pl complaining?
>
> I really don't know what is better or worse. Both can be implemented,
> and there are a mix of advantages and disadvantages in each side.
>
> I'd like to hear from you and colleagues about how to proceed.

    I'd prefer a checkpatch-clean patch. Though I don't think DaveM would take 
further cleanups (printk -> pr_<foo>).

MBR, Sergei


^ permalink raw reply

* ata: WARNING in ata_sff_qc_issue
From: Dmitry Vyukov @ 2017-02-28 14:33 UTC (permalink / raw)
  To: Tejun Heo, linux-ide, LKML; +Cc: syzkaller

Hello,

The following program triggers WARNING in ata_sff_qc_issue:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <sys/syscall.h>
#include <stdint.h>

int main()
{
  syscall(__NR_mmap, 0x20000000ul, 0xf9b000ul, 0x3ul, 0x32ul, -1, 0);
  int fd = syscall(__NR_open, "/dev/sg0", 0x800142ul, 0, 0, 0, 0, 0, 0);
  (*(uint32_t*)0x20007000 = (uint32_t)0x50);
  (*(uint32_t*)0x20007004 = (uint32_t)0xd7b);
  (*(uint64_t*)0x20007008 = (uint64_t)0x1000000000);
  (*(uint32_t*)0x20007010 = (uint32_t)0x6);
  (*(uint32_t*)0x20007014 = (uint32_t)0x5);
  (*(uint32_t*)0x20007018 = (uint32_t)0x10001);
  (*(uint32_t*)0x2000701c = (uint32_t)0x0);
  (*(uint16_t*)0x20007020 = (uint16_t)0x3);
  (*(uint16_t*)0x20007022 = (uint16_t)0xfffffffffffffffd);
  (*(uint32_t*)0x20007024 = (uint32_t)0x8000000001885);
  (*(uint32_t*)0x20007028 = (uint32_t)0x1);
  (*(uint32_t*)0x2000702c = (uint32_t)0x0);
  (*(uint32_t*)0x20007030 = (uint32_t)0x0);
  (*(uint32_t*)0x20007034 = (uint32_t)0x0);
  (*(uint32_t*)0x20007038 = (uint32_t)0x0);
  (*(uint32_t*)0x2000703c = (uint32_t)0x0);
  (*(uint32_t*)0x20007040 = (uint32_t)0x0);
  (*(uint32_t*)0x20007044 = (uint32_t)0x0);
  (*(uint32_t*)0x20007048 = (uint32_t)0x0);
  (*(uint32_t*)0x2000704c = (uint32_t)0x0);
  syscall(__NR_write, fd, 0x20007000ul, 0x50ul);
  return 0;
}


sg_write: data in/out 3415/28 bytes for SCSI command 0x85-- guessing data in;
   program a.out not setting count and/or reply_len properly
------------[ cut here ]------------
WARNING: CPU: 3 PID: 2936 at drivers/ata/libata-sff.c:1485
ata_sff_qc_issue+0x6a2/0x820 drivers/ata/libata-sff.c:1485
Kernel panic - not syncing: panic_on_warn set ...

CPU: 3 PID: 2936 Comm: a.out Not tainted 4.10.0+ #230
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
 panic+0x1fb/0x412 kernel/panic.c:179
 __warn+0x1c4/0x1e0 kernel/panic.c:540
 warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
 ata_sff_qc_issue+0x6a2/0x820 drivers/ata/libata-sff.c:1485
 ata_bmdma_qc_issue+0x288/0x5b0 drivers/ata/libata-sff.c:2799
 ata_qc_issue+0x6f5/0x1030 drivers/ata/libata-core.c:5335
 ata_scsi_translate+0x39b/0x5f0 drivers/ata/libata-scsi.c:2025
 __ata_scsi_queuecmd drivers/ata/libata-scsi.c:4253 [inline]
 ata_scsi_queuecmd+0x37b/0x7d0 drivers/ata/libata-scsi.c:4302
 scsi_dispatch_cmd+0x43a/0xb80 drivers/scsi/scsi_lib.c:1691
 scsi_request_fn+0x1071/0x1d80 drivers/scsi/scsi_lib.c:1826
 __blk_run_queue_uncond block/blk-core.c:305 [inline]
 __blk_run_queue+0xc5/0x130 block/blk-core.c:323
 blk_execute_rq_nowait+0x31b/0x470 block/blk-exec.c:79
 sg_common_write.isra.21+0x11b7/0x1c10 drivers/scsi/sg.c:803
 sg_write+0x7fa/0xe90 drivers/scsi/sg.c:679
 __vfs_write+0x5b1/0x740 fs/read_write.c:510
 vfs_write+0x187/0x530 fs/read_write.c:560
 SYSC_write fs/read_write.c:607 [inline]
 SyS_write+0xfb/0x230 fs/read_write.c:599
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x434b09
RSP: 002b:00007ffd3ba38278 EFLAGS: 00000203 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000401860 RCX: 0000000000434b09
RDX: 0000000000000050 RSI: 0000000020007000 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000203 R12: 0000001000000000
R13: 0000000000401860 R14: 00000000004018f0 R15: 0000000000000000
Kernel Offset: disabled
Rebooting in 86400 seconds..


If the WARNING is merely to inform user about invalid protocol, please
issue a single line pr_err without the stack trace (invalid protocol
value may be more interesting).

On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570

^ permalink raw reply

* Re: [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Bartlomiej Zolnierkiewicz @ 2017-02-28 12:32 UTC (permalink / raw)
  To: Luiz Carlos Ramos; +Cc: Sergei Shtylyov, linux-ide, David Miller, petkovbb
In-Reply-To: <20170222003831.GA14251@giustizia>


On Tuesday, February 21, 2017 09:38:31 PM Luiz Carlos Ramos wrote:
> Hello, Sergei!
> 
> I have a question or two about checkpatch.pl results below.
> 
> On Tue, Feb 21, 2017 at 06:52:13PM +0300, Sergei Shtylyov wrote:
> > On 02/21/2017 05:22 PM, Luiz Carlos Ramos wrote:
> > 
> > >Two messages are now displayed (at "warn" level) to make sure the user
> > >is aware that PCI IDE devices were detected at common addresses (0x1f0
> > >and 0x170) and that they will not be managed by ide-generic, but rather
> > >delegated to its specific driver.
> > >
> > >Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
> > >---
> > > drivers/ide/ide-generic.c | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > >diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> > >index ee11edcdba3170c077381d603918498d79ffa3bb..2204819ef73612deed4ebfe58c69cdadb40fa53b 100644
> > >--- a/drivers/ide/ide-generic.c
> > >+++ b/drivers/ide/ide-generic.c
> > >@@ -125,9 +125,19 @@ static int __init ide_generic_init(void)
> > >
> > > 		if (primary == 0)
> > > 			probe_mask |= 0x1;
> > >+		else {
> > >+			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> > 
> >    Also, please use pr_warn().
> > 
> 
> This code is quite old, and it is in deep maintenance phase.
> 
> Every other message in ide-generic.c is implemented as printk(...),
> but to be fair, there are not so many of them.
> 
> Given that fact, would it be better to change these two ones to be
> inserted to pr_warn() as suggested (and then having a mix of printk()
> and pr_warn() in the code), or to "allow" two more printk() in the code
> and having checkpatck.pl complaining?
> 
> I really don't know what is better or worse. Both can be implemented,
> and there are a mix of advantages and disadvantages in each side.
> 
> I'd like to hear from you and colleagues about how to proceed.

Well, I vote for allowing two more printk() and leaving
the old code as it is.

> > >+			     " ide-generic will not grab this device, delegating it to"
> > >+			     " the driver of its specific chipset\n", 0x1f0);
> > >+		}
> > >
> > > 		if (secondary == 0)
> > > 			probe_mask |= 0x2;
> > >+		else {
> > >+			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> > 
> >    Likewise.
> > 
> > >+			     " ide-generic will not grab this device, delegating it to"
> > >+			     " the driver of its specific chipset\n", 0x170);
> > >+		}
> > > 	} else
> > > 		printk(KERN_INFO DRV_NAME ": enforcing probing of I/O ports "
> > > 			"upon user request\n");
> > 
> > MBR, Sergei
> > 
> 
> Best regards,
> 
> Luiz Carlos Ramos

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


^ permalink raw reply

* Re: [PATCH] ide: palm_bk3710: add __initdata to palm_bk3710_port_info
From: David Miller @ 2017-02-28  1:45 UTC (permalink / raw)
  To: bhumirks; +Cc: julia.lawall, linux-ide, linux-kernel
In-Reply-To: <1483089602-6016-1-git-send-email-bhumirks@gmail.com>

From: Bhumika Goyal <bhumirks@gmail.com>
Date: Fri, 30 Dec 2016 14:50:02 +0530

> The object palm_bk3710_port_info of type ide_port_info is never
> referenced anywhere after initialization by palm_bk3710_probe. It is
> also passed as a parameter to ide_host_add which is called from the init
> function but this call doesn't store the object reference anywhere, and
> it only dereferences the values of the fields. Therefore add __initdata
> to its declaration.
> 
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>

Applied, thanks.

^ permalink raw reply

* [GIT] IDE
From: David Miller @ 2017-02-28  1:50 UTC (permalink / raw)
  To: torvalds; +Cc: akpm, linux-ide, linux-kernel


Just one actual change here this time around, adding some init data
annotations.  The other change was bogus and got reverted.

Please pull, thanks!

The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:

  Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git 

for you to fetch changes up to 96297aee8bce237961b0e1b99e22913c5726af12:

  ide: palm_bk3710: add __initdata to palm_bk3710_port_info (2017-02-27 20:43:26 -0500)

----------------------------------------------------------------
Bhumika Goyal (1):
      ide: palm_bk3710: add __initdata to palm_bk3710_port_info

David S. Miller (1):
      Revert "ide: Fix interface autodetection in legacy IDE driver (trial #2)"

lramos.prof@yahoo.com.br (1):
      ide: Fix interface autodetection in legacy IDE driver (trial #2)

 drivers/ide/palm_bk3710.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

^ permalink raw reply

* £1,500,000.00 GBP Donation
From: Chris Colin & Weir @ 2017-02-27 21:34 UTC (permalink / raw)
  To: Recipients

My wife and I have awarded you with a donation of £1,500,000.00 GBP
from part of our Jackpot Lottery of £161,653,000 Million Pounds, send your name,address, phone for claims.

View http://www.bbc.co.uk/news/uk-scotland-glasgow-west-18801698

We await your earliest response and God Bless you.

Best of luck.

Chris Colin & Weir

Email: chriscolin10001@gmail.com

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


^ permalink raw reply

* [PATCH] Delete redundant return value check of platform_get_resource()
From: Belen Sarabia @ 2017-02-27 21:41 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-ide, linux-kernel

Delete error handling from the result of a call to platform_get_resource()
when the value is immediately passed to devm_ioremap_resource().

Signed-off-by: Belen Sarabia <belensarabia@gmail.com>
---
 drivers/ata/ahci_octeon.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/drivers/ata/ahci_octeon.c b/drivers/ata/ahci_octeon.c
index ea865fe..5a44e08 100644
--- a/drivers/ata/ahci_octeon.c
+++ b/drivers/ata/ahci_octeon.c
@@ -38,11 +38,6 @@ static int ahci_octeon_probe(struct platform_device *pdev)
 	int ret;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (!res) {
-		dev_err(&pdev->dev, "Platform resource[0] is missing\n");
-		return -ENODEV;
-	}
-
 	base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(base))
 		return PTR_ERR(base);
-- 
1.9.1

^ permalink raw reply related

* Re: [PATCH] pata_legacy: Allow disabling of legacy PATA device probes on non-PCI systems
From: tedheadster @ 2017-02-23 19:26 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Gwendal Grignou, One Thousand Gnomes, Greg Kroah-Hartman,
	Sergei Shtylyov, IDE/ATA development list
In-Reply-To: <20170210131918.GA11963@mtj.duckdns.org>

Gwendal,
  could you submit a formal patch so we can get it in the next kernel?

- Matthew

^ permalink raw reply

* RE:
From: Qin's Yanjun @ 2017-02-23 15:09 UTC (permalink / raw)



How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz


^ permalink raw reply

* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Joe Perches @ 2017-02-23 17:53 UTC (permalink / raw)
  To: Emil Velikov
  Cc: linux-fbdev@vger.kernel.org, linux-ia64, SH-Linux,
	Alexander Shishkin, ML nouveau, Linux-ALSA, dri-devel,
	open list:VIRTIO GPU DRIVER, linux-ide@vger.kernel.org,
	linux-mtd@lists.infradead.org, sparclinux, drbd-dev, Rob Herring,
	linux-omap, linux-scsi, Richard Weinberger, tboot-devel,
	amd-gfx mailing list, linux-acpi@vger.kernel.org, sfi-devel
In-Reply-To: <CACvgo50LUm5VSn_F=Dh8kL5zCPpCQDoCyUEL=Z+=1+6hJpfTaw@mail.gmail.com>

On Thu, 2017-02-23 at 17:41 +0000, Emil Velikov wrote:
> On 23 February 2017 at 17:18, Joe Perches <joe@perches.com> wrote:
> > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> > > On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe@perches.com> wrote:
> > > > There are ~4300 uses of pr_warn and ~250 uses of the older
> > > > pr_warning in the kernel source tree.
> > > > 
> > > > Make the use of pr_warn consistent across all kernel files.
> > > > 
> > > > This excludes all files in tools/ as there is a separate
> > > > define pr_warning for that directory tree and pr_warn is
> > > > not used in tools/.
> > > > 
> > > > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> > 
> > []
> > > Where's the removal of pr_warning so we don't have more sneak in?
> > 
> > After all of these actually get applied,
> > and maybe a cycle or two later, one would
> > get sent.
> > 
> 
> By which point you'll get a few reincarnation of it. So you'll have to
> do the same exercise again :-(

Maybe to one or two files.  Not a big deal.

> I guess the question is - are you expecting to get the series merged
> all together/via one tree ?

No.  The only person that could do that effectively is Linus.

> If not, your plan is perfectly reasonable.

^ permalink raw reply

* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Emil Velikov @ 2017-02-23 17:41 UTC (permalink / raw)
  To: Joe Perches
  Cc: linux-fbdev@vger.kernel.org, linux-ia64, SH-Linux,
	Alexander Shishkin, ML nouveau, Linux-ALSA, dri-devel,
	open list:VIRTIO GPU DRIVER, linux-ide@vger.kernel.org,
	linux-mtd@lists.infradead.org, sparclinux, drbd-dev, Rob Herring,
	linux-omap, linux-scsi, Richard Weinberger, tboot-devel,
	amd-gfx mailing list, linux-acpi@vger.kernel.org, sfi-devel
In-Reply-To: <1487870304.14159.29.camel@perches.com>

On 23 February 2017 at 17:18, Joe Perches <joe@perches.com> wrote:
> On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
>> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe@perches.com> wrote:
>> > There are ~4300 uses of pr_warn and ~250 uses of the older
>> > pr_warning in the kernel source tree.
>> >
>> > Make the use of pr_warn consistent across all kernel files.
>> >
>> > This excludes all files in tools/ as there is a separate
>> > define pr_warning for that directory tree and pr_warn is
>> > not used in tools/.
>> >
>> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
> []
>> Where's the removal of pr_warning so we don't have more sneak in?
>
> After all of these actually get applied,
> and maybe a cycle or two later, one would
> get sent.
>
By which point you'll get a few reincarnation of it. So you'll have to
do the same exercise again :-(

I guess the question is - are you expecting to get the series merged
all together/via one tree ? If not, your plan is perfectly reasonable.
Fwiw in the DRM subsystem, similar cleanups does purge the respective
macros/other with the final commit. But there one can pull the lot in
one go.

Regards,
Emil

^ permalink raw reply

* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Joe Perches @ 2017-02-23 17:18 UTC (permalink / raw)
  To: Rob Herring
  Cc: linux-fbdev@vger.kernel.org, linux-ia64, SH-Linux,
	Alexander Shishkin, nouveau, Linux-ALSA, dri-devel,
	virtualization, linux-ide@vger.kernel.org,
	linux-mtd@lists.infradead.org, sparclinux, drbd-dev, linux-scsi,
	Richard Weinberger, sfi-devel, amd-gfx,
	linux-acpi@vger.kernel.org, tboot-devel, oprofile-list,
	linux-input@vger.kernel.org, xen-devel, linux-media
In-Reply-To: <CAL_JsqLTaq-QLTqfyDO8EVJYpgeUx1e4J0Fo2NvfFWqVoiVedQ@mail.gmail.com>

On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote:
> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe@perches.com> wrote:
> > There are ~4300 uses of pr_warn and ~250 uses of the older
> > pr_warning in the kernel source tree.
> > 
> > Make the use of pr_warn consistent across all kernel files.
> > 
> > This excludes all files in tools/ as there is a separate
> > define pr_warning for that directory tree and pr_warn is
> > not used in tools/.
> > 
> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
[]
> Where's the removal of pr_warning so we don't have more sneak in?

After all of these actually get applied,
and maybe a cycle or two later, one would
get sent.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

^ permalink raw reply

* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Rob Herring @ 2017-02-23 15:28 UTC (permalink / raw)
  To: Joe Perches
  Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-ia64-u79uwXL29TY76Z2rM5mHXA, SH-Linux, Alexander Shishkin,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Linux-ALSA, dri-devel,
	virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
	linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	sparclinux-u79uwXL29TY76Z2rM5mHXA,
	drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA, Richard Weinberger,
	sfi-devel-yLnuTTp1/kvcsJTPyzm5gB2eb7JE58TQ,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	tboot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	oprofile-list-TtF/mJH4Jtrk1uMJSBkQmQ,
	linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b, linux-media
In-Reply-To: <cover.1487314666.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>

On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches <joe@perches.com> wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning for that directory tree and pr_warn is
> not used in tools/.
>
> Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
>
> Some files not compiled - no cross-compilers
>
> Joe Perches (35):
>   alpha: Convert remaining uses of pr_warning to pr_warn
>   ARM: ep93xx: Convert remaining uses of pr_warning to pr_warn
>   arm64: Convert remaining uses of pr_warning to pr_warn
>   arch/blackfin: Convert remaining uses of pr_warning to pr_warn
>   ia64: Convert remaining use of pr_warning to pr_warn
>   powerpc: Convert remaining uses of pr_warning to pr_warn
>   sh: Convert remaining uses of pr_warning to pr_warn
>   sparc: Convert remaining use of pr_warning to pr_warn
>   x86: Convert remaining uses of pr_warning to pr_warn
>   drivers/acpi: Convert remaining uses of pr_warning to pr_warn
>   block/drbd: Convert remaining uses of pr_warning to pr_warn
>   gdrom: Convert remaining uses of pr_warning to pr_warn
>   drivers/char: Convert remaining use of pr_warning to pr_warn
>   clocksource: Convert remaining use of pr_warning to pr_warn
>   drivers/crypto: Convert remaining uses of pr_warning to pr_warn
>   fmc: Convert remaining use of pr_warning to pr_warn
>   drivers/gpu: Convert remaining uses of pr_warning to pr_warn
>   drivers/ide: Convert remaining uses of pr_warning to pr_warn
>   drivers/input: Convert remaining uses of pr_warning to pr_warn
>   drivers/isdn: Convert remaining uses of pr_warning to pr_warn
>   drivers/macintosh: Convert remaining uses of pr_warning to pr_warn
>   drivers/media: Convert remaining use of pr_warning to pr_warn
>   drivers/mfd: Convert remaining uses of pr_warning to pr_warn
>   drivers/mtd: Convert remaining uses of pr_warning to pr_warn
>   drivers/of: Convert remaining uses of pr_warning to pr_warn
>   drivers/oprofile: Convert remaining uses of pr_warning to pr_warn
>   drivers/platform: Convert remaining uses of pr_warning to pr_warn
>   drivers/rapidio: Convert remaining use of pr_warning to pr_warn
>   drivers/scsi: Convert remaining use of pr_warning to pr_warn
>   drivers/sh: Convert remaining use of pr_warning to pr_warn
>   drivers/tty: Convert remaining uses of pr_warning to pr_warn
>   drivers/video: Convert remaining uses of pr_warning to pr_warn
>   kernel/trace: Convert remaining uses of pr_warning to pr_warn
>   lib: Convert remaining uses of pr_warning to pr_warn
>   sound/soc: Convert remaining uses of pr_warning to pr_warn

Where's the removal of pr_warning so we don't have more sneak in?

Rob
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply

* Re: [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Luiz Carlos Ramos @ 2017-02-22  0:38 UTC (permalink / raw)
  To: Sergei Shtylyov
  Cc: linux-ide, Bartlomiej Zolnierkiewicz, David Miller, petkovbb
In-Reply-To: <418946e5-38e6-ca97-fce1-543988a5f06d@cogentembedded.com>

Hello, Sergei!

I have a question or two about checkpatch.pl results below.

On Tue, Feb 21, 2017 at 06:52:13PM +0300, Sergei Shtylyov wrote:
> On 02/21/2017 05:22 PM, Luiz Carlos Ramos wrote:
> 
> >Two messages are now displayed (at "warn" level) to make sure the user
> >is aware that PCI IDE devices were detected at common addresses (0x1f0
> >and 0x170) and that they will not be managed by ide-generic, but rather
> >delegated to its specific driver.
> >
> >Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
> >---
> > drivers/ide/ide-generic.c | 10 ++++++++++
> > 1 file changed, 10 insertions(+)
> >
> >diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> >index ee11edcdba3170c077381d603918498d79ffa3bb..2204819ef73612deed4ebfe58c69cdadb40fa53b 100644
> >--- a/drivers/ide/ide-generic.c
> >+++ b/drivers/ide/ide-generic.c
> >@@ -125,9 +125,19 @@ static int __init ide_generic_init(void)
> >
> > 		if (primary == 0)
> > 			probe_mask |= 0x1;
> >+		else {
> >+			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> 
>    Also, please use pr_warn().
> 

This code is quite old, and it is in deep maintenance phase.

Every other message in ide-generic.c is implemented as printk(...),
but to be fair, there are not so many of them.

Given that fact, would it be better to change these two ones to be
inserted to pr_warn() as suggested (and then having a mix of printk()
and pr_warn() in the code), or to "allow" two more printk() in the code
and having checkpatck.pl complaining?

I really don't know what is better or worse. Both can be implemented,
and there are a mix of advantages and disadvantages in each side.

I'd like to hear from you and colleagues about how to proceed.

> >+			     " ide-generic will not grab this device, delegating it to"
> >+			     " the driver of its specific chipset\n", 0x1f0);
> >+		}
> >
> > 		if (secondary == 0)
> > 			probe_mask |= 0x2;
> >+		else {
> >+			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> 
>    Likewise.
> 
> >+			     " ide-generic will not grab this device, delegating it to"
> >+			     " the driver of its specific chipset\n", 0x170);
> >+		}
> > 	} else
> > 		printk(KERN_INFO DRV_NAME ": enforcing probing of I/O ports "
> > 			"upon user request\n");
> 
> MBR, Sergei
> 

Best regards,

Luiz Carlos Ramos


^ permalink raw reply

* Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
From: Tejun Heo @ 2017-02-21 22:18 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Geert Uytterhoeven, Michael Schmitz, linux-ide@vger.kernel.org,
	linux-m68k, linux-kernel@vger.kernel.org, Jens Axboe,
	Christoph Hellwig
In-Reply-To: <1548730.TDiBKU8UQt@amdc3058>

On Mon, Feb 20, 2017 at 07:15:34PM +0100, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Subject: [PATCH] pata_falcon: build fix for block layer changes
> 
> commit aebf526b53ae ("block: fold cmd_type into the REQ_OP_
> space") from the block tree removes cmd_type so pata_falcon
> needs the following trivial update to make it build again.
> 
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> Tejun, I guess that you may need to fold this fix into
> your pull request for 4.11 (block layer pull request has
> been already sent by Jens so it will be most likely merged
> first).
> 
>  drivers/ata/pata_falcon.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: b/drivers/ata/pata_falcon.c
> ===================================================================
> --- a/drivers/ata/pata_falcon.c	2017-02-20 18:40:04.174989455 +0100
> +++ b/drivers/ata/pata_falcon.c	2017-02-20 18:42:59.482993870 +0100
> @@ -54,7 +54,7 @@ static unsigned int pata_falcon_data_xfe
>  	bool swap = 1;
>  
>  	if (dev->class == ATA_DEV_ATA && cmd && cmd->request &&
> -	    cmd->request->cmd_type == REQ_TYPE_FS)
> +	    !blk_rq_is_passthrough(cmd->request))

Sent it along with the pull request.

Thanks.

-- 
tejun

^ permalink raw reply

* [GIT PULL] libata changes for v4.11-rc1
From: Tejun Heo @ 2017-02-21 22:12 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-ide, Bartlomiej Zolnierkiewicz

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]

Hello, Linus.

libata changes for v4.11-rc1.

* Bartlomiej added pata_falcon.
* Christoph is trying to remove use of static 4k buf.  It's still WIP.
* Config cleanup around HAS_DMA.
* Other fixes and driver-specific changes.

This pull causes a silent conflict between the following two commits.

* 7e11aabd48eb ("ata: add Atari Falcon PATA controller driver") - this tree
* aebf526b53ae ("block: fold cmd_type into the REQ_OP_ space") - block tree

The former adds derference of request->cmd_type and the latter removes
that field and replaces its use with accessors.  The conflict can be
fixed by replacing "cmd->request->cmd_type == REQ_TYPE_FS" test in
pata_falcon.c with "!blk_rq_is_passthrough(cmd->request)".  I'm
attaching the fix patch from Bartlomiej.

Thanks.

The following changes since commit 064c3db9c564cc5be514ac21fb4aa26cc33db746:

  ata: sata_mv:- Handle return value of devm_ioremap. (2017-01-06 15:45:32 -0500)

are available in the git repository at:

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

for you to fetch changes up to 73b2951414f661e22dc4b88e4e6590c9406cf822:

  ata: pata_of_platform: using of_property_read_u32() helper (2017-01-24 11:15:01 -0500)

----------------------------------------------------------------
Andy Shevchenko (1):
      ata: sata_mv: Convert to devm_ioremap_resource()

Arnd Bergmann (1):
      ahci: imx: fix building without hwmon or thermal

Bartlomiej Zolnierkiewicz (3):
      ata: allow subsystem to be used on m68k arch
      ata: pass queued command to ->sff_data_xfer method
      ata: add Atari Falcon PATA controller driver

Christoph Hellwig (6):
      libata: avoid global response buffer in atapi_qc_complete
      libata: move struct ata_scsi_args to libata-scsi.c
      libata: remove the done callback from ata_scsi_args
      libata: call ->scsi_done from ata_scsi_simulate
      libata: don't call ata_scsi_rbuf_fill for command without a response buffer
      libata: switch to dynamic allocation instead of ata_scsi_rbuf

Csaba Kertesz (1):
      ahci: imx: Add imx53 SATA temperature sensor support

Darren Stevens (2):
      libata-sff: Don't scan disabled ports when checking for legacy mode.
      pata_atiixp: Don't use unconnected secondary port on SB600/SB700

Geert Uytterhoeven (7):
      ata: SATA_MV should depend on HAS_DMA
      ata: SATA_HIGHBANK should depend on HAS_DMA
      ata: ATA_BMDMA should depend on HAS_DMA
      ata: AHCI and other non-SFF native drivers should depend on HAS_DMA
      libata: Make ata_sg_clean() static again
      libata: Protect DMA core code by #ifdef CONFIG_HAS_DMA
      libata-eh: Use switch() instead of sparse array for protocol strings

Kefeng Wang (1):
      ata: pata_of_platform: using of_property_read_u32() helper

Michał Kępień (1):
      ata: ahci_xgene: free structure returned by acpi_get_object_info()

Tang Yuantian (3):
      ahci: qoriq: added a condition to enable dma coherence
      ahci: qoriq: report error when ecc register address is missing in dts
      ahci: qoriq: added ls2088a platforms support

Tejun Heo (3):
      Merge branch 'for-4.10-fixes' into for-4.11
      Revert "libata: switch to dynamic allocation instead of ata_scsi_rbuf"
      pata_octeon_cf: remove unused local variables from octeon_cf_set_piomode()

Uwe Kleine-König (1):
      ata: sata_mv: fix module license specification

 drivers/ata/Kconfig            |  19 +++-
 drivers/ata/Makefile           |   1 +
 drivers/ata/ahci_imx.c         | 196 +++++++++++++++++++++++++++++++++++++++++
 drivers/ata/ahci_qoriq.c       |  35 ++++++--
 drivers/ata/ahci_xgene.c       |   6 +-
 drivers/ata/libata-core.c      |  61 +++++++------
 drivers/ata/libata-eh.c        |  44 ++++++---
 drivers/ata/libata-scsi.c      |  97 ++++++++------------
 drivers/ata/libata-sff.c       |  45 ++++++----
 drivers/ata/libata.h           |   8 --
 drivers/ata/pata_at91.c        |   6 +-
 drivers/ata/pata_atiixp.c      |   5 ++
 drivers/ata/pata_bf54x.c       |   7 +-
 drivers/ata/pata_ep93xx.c      |   4 +-
 drivers/ata/pata_falcon.c      | 184 ++++++++++++++++++++++++++++++++++++++
 drivers/ata/pata_ixp4xx_cf.c   |   4 +-
 drivers/ata/pata_legacy.c      |  15 ++--
 drivers/ata/pata_octeon_cf.c   |  20 ++---
 drivers/ata/pata_of_platform.c |   9 +-
 drivers/ata/pata_pcmcia.c      |   6 +-
 drivers/ata/pata_samsung_cf.c  |   4 +-
 drivers/ata/sata_mv.c          |  15 ++--
 drivers/ata/sata_rcar.c        |   4 +-
 include/linux/libata.h         |   8 +-
 24 files changed, 612 insertions(+), 191 deletions(-)
 create mode 100644 drivers/ata/pata_falcon.c

-- 
tejun

[-- Attachment #2: 0001-pata_falcon-build-fix-for-block-layer-changes.patch --]
[-- Type: text/plain, Size: 1141 bytes --]

>From 57cee661f97369660077a0d62764dfa50e0a0b5a Mon Sep 17 00:00:00 2001
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date: Tue, 21 Feb 2017 17:11:23 -0500
Subject: [PATCH] pata_falcon: build fix for block layer changes

commit aebf526b53ae ("block: fold cmd_type into the REQ_OP_
space") from the block tree removes cmd_type so pata_falcon
needs the following trivial update to make it build again.

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
---
 drivers/ata/pata_falcon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ata/pata_falcon.c b/drivers/ata/pata_falcon.c
index 7826408..5b0c57d 100644
--- a/drivers/ata/pata_falcon.c
+++ b/drivers/ata/pata_falcon.c
@@ -54,7 +54,7 @@ static unsigned int pata_falcon_data_xfer(struct ata_queued_cmd *qc,
 	bool swap = 1;
 
 	if (dev->class == ATA_DEV_ATA && cmd && cmd->request &&
-	    cmd->request->cmd_type == REQ_TYPE_FS)
+	    !blk_rq_is_passthrough(cmd->request))
 		swap = 0;
 
 	/* Transfer multiple of 2 bytes */
-- 
2.9.3


^ permalink raw reply related

* Re: [PATCH 1/2] ide-generic: add some notes to clarify probing PCI devices
From: Bartlomiej Zolnierkiewicz @ 2017-02-21 16:21 UTC (permalink / raw)
  To: Luiz Carlos Ramos; +Cc: linux-ide, David Miller, petkovbb
In-Reply-To: <20170221142237.GB11234@giustizia>


Hi,

On Tuesday, February 21, 2017 11:22:37 AM Luiz Carlos Ramos wrote:
> Some inline comments were added in ide-generic, to make clear to
> developers the way probe_mask is managed when PCI IDE devices are
> present.
> 
> A not-so-deep analysis of the code could make it is buggy, as it seems
> that if a device is detected, the probing procedure is avoided,
> suggesting some kind of reversed logic.
> 
> Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>

Looks fine overall, some minor nits below.

> ---
>  drivers/ide/ide-generic.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> index 54d7c4685d23aa5e62ce606e7b994a57bb54b08a..ee11edcdba3170c077381d603918498d79ffa3bb 100644
> --- a/drivers/ide/ide-generic.c
> +++ b/drivers/ide/ide-generic.c
> @@ -96,6 +96,33 @@ static int __init ide_generic_init(void)
>  		printk(KERN_INFO DRV_NAME ": please use \"probe_mask=0x3f\" "
>  		     "module parameter for probing all legacy ISA IDE ports\n");
>  
> +		/* Here the logic seems reversed, but it's not. *primary would
> +		 * be 1 if there is a device at 0x1f0 and *secondary would be 1
> +		 * if a device is detected at 0x170.
> +		 *
> +		 * However, the main intention here is to not allow PCI IDE devices
> +		 * using ide-generic unless the user chooses so, as this driver is
> +		 * designed to support ISA IDE devices mainly.

designed to support legacy ISA IDE devices that don't have chipset specific
support.

> +		 *
> +		 * In this case, users are strongly encouraged to use the designated
> +		 * PCI IDE driver, and not isa-generic.

PCI IDE drivers, and not ide-generic.

> +		 *
> +		 * Pure ISA IDE devices OTOH will use ide-generic. In this case, *primary
> +		 * and *secondary will return from ide_generic_check_pci_legacy_iobases()
> +		 * with zero (because they are not PCI...), and probe_mask will be set
> +		 * accordingly (to 0x01, 0x02 or 0x03, depending on which io ports are
> +		 * present).
> +		 *
> +		 * Users would even use ide-generic with such PCI IDE devices, choosing a

Users who would like to use ide-generic with PCI IDE devices (which is not
recommended) should choose a

> +		 * nonzero value for probe_mask when initializing ide-generic. Using
> +		 * probe_mask=0x03 is sufficient to make it detect common IDE interfaces
> +		 * (with primary at 0x1f0 and secondary at 0x170), but in the more
> +		 * general case, one should set probe_mask to 0x3f to check all possible
> +		 * io addresses. In this case, it is up to the user the task of checking

IO addresses. When using probe_mask it is up to the user to check

> +		 * for eventual conflicts between ide-generic and any other driver and
> +		 * manage those conflicts properly.
> +		 */
> +
>  		if (primary == 0)
>  			probe_mask |= 0x1;

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


^ permalink raw reply

* Re: [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Sergei Shtylyov @ 2017-02-21 15:52 UTC (permalink / raw)
  To: Luiz Carlos Ramos, linux-ide
  Cc: Bartlomiej Zolnierkiewicz, David Miller, petkovbb
In-Reply-To: <20170221142249.GC11234@giustizia>

On 02/21/2017 05:22 PM, Luiz Carlos Ramos wrote:

> Two messages are now displayed (at "warn" level) to make sure the user
> is aware that PCI IDE devices were detected at common addresses (0x1f0
> and 0x170) and that they will not be managed by ide-generic, but rather
> delegated to its specific driver.
>
> Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
> ---
>  drivers/ide/ide-generic.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> index ee11edcdba3170c077381d603918498d79ffa3bb..2204819ef73612deed4ebfe58c69cdadb40fa53b 100644
> --- a/drivers/ide/ide-generic.c
> +++ b/drivers/ide/ide-generic.c
> @@ -125,9 +125,19 @@ static int __init ide_generic_init(void)
>
>  		if (primary == 0)
>  			probe_mask |= 0x1;
> +		else {
> +			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."

    Also, please use pr_warn().

> +			     " ide-generic will not grab this device, delegating it to"
> +			     " the driver of its specific chipset\n", 0x1f0);
> +		}
>
>  		if (secondary == 0)
>  			probe_mask |= 0x2;
> +		else {
> +			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."

    Likewise.

> +			     " ide-generic will not grab this device, delegating it to"
> +			     " the driver of its specific chipset\n", 0x170);
> +		}
>  	} else
>  		printk(KERN_INFO DRV_NAME ": enforcing probing of I/O ports "
>  			"upon user request\n");

MBR, Sergei


^ permalink raw reply

* Re: [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Sergei Shtylyov @ 2017-02-21 15:31 UTC (permalink / raw)
  To: Luiz Carlos Ramos, linux-ide
  Cc: Bartlomiej Zolnierkiewicz, David Miller, petkovbb
In-Reply-To: <20170221142249.GC11234@giustizia>

Hello.

On 02/21/2017 05:22 PM, Luiz Carlos Ramos wrote:

> Two messages are now displayed (at "warn" level) to make sure the user
> is aware that PCI IDE devices were detected at common addresses (0x1f0
> and 0x170) and that they will not be managed by ide-generic, but rather
> delegated to its specific driver.
>
> Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
> ---
>  drivers/ide/ide-generic.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
> index ee11edcdba3170c077381d603918498d79ffa3bb..2204819ef73612deed4ebfe58c69cdadb40fa53b 100644
> --- a/drivers/ide/ide-generic.c
> +++ b/drivers/ide/ide-generic.c
> @@ -125,9 +125,19 @@ static int __init ide_generic_init(void)
>
>  		if (primary == 0)
>  			probe_mask |= 0x1;
> +		else {

    CodingStyle: need {} in both *if* branches if at least one branch has them.

> +			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> +			     " ide-generic will not grab this device, delegating it to"
> +			     " the driver of its specific chipset\n", 0x1f0);

    The messages shouldn't be split -- checkpatch.pl knows about that.

> +		}
>
>  		if (secondary == 0)
>  			probe_mask |= 0x2;
> +		else {
> +			printk(KERN_WARN DRV_NAME ": PCI IDE device detected at 0x%4.4x."
> +			     " ide-generic will not grab this device, delegating it to"
> +			     " the driver of its specific chipset\n", 0x170);
> +		}

    Same here.

[..]

MBR, Sergei


^ 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