Matthew Garrett wrote:
> On Fri, Sep 21, 2007 at 12:08:07PM +0900, Tejun Heo wrote:
>
>> Yeah, that's the intended behavior. SATA PHY link can break from time
>> to time (have ever seen a SATA storage box going through ECC testing?
>> PHY goes offline as soon as you begin to hit it with some EM p
On Fri, Sep 21, 2007 at 12:08:07PM +0900, Tejun Heo wrote:
> Yeah, that's the intended behavior. SATA PHY link can break from time
> to time (have ever seen a SATA storage box going through ECC testing?
> PHY goes offline as soon as you begin to hit it with some EM pulses) and
> you don't really
Matthew Garrett wrote:
> On Fri, Sep 21, 2007 at 11:53:33AM +0900, Tejun Heo wrote:
>
>> Maybe just letting both events in is the best idea. It's not like two
>> duplicate events are gonna break anything and I don't think many vendors
>> are gonna implement separate mechanism when the default SAT
On Fri, Sep 21, 2007 at 11:53:33AM +0900, Tejun Heo wrote:
> Maybe just letting both events in is the best idea. It's not like two
> duplicate events are gonna break anything and I don't think many vendors
> are gonna implement separate mechanism when the default SATA phy based
> one works.
Work
Matthew Garrett wrote:
> On Fri, Sep 21, 2007 at 11:35:05AM +0900, Tejun Heo wrote:
>> Matthew Garrett wrote:
>>> The alternative would be to add a flag to the ap structure indicating
>>> whether the hotplugging is handled by the firmware or not. If we find a
>>> reference to a controller or port
On Fri, Sep 21, 2007 at 11:35:05AM +0900, Tejun Heo wrote:
> Matthew Garrett wrote:
> > The alternative would be to add a flag to the ap structure indicating
> > whether the hotplugging is handled by the firmware or not. If we find a
> > reference to a controller or port in the firmware tables, i
Matthew Garrett wrote:
> On Thu, Sep 20, 2007 at 06:04:22PM -0400, Jeff Garzik wrote:
>
>> the code looks correct. I have one main reservation.
>>
>> how can we be sure that this is active only where other hand-programmed
>> hotplug code is absent?
>
> Yes, that's difficult. As Tejun pointed ou
On Thu, Sep 20, 2007 at 06:04:22PM -0400, Jeff Garzik wrote:
> the code looks correct. I have one main reservation.
>
> how can we be sure that this is active only where other hand-programmed
> hotplug code is absent?
Yes, that's difficult. As Tejun pointed out, there's missing locking
here a
Matthew Garrett wrote:
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification state
Matthew Garrett wrote:
> +static void ata_acpi_notify(acpi_handle handle, u32 event, void *data)
> +{
> + struct ata_port *ap = data;
> + struct ata_eh_info *ehi = &ap->eh_info;
> +
> + ata_ehi_clear_desc(ehi);
> + ata_ehi_push_desc(ehi, "ACPI event");
> + ata_ehi_hotplugged(ehi
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification states that
these devices ca
11 matches
Mail list logo
