Re: [PATCH] libata: always use polling SETXFER

Jeff Garzik wrote: > Tejun Heo wrote: >> So, I don't think the problem exists for SATA in the first place. At >> least there hasn't been any report of it and doing SETXFER by polling >> can handle all the existing cases. We can and probably should deal with >> such SATA devices when and if they c

Re: [PATCH] libata: always use polling SETXFER

Tejun Heo wrote: So, I don't think the problem exists for SATA in the first place. At least there hasn't been any report of it and doing SETXFER by polling can handle all the existing cases. We can and probably should deal with such SATA devices when and if they come up. How are we gonna verif

Re: [PATCH] libata: always use polling SETXFER

Hello, Jeff. Jeff Garzik wrote: > Since I wrote them up in IRC, I might as well post them here and get it > archived: Just about to reply on IRC. :-) > We need to figure out a better polling solution. > > For SAS and advanced SATA, polling really has no meaning at all, when > you consider what

Re: [PATCH] libata: always use polling SETXFER

Tejun Heo wrote: Several people have reported LITE-ON LTR-48246S detection failed because SETXFER fails. It seems the device raises IRQ too early after SETXFER. This is controller independent. The same problem has been reported for different controllers. So, now we have pata_via where the con