public inbox for linux-i3c@lists.infradead.org
 help / color / mirror / Atom feed
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 12:11:46 +0530	[thread overview]
Message-ID: <9b8f3c29-3404-4db4-80cf-8fd1b5d018c8@amd.com> (raw)
In-Reply-To: <d0ca0a49-311e-4af3-95df-f7c6f85e184f@amd.com>



On 8/12/2024 15:02, Shyam Sundar S K wrote:
> Hi,
> 
> On 8/12/2024 14:47, Jarkko Nikula wrote:
>> Hi
>>
>> On 8/9/24 6:44 PM, Shyam Sundar S K wrote:
>>>> I was thinking these quirks can be passed as driver_data more cleanly
>>>> and be specific only to affected HW if AMD HW would have an unique
>>>> ACPI ID for each HW version.
>>>>
>>>> Above X86_VENDOR_AMD might be too generic if and when quirks are fixed
>>>> in the future HW :-)
>>>>
>>>> So something like:
>>>>
>>>> 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},
>>>>      {}
>>>> };
>>>>
>>>> and set them in the i3c_hci_probe() as:
>>>>
>>>> hci->quirks = (unsigned long)device_get_match_data(&pdev->dev);
>>>
>>> Nice idea. But only problem is that MSFT wants to have the same ACPI
>>> ID present in the specification.
>>>
>>> I have replied to Andy on patch 1/6. Can you please put your remarks
>>> there?
>>>
>> Well this is implementation detail later in the series and I found it
>> better to focus ACPI ID discussion in 1/6.
>>
>>> Yeah, agreed that having X86_VENDOR_AMD is too generic, but felt its
>>> good to have additional checks only after the HW is fixed, rather than
>>> being speculative now.. :-)
>>>
>>> What would you advise?
>>> Most probably there will be future HW with either exactly same set of 
>> quirks, reduced quirks or new quirks and X86_VENDOR_AMD test will work
>> only with the first case :-)
> 
> 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?

Thanks,
Shyam

> 
> Thanks,
> Shyam
> 
> 
> 

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

  reply	other threads:[~2024-08-19  6:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07  5:23 [PATCH RESEND v3 0/6] Introduce initial AMD I3C HCI driver support Shyam Sundar S K
2024-08-07  5:23 ` [PATCH RESEND v3 1/6] i3c: mipi-i3c-hci: Add MIPI0100 ACPI ID to the I3C Support List Shyam Sundar S K
2024-08-09 13:54   ` Jarkko Nikula
2024-08-09 14:18     ` Andy Shevchenko
2024-08-09 15:32       ` Shyam Sundar S K
2024-08-09 15:57         ` Andy Shevchenko
2024-08-09 16:24           ` Shyam Sundar S K
2024-08-09 18:39           ` Alexandre Belloni
2024-08-12 12:17             ` Andy Shevchenko
2024-08-07  5:23 ` [PATCH RESEND v3 2/6] i3c: mipi-i3c-hci: Read HC_CONTROL_PIO_MODE only after i3c hci v1.1 Shyam Sundar S K
2024-08-09 13:21   ` Jarkko Nikula
2024-08-09 15:46     ` Shyam Sundar S K
2024-08-07  5:23 ` [PATCH RESEND v3 3/6] i3c: mipi-i3c-hci: Add a quirk to set PIO mode Shyam Sundar S K
2024-08-09 13:55   ` Jarkko Nikula
2024-08-09 15:44     ` Shyam Sundar S K
2024-08-12  9:17       ` Jarkko Nikula
2024-08-12  9:32         ` Shyam Sundar S K
2024-08-19  6:41           ` Shyam Sundar S K [this message]
2024-08-19 11:10             ` Jarkko Nikula
2024-08-19 16:35               ` Shyam Sundar S K
2024-08-07  5:23 ` [PATCH RESEND v3 4/6] i3c: mipi-i3c-hci: Relocate helper macros to HCI header file Shyam Sundar S K
2024-08-09 13:21   ` Jarkko Nikula
2024-08-07  5:23 ` [PATCH RESEND v3 5/6] i3c: mipi-i3c-hci: Add a quirk to set timing parameters Shyam Sundar S K
2024-08-07  5:23 ` [PATCH RESEND v3 6/6] i3c: mipi-i3c-hci: Add a quirk to set Response buffer threshold Shyam Sundar S K

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=9b8f3c29-3404-4db4-80cf-8fd1b5d018c8@amd.com \
    --to=shyam-sundar.s-k@amd.com \
    --cc=Guruvendra.Punugupati@amd.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=krishnamoorthi.m@amd.com \
    --cc=linux-i3c@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox