All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Andy Shevchenko" <andriy.shevchenko@intel.com>,
	"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Mark Brown <broonie@kernel.org>, Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>
Subject: Re: [RFC PATCH 0/8] PCI: Define Intel PCI IDs and use them in drivers
Date: Wed, 28 Jun 2023 17:57:56 +0200	[thread overview]
Message-ID: <bbe9f772-e049-4ad3-18aa-cca0b793439f@linux.intel.com> (raw)
In-Reply-To: <ZJxIZGV4+5Al0CpW@smile.fi.intel.com>



On 6/28/23 16:49, Andy Shevchenko wrote:
> On Wed, Jun 28, 2023 at 10:51:27PM +0200, Amadeusz Sławiński wrote:
>> PCI IDs for Intel HDA are duplicated across quite a few drivers, due to
>> various configurations and historical reasons. Currently almost all uses
>> of HDA PCI IDs have corresponding comment telling which platform it is.
>> Additionally there are some inconsistencies between drivers about which
>> ID corresponds to which device.
>>
>> Simplify things, by adding PCI IDs to global header and make use of them
>> in drivers. This allows for removal of comments by having IDs themselves
>> being self explanatory. Additionally it allows for removal of existing
>> inconsistencies by having one source of truth.
> 
> I'm in favour of this series. It allows to use PCI_DEVICE_DATA() in many places.
> With that said, I think you can also add some more definitions to PCI IDs header
> for the sake of being able to use that macro.

I don't have any objections on the change.

The big open is how we add new definitions without a 3-way deadlock
between PCI, sound and ASoC trees, and how those definitions can be
added to the -stable trees.

This isn't an hypothetical case, we have 2 pending submissions for
LunarLake [1] and ArrowLake [2] which will be provided as soon as the
merge window closes.

It's not clear to me if Bjorn is ok to let those audio-specific PCI IDs
go the audio trees, and how things would work between Mark and Takashi.

[1] https://github.com/thesofproject/linux/pull/4425
[2] https://github.com/thesofproject/linux/pull/4437

  reply	other threads:[~2023-06-28 15:59 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 20:51 [RFC PATCH 0/8] PCI: Define Intel PCI IDs and use them in drivers Amadeusz Sławiński
2023-06-28 13:00 ` Mark Brown
2023-06-28 14:49 ` Andy Shevchenko
2023-06-28 15:57   ` Pierre-Louis Bossart [this message]
2023-06-28 20:51 ` [RFC PATCH 1/8] PCI: Add Intel Audio DSP devices to pci_ids.h Amadeusz Sławiński
2023-06-28 14:44   ` Andy Shevchenko
2023-06-29  8:18     ` Amadeusz Sławiński
2023-06-29 16:09   ` Bjorn Helgaas
2023-06-28 20:51 ` [RFC PATCH 2/8] ALSA: intel-dsp-config: Update PCI ID list Amadeusz Sławiński
2023-06-28 20:51 ` [RFC PATCH 3/8] ALSA: hda: " Amadeusz Sławiński
2023-06-28 14:47   ` Andy Shevchenko
2023-06-29  8:18     ` Amadeusz Sławiński
2023-06-29 16:08   ` Bjorn Helgaas
2023-06-28 20:51 ` [RFC PATCH 4/8] ALSA: hda/i915: Update PCI IDs Amadeusz Sławiński
2023-06-28 14:42   ` Andy Shevchenko
2023-06-28 14:44     ` Andy Shevchenko
2023-06-28 20:51 ` [RFC PATCH 5/8] ASoC: Intel: avs: Update PCI ID list Amadeusz Sławiński
2023-06-28 14:48   ` Andy Shevchenko
2023-06-28 20:51 ` [RFC PATCH 6/8] " Amadeusz Sławiński
2023-06-28 14:51   ` Andy Shevchenko
2023-06-28 20:51 ` [RFC PATCH 7/8] ASoC: Intel: Skylake: " Amadeusz Sławiński
2023-06-28 14:52   ` Andy Shevchenko
2023-06-29  8:19     ` Amadeusz Sławiński
2023-06-29  9:28       ` Andy Shevchenko
2023-06-28 20:51 ` [RFC PATCH 8/8] ASoC: SOF: Intel: " Amadeusz Sławiński
2023-06-28 14:54   ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bbe9f772-e049-4ad3-18aa-cca0b793439f@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=bhelgaas@google.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.