Re: [PATCH v5 0/8] Support ROHM BU27034 ALS sensor

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/22/23 12:34, Javier Martinez Canillas wrote:
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> writes:

Hello Andy,

On Wed, Mar 22, 2023 at 11:05:23AM +0200, Matti Vaittinen wrote:

Revision history:
v4 => v5: Mostly fixes to review comments from Andy and Jonathan.
- more accurate change-log in individual patches

- copy code from DRM test helper instead of moving it to simplify
   merging

1) Why do you think this is a problem?
2) How would we avoid spreading more copies of the same code in the future?


1) Merge conflicts is not a bad thing. It shows that people tested their code
in isolation and stabilized it before submitting to the upper maintainer.

https://yarchive.net/comp/linux/git_merges_from_upstream.html

2) Spreading the same code when we _know_ this, should be very well justified.
Merge conflict is an administrative point, and not a technical obstacle to
avoid.

I definitely agree. This is also why I did the renaming and not copying in the first version. In this version I did still add the subsequent patch 2/8 - which drops the duplicates from DRM tree.

I believe this was suggested by Maxime and the rationale is that by just
copying the helpers for now, that would make it easier to land instead of
requiring coordination between different subystems.

This is correct.

Otherwise the IIO tree will need to provide an inmutable branch for the
DRM tree to merge and so on.

Or, if we carry the patch 1/8 via self-test tree, then we get even more players here.

Still, I am not opposing immutable branch because that would allow fast applying of the patch 2/8 as well. Longer that is delayed, more likely we will see more users of the DRM helpers and harder it gets to remove the duplicates later.

I agree with Maxime that a little bit of duplication (that can be cleaned
up by each subsystem at their own pace) is the path of least resistance.

I'd say this depends. It probably is the path of least resistance for people maintaining the trees. It can also be the path of least resistance in general - but it depends on if there will be no new users for those DRM helpers while waiting the new APIs being merged in DRM tree. More users we see in DRM, more effort the clean-up requires.

I have no strong opinion on this specific case. I'd just be happy to see the IIO tests getting in preferably sooner than later - although 'soon' and 'late' does also depend on other factors besides these helpers...

Yours,
	-- Matti

--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux