[PATCH v5 1/4] i2c: designware: Add quirk for Intel Xe
Andy Shevchenko
andriy.shevchenko at linux.intel.com
Mon Jun 30 13:16:56 UTC 2025
On Mon, Jun 30, 2025 at 02:59:21PM +0300, Heikki Krogerus wrote:
> On Mon, Jun 30, 2025 at 01:02:56PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 30, 2025 at 11:10:00AM +0300, Heikki Krogerus wrote:
> > > On Mon, Jun 30, 2025 at 10:30:19AM +0300, Andy Shevchenko wrote:
> > > > On Fri, Jun 27, 2025 at 05:32:01PM -0400, Rodrigo Vivi wrote:
> > > > > On Fri, Jun 27, 2025 at 05:13:36PM +0300, Andy Shevchenko wrote:
> > > > > > On Fri, Jun 27, 2025 at 04:53:11PM +0300, Heikki Krogerus wrote:
...
> > > > > > > static int dw_i2c_plat_probe(struct platform_device *pdev)
> > > > > > > {
> > > > > > > + u32 flags = (uintptr_t)device_get_match_data(&pdev->dev);
> > > > > >
> > > > > > > - dev->flags = (uintptr_t)device_get_match_data(device);
> > > > > > > if (device_property_present(device, "wx,i2c-snps-model"))
> > > > > > > - dev->flags = MODEL_WANGXUN_SP | ACCESS_POLLING;
> > > > > > > + flags = MODEL_WANGXUN_SP | ACCESS_POLLING;
> > > > > > >
> > > > > > > dev->dev = device;
> > > > > > > dev->irq = irq;
> > > > > > > + dev->flags = flags;
> > > > > >
> > > > > > Maybe I'm missing something, but why do we need these (above) changes?
> > > > >
> > > > > in between, it is introduced a new one:
> > > > > flags |= ACCESS_POLLING;
> > > > >
> > > > > So, the initialization moved up, before the ACCESS_POLLING, and
> > > > > it let the assignment to the last, along with the group.
> > > >
> > > > I still don't get. The cited code is complete equivalent.
> > >
> > > This was requested by Jarkko.
> >
> > Okay, but why? Sounds to me like unneeded churn. Can't we do this later when
> > required?
>
> You need to ask why from Jarkko - I did not really question him on
> this one. Unfortunately his on vacation at the moment.
Yeah :-(
> I can drop this, but then I'll have to drop also Jarkko's ACK.
I can give mine if it helps. The code as far as I can see is 100% equivalent.
> I think we already agreed that this function, and probable the entire
> file, need to be refactored a bit, so would you mind much if we just
> went ahead with this as it is?
>
> I'm asking that also because I don't have means or time to test this
> anymore before I start my vacation.
I see, then we may ask Andi and Wolfram on this. I slightly prefer to have
no additional churn added without a good reason.
--
With Best Regards,
Andy Shevchenko
More information about the Intel-xe
mailing list