* 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
* [PATCH 2/2] ide-generic: added messages in case of PCI IDE devices
From: Luiz Carlos Ramos @ 2017-02-21 14:22 UTC (permalink / raw)
To: linux-ide; +Cc: Bartlomiej Zolnierkiewicz, David Miller, petkovbb
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."
+ " 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."
+ " 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");
--
2.8.2
^ permalink raw reply related
* [PATCH 1/2] ide-generic: add some notes to clarify probing PCI devices
From: Luiz Carlos Ramos @ 2017-02-21 14:22 UTC (permalink / raw)
To: linux-ide; +Cc: Bartlomiej Zolnierkiewicz, David Miller, petkovbb
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>
---
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.
+ *
+ * In this case, users are strongly encouraged to use the designated
+ * PCI IDE driver, and not isa-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
+ * 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
+ * for eventual conflicts between ide-generic and any other driver and
+ * manage those conflicts properly.
+ */
+
if (primary == 0)
probe_mask |= 0x1;
--
2.8.2
^ permalink raw reply related
* Re: [PATCH] Fix interface autodetection in legacy IDE driver (trial #2)
From: Luiz Carlos Ramos @ 2017-02-21 14:22 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: David Miller, linux-ide, petkovbb
In-Reply-To: <2007222.eymCZIUvPG@amdc3058>
Hi, Bartlomiej, David and list!
On Fri, Dec 30, 2016 at 05:05:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> [ Your mails don't make it into linux-ide mailing list for some reason
> (the reason why I have not seen your patch before Dave applied it). ]
>
> On Thursday, December 29, 2016 10:52:33 PM Luiz Carlos Ramos wrote:
> > Hi,
> >
> > I think I could catch the whole picture after your explanation. I'll try
> > to summarize all the points discussed below in the body.
> >
> > My suggestion now is to drop the current (proposed) patch and substitute
> > it for a pure "documentational" patch, as it seems for me that a
> > programmer new to that subsystem - as the case of myself - tends to find
> > ide-generic.c buggy, if analyzed out of the whole context. Some more
> > inline documentation may help all of us IMHO.
>
> I agree. BTW ide-generic is a bad name (my fault), it should have been
> ide-isa or (better) ide-legacy.
>
> > Of course improving the printed messages - as suggested - can help as well.
> >
> > I'd like to hear from David (cc'ed) about this suggestion. What would you David
> > suggest?
> >
> > Anyway, there is a "break of the contract" with the old patch which
> > introduced the search for the IDE interfaces. Before, it was not necessary
> > to specify probe_mask=0x03 or like to make ide-generic find something in
> > I/O addresses 0x1f0 and 0x170 (I wrongly wrote 0x1e0 in the former emails;
> > please apologize me for that mistake). But this contract break seems to be
> > justifiable on the grounds that - by a design decision - users "are encouraged"
> > to use the designated drivers as a basic axiom. I suppose (or I hope) this
> > was discussed at that time and this decision was taken consciously.
>
> Yes, it was a conscious decision.
>
> > On Wed, Dec 28, 2016 at 12:10:16PM +0100, Bartlomiej Zolnierkiewicz wrote:
> >
> > > > > > >> > > This humble patch was sent one or two months before, and had no actions,
> > > > > > >> > > except for a colleague reply which friendly pointed out some formatting
> > > > > > >> > > problems (which were solved in a second message).
> > > > > > >> > >
> > > > > > >> > > It relates to an old code, the legacy IDE driver, but the bug it
> > > > > > >> > > addresses is real. The code, although rarely used, is
> > > > > > >> > > still there to be compiled if one chooses to do so (like me).
> > > > > > >> > >
> > > > > > >> > > Also, the fix has a very low risk of present collateral effects IMHO.
> > > > > > >> > > It is already compiled and tested in some embedded machines.
> > > > > > >> > >
> > > > > > >> > > So, again IMHO, it is worth be fixed.
> > > > > > >> > >
> > > > > > >> > > This email is a second trial with it. I hope it can help the one or two
> > > > > > >> > > guys out there which are still running the legacy IDE driver and
> > > > > > >> > > haven't noticed the former email.
> > > > > > >> > >
> > > > > > >> > > Best regards,
> > > > > > >> > >
> > > > > > >> > > Signed-off-by: Luiz Carlos Ramos <lramos.prof@yahoo.com.br>
> > > > > > >> >
> > > > > > >> > This bug was introduced by commit
> > > > > > >> > 20df429dd6671804999493baf2952f82582869fa ("ide-generic: handle probing
> > > > > > >> > of legacy io-ports v5") which seems poorly tested.
> > > > > > >>
> > > > > > >> Please always cc: the original commit author.
> > > > > > >>
> > > > > > >> > Applied and queued up for -stable, th anks.
> > > > > > >>
> > > > > > >> For some reason I've never got the discussed patch from
> > > > > > >> linux-ide ML though I now have found in the patchwork:
> > > > > > >>
> > > > > > >> https://patchwork.ozlabs.org/patch/680975/
> > > > > > >>
> > > > > > >> The patch is incorrect. If you have PCI IDE devices (like in
> > > >
> > > > I think all of you have checked the code, but I will try to describe
> > > > what I'm seeing.
> > > >
> > > > The routine ide_generic_check_pci_legacy_iobases() returns *primary
> > > > equal to 1 if some PCI IDE resource is found at 0x1f0, and *secondary
> > > > equal to 1 if some PCI IDE resource is found at 0x1e0. The same
> > > > routine doesn't change neither *primary not *secondary if nothing is
> > > > found. The only caller - ide_generic_init() - initializes both to zero
> > > > before the call.
> > > >
> > > > So, ide_generic_init() should test *primary for 1 in the case of an
> > > > existing IDE primary resource, and *secondary for 1 in the case of a
> > > > secondary IDE resource.
> > > >
> > > > Unpatched code checks both for zero in order to set the proper bits in
> > > > probe_mask, and IMHO this is reversed logic.
> > >
> > > Unpatched code is correct.
> > >
> > > If PCI IDE resource is found we shouldn't do the probe automatically
> > > as ide-generic is not the proper driver to run the hardware. IOW we
> > > only want to do automatic probe if no PCI IDE resources are found (if
> > > primary/secondary == 0). In such case we are most likely running on
> > > pre-PCI system and should be probing for legacy ISA IDE ports. Please
> > > note they are are using the same I/O resources as PCI IDE ones (!).
> > >
> >
> > Understood. ide-generic should not use devices which have a PCI
> > interface, unless the user tells it to do it (using probe_mask!=0).
> >
> > The basic assumption - as stated I think in your first reply - is that
> > by design, users should use the driver more suitable for the chipset, if
> > it has a PCI interface, and not ide-generic.
> >
> > I think this assumption should be highlighted as an axiom, or a design
> > decision. Otherwise, one could argue in favor of enabling ide-generic as a first
> > option for handling the IDE interface, be that PCI or IDE.
> >
> > Also is supposed that this decision is not subject to discussion (now).
>
> You are correct, also IDE subsystem is now in deep maintenance mode.
>
> > > > > > >> The patch is incorrect. If you have PCI IDE devices (like in
> > > > > > >> the case described in the situation being "fixed" by the patch)
> > > > > > >> you should use the correct PCI IDE host driver for proper
> > > > > > >> operation and not ide-generic host driver (the latter still can
> > > > > > >> be used by using kernel parameters).
> > > > > > >
> > > >
> > > > Please elaborate more on this; I really haven't understood. It seems that
> > > > you're telling about PCI host driver code, which I haven't studied. I
> > > > haven't caught the whole picture.
> > > >
> > > > In my case, there are two IDE interfaces, which are at the common
> > > > addresses 0x1f0 and 0x1e0 (PCI also tells me that), and the chipset is
> > > > a CS5536. The previous kernel used in the system (2.6.16) worked with
> > > > ide-generic, and the one I'm testing now (3.18.x) doesn't bring any of
> > > > the IDE interfaces up.
> > > >
> > > > You're right in the sense I haven't compiled the CS5536 legacy host
> > > > driver code; so, I can't tell about how it works.
> > >
> > > You should be using CS5336 PCI IDE host driver (drivers/ide/cs5536.c
> > > enabled by CONFIG_BLK_DEV_CS5536 config option) for optimal performance
> > > and proper operations.
> > >
> > > CS5536 PCI IDE host driver was added in kernel v2.6.29.
> >
> > This can be one reason to not have CS5536 driver used in the first
> > version of the system (kernel 2.6.16).
>
> Please note that CS5536 is supported also in amd74xx.c host driver
> (for historical reasons) and this support was merged in 2005 in
> commit 7fab773de16ccaeb249acdc6e956a9759c68225d (kernel v2.6.15).
>
> Also even before that ide-pci-generic.c driver has been available
> which is still more suitable than ide-generic.c one for CS5536
> (it needs to be forced with "ide_pci_generic.all_generic_ide" kernel
> command line parameter).
>
> > > > Of course there are many reasons to use the correct PCI IDE host
> > > > driver, but at the end, it's up to the user to choose which one he/she will
> > > > use, and ideally any of them should work.
> > >
> > > It happens to "work" on your system because CS5536 is relatively
> > > simple and non-buggy PCI IDE chipset.
> > >
> > > In case of other PCI IDE chipsets you may not only be missing
> > > performance or some functionality - on some more quirky chipsets
> > > you may be also affecting data integrity (!).
> > >
> > > Anyway you still can use ide-generic by using kernel parameters
> > > (just add "ide_generic.probe_mask=0x03" to your kernel command line).
> > >
> >
> > As said before, this is a contract break between versions from, let's
> > say, 2006 and today's.
> >
> > Anyway, there's no way to avoid it, it we take the assumption above
> > (designated drivers prior to ide-generic) as an axiom.
> >
> > > I agree that the ide-generic could be more verbose and print more
> > > information in case of skipping the probe (patches are welcomed).
> > >
> >
> > I think this is a good idea, but more important IMHO is to document
> > properly in the code all this discussion. If I have some spare time
> > (not sure about this), I'll try to submit patches (better to have two)
> > to address both "issues".
>
> Thank you, it would be good to have this covered.
>
Two patches were prepared. The first one only documents (or tries to)
this discussion, focusing the clear understanding of the issue, for
developers. The second introduces new messages for the case where a PCI
IDE device is detected and purposedly not grabbed by ide-device. It
should help system admins to figure out more quickly what is going on
and what should be done next.
I'll send them next, in two additional emails.
Please advise me if I'm proceeding in the proper way, as I'm quite new
regarding LKMLs protocols.
> > > > > > > Moreover this patch introduces a regression. In the situation
> > > > > > > when there are no PCI IDE devices and the probing should be done
> > > > > > > automatically (for the first two legacy IDE ports) it will be no
> > > > > > > longer done.
> > > > > > >
> > > >
> > > > Again, please elaborate more on this.
> > > >
> > > > If there are no PCI IDE devices, well, there are no PCI IDE devices.
> > > > Nothing is supposed to be found. Anyway, it seems they will be searched
> > > > for, in ide_generic_check_pci_legacy_iobases(). Or I missed something
> > > > important.
> > >
> > > In case there are no PCI IDE devices we most likely are running on
> > > pre-PCI system and should be probing for legacy ISA IDE ports (please
> > > note they are are using the same I/O resources),
> > >
> >
> > Ok, that is, ide-generic is tailored to pure ISA devices, and _can_ work
> > in some PCI devices, although not guaranteed, on user request
> > (probe_mask!=0).
>
> Yes.
>
> > > > > > > Now back to the using correct PCI IDE host drivers - Luiz what
> > > > > > > are the systems that you need this patch on? Could you please
> > > > > > > get 'lspci -nn' command output from them?
> > > > > >
> > > > > > The original code before the patch in question probed the interfaces
> > > > > > unconditionally, probe_mask was a static int set to "0x03".
> > > > > >
> > > > > > Commit 20df429dd6671804999493baf2952f82582869fa changed the default
> > > > > > behavior, as well as adding a new module parameter whose behavior
> > > > > > makes no sense at all. Inverted bit logic? Give me a break.
> > > > > >
> > > > > > Sorry, no, the fix is correct and I'm pushing it to Linus.
> > > > >
> > > > > The "fix" is not correct and is not needed. 99% of users of ide-generic
> > > > > used it by mistake and should have used the designated host drivers for
> > > > > their hardware or PCI IDE generic host driver (not ide-generic one).
> > > >
> > > > My system didn't work without this patch. I agree I could use the
> > > > designated host driver, but it seems a little strong to say one _should_
> > > > use it.
> > >
> > > Sorry but one should really use the designated drivers and we don't
> > > want to see any bugreports from using ide-generic on hardware that
> > > have designated drivers.
> > >
> >
> > As said above, this is a kind of axiom, and I understand this is a
> > conscious decision made somewhere in the past.
> >
> > Avoiding extra bug reports is a smart decision, anyway.
> >
> > > > > Alan Cox did the work on fixing this for his pata_legacy libata host
> > > > > driver and later Borislav back-ported needed changes to ide-generic host
> > > > > driver in commit 20df429dd6671804999493baf2952f82582869fa (in *2008*).
> > > > >
> > > > > Also the "fix" is not a revert but a new patch which introduces a real
> > > > > regression described by me in the previous mail.
> > > > >
> > > >
> > > > As said above, it is a regression considering the versions from 2006. I
> > > > agree that for someone who used the drivers from 2009 and after, it
> > > > _may_ be a regression if she uses to bring all up with probe_mask=0.
> > >
> > > The regression I was talking about is in the proposed patch.
> > >
> > > By simply reversing the logic ISA IDE ports will no longer be probed
> > > automatically on non-PCI systems.
> > >
> >
> > Understood. It makes sense.
>
> Thank you for understanding.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Best regards,
Luiz
^ permalink raw reply
* Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
From: Bartlomiej Zolnierkiewicz @ 2017-02-20 18:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Tejun Heo, Michael Schmitz, linux-ide@vger.kernel.org, linux-m68k,
linux-kernel@vger.kernel.org, Jens Axboe, Christoph Hellwig
In-Reply-To: <CAMuHMdWX-PT_8a==rqAvc5Hx_1PNWPwvLGPeERUXvsMcEarziQ@mail.gmail.com>
Hi,
On Wednesday, February 15, 2017 09:45:53 AM Geert Uytterhoeven wrote:
> On Fri, Dec 30, 2016 at 3:01 PM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> > This patchset adds m68k/Atari Falcon PATA support to libata.
> > The major difference in the new libata's pata_falcon host
> > driver when compared to legacy IDE's falconide host driver is
> > that we are using polled PIO mode and thus avoiding the need
> > for STDMA locking magic altogether.
> >
> > Tested under ARAnyM emulator.
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> >
> > 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
>
> drivers/ata/pata_falcon.c:57:18: error: 'struct request' has no member
> named 'cmd_type'
> drivers/ata/pata_falcon.c:57:32: error: 'REQ_TYPE_FS' undeclared
> (first use in this function)
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/12936876/
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))
swap = 0;
/* Transfer multiple of 2 bytes */
^ permalink raw reply
* Re: [PATCH] pata: remove the at91 driver
From: Nicolas Ferre @ 2017-02-20 17:28 UTC (permalink / raw)
To: Boris Brezillon, Bartlomiej Zolnierkiewicz
Cc: Alexandre Belloni, Tejun Heo, linux-ide, linux-arm-kernel,
linux-kernel
In-Reply-To: <20170217144235.1fd12c80@bbrezillon>
Le 17/02/2017 à 14:42, Boris Brezillon a écrit :
> On Fri, 17 Feb 2017 13:36:08 +0100
> Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote:
>
>> Hi,
>>
>> On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote:
>>> This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove
>>> at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared
>>> adding DT support to it, it probably means it's no longer used and is
>>> thus a good candidate for removal.
>>
>> The exact commit which removed PATA support for AT91SAM9260 seems to
>> be b2026f708e09 ("ARM: at91: remove at91sam9260/at91sam9g20 legacy
>> board support").
>
> Indeed. I'll fix the commit message and send a new version.
>
>>
>>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>>
>> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 18/35] drivers/ide: Convert remaining uses of pr_warning to pr_warn
From: David Miller @ 2017-02-17 15:20 UTC (permalink / raw)
To: joe; +Cc: linux-ide, linux-kernel
In-Reply-To: <94a040b80eec22d9d2b5cf929fe06880ab0bc31a.1487314667.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Thu, 16 Feb 2017 23:11:31 -0800
> To enable eventual removal of pr_warning
>
> This makes pr_warn use consistent for drivers/ide
>
> Prior to this patch, there were 2 uses of pr_warning and
> 0 uses of pr_warn in drivers/ide
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] pata: remove the at91 driver
From: Boris Brezillon @ 2017-02-17 13:42 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Nicolas Ferre, Alexandre Belloni, Tejun Heo, linux-ide,
linux-arm-kernel, linux-kernel
In-Reply-To: <1599704.hbkP4KrUDJ@amdc3058>
On Fri, 17 Feb 2017 13:36:08 +0100
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> wrote:
> Hi,
>
> On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote:
> > This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove
> > at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared
> > adding DT support to it, it probably means it's no longer used and is
> > thus a good candidate for removal.
>
> The exact commit which removed PATA support for AT91SAM9260 seems to
> be b2026f708e09 ("ARM: at91: remove at91sam9260/at91sam9g20 legacy
> board support").
Indeed. I'll fix the commit message and send a new version.
>
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>
> Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Thanks,
Boris
^ permalink raw reply
* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Geert Uytterhoeven @ 2017-02-17 12:37 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: open list:FRAMEBUFFER LAYER, linux-ia64@vger.kernel.org,
Linux-sh list, Alexander Shishkin, nouveau,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
dri-devel, virtualization, linux-ide@vger.kernel.org,
MTD Maling List, sparclinux, Lars Ellenberg,
open list:TARGET SUBSYSTEM, Richard Weinberger, sfi-devel,
amd-gfx, ACPI Devel Maling List, tboot-devel, oprofil
In-Reply-To: <CAJZ5v0gNcGtnXpE1n6LSq7ey+UDKx+oQfmTg0_PgFwzB0Dd_5A@mail.gmail.com>
Hi Rafael,
On Fri, Feb 17, 2017 at 1:27 PM, Rafael J. Wysocki <rafael@kernel.org> wrote:
> On Fri, Feb 17, 2017 at 8: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.
>
> Sorry about asking if that has been asked already.
>
> Wouldn't it be slightly less intrusive to simply redefined
> pr_warning() as a synonym for pr_warn()?
That's already the case.
This series cleans up the cruft, so we can catch all users with
"git grep -w pr_warn".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] pata: remove the at91 driver
From: Bartlomiej Zolnierkiewicz @ 2017-02-17 12:36 UTC (permalink / raw)
To: Boris Brezillon
Cc: Nicolas Ferre, linux-kernel, linux-ide, Alexandre Belloni,
Tejun Heo, linux-arm-kernel
In-Reply-To: <1487324200-17517-1-git-send-email-boris.brezillon@free-electrons.com>
Hi,
On Friday, February 17, 2017 10:36:40 AM Boris Brezillon wrote:
> This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove
> at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared
> adding DT support to it, it probably means it's no longer used and is
> thus a good candidate for removal.
The exact commit which removed PATA support for AT91SAM9260 seems to
be b2026f708e09 ("ARM: at91: remove at91sam9260/at91sam9g20 legacy
board support").
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> Note that I'm removing this driver because I plan to rework the macro
> definitions in atmel-smc.h, and some of them are used in this driver.
> Since I can't test it, and this drivers is not used anymore, it's probably
> better to remove it.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Rafael J. Wysocki @ 2017-02-17 12:27 UTC (permalink / raw)
To: Joe Perches
Cc: Alexander Shishkin, Karol Herbst, Pekka Paalanen,
Richard Weinberger, Fabio Estevam, Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linuxppc-dev, tboot-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
oprofile-list-TtF/mJH4Jtrk1uMJSBkQmQ,
sfi-devel-yLnuTTp1/kvcsJTPyzm5gB2eb7JE58TQ,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b,
ACPI Devel Maling List, drbd-dev-cunTk1MwBs8qoQakbn7OcQ,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
gigaset307x-common-5NWGOfrQmneRv+LV9MX5uv+2+P5yyue3
In-Reply-To: <cover.1487314666.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> 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.
Sorry about asking if that has been asked already.
Wouldn't it be slightly less intrusive to simply redefined
pr_warning() as a synonym for pr_warn()?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] pata: remove the at91 driver
From: Boris Brezillon @ 2017-02-17 9:36 UTC (permalink / raw)
To: Nicolas Ferre, Alexandre Belloni, Tejun Heo,
Bartlomiej Zolnierkiewicz, linux-ide
Cc: linux-arm-kernel, linux-kernel, Boris Brezillon
This driver is orphan since commit 2e591e7b3ac2 ("ARM: at91: remove
at91sam9261/at91sam9g10 legacy board support"). Given that nobody cared
adding DT support to it, it probably means it's no longer used and is
thus a good candidate for removal.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
---
Note that I'm removing this driver because I plan to rework the macro
definitions in atmel-smc.h, and some of them are used in this driver.
Since I can't test it, and this drivers is not used anymore, it's probably
better to remove it.
---
drivers/ata/Kconfig | 8 -
drivers/ata/Makefile | 1 -
drivers/ata/pata_at91.c | 503 ------------------------------------------------
3 files changed, 512 deletions(-)
delete mode 100644 drivers/ata/pata_at91.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 2c8be74f401d..cbf871dabcb5 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -877,14 +877,6 @@ config PATA_AT32
If unsure, say N.
-config PATA_AT91
- tristate "PATA support for AT91SAM9260"
- depends on ARM && SOC_AT91SAM9
- help
- This option enables support for IDE devices on the Atmel AT91SAM9260 SoC.
-
- If unsure, say N.
-
config PATA_CMD640_PCI
tristate "CMD640 PCI PATA support (Experimental)"
depends on PCI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index a46e6b784bda..c5c09e34f2eb 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -91,7 +91,6 @@ obj-$(CONFIG_PATA_WINBOND) += pata_sl82c105.o
# SFF PIO only
obj-$(CONFIG_PATA_AT32) += pata_at32.o
-obj-$(CONFIG_PATA_AT91) += pata_at91.o
obj-$(CONFIG_PATA_CMD640_PCI) += pata_cmd640.o
obj-$(CONFIG_PATA_ISAPNP) += pata_isapnp.o
obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
diff --git a/drivers/ata/pata_at91.c b/drivers/ata/pata_at91.c
deleted file mode 100644
index 1611e0e8d767..000000000000
--- a/drivers/ata/pata_at91.c
+++ /dev/null
@@ -1,503 +0,0 @@
-/*
- * PATA driver for AT91SAM9260 Static Memory Controller
- * with CompactFlash interface in True IDE mode
- *
- * Copyright (C) 2009 Matyukevich Sergey
- * 2011 Igor Plyatov
- *
- * Based on:
- * * generic platform driver by Paul Mundt: drivers/ata/pata_platform.c
- * * pata_at32 driver by Kristoffer Nyborg Gregertsen
- * * at91_ide driver by Stanislaw Gruszka
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2
- * as published by the Free Software Foundation.
- *
- */
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/blkdev.h>
-#include <linux/gfp.h>
-#include <scsi/scsi_host.h>
-#include <linux/ata.h>
-#include <linux/clk.h>
-#include <linux/libata.h>
-#include <linux/mfd/syscon.h>
-#include <linux/mfd/syscon/atmel-smc.h>
-#include <linux/platform_device.h>
-#include <linux/ata_platform.h>
-#include <linux/platform_data/atmel.h>
-#include <linux/regmap.h>
-#include <linux/gpio.h>
-
-#define DRV_NAME "pata_at91"
-#define DRV_VERSION "0.3"
-
-#define CF_IDE_OFFSET 0x00c00000
-#define CF_ALT_IDE_OFFSET 0x00e00000
-#define CF_IDE_RES_SIZE 0x08
-#define CS_PULSE_MAXIMUM 319
-#define ER_SMC_CALC 1
-#define ER_SMC_RECALC 2
-
-struct at91_ide_info {
- unsigned long mode;
- unsigned int cs;
- struct clk *mck;
- void __iomem *ide_addr;
- void __iomem *alt_addr;
-};
-
-/**
- * struct smc_range - range of valid values for SMC register.
- */
-struct smc_range {
- int min;
- int max;
-};
-
-struct regmap *smc;
-
-struct at91sam9_smc_generic_fields {
- struct regmap_field *setup;
- struct regmap_field *pulse;
- struct regmap_field *cycle;
- struct regmap_field *mode;
-} fields;
-
-/**
- * adjust_smc_value - adjust value for one of SMC registers.
- * @value: adjusted value
- * @range: array of SMC ranges with valid values
- * @size: SMC ranges array size
- *
- * This returns the difference between input and output value or negative
- * in case of invalid input value.
- * If negative returned, then output value = maximal possible from ranges.
- */
-static int adjust_smc_value(int *value, struct smc_range *range, int size)
-{
- int maximum = (range + size - 1)->max;
- int remainder;
-
- do {
- if (*value < range->min) {
- remainder = range->min - *value;
- *value = range->min; /* nearest valid value */
- return remainder;
- } else if ((range->min <= *value) && (*value <= range->max))
- return 0;
-
- range++;
- } while (--size);
- *value = maximum;
-
- return -1; /* invalid value */
-}
-
-/**
- * calc_smc_vals - calculate SMC register values
- * @dev: ATA device
- * @setup: SMC_SETUP register value
- * @pulse: SMC_PULSE register value
- * @cycle: SMC_CYCLE register value
- *
- * This returns negative in case of invalid values for SMC registers:
- * -ER_SMC_RECALC - recalculation required for SMC values,
- * -ER_SMC_CALC - calculation failed (invalid input values).
- *
- * SMC use special coding scheme, see "Coding and Range of Timing
- * Parameters" table from AT91SAM9 datasheets.
- *
- * SMC_SETUP = 128*setup[5] + setup[4:0]
- * SMC_PULSE = 256*pulse[6] + pulse[5:0]
- * SMC_CYCLE = 256*cycle[8:7] + cycle[6:0]
- */
-static int calc_smc_vals(struct device *dev,
- int *setup, int *pulse, int *cycle, int *cs_pulse)
-{
- int ret_val;
- int err = 0;
- struct smc_range range_setup[] = { /* SMC_SETUP valid values */
- {.min = 0, .max = 31}, /* first range */
- {.min = 128, .max = 159} /* second range */
- };
- struct smc_range range_pulse[] = { /* SMC_PULSE valid values */
- {.min = 0, .max = 63}, /* first range */
- {.min = 256, .max = 319} /* second range */
- };
- struct smc_range range_cycle[] = { /* SMC_CYCLE valid values */
- {.min = 0, .max = 127}, /* first range */
- {.min = 256, .max = 383}, /* second range */
- {.min = 512, .max = 639}, /* third range */
- {.min = 768, .max = 895} /* fourth range */
- };
-
- ret_val = adjust_smc_value(setup, range_setup, ARRAY_SIZE(range_setup));
- if (ret_val < 0)
- dev_warn(dev, "maximal SMC Setup value\n");
- else
- *cycle += ret_val;
-
- ret_val = adjust_smc_value(pulse, range_pulse, ARRAY_SIZE(range_pulse));
- if (ret_val < 0)
- dev_warn(dev, "maximal SMC Pulse value\n");
- else
- *cycle += ret_val;
-
- ret_val = adjust_smc_value(cycle, range_cycle, ARRAY_SIZE(range_cycle));
- if (ret_val < 0)
- dev_warn(dev, "maximal SMC Cycle value\n");
-
- *cs_pulse = *cycle;
- if (*cs_pulse > CS_PULSE_MAXIMUM) {
- dev_err(dev, "unable to calculate valid SMC settings\n");
- return -ER_SMC_CALC;
- }
-
- ret_val = adjust_smc_value(cs_pulse, range_pulse,
- ARRAY_SIZE(range_pulse));
- if (ret_val < 0) {
- dev_warn(dev, "maximal SMC CS Pulse value\n");
- } else if (ret_val != 0) {
- *cycle = *cs_pulse;
- dev_warn(dev, "SMC Cycle extended\n");
- err = -ER_SMC_RECALC;
- }
-
- return err;
-}
-
-/**
- * to_smc_format - convert values into SMC format
- * @setup: SETUP value of SMC Setup Register
- * @pulse: PULSE value of SMC Pulse Register
- * @cycle: CYCLE value of SMC Cycle Register
- * @cs_pulse: NCS_PULSE value of SMC Pulse Register
- */
-static void to_smc_format(int *setup, int *pulse, int *cycle, int *cs_pulse)
-{
- *setup = (*setup & 0x1f) | ((*setup & 0x80) >> 2);
- *pulse = (*pulse & 0x3f) | ((*pulse & 0x100) >> 2);
- *cycle = (*cycle & 0x7f) | ((*cycle & 0x300) >> 1);
- *cs_pulse = (*cs_pulse & 0x3f) | ((*cs_pulse & 0x100) >> 2);
-}
-
-static unsigned long calc_mck_cycles(unsigned long ns, unsigned long mck_hz)
-{
- unsigned long mul;
-
- /*
- * cycles = x [nsec] * f [Hz] / 10^9 [ns in sec] =
- * x * (f / 1_000_000_000) =
- * x * ((f * 65536) / 1_000_000_000) / 65536 =
- * x * (((f / 10_000) * 65536) / 100_000) / 65536 =
- */
-
- mul = (mck_hz / 10000) << 16;
- mul /= 100000;
-
- return (ns * mul + 65536) >> 16; /* rounding */
-}
-
-/**
- * set_smc_timing - SMC timings setup.
- * @dev: device
- * @info: AT91 IDE info
- * @ata: ATA timings
- *
- * Its assumed that write timings are same as read timings,
- * cs_setup = 0 and cs_pulse = cycle.
- */
-static void set_smc_timing(struct device *dev, struct ata_device *adev,
- struct at91_ide_info *info, const struct ata_timing *ata)
-{
- int ret = 0;
- int use_iordy;
- unsigned int t6z; /* data tristate time in ns */
- unsigned int cycle; /* SMC Cycle width in MCK ticks */
- unsigned int setup; /* SMC Setup width in MCK ticks */
- unsigned int pulse; /* CFIOR and CFIOW pulse width in MCK ticks */
- unsigned int cs_pulse; /* CS4 or CS5 pulse width in MCK ticks*/
- unsigned int tdf_cycles; /* SMC TDF MCK ticks */
- unsigned long mck_hz; /* MCK frequency in Hz */
-
- t6z = (ata->mode < XFER_PIO_5) ? 30 : 20;
- mck_hz = clk_get_rate(info->mck);
- cycle = calc_mck_cycles(ata->cyc8b, mck_hz);
- setup = calc_mck_cycles(ata->setup, mck_hz);
- pulse = calc_mck_cycles(ata->act8b, mck_hz);
- tdf_cycles = calc_mck_cycles(t6z, mck_hz);
-
- do {
- ret = calc_smc_vals(dev, &setup, &pulse, &cycle, &cs_pulse);
- } while (ret == -ER_SMC_RECALC);
-
- if (ret == -ER_SMC_CALC)
- dev_err(dev, "Interface may not operate correctly\n");
-
- dev_dbg(dev, "SMC Setup=%u, Pulse=%u, Cycle=%u, CS Pulse=%u\n",
- setup, pulse, cycle, cs_pulse);
- to_smc_format(&setup, &pulse, &cycle, &cs_pulse);
- /* disable or enable waiting for IORDY signal */
- use_iordy = ata_pio_need_iordy(adev);
- if (use_iordy)
- info->mode |= AT91_SMC_EXNWMODE_READY;
-
- if (tdf_cycles > 15) {
- tdf_cycles = 15;
- dev_warn(dev, "maximal SMC TDF Cycles value\n");
- }
-
- dev_dbg(dev, "Use IORDY=%u, TDF Cycles=%u\n", use_iordy, tdf_cycles);
-
- regmap_fields_write(fields.setup, info->cs,
- AT91SAM9_SMC_NRDSETUP(setup) |
- AT91SAM9_SMC_NWESETUP(setup) |
- AT91SAM9_SMC_NCS_NRDSETUP(0) |
- AT91SAM9_SMC_NCS_WRSETUP(0));
- regmap_fields_write(fields.pulse, info->cs,
- AT91SAM9_SMC_NRDPULSE(pulse) |
- AT91SAM9_SMC_NWEPULSE(pulse) |
- AT91SAM9_SMC_NCS_NRDPULSE(cs_pulse) |
- AT91SAM9_SMC_NCS_WRPULSE(cs_pulse));
- regmap_fields_write(fields.cycle, info->cs,
- AT91SAM9_SMC_NRDCYCLE(cycle) |
- AT91SAM9_SMC_NWECYCLE(cycle));
- regmap_fields_write(fields.mode, info->cs, info->mode |
- AT91_SMC_TDF_(tdf_cycles));
-}
-
-static void pata_at91_set_piomode(struct ata_port *ap, struct ata_device *adev)
-{
- struct at91_ide_info *info = ap->host->private_data;
- struct ata_timing timing;
- int ret;
-
- /* Compute ATA timing and set it to SMC */
- ret = ata_timing_compute(adev, adev->pio_mode, &timing, 1000, 0);
- if (ret) {
- dev_warn(ap->dev, "Failed to compute ATA timing %d, "
- "set PIO_0 timing\n", ret);
- timing = *ata_timing_find_mode(XFER_PIO_0);
- }
- set_smc_timing(ap->dev, adev, info, &timing);
-}
-
-static unsigned int pata_at91_data_xfer_noirq(struct ata_device *dev,
- unsigned char *buf, unsigned int buflen, int rw)
-{
- struct at91_ide_info *info = dev->link->ap->host->private_data;
- unsigned int consumed;
- unsigned int mode;
- unsigned long flags;
-
- local_irq_save(flags);
- regmap_fields_read(fields.mode, info->cs, &mode);
-
- /* set 16bit mode before writing data */
- regmap_fields_write(fields.mode, info->cs, (mode & ~AT91_SMC_DBW) |
- AT91_SMC_DBW_16);
-
- consumed = ata_sff_data_xfer(dev, buf, buflen, rw);
-
- /* restore 8bit mode after data is written */
- regmap_fields_write(fields.mode, info->cs, (mode & ~AT91_SMC_DBW) |
- AT91_SMC_DBW_8);
-
- local_irq_restore(flags);
- return consumed;
-}
-
-static struct scsi_host_template pata_at91_sht = {
- ATA_PIO_SHT(DRV_NAME),
-};
-
-static struct ata_port_operations pata_at91_port_ops = {
- .inherits = &ata_sff_port_ops,
-
- .sff_data_xfer = pata_at91_data_xfer_noirq,
- .set_piomode = pata_at91_set_piomode,
- .cable_detect = ata_cable_40wire,
-};
-
-static int at91sam9_smc_fields_init(struct device *dev)
-{
- struct reg_field field = REG_FIELD(0, 0, 31);
-
- field.id_size = 8;
- field.id_offset = AT91SAM9_SMC_GENERIC_BLK_SZ;
-
- field.reg = AT91SAM9_SMC_SETUP(AT91SAM9_SMC_GENERIC);
- fields.setup = devm_regmap_field_alloc(dev, smc, field);
- if (IS_ERR(fields.setup))
- return PTR_ERR(fields.setup);
-
- field.reg = AT91SAM9_SMC_PULSE(AT91SAM9_SMC_GENERIC);
- fields.pulse = devm_regmap_field_alloc(dev, smc, field);
- if (IS_ERR(fields.pulse))
- return PTR_ERR(fields.pulse);
-
- field.reg = AT91SAM9_SMC_CYCLE(AT91SAM9_SMC_GENERIC);
- fields.cycle = devm_regmap_field_alloc(dev, smc, field);
- if (IS_ERR(fields.cycle))
- return PTR_ERR(fields.cycle);
-
- field.reg = AT91SAM9_SMC_MODE(AT91SAM9_SMC_GENERIC);
- fields.mode = devm_regmap_field_alloc(dev, smc, field);
-
- return PTR_ERR_OR_ZERO(fields.mode);
-}
-
-static int pata_at91_probe(struct platform_device *pdev)
-{
- struct at91_cf_data *board = dev_get_platdata(&pdev->dev);
- struct device *dev = &pdev->dev;
- struct at91_ide_info *info;
- struct resource *mem_res;
- struct ata_host *host;
- struct ata_port *ap;
-
- int irq_flags = 0;
- int irq = 0;
- int ret;
-
- /* get platform resources: IO/CTL memories and irq/rst pins */
-
- if (pdev->num_resources != 1) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- if (!mem_res) {
- dev_err(dev, "failed to get mem resource\n");
- return -EINVAL;
- }
-
- irq = board->irq_pin;
-
- smc = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "atmel,smc");
- if (IS_ERR(smc))
- return PTR_ERR(smc);
-
- ret = at91sam9_smc_fields_init(dev);
- if (ret < 0)
- return ret;
-
- /* init ata host */
-
- host = ata_host_alloc(dev, 1);
-
- if (!host)
- return -ENOMEM;
-
- ap = host->ports[0];
- ap->ops = &pata_at91_port_ops;
- ap->flags |= ATA_FLAG_SLAVE_POSS;
- ap->pio_mask = ATA_PIO4;
-
- if (!gpio_is_valid(irq)) {
- ap->flags |= ATA_FLAG_PIO_POLLING;
- ata_port_desc(ap, "no IRQ, using PIO polling");
- }
-
- info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
-
- if (!info) {
- dev_err(dev, "failed to allocate memory for private data\n");
- return -ENOMEM;
- }
-
- info->mck = clk_get(NULL, "mck");
-
- if (IS_ERR(info->mck)) {
- dev_err(dev, "failed to get access to mck clock\n");
- return -ENODEV;
- }
-
- info->cs = board->chipselect;
- info->mode = AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
- AT91_SMC_EXNWMODE_READY | AT91_SMC_BAT_SELECT |
- AT91_SMC_DBW_8 | AT91_SMC_TDF_(0);
-
- info->ide_addr = devm_ioremap(dev,
- mem_res->start + CF_IDE_OFFSET, CF_IDE_RES_SIZE);
-
- if (!info->ide_addr) {
- dev_err(dev, "failed to map IO base\n");
- ret = -ENOMEM;
- goto err_put;
- }
-
- info->alt_addr = devm_ioremap(dev,
- mem_res->start + CF_ALT_IDE_OFFSET, CF_IDE_RES_SIZE);
-
- if (!info->alt_addr) {
- dev_err(dev, "failed to map CTL base\n");
- ret = -ENOMEM;
- goto err_put;
- }
-
- ap->ioaddr.cmd_addr = info->ide_addr;
- ap->ioaddr.ctl_addr = info->alt_addr + 0x06;
- ap->ioaddr.altstatus_addr = ap->ioaddr.ctl_addr;
-
- ata_sff_std_ports(&ap->ioaddr);
-
- ata_port_desc(ap, "mmio cmd 0x%llx ctl 0x%llx",
- (unsigned long long)mem_res->start + CF_IDE_OFFSET,
- (unsigned long long)mem_res->start + CF_ALT_IDE_OFFSET);
-
- host->private_data = info;
-
- ret = ata_host_activate(host, gpio_is_valid(irq) ? gpio_to_irq(irq) : 0,
- gpio_is_valid(irq) ? ata_sff_interrupt : NULL,
- irq_flags, &pata_at91_sht);
- if (ret)
- goto err_put;
-
- return 0;
-
-err_put:
- clk_put(info->mck);
- return ret;
-}
-
-static int pata_at91_remove(struct platform_device *pdev)
-{
- struct ata_host *host = platform_get_drvdata(pdev);
- struct at91_ide_info *info;
-
- if (!host)
- return 0;
- info = host->private_data;
-
- ata_host_detach(host);
-
- if (!info)
- return 0;
-
- clk_put(info->mck);
-
- return 0;
-}
-
-static struct platform_driver pata_at91_driver = {
- .probe = pata_at91_probe,
- .remove = pata_at91_remove,
- .driver = {
- .name = DRV_NAME,
- },
-};
-
-module_platform_driver(pata_at91_driver);
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("Driver for CF in True IDE mode on AT91SAM9260 SoC");
-MODULE_AUTHOR("Matyukevich Sergey");
-MODULE_VERSION(DRV_VERSION);
-
--
2.7.4
^ permalink raw reply related
* [PATCH 18/35] drivers/ide: Convert remaining uses of pr_warning to pr_warn
From: Joe Perches @ 2017-02-17 7:11 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-ide, linux-kernel
In-Reply-To: <cover.1487314666.git.joe@perches.com>
To enable eventual removal of pr_warning
This makes pr_warn use consistent for drivers/ide
Prior to this patch, there were 2 uses of pr_warning and
0 uses of pr_warn in drivers/ide
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/ide/tx4938ide.c | 2 +-
drivers/ide/tx4939ide.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/ide/tx4938ide.c b/drivers/ide/tx4938ide.c
index 40a3f55b08dd..962eb92501b5 100644
--- a/drivers/ide/tx4938ide.c
+++ b/drivers/ide/tx4938ide.c
@@ -46,7 +46,7 @@ static void tx4938ide_tune_ebusc(unsigned int ebus_ch,
while ((shwt * 4 + wt + (wt ? 2 : 3)) * cycle < t->cycle)
shwt++;
if (shwt > 7) {
- pr_warning("tx4938ide: SHWT violation (%d)\n", shwt);
+ pr_warn("tx4938ide: SHWT violation (%d)\n", shwt);
shwt = 7;
}
pr_debug("tx4938ide: ebus %d, bus cycle %dns, WT %d, SHWT %d\n",
diff --git a/drivers/ide/tx4939ide.c b/drivers/ide/tx4939ide.c
index 67d4a7d4acc8..7fa4ff6fc099 100644
--- a/drivers/ide/tx4939ide.c
+++ b/drivers/ide/tx4939ide.c
@@ -364,9 +364,8 @@ static int tx4939ide_dma_test_irq(ide_drive_t *drive)
case TX4939IDE_INT_HOST | TX4939IDE_INT_XFEREND:
dma_stat = tx4939ide_readb(base, TX4939IDE_DMA_Stat);
if (!(dma_stat & ATA_DMA_INTR))
- pr_warning("%s: weird interrupt status. "
- "DMA_Stat %#02x int_ctl %#04x\n",
- hwif->name, dma_stat, ctl);
+ pr_warn("%s: weird interrupt status. DMA_Stat %#02x int_ctl %#04x\n",
+ hwif->name, dma_stat, ctl);
found = 1;
break;
}
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn
From: Joe Perches @ 2017-02-17 7:11 UTC (permalink / raw)
To: Alexander Shishkin, Karol Herbst, Pekka Paalanen,
Richard Weinberger, Fabio Estevam, linux-kernel, linux-arm-kernel,
linuxppc-dev, tboot-devel, nouveau, oprofile-list, sfi-devel,
xen-devel, linux-acpi, drbd-dev, virtualization, linux-crypto,
linux-ide, gigaset307x-common, linux-media, linux-omap, linux-mtd,
devicetree, acpi4asus-user, platform-driver-x86, linux-scsi
Cc: linux-ia64, linux-sh, netdev, linux-input, adi-buildroot-devel,
amd-gfx, dri-devel, linux-alpha, sparclinux
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
arch/alpha/kernel/perf_event.c | 4 +-
arch/arm/mach-ep93xx/core.c | 4 +-
arch/arm64/include/asm/syscall.h | 8 ++--
arch/arm64/kernel/hw_breakpoint.c | 8 ++--
arch/arm64/kernel/smp.c | 4 +-
arch/blackfin/kernel/nmi.c | 2 +-
arch/blackfin/kernel/ptrace.c | 2 +-
arch/blackfin/mach-bf533/boards/stamp.c | 2 +-
arch/blackfin/mach-bf537/boards/cm_bf537e.c | 2 +-
arch/blackfin/mach-bf537/boards/cm_bf537u.c | 2 +-
arch/blackfin/mach-bf537/boards/stamp.c | 2 +-
arch/blackfin/mach-bf537/boards/tcm_bf537.c | 2 +-
arch/blackfin/mach-bf561/boards/cm_bf561.c | 2 +-
arch/blackfin/mach-bf561/boards/ezkit.c | 2 +-
arch/blackfin/mm/isram-driver.c | 4 +-
arch/ia64/kernel/setup.c | 6 +--
arch/powerpc/kernel/pci-common.c | 4 +-
arch/powerpc/mm/init_64.c | 5 +--
arch/powerpc/mm/mem.c | 3 +-
arch/powerpc/platforms/512x/mpc512x_shared.c | 4 +-
arch/powerpc/platforms/85xx/socrates_fpga_pic.c | 7 ++--
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 +-
arch/powerpc/platforms/pasemi/dma_lib.c | 4 +-
arch/powerpc/platforms/powernv/opal.c | 8 ++--
arch/powerpc/platforms/powernv/pci-ioda.c | 10 ++---
arch/powerpc/platforms/ps3/device-init.c | 14 +++----
arch/powerpc/platforms/ps3/mm.c | 4 +-
arch/powerpc/platforms/ps3/os-area.c | 2 +-
arch/powerpc/platforms/pseries/iommu.c | 8 ++--
arch/powerpc/platforms/pseries/setup.c | 4 +-
arch/powerpc/sysdev/fsl_pci.c | 9 ++---
arch/powerpc/sysdev/mpic.c | 10 ++---
arch/powerpc/sysdev/xics/icp-native.c | 10 ++---
arch/powerpc/sysdev/xics/ics-opal.c | 4 +-
arch/powerpc/sysdev/xics/ics-rtas.c | 4 +-
arch/powerpc/sysdev/xics/xics-common.c | 8 ++--
arch/sh/boards/mach-sdk7786/nmi.c | 2 +-
arch/sh/drivers/pci/fixups-sdk7786.c | 2 +-
arch/sh/kernel/io_trapped.c | 2 +-
arch/sh/kernel/setup.c | 2 +-
arch/sh/mm/consistent.c | 5 +--
arch/sparc/kernel/smp_64.c | 5 +--
arch/x86/kernel/amd_gart_64.c | 12 ++----
arch/x86/kernel/apic/apic.c | 46 ++++++++++------------
arch/x86/kernel/apic/apic_noop.c | 2 +-
arch/x86/kernel/setup_percpu.c | 4 +-
arch/x86/kernel/tboot.c | 15 ++++---
arch/x86/kernel/tsc_sync.c | 8 ++--
arch/x86/mm/kmmio.c | 8 ++--
arch/x86/mm/mmio-mod.c | 5 +--
arch/x86/mm/numa.c | 12 +++---
arch/x86/mm/numa_emulation.c | 6 +--
arch/x86/mm/testmmiotrace.c | 5 +--
arch/x86/oprofile/op_x86_model.h | 6 +--
arch/x86/platform/olpc/olpc-xo15-sci.c | 2 +-
arch/x86/platform/sfi/sfi.c | 3 +-
arch/x86/xen/debugfs.c | 2 +-
arch/x86/xen/setup.c | 2 +-
drivers/acpi/apei/apei-base.c | 32 +++++++--------
drivers/acpi/apei/einj.c | 4 +-
drivers/acpi/apei/erst-dbg.c | 4 +-
drivers/acpi/apei/ghes.c | 30 +++++++-------
drivers/acpi/apei/hest.c | 10 ++---
drivers/acpi/resource.c | 4 +-
drivers/block/drbd/drbd_nl.c | 13 +++---
drivers/cdrom/gdrom.c | 4 +-
drivers/char/virtio_console.c | 2 +-
drivers/clocksource/samsung_pwm_timer.c | 4 +-
drivers/crypto/n2_core.c | 12 +++---
drivers/fmc/fmc-fakedev.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/inc/pp_debug.h | 2 +-
drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c | 4 +-
drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c | 14 +++----
.../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c | 4 +-
drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c | 4 +-
drivers/ide/tx4938ide.c | 2 +-
drivers/ide/tx4939ide.c | 5 +--
drivers/input/gameport/gameport.c | 4 +-
drivers/input/joystick/gamecon.c | 3 +-
drivers/input/misc/apanel.c | 3 +-
drivers/input/misc/xen-kbdfront.c | 8 ++--
drivers/input/serio/serio.c | 8 ++--
drivers/isdn/gigaset/interface.c | 2 +-
drivers/isdn/hardware/mISDN/avmfritz.c | 17 ++++----
drivers/isdn/hardware/mISDN/hfcmulti.c | 8 ++--
drivers/isdn/hardware/mISDN/hfcpci.c | 4 +-
drivers/isdn/hardware/mISDN/hfcsusb.c | 4 +-
drivers/isdn/hardware/mISDN/mISDNipac.c | 4 +-
drivers/isdn/hardware/mISDN/mISDNisar.c | 10 ++---
drivers/isdn/hardware/mISDN/netjet.c | 8 ++--
drivers/isdn/hardware/mISDN/w6692.c | 12 +++---
drivers/isdn/mISDN/hwchannel.c | 8 ++--
drivers/macintosh/windfarm_fcu_controls.c | 5 +--
drivers/macintosh/windfarm_lm87_sensor.c | 4 +-
drivers/macintosh/windfarm_pm72.c | 22 +++++------
drivers/macintosh/windfarm_rm31.c | 6 +--
drivers/media/platform/sh_vou.c | 4 +-
drivers/mfd/db8500-prcmu.c | 2 +-
drivers/mfd/sta2x11-mfd.c | 4 +-
drivers/mfd/twl4030-power.c | 7 +---
drivers/mtd/chips/cfi_cmdset_0002.c | 12 ++++--
drivers/mtd/nand/cmx270_nand.c | 4 +-
drivers/mtd/ofpart.c | 4 +-
drivers/of/fdt.c | 20 +++++-----
drivers/oprofile/oprofile_perf.c | 8 ++--
drivers/platform/x86/asus-laptop.c | 2 +-
drivers/platform/x86/eeepc-laptop.c | 2 +-
drivers/platform/x86/intel_oaktrail.c | 10 ++---
drivers/rapidio/rio-sysfs.c | 4 +-
drivers/scsi/a3000.c | 2 +-
drivers/sh/intc/core.c | 4 +-
drivers/tty/hvc/hvcs.c | 2 +-
drivers/tty/tty_io.c | 4 +-
drivers/video/fbdev/aty/radeon_base.c | 4 +-
drivers/video/fbdev/core/fbmon.c | 4 +-
drivers/video/fbdev/pxafb.c | 7 ++--
kernel/trace/trace_benchmark.c | 4 +-
lib/cpu_rmap.c | 2 +-
lib/dma-debug.c | 2 +-
sound/soc/fsl/imx-audmux.c | 6 +--
sound/soc/samsung/s3c-i2s-v2.c | 6 +--
122 files changed, 367 insertions(+), 397 deletions(-)
--
2.10.0.rc2.1.g053435c
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support
From: Geert Uytterhoeven @ 2017-02-15 8:45 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Tejun Heo, Michael Schmitz, linux-ide@vger.kernel.org, linux-m68k,
linux-kernel@vger.kernel.org, Jens Axboe
In-Reply-To: <1483106478-1382-1-git-send-email-b.zolnierkie@samsung.com>
On Fri, Dec 30, 2016 at 3:01 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> This patchset adds m68k/Atari Falcon PATA support to libata.
> The major difference in the new libata's pata_falcon host
> driver when compared to legacy IDE's falconide host driver is
> that we are using polled PIO mode and thus avoiding the need
> for STDMA locking magic altogether.
>
> Tested under ARAnyM emulator.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
> 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
drivers/ata/pata_falcon.c:57:18: error: 'struct request' has no member
named 'cmd_type'
drivers/ata/pata_falcon.c:57:32: error: 'REQ_TYPE_FS' undeclared
(first use in this function)
http://kisskb.ellerman.id.au/kisskb/buildresult/12936876/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* КЛИЕНСКИЕ БАЗЫ тел +79139230330 Skype: prodawez390 Email: prodawez393@gmail.com Viber\whatsapp\telegram +79139230330 Узнайте подробнее!!!
From: linux-ide @ 2017-02-14 18:37 UTC (permalink / raw)
To: linux-ide
^ permalink raw reply
* [RESEND][PATCH v2] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Rameshwar Prasad Sahu @ 2017-02-14 17:53 UTC (permalink / raw)
To: olof, tj, arnd
Cc: devicetree, mlangsdo, linux-scsi, jcm, Rameshwar Prasad Sahu,
patches, linux-ide, linux-arm-kernel
This patch enables NCQ support for APM X-Gene SATA controller hardware v1.1
that was broken with hardware v1.0. Second thing, here we should not assume
XGENE_AHCI_V2 always in case of having valid _CID in ACPI table. I need to
remove this assumption because V1_1 also has a valid _CID for backward
compatibly with v1.
v2 changes:
1. Changed patch description
Signed-off-by: Rameshwar Prasad Sahu <rsahu@apm.com>
---
drivers/ata/ahci_xgene.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 73b19b2..8b88be9 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -87,6 +87,7 @@
enum xgene_ahci_version {
XGENE_AHCI_V1 = 1,
+ XGENE_AHCI_V1_1,
XGENE_AHCI_V2,
};
@@ -734,6 +735,7 @@ static struct scsi_host_template ahci_platform_sht = {
#ifdef CONFIG_ACPI
static const struct acpi_device_id xgene_ahci_acpi_match[] = {
{ "APMC0D0D", XGENE_AHCI_V1},
+ { "APMC0D67", XGENE_AHCI_V1_1},
{ "APMC0D32", XGENE_AHCI_V2},
{},
};
@@ -742,6 +744,7 @@ MODULE_DEVICE_TABLE(acpi, xgene_ahci_acpi_match);
static const struct of_device_id xgene_ahci_of_match[] = {
{.compatible = "apm,xgene-ahci", .data = (void *) XGENE_AHCI_V1},
+ {.compatible = "apm,xgene-ahci-v1-1", .data = (void *) XGENE_AHCI_V1_1},
{.compatible = "apm,xgene-ahci-v2", .data = (void *) XGENE_AHCI_V2},
{},
};
@@ -755,8 +758,7 @@ static int xgene_ahci_probe(struct platform_device *pdev)
struct resource *res;
const struct of_device_id *of_devid;
enum xgene_ahci_version version = XGENE_AHCI_V1;
- const struct ata_port_info *ppi[] = { &xgene_ahci_v1_port_info,
- &xgene_ahci_v2_port_info };
+ const struct ata_port_info *ppi;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(&pdev->dev, "%s: Error reading device info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
- } else if (info->valid & ACPI_VALID_CID) {
- version = XGENE_AHCI_V2;
}
}
}
@@ -858,18 +858,20 @@ skip_clk_phy:
switch (version) {
case XGENE_AHCI_V1:
+ ppi = &xgene_ahci_v1_port_info;
hpriv->flags = AHCI_HFLAG_NO_NCQ;
break;
case XGENE_AHCI_V2:
+ ppi = &xgene_ahci_v2_port_info;
hpriv->flags |= AHCI_HFLAG_YES_FBS;
hpriv->irq_handler = xgene_ahci_irq_intr;
break;
default:
+ ppi = &xgene_ahci_v1_port_info;
break;
}
- rc = ahci_platform_init_host(pdev, hpriv, ppi[version - 1],
- &ahci_platform_sht);
+ rc = ahci_platform_init_host(pdev, hpriv, ppi, &ahci_platform_sht);
if (rc)
goto disable_resources;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] cdrom: Make device operations read-only
From: Jens Axboe @ 2017-02-14 15:30 UTC (permalink / raw)
To: Kees Cook, linux-kernel
Cc: Jonathan Corbet, Tim Waugh, Borislav Petkov, David S. Miller,
James E.J. Bottomley, Martin K. Petersen, linux-doc, linux-ide,
linux-scsi, kernel-hardening
In-Reply-To: <20170214002526.GA124769@beast>
On 02/13/2017 05:25 PM, Kees Cook wrote:
> Since function tables are a common target for attackers, it's best to keep
> them in read-only memory. As such, this makes the CDROM device ops tables
> const. This drops additionally n_minors, since it isn't used meaningfully,
> and sets the only user of cdrom_dummy_generic_packet explicitly so the
> variables can all be const.
Agree, it's a good change. Applied for 4.11.
--
Jens Axboe
^ permalink raw reply
* Re: DMA issue caused by vmapped stacks
From: Christoph Hellwig @ 2017-02-14 12:27 UTC (permalink / raw)
To: Guillermo Amaral; +Cc: linux-ide
In-Reply-To: <CAPeEpDroE2bYQ_viz7qExspordpR6gLYHjVxaJ53px3utz+PrA@mail.gmail.com>
Hi Guillermo,
are you using libata or the old IDE driver? Any messages in the kernel
log that might be useful?
^ permalink raw reply
* Re: [PATCH] cdrom: Make device operations read-only
From: David Miller @ 2017-02-14 2:58 UTC (permalink / raw)
To: keescook
Cc: linux-kernel, axboe, corbet, tim, bp, jejb, martin.petersen,
linux-doc, linux-ide, linux-scsi, kernel-hardening
In-Reply-To: <20170214002526.GA124769@beast>
From: Kees Cook <keescook@chromium.org>
Date: Mon, 13 Feb 2017 16:25:26 -0800
> diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
> index 9cbd217bc0c9..ab9232e1e16f 100644
> --- a/drivers/ide/ide-cd.c
> +++ b/drivers/ide/ide-cd.c
> @@ -1166,7 +1166,7 @@ void ide_cdrom_update_speed(ide_drive_t *drive, u8 *buf)
> CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM | CDC_GENERIC_PACKET | \
> CDC_MO_DRIVE | CDC_MRW | CDC_MRW_W | CDC_RAM)
>
> -static struct cdrom_device_ops ide_cdrom_dops = {
> +static const struct cdrom_device_ops ide_cdrom_dops = {
> .open = ide_cdrom_open_real,
> .release = ide_cdrom_release_real,
> .drive_status = ide_cdrom_drive_status,
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] cdrom: Make device operations read-only
From: Kees Cook @ 2017-02-14 0:25 UTC (permalink / raw)
To: linux-kernel
Cc: Jens Axboe, Jonathan Corbet, Tim Waugh, Borislav Petkov,
David S. Miller, James E.J. Bottomley, Martin K. Petersen,
Kees Cook, linux-doc, linux-ide, linux-scsi, kernel-hardening
Since function tables are a common target for attackers, it's best to keep
them in read-only memory. As such, this makes the CDROM device ops tables
const. This drops additionally n_minors, since it isn't used meaningfully,
and sets the only user of cdrom_dummy_generic_packet explicitly so the
variables can all be const.
Inspired by similar changes in grsecurity/PaX.
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Documentation/cdrom/cdrom-standard.tex | 9 +-----
drivers/block/paride/pcd.c | 2 +-
drivers/cdrom/cdrom.c | 58 ++++++++++++++++------------------
drivers/cdrom/gdrom.c | 4 +--
drivers/ide/ide-cd.c | 2 +-
drivers/scsi/sr.c | 2 +-
include/linux/cdrom.h | 5 +--
7 files changed, 37 insertions(+), 45 deletions(-)
diff --git a/Documentation/cdrom/cdrom-standard.tex b/Documentation/cdrom/cdrom-standard.tex
index c06233fe52ac..8f85b0e41046 100644
--- a/Documentation/cdrom/cdrom-standard.tex
+++ b/Documentation/cdrom/cdrom-standard.tex
@@ -249,7 +249,6 @@ struct& cdrom_device_ops\ \{ \hidewidth\cr
unsigned\ long);\cr
\noalign{\medskip}
&const\ int& capability;& capability flags \cr
- &int& n_minors;& number of active minor devices \cr
\};\cr
}
$$
@@ -258,13 +257,7 @@ it should add a function pointer to this $struct$. When a particular
function is not implemented, however, this $struct$ should contain a
NULL instead. The $capability$ flags specify the capabilities of the
\cdrom\ hardware and/or low-level \cdrom\ driver when a \cdrom\ drive
-is registered with the \UCD. The value $n_minors$ should be a positive
-value indicating the number of minor devices that are supported by
-the low-level device driver, normally~1. Although these two variables
-are `informative' rather than `operational,' they are included in
-$cdrom_device_ops$ because they describe the capability of the {\em
-driver\/} rather than the {\em drive}. Nomenclature has always been
-difficult in computer programming.
+is registered with the \UCD.
Note that most functions have fewer parameters than their
$blkdev_fops$ counterparts. This is because very little of the
diff --git a/drivers/block/paride/pcd.c b/drivers/block/paride/pcd.c
index 5fd2d0e25567..10aed84244f5 100644
--- a/drivers/block/paride/pcd.c
+++ b/drivers/block/paride/pcd.c
@@ -273,7 +273,7 @@ static const struct block_device_operations pcd_bdops = {
.check_events = pcd_block_check_events,
};
-static struct cdrom_device_ops pcd_dops = {
+static const struct cdrom_device_ops pcd_dops = {
.open = pcd_open,
.release = pcd_release,
.drive_status = pcd_drive_status,
diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 59cca72647a6..bbbd3caa927c 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -342,8 +342,8 @@ static void cdrom_sysctl_register(void);
static LIST_HEAD(cdrom_list);
-static int cdrom_dummy_generic_packet(struct cdrom_device_info *cdi,
- struct packet_command *cgc)
+int cdrom_dummy_generic_packet(struct cdrom_device_info *cdi,
+ struct packet_command *cgc)
{
if (cgc->sense) {
cgc->sense->sense_key = 0x05;
@@ -354,6 +354,7 @@ static int cdrom_dummy_generic_packet(struct cdrom_device_info *cdi,
cgc->stat = -EIO;
return -EIO;
}
+EXPORT_SYMBOL(cdrom_dummy_generic_packet);
static int cdrom_flush_cache(struct cdrom_device_info *cdi)
{
@@ -371,7 +372,7 @@ static int cdrom_flush_cache(struct cdrom_device_info *cdi)
static int cdrom_get_disc_info(struct cdrom_device_info *cdi,
disc_information *di)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct packet_command cgc;
int ret, buflen;
@@ -586,7 +587,7 @@ static int cdrom_mrw_set_lba_space(struct cdrom_device_info *cdi, int space)
int register_cdrom(struct cdrom_device_info *cdi)
{
static char banner_printed;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
int *change_capability = (int *)&cdo->capability; /* hack */
cd_dbg(CD_OPEN, "entering register_cdrom\n");
@@ -610,7 +611,6 @@ int register_cdrom(struct cdrom_device_info *cdi)
ENSURE(reset, CDC_RESET);
ENSURE(generic_packet, CDC_GENERIC_PACKET);
cdi->mc_flags = 0;
- cdo->n_minors = 0;
cdi->options = CDO_USE_FFLAGS;
if (autoclose == 1 && CDROM_CAN(CDC_CLOSE_TRAY))
@@ -630,8 +630,7 @@ int register_cdrom(struct cdrom_device_info *cdi)
else
cdi->cdda_method = CDDA_OLD;
- if (!cdo->generic_packet)
- cdo->generic_packet = cdrom_dummy_generic_packet;
+ WARN_ON(!cdo->generic_packet);
cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" registered\n", cdi->name);
mutex_lock(&cdrom_mutex);
@@ -652,7 +651,6 @@ void unregister_cdrom(struct cdrom_device_info *cdi)
if (cdi->exit)
cdi->exit(cdi);
- cdi->ops->n_minors--;
cd_dbg(CD_REG_UNREG, "drive \"/dev/%s\" unregistered\n", cdi->name);
}
@@ -1036,7 +1034,7 @@ static
int open_for_data(struct cdrom_device_info *cdi)
{
int ret;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
tracktype tracks;
cd_dbg(CD_OPEN, "entering open_for_data\n");
/* Check if the driver can report drive status. If it can, we
@@ -1198,8 +1196,8 @@ int cdrom_open(struct cdrom_device_info *cdi, struct block_device *bdev,
/* This code is similar to that in open_for_data. The routine is called
whenever an audio play operation is requested.
*/
-static int check_for_audio_disc(struct cdrom_device_info * cdi,
- struct cdrom_device_ops * cdo)
+static int check_for_audio_disc(struct cdrom_device_info *cdi,
+ const struct cdrom_device_ops *cdo)
{
int ret;
tracktype tracks;
@@ -1254,7 +1252,7 @@ static int check_for_audio_disc(struct cdrom_device_info * cdi,
void cdrom_release(struct cdrom_device_info *cdi, fmode_t mode)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
int opened_for_data;
cd_dbg(CD_CLOSE, "entering cdrom_release\n");
@@ -1294,7 +1292,7 @@ static int cdrom_read_mech_status(struct cdrom_device_info *cdi,
struct cdrom_changer_info *buf)
{
struct packet_command cgc;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
int length;
/*
@@ -1643,7 +1641,7 @@ static int dvd_do_auth(struct cdrom_device_info *cdi, dvd_authinfo *ai)
int ret;
u_char buf[20];
struct packet_command cgc;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
rpc_state_t rpc_state;
memset(buf, 0, sizeof(buf));
@@ -1791,7 +1789,7 @@ static int dvd_read_physical(struct cdrom_device_info *cdi, dvd_struct *s,
{
unsigned char buf[21], *base;
struct dvd_layer *layer;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
int ret, layer_num = s->physical.layer_num;
if (layer_num >= DVD_LAYERS)
@@ -1842,7 +1840,7 @@ static int dvd_read_copyright(struct cdrom_device_info *cdi, dvd_struct *s,
{
int ret;
u_char buf[8];
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
init_cdrom_command(cgc, buf, sizeof(buf), CGC_DATA_READ);
cgc->cmd[0] = GPCMD_READ_DVD_STRUCTURE;
@@ -1866,7 +1864,7 @@ static int dvd_read_disckey(struct cdrom_device_info *cdi, dvd_struct *s,
{
int ret, size;
u_char *buf;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
size = sizeof(s->disckey.value) + 4;
@@ -1894,7 +1892,7 @@ static int dvd_read_bca(struct cdrom_device_info *cdi, dvd_struct *s,
{
int ret, size = 4 + 188;
u_char *buf;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
buf = kmalloc(size, GFP_KERNEL);
if (!buf)
@@ -1928,7 +1926,7 @@ static int dvd_read_manufact(struct cdrom_device_info *cdi, dvd_struct *s,
{
int ret = 0, size;
u_char *buf;
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
size = sizeof(s->manufact.value) + 4;
@@ -1995,7 +1993,7 @@ int cdrom_mode_sense(struct cdrom_device_info *cdi,
struct packet_command *cgc,
int page_code, int page_control)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
memset(cgc->cmd, 0, sizeof(cgc->cmd));
@@ -2010,7 +2008,7 @@ int cdrom_mode_sense(struct cdrom_device_info *cdi,
int cdrom_mode_select(struct cdrom_device_info *cdi,
struct packet_command *cgc)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
memset(cgc->cmd, 0, sizeof(cgc->cmd));
memset(cgc->buffer, 0, 2);
@@ -2025,7 +2023,7 @@ int cdrom_mode_select(struct cdrom_device_info *cdi,
static int cdrom_read_subchannel(struct cdrom_device_info *cdi,
struct cdrom_subchnl *subchnl, int mcn)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct packet_command cgc;
char buffer[32];
int ret;
@@ -2073,7 +2071,7 @@ static int cdrom_read_cd(struct cdrom_device_info *cdi,
struct packet_command *cgc, int lba,
int blocksize, int nblocks)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
memset(&cgc->cmd, 0, sizeof(cgc->cmd));
cgc->cmd[0] = GPCMD_READ_10;
@@ -2093,7 +2091,7 @@ static int cdrom_read_block(struct cdrom_device_info *cdi,
struct packet_command *cgc,
int lba, int nblocks, int format, int blksize)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
memset(&cgc->cmd, 0, sizeof(cgc->cmd));
cgc->cmd[0] = GPCMD_READ_CD;
@@ -2764,7 +2762,7 @@ static int cdrom_ioctl_audioctl(struct cdrom_device_info *cdi,
*/
static int cdrom_switch_blocksize(struct cdrom_device_info *cdi, int size)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct packet_command cgc;
struct modesel_head mh;
@@ -2790,7 +2788,7 @@ static int cdrom_switch_blocksize(struct cdrom_device_info *cdi, int size)
static int cdrom_get_track_info(struct cdrom_device_info *cdi,
__u16 track, __u8 type, track_information *ti)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct packet_command cgc;
int ret, buflen;
@@ -3049,7 +3047,7 @@ static noinline int mmc_ioctl_cdrom_play_msf(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_msf msf;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYMSF\n");
if (copy_from_user(&msf, (struct cdrom_msf __user *)arg, sizeof(msf)))
@@ -3069,7 +3067,7 @@ static noinline int mmc_ioctl_cdrom_play_blk(struct cdrom_device_info *cdi,
void __user *arg,
struct packet_command *cgc)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
struct cdrom_blk blk;
cd_dbg(CD_DO_IOCTL, "entering CDROMPLAYBLK\n");
if (copy_from_user(&blk, (struct cdrom_blk __user *)arg, sizeof(blk)))
@@ -3164,7 +3162,7 @@ static noinline int mmc_ioctl_cdrom_start_stop(struct cdrom_device_info *cdi,
struct packet_command *cgc,
int cmd)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
cd_dbg(CD_DO_IOCTL, "entering CDROMSTART/CDROMSTOP\n");
cgc->cmd[0] = GPCMD_START_STOP_UNIT;
cgc->cmd[1] = 1;
@@ -3177,7 +3175,7 @@ static noinline int mmc_ioctl_cdrom_pause_resume(struct cdrom_device_info *cdi,
struct packet_command *cgc,
int cmd)
{
- struct cdrom_device_ops *cdo = cdi->ops;
+ const struct cdrom_device_ops *cdo = cdi->ops;
cd_dbg(CD_DO_IOCTL, "entering CDROMPAUSE/CDROMRESUME\n");
cgc->cmd[0] = GPCMD_PAUSE_RESUME;
cgc->cmd[8] = (cmd == CDROMRESUME) ? 1 : 0;
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 584bc3126403..f1a6e520ac6e 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -481,7 +481,7 @@ static int gdrom_audio_ioctl(struct cdrom_device_info *cdi, unsigned int cmd,
return -EINVAL;
}
-static struct cdrom_device_ops gdrom_ops = {
+static const struct cdrom_device_ops gdrom_ops = {
.open = gdrom_open,
.release = gdrom_release,
.drive_status = gdrom_drivestatus,
@@ -489,9 +489,9 @@ static struct cdrom_device_ops gdrom_ops = {
.get_last_session = gdrom_get_last_session,
.reset = gdrom_hardreset,
.audio_ioctl = gdrom_audio_ioctl,
+ .generic_packet = cdrom_dummy_generic_packet,
.capability = CDC_MULTI_SESSION | CDC_MEDIA_CHANGED |
CDC_RESET | CDC_DRIVE_STATUS | CDC_CD_R,
- .n_minors = 1,
};
static int gdrom_bdops_open(struct block_device *bdev, fmode_t mode)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 9cbd217bc0c9..ab9232e1e16f 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1166,7 +1166,7 @@ void ide_cdrom_update_speed(ide_drive_t *drive, u8 *buf)
CDC_CD_RW | CDC_DVD | CDC_DVD_R | CDC_DVD_RAM | CDC_GENERIC_PACKET | \
CDC_MO_DRIVE | CDC_MRW | CDC_MRW_W | CDC_RAM)
-static struct cdrom_device_ops ide_cdrom_dops = {
+static const struct cdrom_device_ops ide_cdrom_dops = {
.open = ide_cdrom_open_real,
.release = ide_cdrom_release_real,
.drive_status = ide_cdrom_drive_status,
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 94352e4df831..013bfe049a48 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -117,7 +117,7 @@ static unsigned int sr_check_events(struct cdrom_device_info *cdi,
unsigned int clearing, int slot);
static int sr_packet(struct cdrom_device_info *, struct packet_command *);
-static struct cdrom_device_ops sr_dops = {
+static const struct cdrom_device_ops sr_dops = {
.open = sr_open,
.release = sr_release,
.drive_status = sr_drive_status,
diff --git a/include/linux/cdrom.h b/include/linux/cdrom.h
index 8609d577bb66..6e8f209a6dff 100644
--- a/include/linux/cdrom.h
+++ b/include/linux/cdrom.h
@@ -36,7 +36,7 @@ struct packet_command
/* Uniform cdrom data structures for cdrom.c */
struct cdrom_device_info {
- struct cdrom_device_ops *ops; /* link to device_ops */
+ const struct cdrom_device_ops *ops; /* link to device_ops */
struct list_head list; /* linked list of all device_info */
struct gendisk *disk; /* matching block layer disk */
void *handle; /* driver-dependent data */
@@ -87,7 +87,6 @@ struct cdrom_device_ops {
/* driver specifications */
const int capability; /* capability flags */
- int n_minors; /* number of active minor devices */
/* handle uniform packets for scsi type devices (scsi,atapi) */
int (*generic_packet) (struct cdrom_device_info *,
struct packet_command *);
@@ -123,6 +122,8 @@ extern int cdrom_mode_sense(struct cdrom_device_info *cdi,
int page_code, int page_control);
extern void init_cdrom_command(struct packet_command *cgc,
void *buffer, int len, int type);
+extern int cdrom_dummy_generic_packet(struct cdrom_device_info *cdi,
+ struct packet_command *cgc);
/* The SCSI spec says there could be 256 slots. */
#define CDROM_MAX_SLOTS 256
--
2.7.4
--
Kees Cook
Pixel Security
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox