Re: [PATCH v5 1/4] i2c: designware: Add quirk for Intel Xe

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

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