From: Nayna <nayna-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Jason Gunthorpe
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: Regarding recently Added TPM2.0 support to the Nuvoton i2c driver
Date: Fri, 29 Jul 2016 12:10:08 +0530 [thread overview]
Message-ID: <579AFA48.2040304@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160727223419.GA6132-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Thanks everyone for discussion and clarifying the design points. This
helps and we can now test by changing our device-tree entries.
Also, we are assuming that just updating .compatible device tree entry
should do the fix. We don't have to add any additional .data property.
And driver will match .data value even for nuvoton,npct650 from device
driver npct601 entry, where .data is explicitly specified.
Thanks & Regards,
- Nayna
On 07/28/2016 04:04 AM, George Wilson wrote:
> On Wed, Jul 27, 2016 at 11:42:29AM -0600, Jason Gunthorpe wrote:
>>> Should not the device tree tell you what is actually *there* and let the
>>> driver code decide what is compatible? Rather than the firmware trying to
>>> make a guess as to which Nuvoton device id to try to match in the Nuvoton
>>> driver code?
>>
>> Yes, that is what I suggested:
>>
>>>>>> compatible = "nuvoton,npct650", "nuvoton,npct601"
>>
>> Today's kernel has no idea what 650 is, but since the DT says it is
>> compatible with the 601 then today's kernel will bind to it. 601 is
>> the kernel documented compatible tag for that specific I2C
>> API.
>
> So in this case, early firmware would simply pass the additional
> compatible string.
>
>> Perhaps we should add 6xx as the generic flavor? I'm not as clear on
>> what DT maintainers think about that, but there is precedent.
>
> We thought about suggesting that too. However,
> http://elinux.org/Device_Tree_Usage advises:
>
> Warning: Don't use wildcard compatible values, like
> "fsl,mpc83xx-uart" or similar. Silicon vendors will invariably
> make a change that breaks your wildcard assumptions the moment
> it is too late to change it. Instead, choose a specific silicon
> implementations and make all subsequent silicon compatible with
> it.
>
> It looks like the driver's compatible table is on the right track and
> we need to make our platform's device tree conform to its expectations.
>
------------------------------------------------------------------------------
next prev parent reply other threads:[~2016-07-29 6:40 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-26 18:14 Regarding recently Added TPM2.0 support to the Nuvoton i2c driver Nayna
[not found] ` <5797A893.9020205-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-07-26 20:17 ` Jason Gunthorpe
[not found] ` <20160726201711.GA17742-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-26 20:39 ` George Wilson
[not found] ` <20160726203902.GA17730-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2016-07-26 21:03 ` Jason Gunthorpe
[not found] ` <20160726210344.GA18332-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-27 16:05 ` George Wilson
[not found] ` <20160727160511.GA26597-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2016-07-27 16:31 ` Jason Gunthorpe
[not found] ` <20160727163152.GA27915-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-27 21:46 ` George Wilson
2016-07-27 14:30 ` Dave Heller
[not found] ` <5798C571.1000309-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-07-27 16:24 ` Jason Gunthorpe
[not found] ` <20160727162415.GA18843-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-27 17:27 ` Dave Heller
[not found] ` <5798EEFB.1000004-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2016-07-27 17:42 ` Jason Gunthorpe
[not found] ` <20160727174229.GA28681-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-07-27 22:34 ` George Wilson
[not found] ` <20160727223419.GA6132-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2016-07-29 6:40 ` Nayna [this message]
2016-08-26 3:49 ` Jarkko Sakkinen
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=579AFA48.2040304@linux.vnet.ibm.com \
--to=nayna-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@public.gmane.org \
--cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.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;
as well as URLs for NNTP newsgroup(s).