Re: [PATCH] Raise the maximum number of usb-serial devices to 256
On 05/27/2013 04:30:12 AM, Tobias Winter wrote: Raise the maximum number of usb-serial devices to 256, which is the actual limit supported by the codebase. Signed-off-by: Jakob-Tobias Winter tob...@linuxdingsda.de Tested-by: Jakob-Tobias Winter tob...@linuxdingsda.de --- include/linux/usb/serial.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h index 302ddf5..c0ce5ed 100644 --- a/include/linux/usb/serial.h +++ b/include/linux/usb/serial.h @@ -20,7 +20,7 @@ #include linux/kfifo.h #define SERIAL_TTY_MAJOR 188 /* Nice legal number now */ -#define SERIAL_TTY_MINORS 254 /* loads of devices :) */ +#define SERIAL_TTY_MINORS 256 /* loads of devices :) */ #define SERIAL_TTY_NO_MINOR255 /* No minor was assigned */ So SERIAL_TTY_NO_MINOR is now a valid minor? Rob-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] build some drivers only when compile-testing
On 05/23/2013 09:01:40 AM, Ben Hutchings wrote: On Wed, 2013-05-22 at 19:23 -0700, Greg Kroah-Hartman wrote: On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote: Some drivers can be built on more platforms than they run on. This causes users and distributors packaging burden when they have to manually deselect some drivers from their allmodconfigs. Or sometimes it is even impossible to disable the drivers without patching the kernel. Introduce a new config option COMPILE_TEST and make all those drivers to depend on the platform they run on, or on the COMPILE_TEST option. Now, when users/distributors choose COMPILE_TEST=n they will not have the drivers in their allmodconfig setups, but developers still can compile-test them with COMPILE_TEST=y. I understand the urge, and it's getting hard for distros to handle these drivers that just don't work on other architectures, but it's really valuable to ensure that they build properly, for those of us that don't have many/any cross compilers set up. In http://landley.net/aboriginal/bin grab the cross-compiler-*.tar.bz2 tarballs, extract them, add the bin subdirectory of each to the $PATH. Congratulations, you have cross compilers set up. (They're statically linked and relocatable, so should run just about anywhere. If they don't, let me know and I'll fix it.) Example build: make ARCH=sparc sparc32_defconfig PATH=/home/landley/simple-cross-compiler-sparc/bin:$PATH \ make ARCH=sparc CROSS_COMPILE=sparc- Rob-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/5] Generic PHY Framework
On 02/19/2013 09:05:00 AM, Felipe Balbi wrote: Greg, can you pitch your suggestion here ? It would be great to hear your rationale behind dropping class infrastructure, couldn't find anything through Google and since feature-removal-schedule.txt has been removed (without adding it to feature-removal-schedule.txt, I must add :-) I don't know what's the idea behind removing classes. I actually went through and poked a couple of people about old entries in feature-removal-shedule.txt last year, but I haven't been very active since the kernel.org breakin because my account got disabled, and I needed to meet kernel developers in person to get keys signed to get it switched back on (or set up a separate git tree with signed commits -next could pull from). I don't get out much; as a consultant I have to take time off from work and pay for my own travel and lodging. So I've been to exactly two conferences in the past 3 years: last year's Texas Linux Fest (my house got broken into and a netbook with the key on it stolen the following wednesday), and CELF (which I'm on the plane back from now, Greg KH signed my key! Woo!). If I can use that to get my account back, set up a tree feeding into linux-next, and maybe even recover the ability to update http://kernel.org/doc, I'd happily field some sort of feature-removal-schedule list and make sure it stays current. (Linus didn't ask me about removing the old one, I found out about it from the git log. But I can't blame him, I haven't exactly been tearing through the bureaucracy to get my access back. Volunteer work and painful tend not to combine well on my todo list in terms of scheduling priority...) Rob-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/5] drivers: phy: add generic PHY framework
On 02/18/2013 11:53:14 PM, Kishon Vijay Abraham I wrote: The PHY framework 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. To obtain a reference to the PHY without using phandle, the platform specfic intialization code (say from board file) should have already called phy_bind with the binding information. The binding information consists of phy's device name, phy user device name and an index. The index is used when the same phy user binds to mulitple phys. Given that this has a separately selectable config option, I'm guessing that it's useful all by itself even in the absence of a driver using this phy? (Or it gives user visibility to the phy buried in an E1000 or SATA drive or some such?) +1. Introduction + +*PHY* is the abbreviation for physical layer. It is used to connect a device +to the physical medium e.g., the USB controller has a PHY to provide functions +such as serialization, de-serialization, encoding, decoding and is responsible +for obtaining the required data transmission rate. Note that some USB +controller has PHY functionality embedded into it and others use an external +PHY. Other peripherals that uses a PHY include Wireless LAN, Ethernet, +SATA etc. I've usually heard the word transciever used to describe these. +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. + +This framework will be of use only to devices that uses external PHY (PHY +functionality is not embedded within the controller). + +2. Creating the PHY + +The PHY driver should create the PHY in order for other peripheral controllers +to make use of it. The PHY framework provides 2 APIs to create the PHY. Given that a PHY is a chip (random example http://ark.intel.com/products/47620/Intel-82579LM-Gigabit-Ethernet-PHY), you seem to be saying that software should manifest a piece of hardware out of thin air through sheer willpower. I'm pretty sure I've misunderstood this phrasing. +struct phy *phy_create(struct device *dev, struct phy_descriptor *desc); +struct phy *devm_phy_create(struct device *dev, struct phy_descriptor *desc); + +The PHY drivers can use one of the above 2 APIs to create the PHY by passing Um, the driver should _bind_ to the phy, maybe? Allocate? Initialize? +6. Destroying the PHY I've run drivers like that. I try not to, though. +7. Current Status + +Currently only USB in OMAP is made to use this framework. However using the +USB PHY library cannot be completely removed because it is intertwined with +OTG. Once we move OTG out of PHY completely, using the old PHY library can be +completely removed. SATA in OMAP will also more likely use this new framework +and we should have a patch for it soon. Does this paragraph belong in the documentation? (Git commit, sure, but I've seen a lot of stale paragraphs like these hang around a surprisingly long time.) Rob-- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
