Hi Ilpo, On 12/12/2024 22:17, Ilpo Järvinen wrote: > On Thu, 12 Dec 2024, Shyam Sundar S K wrote: >> On 12/12/2024 21:16, Mario Limonciello wrote: >>> On 12/12/2024 09:19, Shyam Sundar S K wrote: >>>> From: Basavaraj Natikar <basavaraj.natikar@xxxxxxx> >>>> >>>> Add support to export device operating states, such as laptop >>>> placement, >>>> platform types and propagate this data to AMD PMF driver for use in >>>> actions. >>>> >>>> To retrieve the device operating states data, SRA sensor support >>>> need to >>>> be enabled in AMD SFH driver. So add support to enable the SRA sensor. >>>> >>>> Co-developed-by: Akshata MukundShetty <akshata.mukundshetty@xxxxxxx> >>>> Signed-off-by: Akshata MukundShetty <akshata.mukundshetty@xxxxxxx> >>>> Signed-off-by: Basavaraj Natikar <basavaraj.natikar@xxxxxxx> >>> >>> When you send someone else's patch but don't change it you are still >>> supposed to add your "own" S-o-b. >> >> ah! Thanks. I missed to add it. >> >>> >>> I have two small nits below. >>> >> >> Sure, but I have a question to Hans and Ilpo >> >> while we address the remarks what should be approach for merging this >> series? Should it go via pdx86 tree or hid because patch 2/2 is >> dependent of 1/2. > > Hi, > > Given pdx86 pmf driver gets much more changes overall, it would seem > better to merge the series through pdx86 tree. But I also want to mention > that generally it's also possible to make requests on merge path as the > submitter of the series, in particular, it is good to take into account > if you know there are patches that might conflict with the changes > (within this kernel cycle) to make the merge window less problematic for > maintainers. > > [In some cases it's possible to create an immutable branch which can be > merged by two (or more) subsystems but I don't think it provides added > value here given how low traffic amd-sfh-hid is.] > Thank you. I have sent out v2 and added additional notes to the cover-letter. Thanks, Shyam
