On Sat, Nov 28, 2020 at 2:25 AM Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> wrote: > > On Fri, 27 Nov 2020 at 10:25, Tzung-Bi Shih <tzungbi@xxxxxxxxxx> wrote: > > > > On Sat, Nov 28, 2020 at 12:11 AM Mathieu Poirier > > <mathieu.poirier@xxxxxxxxxx> wrote: > > > On Fri, 27 Nov 2020 at 02:30, Tzung-Bi Shih <tzungbi@xxxxxxxxxx> wrote: > > > > The patch breaks MTK SCP when working with legacy SCP firmware. We're > > > > aware of it and will upgrade the devices' kernel and SCP firmware > > > > carefully. Other than that, AFAICT, no other devices in the wild are > > > > using this driver. > > > > > > I agree the patch is aggressive which would break machines with old > > SCP firmware. But AFAICT, no other devices are using this driver; and > > we'll take care of our devices to upgrade SCP firmware first and then > > kernel drivers. Thus, ideally, no real device breakage is expected. > > > > How do you know about all the systems out there that use this SoC? > Moreover why would the original author have implemented the driver the > way they did if it didn't work for them? I am trying not to repeat my statements. - AFAIK, MT8183-based chromebooks are the only user of the driver. We're happy to provide fixups if any other devices break due to the aggressive patch. - The original author Erin Lo <erin.lo@xxxxxxxxxxxx> adds the driver for MT8183-based chromebooks. - The IPI buffer address was hard-coded because we didn't foresee new feature changes in the next generation MTK SCP. If it still makes no sense, here is v3 which is backward compatible with legacy firmwares. (https://patchwork.kernel.org/project/linux-remoteproc/patch/20201130034025.3232229-1-tzungbi@xxxxxxxxxx/)
