From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 5 Jan 2016 10:05:12 -0700 Subject: [U-Boot] [PATCH 0/3] dm: add dev_get_reg() for getting device node's reg In-Reply-To: References: <1450197123-1822-1-git-send-email-p.marczak@samsung.com> <5671B33E.5070701@wwwdotorg.org> <5682489B.2050408@samsung.com> <568ACFDE.5080306@wwwdotorg.org> Message-ID: <568BF7C8.6040706@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/04/2016 05:58 PM, Simon Glass wrote: > Hi Stephen, > > On 4 January 2016 at 13:02, Stephen Warren wrote: >> >> On 12/29/2015 01:47 AM, Przemyslaw Marczak wrote: >>> >>> Hello Stephen, >>> >>> On 12/16/2015 07:53 PM, Stephen Warren wrote: >>>> >>>> On 12/15/2015 09:32 AM, Przemyslaw Marczak wrote: >>>>> >>>>> commit: dm: core: Enable optional use of fdt_translate_address() >>>>> >>>>> enables device's bus/child address translation method, depending >>>>> on bus 'ranges' property and including child 'reg' property. >>>>> This change makes impossible to decode the 'reg' for node with >>>>> '#size-cells' equal to 0. >>>>> >>>>> Such case is possible by the specification and is also used in U-Boot, >>>>> e.g. by I2C uclass or S5P GPIO - the last one is broken at present. >>>> >>>> >>>> Can you please explain the problem you're seeing in more detail? Without >>>> any context, my initial reaction is that this is simply a bug somewhere. >>>> That bug should be fixed, rather than introducing new APIs to hide the >>>> problem. >>>> >>> >>> Some time ago I send a patch with such fix: >>> >>> [1] https://patchwork.ozlabs.org/patch/537372/ >>> >>> Sorry, I didn't add you to the 'CC' list. >>> >>> However. I checked this in linux, and the code is the same, the >>> size-cells == 0 is not supported also in Linux. >> >> >> The discussion there does indicate that removing the check on #size-cells would be incorrect. > > OK, but since we have a breakage and a release in a week, I'm planning > on picking up Przemyslaw's patch. We can revert it immediately > afterwards. > > Who is going to work out a proper solution (post-release)? I would assume the owner of the affected I2C/SPI controllers, or if the issue is triggered by core/subsystem code, then the owner of that subsystem.