On Fri, Jul 19, 2024 at 10:07:29AM -0700, Doug Anderson wrote: > Hi, > > On Thu, Jul 18, 2024 at 7:59 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Thu, Jul 18, 2024 at 7:56 AM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > > > On Thu, Jul 18, 2024 at 07:45:57AM -0700, Doug Anderson wrote: > > > > Hi, > > > > > > > > On Wed, Jul 17, 2024 at 11:19 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > > > > > > > > > On 18/07/2024 02:21, Doug Anderson wrote: > > > > > > Conor (and/or) Krzysztof and Rob, > > > > > > > > > > > > On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley <conor@xxxxxxxxxx> wrote: > > > > > >> > > > > > >> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote: > > > > > >>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight > > > > > >>> control over the DP AUX channel. While it works almost correctly with the > > > > > >>> generic "edp-panel" compatible, the backlight needs special handling to > > > > > >>> work correctly. It is similar to the existing ATNA33XC20 panel, just with > > > > > >>> a larger resolution and size. > > > > > >>> > > > > > >>> Add a new "samsung,atna45af01" compatible to describe this panel in the DT. > > > > > >>> Use the existing "samsung,atna33xc20" as fallback compatible since existing > > > > > >>> drivers should work as-is, given that resolution and size are discoverable > > > > > >>> through the eDP link. > > > > > >>> > > > > > >>> Signed-off-by: Stephan Gerhold <stephan.gerhold@xxxxxxxxxx> > > > > > >> > > > > > >> Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> > > > > > > > > > > > > Can you comment on whether you would consider this bindings a "Fix" > > > > > > since it's a dependency for later patches in this series (which are > > > > > > "Fix"es) to pass dtbs_check? See: > > > > > > > > > > > > https://lore.kernel.org/r/4bca316a-2334-425b-87a6-e1bb241d26b5@xxxxxxxxxx > > > > > > > > > > The patch itself is not a fix, for sure, but it might be a dependency of > > > > > a fix (which you wrote above), thus could be pulled to stable as a > > > > > dependency. > > > > > > > > > > I do not care about dtbs_check warnings in stable kernels, mostly > > > > > because dtbs_check warnings depend heavily on dtschema and dtschema > > > > > follows mainline kernel. Basically if you had warnings-free v6.8 but try > > > > > to run dtbs_check now with latest dtschema, your results will differ. > > > > > > > > > > At some point in the future, I could imagine "no new dtbs_check warnings > > > > > in stable kernels" requirement or at least preference, but so far I > > > > > don't think there is any benefit. > > > > > > > > In this case it's not about whether it makes it to the stable kernel > > > > but about which main kernel it goes through. > > > > > > > > If we land the bindings in drm-misc-next right now then it'll be a > > > > long time before it makes it into Linus's tree because of the way that > > > > drm-misc-next merges. It will make it to Linus's tree at 6.12. You can > > > > see the drm-misc merging strategy at: > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html > > > > > > > > If we land the dts change (a fix) through the Qualcomm tree as a fix > > > > then it should target 6.11. > > > > > > > > This means that the 6.11 tree will have a dtbs_check error because it > > > > has the dts change (a fix) but not the bindings change (not a fix). > > > > > > > > One way to resolve this would be to treat this bindings as a "fix" and > > > > land it through "drm-misc-fixes". That would make the bindings and > > > > device tree change meet up in Linux 6.11. > > > > > > > > Did I get that all correct? > > > > > > Is not not fairly established that a dependency for a fix can go onto a > > > fixes branch even if it is not a fix in and of itself? > > > > That would certainly be my take on it, but DT folks confirmation was > > requested by Neil in: > > > > https://lore.kernel.org/all/4bca316a-2334-425b-87a6-e1bb241d26b5@xxxxxxxxxx/ > > FWIW, I'd rather not let this stagnate too long. I dunno if you were waiting for me (or Krzk/Rob) to reply, but I didn't cos I figured I'd already pretty much said there was nothing wrong with the prereq being on -fixes too. > I'm fairly confident > in my assertion that this should go into drm-misc-fixes. I'll give it > until Monday and then I'm just going to land this bindings change in > drm-misc-fixes. Shout soon if you feel strongly that I shouldn't do > this. If someone wants to flame me after the fact then so be it.
Attachment:
signature.asc
Description: PGP signature
