[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87eem84sad.fsf@dell.be.48ers.dk>
Date: Thu, 08 Oct 2020 18:05:30 +0200
From: Peter Korsgaard <peter@...sgaard.com>
To: Sagar Kadam <sagar.kadam@...nfive.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-riscv\@lists.infradead.org" <linux-riscv@...ts.infradead.org>,
"linux-i2c\@vger.kernel.org" <linux-i2c@...r.kernel.org>,
"andrew\@lunn.ch" <andrew@...n.ch>,
"Paul Walmsley \( Sifive\)" <paul.walmsley@...ive.com>,
"palmer\@dabbelt.com" <palmer@...belt.com>,
"aou\@eecs.berkeley.edu" <aou@...s.berkeley.edu>
Subject: Re: [PATCH 1/1] i2c: ocores: fix polling mode workaround on FU540-C000 SoC
>>>>> "Sagar" == Sagar Kadam <sagar.kadam@...nfive.com> writes:
> Hello Peter,
>> Are both affected by this issue? if not, we will need to extend the code
>> to handle them differently.
>>
> No, this issue is present in FU540-C000 SoC i.e SoC- specific, and so I can check
> for the soc-compatible string as follows:
> - match = of_match_node(ocores_i2c_match, pdev->dev.of_node);
> - if (match && (long)match->data == TYPE_SIFIVE_REV0)
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "sifive,fu540-c000-i2c"))
> Please let me know if this is okay.
Yes, that sounds sensible. Thanks.
--
Bye, Peter Korsgaard
Powered by blists - more mailing lists