mbox series

[GIT,PULL] intel-pinctrl for 6.13-1

Message ID ZySrvXpFANlXrnh2@black.fi.intel.com
State New
Headers show
Series [GIT,PULL] intel-pinctrl for 6.13-1 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v6.13-1

Message

Andy Shevchenko Nov. 1, 2024, 10:21 a.m. UTC
Hi Linux pin control  maintainers,

One of the tiniest PR for Intel pin control drivers, only two changes there
which were in the Linux Next for some time without reported issues. Please,
pull for v6.13-rc1 (next cycle).

Thanks,

With Best Regards,
Andy Shevchenko

The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:

  Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git tags/intel-pinctrl-v6.13-1

for you to fetch changes up to ffe624c4130f902bc519b8201a1cb4ef1e6bb05c:

  pinctrl: elkhartlake: Add support for DSW community (2024-10-28 19:06:54 +0200)

----------------------------------------------------------------
intel-pinctrl for v6.13-1

* Expose DSW community on Elkhart Lake
* Elaborate in the code comment the pull bias settings

The following is an automated git shortlog grouped by driver:

elkhartlake:
 -  Add support for DSW community

intel:
 -  Add a human readable decoder for pull bias values

----------------------------------------------------------------
Andy Shevchenko (2):
      pinctrl: intel: Add a human readable decoder for pull bias values
      pinctrl: elkhartlake: Add support for DSW community

 drivers/pinctrl/intel/pinctrl-elkhartlake.c | 38 +++++++++++++++++++++++++++++
 drivers/pinctrl/intel/pinctrl-intel.c       | 12 +++++++++
 2 files changed, 50 insertions(+)

Comments

Linus Walleij Nov. 1, 2024, 11:43 a.m. UTC | #1
Hi Andy,

On Fri, Nov 1, 2024 at 11:21 AM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:

> One of the tiniest PR for Intel pin control drivers, only two changes there
> which were in the Linux Next for some time without reported issues. Please,
> pull for v6.13-rc1 (next cycle).
(...)
> The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:
>
>   Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)

Does this require stuff from rc4 or can you send it based on rc1?

I know we added some ACPI ID or so for rc4 but ... that's only
required at runtime right? Are there hard compile-time or
textual dependencies?

Yours,
Linus Walleij
Mika Westerberg Nov. 1, 2024, 12:09 p.m. UTC | #2
Hi Linus,

On Fri, Nov 01, 2024 at 12:43:07PM +0100, Linus Walleij wrote:
> Hi Andy,
> 
> On Fri, Nov 1, 2024 at 11:21 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> 
> > One of the tiniest PR for Intel pin control drivers, only two changes there
> > which were in the Linux Next for some time without reported issues. Please,
> > pull for v6.13-rc1 (next cycle).
> (...)
> > The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:
> >
> >   Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)
> 
> Does this require stuff from rc4 or can you send it based on rc1?
> 
> I know we added some ACPI ID or so for rc4 but ... that's only
> required at runtime right? Are there hard compile-time or
> textual dependencies?

It does not strictly depend on -rc4 but is that a problem pulling from
something that is based on > -rc1? I mean this is what we do all the
time in TB/USB side of things and typically apply first patches to
"next" branch on top of what was the -rcX at the moment.

Thanks!
Linus Walleij Nov. 1, 2024, 10:30 p.m. UTC | #3
On Fri, Nov 1, 2024 at 1:09 PM Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> On Fri, Nov 01, 2024 at 12:43:07PM +0100, Linus Walleij wrote:
> > Hi Andy,
> >
> > On Fri, Nov 1, 2024 at 11:21 AM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > One of the tiniest PR for Intel pin control drivers, only two changes there
> > > which were in the Linux Next for some time without reported issues. Please,
> > > pull for v6.13-rc1 (next cycle).
> > (...)
> > > The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:
> > >
> > >   Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)
> >
> > Does this require stuff from rc4 or can you send it based on rc1?
> >
> > I know we added some ACPI ID or so for rc4 but ... that's only
> > required at runtime right? Are there hard compile-time or
> > textual dependencies?
>
> It does not strictly depend on -rc4 but is that a problem pulling from
> something that is based on > -rc1? I mean this is what we do all the
> time in TB/USB side of things and typically apply first patches to
> "next" branch on top of what was the -rcX at the moment.

I usually do not pull in later release candidates unless it is necessary,
if it is necessary then I do it, such as if there will be merge conflicts unless
I pull it in.

Yours,
Linus Walleij
Mika Westerberg Nov. 4, 2024, 10:07 a.m. UTC | #4
On Fri, Nov 01, 2024 at 11:30:48PM +0100, Linus Walleij wrote:
> On Fri, Nov 1, 2024 at 1:09 PM Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:
> > On Fri, Nov 01, 2024 at 12:43:07PM +0100, Linus Walleij wrote:
> > > Hi Andy,
> > >
> > > On Fri, Nov 1, 2024 at 11:21 AM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > > One of the tiniest PR for Intel pin control drivers, only two changes there
> > > > which were in the Linux Next for some time without reported issues. Please,
> > > > pull for v6.13-rc1 (next cycle).
> > > (...)
> > > > The following changes since commit 42f7652d3eb527d03665b09edac47f85fb600924:
> > > >
> > > >   Linux 6.12-rc4 (2024-10-20 15:19:38 -0700)
> > >
> > > Does this require stuff from rc4 or can you send it based on rc1?
> > >
> > > I know we added some ACPI ID or so for rc4 but ... that's only
> > > required at runtime right? Are there hard compile-time or
> > > textual dependencies?
> >
> > It does not strictly depend on -rc4 but is that a problem pulling from
> > something that is based on > -rc1? I mean this is what we do all the
> > time in TB/USB side of things and typically apply first patches to
> > "next" branch on top of what was the -rcX at the moment.
> 
> I usually do not pull in later release candidates unless it is necessary,
> if it is necessary then I do it, such as if there will be merge conflicts unless
> I pull it in.

Okay, thanks. We'll rebase this on top of -rc1 and resend the pull
request.