From linus.probert at gmail.com Fri May 1 17:13:52 2026 From: linus.probert at gmail.com (Linus Probert) Date: Fri, 01 May 2026 23:13:52 +0200 Subject: Upstreaming - how to deal with vendor fork In-Reply-To: <2026043025-confined-paralyses-bb09@gregkh> References: <2026043025-confined-paralyses-bb09@gregkh> Message-ID: On Thu Apr 30, 2026 at 9:15 AM CEST, Greg KH wrote: > On Wed, Apr 29, 2026 at 07:42:14PM +0200, Linus Probert wrote: >> On Wed Apr 29, 2026 at 3:27 PM CEST, Patryk wrote: >> > Hi >> > Some time ago I managed to upstream one bugfix, now I have more changes but >> > I'm wondering how to approach this. >> > >> > Suppose that I have found a bug and prepared a fix. However, the bug and >> > its solution has been found and tested on a custom board that is equipped >> > with a particular buggy device. The problem is that I cannot simply use >> > mainline/maintainer tree, build it, and run on my board as these source >> > trees do not have support for my board, as I use SoC vendor fork (v6.12) >> > supplied with their bsp with patches that add support for my board. >> > >> > It's not mine decision - obviously - me and my team would be very willing >> > to use mainline but it would require some effort, time and obviously we >> > would not get vendor support in case of some bugs (it happened mamy times). >> > >> > I can of course take the minimal set of patches for out board and apply >> > them over mainline but e.g. now I have a bugfix for mainline driver...but >> > in order to fully test it I need vendor changes as they did not upstream it >> > yet. >> > >> > So at the end in order to test a bugfix on the mainline I would need to >> > apply patches that add support for my board as well patches from vendor >> > fork that add support for the rest of the functionality (not yet upstreamed >> > by vendor) that I need in order to test the bugfix. >> > >> > Any sugestion on how to approach this? I have already few changes that >> > could be applied to mainline but due to what I described above they're just >> > waiting... >> > >> > Will be grateful for some sugestion. >> > >> > Best regards >> > Patryk >> >> Hi Patryk, >> >> if your patches can't be applied without first applying the vendors >> patches then there's not much you can do is there. Your fixes won't >> apply. >> >> If your patches do apply to staging-next and they do fix your issue >> isn't that enough to submit them? You should be able to explain how you >> have confirmed the fixes even though it requires some steps to get >> there. >> >> You can always submit a patch-tree to linux-staging with an RFC prefix >> and you will get feedback based on that. Either you get a no or a yes. >> Worth testing IMO. > > What does the staging tree have to do with this? > > confused, > > greg k-h Nothing most likely. Patryk should use an appropriate tree for his fixes if they are applicable. The driver was never named. I mostly look at the staging tree so it was fresh on my mind. Freudian slip if you will. Br, Linus From momin.mohammed7860 at gmail.com Sat May 9 12:11:59 2026 From: momin.mohammed7860 at gmail.com (Momin M) Date: Sat, 9 May 2026 21:41:59 +0530 Subject: Newbie Question: Clarifying I2C Master/Slave roles and device tree binding for client hardware info Message-ID: Hi all, I have been reading the I2C kernel documentation, and I understand the basic principles of SDA/SCL. I am now trying to grasp the kernel-side implementation. I'm struggling with two interconnected points regarding driver development: 1. *Master/Slave Abstraction:* How are the concepts of I2C "Master" and "Slave" represented in Linux kernel drivers? Specifically, is the i2c_adapter always considered the "master" (the controller that initiates transactions), and the i2c_client always considered the "slave" (the device being accessed), or are there contexts where this simple analogy breaks down (e.g., multi-master environments or slave-mode drivers)? 2. *Client Hardware Information:* I'm trying to understand the minimum necessary hardware information required for the i2c_client to probe successfully. Beyond the reg property (slave address) and a compatible string in the Device Tree, what other information, if any, is crucial for correctly instantiating the client device, especially for a standard, non-complex sensor? Any guidance on tracing this abstraction back to the low-level register/hardware interaction would be greatly appreciated. Thanks, Momin M -------------- next part -------------- An HTML attachment was scrubbed... URL: