On 11 January 2018 at 02:25, Ni, Ruiyu <[email protected]> wrote: > On 1/10/2018 5:52 PM, Ard Biesheuvel wrote: >> >> On 10 January 2018 at 09:43, Udit Kumar <[email protected]> wrote: >>> >>> Hi Ruiyu, >>> >>>> -----Original Message----- >>>>> >>>>> >>>>> And this change will not impact any other hardware so no one is >>>>> basically >>>> >>>> impacted by this change. >>>> >>>> Your buggy HW only need the value zero. But the addition of PCD exposes >>>> an interface that can use any size of PRD. >>>> I am not sure the AtaAtapiPassThru can work if some platform sets the >>>> PCD >>>> value to others than 0 or 3F_FFFFh. >>> >>> >>> I don't see someone using this driver will set Pcd randomly, but I agree >>> on this >>> point other value should be handled. >>> Error or Assert could be added, if Pcd value is not 0 or 3F_FFFFh. >>> >>>> Can you please >>>> just duplicate the AtaAtapiPassThru in your platform? >>>> Because the driver is very stable today, not much code sync effort will >>>> be >>>> needed if core version is changed. >>> >>> >>> Duplicating is always a possibility :), but When we will push this >>> duplicated driver >>> (just for one line change) for upstreaming. >>> will this be acceptable ?? >> >> >> My main concern with this (and with using a PCD) is that the setting >> affects all SATA controllers in the system, including ones the you >> stick into a PCIe slot. >> >> So I think forking the driver is the only possible solution, but it >> will not be a one-line change: you need to ensure that you apply the >> workaround only to the SATA controllers in the SoC. >> > > Depending on the new driver's location. The package owner decides > whether forking is acceptable :) >
I think forking is reasonable in this case: the workaround does not belong in generic code, and it seems only early silicon is affected anyway. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
