Re: [PATCH RESEND v3 3/6] i3c: mipi-i3c-hci: Add a quirk to set PIO mode

From: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
To: Jarkko Nikula <jarkko.nikula@linux.intel.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Guruvendra Punugupati <Guruvendra.Punugupati@amd.com>,
	Krishnamoorthi M <krishnamoorthi.m@amd.com>,
	linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RESEND v3 3/6] i3c: mipi-i3c-hci: Add a quirk to set PIO mode
Date: Mon, 19 Aug 2024 22:05:14 +0530	[thread overview]
Message-ID: <a5fb711a-daab-40ac-a9df-da542484e0f2@amd.com> (raw)
In-Reply-To: <9fbbefde-443d-458b-b2a7-b8e0c90af1bd@linux.intel.com>

On 8/19/2024 16:40, Jarkko Nikula wrote:
> On 8/19/24 9:41 AM, Shyam Sundar S K wrote:
>>> I can add an additional check with the CPU ID and distinguish them(so
>>> the quirk gets applied to the affected HW versions) and just not
>>> restrict to X86_VENDOR_AMD, would that be fine with you?
>>>
>>> OTOH, Since these are quirks (where its a broken hardware problems)
>>> and the idea you suggested is related to driver data (where driver
>>> data is meant to store private information about the device)
>>>
>>> static const struct acpi_device_id i3c_hci_acpi_match[] = {
>>>       {"AMDI1234", HCI_QUIRK_PIO_MODE | HCI_QUIRK_OD_PP_TIMING |
>>> HCI_QUIRK_RESP_BUF_THLD},
>>>       {}
>>> };
>>>
>>> does that not conflict? quirk vs driver data?
>>>
>>> I am OK to implement it the way you prefer :-)
>>
>> Jarkko, any feedback on this?
>>
> Sorry, forgot to reply... What do you mean about conflict? So if
> driver data would pass quirk bits as above and set only to unique ACPI
> ID specific to that HW then there is no reason to check CPU ID later
> in the code.

OK. Let me respin a new version.

Thanks,
Shyam

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c