linux-kernel - Re: [PATCH 1/3] mfd: add Intel MSIC driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110921104456.GV32263@sortiz-mobl>
Date:	Wed, 21 Sep 2011 12:44:56 +0200
From:	Samuel Ortiz <sameo@...ux.intel.com>
To:	Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc:	linux-kernel@...r.kernel.org, alan@...ux.intel.com,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	feng.tang@...el.com, jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH 1/3] mfd: add Intel MSIC driver

Hi Mika,

On Wed, Sep 21, 2011 at 11:07:17AM +0300, Mika Westerberg wrote:
> > > +/*
> > > + * Other MSIC related devices which are not directly available via SFI DEVS
> > > + * table. 
> > Would that mean a broken firmware, or something else I'm missing ?
> > It looks odd.
> 
> Not all devices in the MSIC are listed in SFI DEVS table. For example
> regulators are missing. We currently don't have regulator support for MSIC
> but once it is added the devices will be created here.
> 
> Audio codec is similar - it does not exist in the SFI DEVS table.
Ok. So I can expect further patches removing this one then.


> > > +/**
> > > + * intel_msic_reg_read - read a single MSIC register
> > > + * @reg: register to read
> > > + * @val: register value is placed here
> > > + *
> > > + * Read a single register from MSIC. Returns %0 on success and negative
> > > + * errno in case of failure.
> > > + *
> > > + * Function may sleep.
> > > + */
> > > +int intel_msic_reg_read(unsigned short reg, u8 *val)
> > > +{
> > > +	return intel_scu_ipc_ioread8(reg, val);
> > > +}
> > > +EXPORT_SYMBOL_GPL(intel_msic_reg_read);
> > > +
> > > +/**
> > > + * intel_msic_reg_write - write a single MSIC register
> > > + * @reg: register to write
> > > + * @val: value to write to that register
> > > + *
> > > + * Write a single MSIC register. Returns 0 on success and negative
> > > + * errno in case of failure.
> > > + *
> > > + * Function may sleep.
> > > + */
> > > +int intel_msic_reg_write(unsigned short reg, u8 val)
> > > +{
> > > +	return intel_scu_ipc_iowrite8(reg, val);
> > > +}
> > > +EXPORT_SYMBOL_GPL(intel_msic_reg_write);
> > What is the benefit of those wrappers since you're probably not going to get
> > rid of the SCU IPC APIs, right ? What's wrong with the subdevices using the
> > SCU IPC API directly ?
> 
> Right, we are not going to get rid of SCU IPC APIs. The idea behind having
> these register access wrapper functions is that we are now able to separate
> the MSIC subdevices from other SCU IPC usage. In other words we get a bit
> cleaner "architecture".
I'm not entirely convinced that wrapping around the IPC API gives you a
cleaner architecture.

 
> It also allows us to add caching and intercepting register accesses if a
> need rises.
That would define a real need for this API, yes.


> > > +	for (i = 0; i < ARRAY_SIZE(msic_devs); i++) {
> > > +		if (!pdata->irq[i])
> > > +			continue;
> > I would expect some sort of warning here since it would mean your platform
> > code defined a sub device platform data without giving you the right IRQ. And
> > afaiu, all of your sub devices must have one.
> 
> The interface for platform data says that if irq is zero, it means that no
> platform device is created.
> 
> For example in patch 3/3 we add the platform data for battery, gpio, audio,
> power_button and ocd but the SFI table actually contains more devices. We
> don't yet have (upstream) driver for those so there is a little point of
> creating platform device for them at this point.

Ok, I see.

So, I'm fine with this patch, at least the MFD part. I'll go ahead and apply
it to my for-next branch. I'd appreciate to get ACKs or NACKs for the x86
parts from the relevant people though.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/