Aaron Lu | 1 Apr 12:34 2012
Picon

Re: [PATCH v3 7/7] [SCSI] sr: adds Zero-power ODD support

On Sat, Mar 31, 2012 at 12:45:40PM +0200, Jan Ceuleers wrote:
> 
> What about slot-loading optical drives, where the user does not
> first have to press a button to open the tray (due to a lack of
> tray)?

For slot type ODD, the insert of a disk will fire the gpe event by
means of the sata slimline connector's device attention pin.

That means, the insert of a disk into a slot type ODD and the
press of the eject button of a tray type ODD has the same effect to
trigger the resume process.

Thanks,
Aaron

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jiri Slaby | 1 Apr 22:48 2012
Picon

Re: [PATCH v2] libata: disable runtime pm for hotpluggable port

On 03/13/2012 02:57 AM, Lin Ming wrote:
> Currently, hotplug doesn't work if port is already runtime suspended.
> For now, we simply disable runtime pm for hotpluggable port.
> Later, we should add runtime pm support for hotpluggable port too.
> 
> Bug report:
> https://lkml.org/lkml/2012/2/19/70
> 
> v2:
> - Use bit 2 and 3 for flags ATA_FLAG_EXTERNAL and ATA_FLAG_PLUGGABLE.
> 
> TODO: add similar hotpluggable port check for controllers other than
> AHCI.

Any updates on this? The patches which introduced the bug are in -rc1
now. Unlike this patch.

> Reported-and-tested-by: Jiri Slaby <jslaby <at> suse.cz>
> Reported-and-tested-by: cwillu <at> cwillu.com
> Reported-and-tested-by: jackdachef <at> gmail.com
> Signed-off-by: Lin Ming <ming.m.lin <at> intel.com>
> ---
>  drivers/ata/ahci.c             |    3 +++
>  drivers/ata/ahci.h             |    3 +++
>  drivers/ata/libahci.c          |   20 ++++++++++++++++++++
>  drivers/ata/libata-transport.c |    6 ++++--
>  include/linux/libata.h         |    2 ++
>  5 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
(Continue reading)

Rafal Prylowski | 2 Apr 09:52 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On 2012-03-30 22:18, Arnd Bergmann wrote:
>> +static u16 ep93xx_pata_read(struct ep93xx_pata_data *drv_data,
>> +			    void *addr_io,
>> +			    const struct ata_timing *t)
>> +{
>> +	unsigned long addr = (unsigned long) addr_io & 0x1f;
>> +	void __iomem *base = drv_data->ide_base;
>> +	u16 ret;
>> +
>> +	writel(IDECtrl_DIOWn | IDECtrl_DIORn | addr, base + IDECtrl);
>> +	ndelay(t->setup);
>> +	writel(IDECtrl_DIOWn | addr, base + IDECtrl);
> 
> The pointer arithmetic that you do here on addr_io looks really evil.
> Basically your registers are indirect and cannot be accessed through
> pointer dereference. Maybe you should not be trying to do that then
> and not use the ata_port->ioaddr structure.

Yes, I already prepared a version of the driver in which IDE register
addresses are coded as enums instead of using ata_port->ioaddr structure. 
I will post updated version, when I get feedback from Ryan if enums
or defines are preferred.

>> +	ndelay(t->act8b);
> 
> I'm not too familar with ata drivers, but I don't think you're supposed
> to have delays in the code for the timings, rather than programming
> the timings into the controller registers. Are you sure this is the
> right thing here?

(Continue reading)

Arnd Bergmann | 2 Apr 10:08 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On Monday 02 April 2012, Rafal Prylowski wrote:
> > 
> > And I think this should be consequently be sorted below nonstandard ports, instead of the SFF list.
> > 
> >       Arnd
> 
> I selected "PATA SFF controllers with BMDMA" list because the driver
> inherits .ata_bmdma_port_ops (this is in libata-sff.c, which is compiled
> only if ATA_SFF is set).

Ok, I see. Is it actually the right one to inherit from though?

You end up overriding most of the opterations that are set there again,
the only ones that you use are:

ata_bmdma_error_handler, ata_bmdma_post_internal_cmd, ata_bmdma_qc_issue,
ata_sff_qc_fill_rtf, ata_sff_freeze, ata_sff_thaw, ata_sff_prereset,
ata_sff_postreset and ata_sff_error_handler.

Are you sure they are all doing the righ thing on your hardware? If
not, it might be better to explicitly just set the ones you need and
see if that still uses any sff functions in the end.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Rafal Prylowski | 2 Apr 11:28 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On 2012-04-02 10:08, Arnd Bergmann wrote:
> On Monday 02 April 2012, Rafal Prylowski wrote:
>>
>> I selected "PATA SFF controllers with BMDMA" list because the driver
>> inherits .ata_bmdma_port_ops (this is in libata-sff.c, which is compiled
>> only if ATA_SFF is set).
> 
> Ok, I see. Is it actually the right one to inherit from though?
> 
> You end up overriding most of the opterations that are set there again,
> the only ones that you use are:
> 
> ata_bmdma_error_handler, ata_bmdma_post_internal_cmd, ata_bmdma_qc_issue,
> ata_sff_qc_fill_rtf, ata_sff_freeze, ata_sff_thaw, ata_sff_prereset,
> ata_sff_postreset and ata_sff_error_handler.
> 
> Are you sure they are all doing the righ thing on your hardware? If
> not, it might be better to explicitly just set the ones you need and
> see if that still uses any sff functions in the end.
> 
> 	Arnd

I think that inheriting from .ata_bmdma_port_ops is quite reasonable.
Another option would be to inherit from .ata_sff_port_ops and implement
.qc_issue hook (like in pata_octeon_cf.c), but this way we end up
reimplementing the same things from libata-sff.c, IMHO. Also, I think
that it's not possible to write PATA driver without this SFF stuff
(at least for me - I'm not libata expert).
I reviewed code paths from all hooks used in ep93xx driver to make sure
that we use only ep93xx_pata_read/ep93xx_pata_write instead of ioread/iowrite.
(Continue reading)

Arnd Bergmann | 2 Apr 12:24 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On Monday 02 April 2012, Rafal Prylowski wrote:
> I think that inheriting from .ata_bmdma_port_ops is quite reasonable.
> Another option would be to inherit from .ata_sff_port_ops and implement
> .qc_issue hook (like in pata_octeon_cf.c), but this way we end up
> reimplementing the same things from libata-sff.c, IMHO. Also, I think
> that it's not possible to write PATA driver without this SFF stuff
> (at least for me - I'm not libata expert).
> I reviewed code paths from all hooks used in ep93xx driver to make sure
> that we use only ep93xx_pata_read/ep93xx_pata_write instead of ioread/iowrite.
> 
Ok, thanks for the confirmation.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ryan Mallon | 3 Apr 03:50 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On 02/04/12 17:52, Rafal Prylowski wrote:

> On 2012-03-30 22:18, Arnd Bergmann wrote:
>>> +static u16 ep93xx_pata_read(struct ep93xx_pata_data *drv_data,
>>> +			    void *addr_io,
>>> +			    const struct ata_timing *t)
>>> +{
>>> +	unsigned long addr = (unsigned long) addr_io & 0x1f;
>>> +	void __iomem *base = drv_data->ide_base;
>>> +	u16 ret;
>>> +
>>> +	writel(IDECtrl_DIOWn | IDECtrl_DIORn | addr, base + IDECtrl);
>>> +	ndelay(t->setup);
>>> +	writel(IDECtrl_DIOWn | addr, base + IDECtrl);
>>
>> The pointer arithmetic that you do here on addr_io looks really evil.
>> Basically your registers are indirect and cannot be accessed through
>> pointer dereference. Maybe you should not be trying to do that then
>> and not use the ata_port->ioaddr structure.
> 
> Yes, I already prepared a version of the driver in which IDE register
> addresses are coded as enums instead of using ata_port->ioaddr structure. 
> I will post updated version, when I get feedback from Ryan if enums
> or defines are preferred.

I would prefer defines, simply because it looks odd having an enum which
has multiple names defined to the same value, and most drivers tend to
use defines rather than enums for registers. It's not a big deal though,
and certainly not a show stopper.

(Continue reading)

Arnd Bergmann | 3 Apr 09:41 2012
Picon

Re: [PATCH 1/3] PATA host controller driver for ep93xx

On Tuesday 03 April 2012, Ryan Mallon wrote:
> On 02/04/12 17:52, Rafal Prylowski wrote:
>
> > Yes, I already prepared a version of the driver in which IDE register
> > addresses are coded as enums instead of using ata_port->ioaddr structure. 
> > I will post updated version, when I get feedback from Ryan if enums
> > or defines are preferred.
> 
> I would prefer defines, simply because it looks odd having an enum which
> has multiple names defined to the same value, and most drivers tend to
> use defines rather than enums for registers. It's not a big deal though,
> and certainly not a show stopper.

I tend to prefer enums, but I agree that it's a minor issue and I generally
don't even mention it in reviews.

	Arnd

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thang Q. Nguyen | 3 Apr 12:12 2012

[PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c


Signed-off-by: Thang Q. Nguyen <tqnguyen <at> apm.com>
---
Changes for v2:
	- Use git rename feature to change the driver to the newname and for
	  easier review.

 arch/powerpc/boot/dts/bluestone.dts              |   21 +
 drivers/ata/Makefile                             |    2 +-
 drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} | 1371 ++++++++++++++--------
 3 files changed, 904 insertions(+), 490 deletions(-)
 rename drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} (56%)

diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
index cfa23bf..803fda6 100644
--- a/arch/powerpc/boot/dts/bluestone.dts
+++ b/arch/powerpc/boot/dts/bluestone.dts
 <at>  <at>  -155,6 +155,27  <at>  <at> 
 					/*RXDE*/  0x5 0x4>;
 		};
 
+		/* SATA DWC devices */
+		SATA0: sata <at> bffd1000 {
+			compatible = "amcc,sata-apm821xx";
+			reg = <4 0xbffd1000 0x800   /* SATA0 */
+			       4 0xbffd0800 0x400>; /* AHBDMA */
+			dma-channel=<0>;
+			interrupt-parent = <&UIC0>;
+			interrupts = <26 4    /* SATA0 */
+			              25 4>;  /* AHBDMA */
(Continue reading)

Sergei Shtylyov | 3 Apr 13:56 2012

Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c

Hello.

On 03-04-2012 14:12, Thang Q. Nguyen wrote:

> Signed-off-by: Thang Q. Nguyen<tqnguyen <at> apm.com>
> ---
> Changes for v2:
> 	- Use git rename feature to change the driver to the newname and for
> 	  easier review.

>   arch/powerpc/boot/dts/bluestone.dts              |   21 +
>   drivers/ata/Makefile                             |    2 +-
>   drivers/ata/{sata_dwc_460ex.c =>  sata_dwc_4xx.c} | 1371 ++++++++++++++--------
>   3 files changed, 904 insertions(+), 490 deletions(-)
>   rename drivers/ata/{sata_dwc_460ex.c =>  sata_dwc_4xx.c} (56%)

    You submitted a magapatch doing several things at once (some even 
needlessly) and even in two areas of the kernel. This needs proper 
splitting/description.

> diff --git a/arch/powerpc/boot/dts/bluestone.dts b/arch/powerpc/boot/dts/bluestone.dts
> index cfa23bf..803fda6 100644
> --- a/arch/powerpc/boot/dts/bluestone.dts
> +++ b/arch/powerpc/boot/dts/bluestone.dts
>  <at>  <at>  -155,6 +155,27  <at>  <at> 
>   					/*RXDE*/  0x5 0x4>;
>   		};
>
> +		/* SATA DWC devices */
> +		SATA0: sata <at> bffd1000 {
(Continue reading)


Gmane