On 10/01/2014 22:52, Gregory CLEMENT wrote: > On 10/01/2014 22:37, Jason Cooper wrote: >> On Fri, Jan 10, 2014 at 10:21:29PM +0100, Gregory CLEMENT wrote: >>> On 10/01/2014 22:14, Jason Cooper wrote: >>>> On Fri, Jan 10, 2014 at 09:12:41PM +0100, Gregory CLEMENT wrote: >>>>> Jason, >>>>> On 10/01/2014 21:08, Jason Cooper wrote: >>>>>> On Fri, Jan 10, 2014 at 02:45:50PM -0500, Jason Cooper wrote: >>>>>>> On Fri, Jan 10, 2014 at 12:05:21PM -0700, Jason Gunthorpe wrote: >>>>>>>> On Fri, Jan 10, 2014 at 01:22:40PM -0500, Jason Cooper wrote: >>>>>>>> >>>>>>>>> Do we create new compatible strings to indicate errata, or to indicate >>>>>>>>> 'from this version forward there are new features'? The former would >>>>>>>>> indicate as Gregory has written '...-a0-i2c', the latter would warrant >>>>>>>>> '...-b0-i2c' and disabling offloading if we don't see '...-b0-i2c'. >>>>>>> >>>>>>> s/-b0-i2c'./-b0-i2c' or newer./ >>>>>>> >>>>>>>> IMHO the compatible string should represent a specific HW/SW ABI. So >>>>>>>> you need a unique compatible string for every variation of that ABI. >>>>>>> >>>>>>> My concern is that we tend to do things like "marvell,orion-sata" for >>>>>>> the first version of the IP block we can work with. orion5x, kirkwood, >>>>>>> dove, and armada 370/xp all use that compatible string to refer to that >>>>>>> IP block. >>>>>>> >>>>>>> Given that we look at it as 'and newer', '...-a0-i2c' would mean no >>>>>>> offloading until we introduce '-b0-i2c'. Or am I mis-understanding what >>>>>>> you're saying? >>>>>>> >>>>>>>> We already have a compatible string defined for the ABI that B0 >>>>>>>> presents. >>>>>>> >>>>>>> So 'mv78230-i2c' is newer than 'mv78230-a0-i2c', or are you referring to >>>>>>> something else? >>>>>> >>>>>> I think the crux of it is: Is mv78230-i2c the first, or the default? >>>>> >>>>> Here it's clearly the default >>>> >>>> So we should default to no offloading when we see it? Since it has been >>>> deployed referring to -a0 revision i2c IP blocks? >>>> >>> >>> But this assumption is wrong as I already wrote few days ago, mv78230-i2c >>> has been deployed referring to -b0 revision i2c IP blocks since the begining. >> >> Ok, sorry. As I wrote on irc last week, I've been on travel and haven't >> been able to fully digest everything coming in. My re-read of all the >> threads regarding this this morning didn't catch it. > > No problem there was a lot of email just for this simple fix! > >> >>> It was developed on and for B0 version, and this compatible was created for >>> this specific version. It was latter that we realized that it was not fully >>> compatible with A0. But for sure: >>> >>> mv78230-i2c == I2C IP running on Armada XP B0 (or latter) >> >> Ok, this still feels counter-intuitive, and folks not familiar with the >> development process might assume the opposite. So I'll reply to 4/4 >> with a reword to make your above statement an explicit part of the >> binding documentation. No need to do another patch version. I'll fix >> it up when I pull it in if you're ok with it. > > Please use my branch because as I wrote you: > https://github.com/MISL-EBU-System-SW/mainline-public/tree/i2c-mv64xxx-3.13-rc6-fixes-v6 > > I took into account the last minor review from Arnd and Wolfram, and I > also updated all the flags acked-by and reported-by. But if you prefer > I can just sent a 6th version on the mailing list. Hi Jason, Finally 3.13 was not released but the 3.13-rc8 instead. Do you consider to pull this series and then push it this week, before the final release of 3.13? Thanks, Gregory > > Thanks, > > Gregory > > >> >> thx, >> >> Jason. >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
