Hi Palmer, > -----Original Message----- > From: Palmer Dabbelt <palmer@xxxxxxxxxxx> > Sent: Tuesday, December 19, 2023 6:07 PM > To: Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > Cc: Conor Dooley <conor@xxxxxxxxxx>; Conor Dooley <conor.dooley@xxxxxxxxxxxxx>; > prabhakar.csengg@xxxxxxxxx; geert+renesas@xxxxxxxxx; Atish Patra <atishp@xxxxxxxxxxxx>; Paul Walmsley > <paul.walmsley@xxxxxxxxxx>; apatel@xxxxxxxxxxxxxxxx; alexghiti@xxxxxxxxxxxx; Bjorn Topel > <bjorn@xxxxxxxxxxxx>; suagrfillet@xxxxxxxxx; jeeheng.sia@xxxxxxxxxxxxxxxx; > petrtesarik@xxxxxxxxxxxxxxx; linux-riscv@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > stable@xxxxxxxxxxxxxxx > Subject: RE: [RFT 1/2] RISC-V: handle missing "no-map" properties for OpenSBI's PMP protected regions > > On Tue, 19 Dec 2023 09:27:42 PST (-0800), prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx wrote: > > Hi Conor, > > > >> -----Original Message----- > >> From: Conor Dooley <conor@xxxxxxxxxx> > >> Sent: Tuesday, December 19, 2023 5:18 PM > >> To: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > >> Cc: Lad, Prabhakar <prabhakar.csengg@xxxxxxxxx>; Palmer Dabbelt > >> <palmer@xxxxxxxxxxx>; > >> geert+renesas@xxxxxxxxx; Atish Patra <atishp@xxxxxxxxxxxx>; Paul > >> geert+Walmsley <paul.walmsley@xxxxxxxxxx>; > >> apatel@xxxxxxxxxxxxxxxx; alexghiti@xxxxxxxxxxxx; Bjorn Topel > >> <bjorn@xxxxxxxxxxxx>; suagrfillet@xxxxxxxxx; > >> jeeheng.sia@xxxxxxxxxxxxxxxx; petrtesarik@xxxxxxxxxxxxxxx; linux- > >> riscv@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > >> stable@xxxxxxxxxxxxxxx; Prabhakar Mahadev Lad > >> <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > >> Subject: Re: [RFT 1/2] RISC-V: handle missing "no-map" properties for > >> OpenSBI's PMP protected regions > >> > >> Hey, > >> > >> On Thu, Dec 07, 2023 at 01:11:23PM +0000, Conor Dooley wrote: > >> > On Thu, Dec 07, 2023 at 01:02:00PM +0000, Lad, Prabhakar wrote: > >> > > On Wed, Dec 6, 2023 at 2:26 PM Conor Dooley <conor@xxxxxxxxxx> wrote: > >> > > > On Wed, Dec 06, 2023 at 04:52:11AM -0800, Palmer Dabbelt wrote: > >> > > > > On Thu, 10 Aug 2023 02:07:10 PDT (-0700), Conor Dooley wrote: > >> > > >> > > > > > I'm perfectly happy to drop this series though, if people > >> > > > > > generally are of the opinion that this sort of firmware workaround is ill-advised. > >> > > > > > We are unaffected by it, so I certainly have no pressure to > >> > > > > > have something working here. It's my desire not to be > >> > > > > > user-hostile that motivated this patch. > >> > > > > > >> > > > > IIUC you guys and Reneas are the only ones who have hardware > >> > > > > that might be in a spot where users aren't able to update the > >> > > > > firmware (ie, it's out in production somewhere). > >> > > > > >> > > > I dunno if we can really keep thinking like that though. In > >> > > > terms of people who have devicetrees in the kernel and stuff > >> > > > available in western catalog distribution, sure. > >> > > > I don't think we can assume that that covers all users though, > >> > > > certainly the syntacore folks pop up every now and then, and I > >> > > > sure hope that Andes etc have larger customer bases than the > >> > > > in-kernel users would suggest. > >> > > > > >> > > > > So I'm adding Geert, though he probably saw this months ago... > >> > > > > >> > > > Prabhakar might be a good call on that front. I'm not sure if > >> > > > the Renesas stuff works on affected versions of OpenSBI though, > >> > > > guess it depends on the sequencing of the support for the > >> > > > non-coherent stuff and when this bug was fixed. > >> > > > > >> > > ATM, I dont think there are any users who are using the upstream > >> > > kernel + OpenSBI (apart from me and Geert!). Currently the > >> > > customers are using the BSP releases. > >> > > >> > That doesn't really answer whether or not you (and your customers) > >> > are using an affected version of the vendor OpenSBI? > >> > The affected range for OpenSBI itself is [v0.8 to v1.3). > >> > >> Did you perhaps miss this mail Prabhakar? > >> > > Oops sorry for that. > > > > I can confirm the BSP version used by the customers is v1.0 [0]. > > > > [0] > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > ub.com%2Frenesas-rz%2Frz_opensbi%2Fcommits%2Fwork%2FOpenSBI-PMA%2F&dat > > a=05%7C02%7Cprabhakar.mahadev-lad.rj%40bp.renesas.com%7C014cf4ddfd1e48 > > 1ff5bc08dc00bd467f%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638386 > > 060130410731%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM > > zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=a0tcsXY4EQlODi > > I34QygXS9QpJnVBqL8bNkxE8N5J2g%3D&reserved=0 > > OK, so sounds like would end up with broken systems from this bug, then? > > IIRC we still have the Renesas systems as NONPORTABLE due to that DMA pool Kconfig conflict. So if > it's really only these Renesas systems that have the bug, maybe we can still remove hibernation from > NONPORTABLE and just add in some sort of Kconfig to disable the > Renesas+hibernation combinations that would break? > Well customers using BSP uses v1.0 for OpenSBI and kernel 5.10-cip, and people wanting to run upstream kernel will have to only use the upstream OpenSBI as the OpenSBI used in BSP is not compatible with upstream kernel(Linux doesn’t bootup). ATM I can say that its only me and Geert using upstream OpenBSI and upstream kernel. With that in mind would we still require that change? Cheers, Prabhakar