Re: new binutils needed for arm in 3.12-rc1
Hi! Given you're not upgrading your binutils anymore that means you'll have to apply that patch only once instead of having to apply it to every kernel upgrade. Indeed. Patching my own toolchain isn't really a problem. My objection was to the Documentation patch telling the world at large that for all targets, older binutils aren't supported even on x86. That was worth pushing back against. I don't indend to use old gcc/binutils versions forever, I just want to be able to use them until I can replace them with llvm or similar. So, what is the proposal? Just ignore the problem and make people wonder why their arm kernels are not compiling? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new binutils needed for arm in 3.12-rc1
On Thu, Sep 26, 2013 at 9:18 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: Hi Rob, On Wed, Sep 25, 2013 at 3:13 AM, Rob Landley r...@landley.net wrote: Some of us can't ship GPLv3 binaries and are looking forward to the day LLVM or some such provides a complete solution. Sorry, I didn't have a coffee yet, but which subtility am I missing that prohibits you from shipping GPLv3 binaries? /me had coffee but still doesn't get why you can't ship GPLv3 binaries. Rob, can you please enlighten us? -- Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v12 0/7] PHY framework
On Saturday 28 September 2013 06:07 AM, Greg KH wrote: On Fri, Sep 27, 2013 at 11:53:24AM +0530, Kishon Vijay Abraham I wrote: Added a generic PHY framework that provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. This framework will be of use only to devices that uses external PHY (PHY functionality is not embedded within the controller). The intention of creating this framework is to bring the phy drivers spread all over the Linux kernel to drivers/phy to increase code re-use and to increase code maintainability. Comments to make PHY as bus wasn't done because PHY devices can be part of other bus and making a same device attached to multiple bus leads to bad design. If the PHY driver has to send notification on connect/disconnect, the PHY driver should make use of the extcon framework. Using this susbsystem to use extcon framwork will have to be analysed. You can find this patch series @ git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git testing I'll create a new branch *next* once this patch series is finalized. All the PHY driver development that depends on PHY framework can be based on this branch. Did USB enumeration testing in panda and beagle after applying [1] (needed for non-dt) All now applied to my usb-next branch. Thanks for redoing this many times and sticking with it. Thanks :-) -Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
