linux-kernel - Re: am335x: TSC & ADC reworking including DT pieces, take 4

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: <51B74252.5090906@linutronix.de>
Date:	Tue, 11 Jun 2013 17:29:22 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Samuel Ortiz <sameo@...ux.intel.com>
CC:	Lee Jones <lee.jones@...aro.org>,
	Benoît Cousson <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	Jonathan Cameron <jic23@....ac.uk>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Felipe Balbi <balbi@...com>, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, linux-iio@...r.kernel.org,
	linux-input@...r.kernel.org
Subject: Re: am335x: TSC & ADC reworking including DT pieces, take 4

On 06/11/2013 04:23 PM, Samuel Ortiz wrote:
> Hi Sebastian,

Hi Samuel,

> On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote:
>> I believe the whole thing should go via the MFD tree. It touches also
>> input & iio subsystem. I collected ACKs where I got some in the meantime.
> Please fix your commit logs, and your subject lines. It should be e.g.
> mfd: input: ti_am335x_adc: Blablabla
> 
> if it's mostly an mfd patch that also touches an input driver.

I usually do "subsystem / driver: short description" but if you want
the ":" as delimiter I can do this.

> Then, this is a pretty big patchset, with iio, input and mfd all mixed
> together and it is likely to create merge conflicts.
They somehow depend on each other. Otherwise I would have sent three
series, one per subsystem.

>>>From what I can see from it, and please correct me if I'm
> wrong, the iio and input changes depend on the mfd ones, and not the
> other way around. If that's so, I'm going to ask you to reshuffle your
> patch set and separate the MFD changes from the iio and input ones. I'll
> take the MFD ones and will create an immutable branch for Jonathan and
> Dmitry to pull from and apply the iio and input changes on top of it.
> Merge conflicts should be mostly avoided that way.
> AFAICT, only patch #2 should be kept with input and iio bits mixed
> together with MFD as otherwise this would introduce functional breakage.
> Otherwise, all MFD bits from the other patches could be either separated
> or merged together (e.g. MFD bits from patches #6 and #8, and #16 and
> #17).
> 
> Does that sound doable to you ?

The device renaming shouldn't matter since I added DT nodes for the mfd
child devices earlier. But then the of_compatible assignments should
go hand in hand. However if I split this then the driver won't work
but then it does not now as well (because there is no platform_data
provider in tree).

Still. There is #18 which reworks the "step addressing" and involves
changes in both (iio & input) at the same time.
There is #21. Adding this to the initial "DT support" patch would be bad
I think because it requires some changes on the iio side which have
nothing to do with DT. Putting the iio changes before DT would require
to make some change to platform-data part which will go away anyway.

So I started collecting ACKs from input and iio to avoid this split. If
you really want the split then I will start doing so…

> Cheers,
> Samuel.

Sebastian
--
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/