Re: Documentation: add Kernel Driver Statement to the kernel
On Sat, Oct 14, 2017 at 06:14:13PM +0200, Wolfram Sang wrote: > On Fri, Oct 06, 2017 at 11:10:38AM +0200, gre...@linuxfoundation.org wrote: > > Way back in 2008 we didn't have "robust" in-kernel documentation system, > > so the idea of putting something like the kernel driver statement in the > > kernel tree wasn't even imagined. But now that has changed, so add the > > old document to the kernel source itself to allow for us to properly > > reference it in one canonical place (as the LF wiki keeps moving things > > around.) > > Cool, I like it much to see it added to the kernel tree. > > But could you explain what "robust" means in this context? We did not have a way to easily turn the files in Documentation/ into html and pdf docs like we now do. The documentation is now auto-generated and placed up on kernel.org here: https://www.kernel.org/doc/html/ > And what has changed which makes it "robust"? Sphinx? Yes, remember the mess we had before? Not that sphinx doesn't have it's own issues, but you have to admit it is much better now than it used to be, right? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Sun, Nov 20, 2016 at 06:30:19AM +, Levy, Amir (Jer) wrote: > On Fri, Nov 18 2016, 12:07 PM, gre...@linuxfoundation.org wrote: > > On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote: > > > > BTW, it is quite a shame that the Thunderbolt firmware version can't > > > > be read from Linux. > > > > > > > > > > This is WIP, once this patch will be upstream, we will be able to > > > focus more on aligning Linux with the Thunderbolt features that we have > > for windows. > > > > Why is this patch somehow holding that work back? You aren't just sitting > > around waiting for people to review this and not doing anything else, right? > > Is there some basic building block in these patches that your firmware > > download code is going to rely on? > > > > confused, > > > > greg k-h > > All the Thunderbolt SW features (including networking and FW update) depend > on the communication with FW, which is patch 3/8 in the series. > The patch also sets up a generic netlink for user space communication. It's that "generic netlink" connection that I really want a whole lot of revewers to read over as it's very unusual and "different" from all other driver subsystems. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Nov 18, 2016 at 08:48:36AM +, Levy, Amir (Jer) wrote: > > BTW, it is quite a shame that the Thunderbolt firmware version can't > > be read from Linux. > > > > This is WIP, once this patch will be upstream, we will be able to focus more > on aligning Linux with the Thunderbolt features that we have for windows. Why is this patch somehow holding that work back? You aren't just sitting around waiting for people to review this and not doing anything else, right? Is there some basic building block in these patches that your firmware download code is going to rely on? confused, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/8] thunderbolt: Introducing Thunderbolt(TM) Networking
On Fri, Sep 30, 2016 at 08:37:36AM +, Levy, Amir (Jer) wrote: > On Fri, Sep 30 2016, 09:40 AM, David Miller wrote: > > From: Greg KH <gre...@linuxfoundation.org> > > Date: Fri, 30 Sep 2016 08:30:05 +0200 > > > > > On Fri, Sep 30, 2016 at 01:55:55AM -0400, David Miller wrote: > > >> From: Amir Levy <amir.jer.l...@intel.com> > > >> Date: Wed, 28 Sep 2016 17:44:22 +0300 > > >> > > >> > This driver enables Thunderbolt Networking on non-Apple platforms > > >> > running Linux. > > >> > > >> Greg, any idea where this should get merged once fully vetted? I can > > >> take it through the net-next tree, but I'm fine with another more > > >> appropriate tree taking it as well. > > > > > > I am supposed to be taking thunderbolt patches, but if this really is > > > a network driver, it should go under drivers/net/ somewhere. It needs > > > more review though, it's not ready to go through anyone's tree just > > > yet :) > > > > > > I'll let the thunderbolt maintainer go through it first before asking > > > for a netdev review. > > > > Ok, thanks Greg. > > Greg, David, > Andreas replied to similar request on patch v6: > "This driver is independent from mine. It uses an interface provided > by the firmware which is not present on Apple hardware and with which > I am not familiar (also it does networking, not pci with which I am > also not familiar). So I cannot comment on the driver itself. I don't > mind a second driver, if that is what you are asking." Yes, but I still need an ack from the thunderbolt maintainer that you aren't doing anything foolish with that interface before I can take the code. > Note that Thunderbolt Networking is the first feature we would like to > submit, but the next features aren't related to network, but more to > Thunderbolt functionality. If this really is a real network device, it should probably live in drivers/net/ like other network drivers. > This is the reason I created the directory thunderbolt/icm, since the > next features requires ICM to be enabled as well. As long as you have ICM split out so that other drivers can use it, it should be fine, no matter where in the tree it lives, right? > I also followed the firewire as example that includes net.c (in > drivers/firewire directory) along with other firewire functionality. That's the old-style of placing files. We have moved the USB network drivers out of drivers/usb/ a while ago. The current thought is to group drivers of specific types, not busses, together wherever possible, as that is usually the majority of the logic in the driver (i.e. a USB network driver has more network-driver specific logic than USB-specific logic.) Hope this helps explain things. I'll get to your patches next week, they are in my queue at the moment, but have conferences to deal with at the moment. Don't let my delay stop you from working on further "ICM" drivers if needed, you can always send new series of patches that build on this one when you have it ready. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usb device to ether is not identification in 64bit Windows OS
On Sun, Sep 18, 2016 at 01:16:59PM +, Lipengcheng wrote: > Hi, > kernel version：4.8.0 > file:Documentation / usb / linux.inf > problem:PC windows is 32bit OS, using Ethernet gadget driver, it can > be correct identification. But PC windows is 64bit OS, while modifying > linux.inf file LinuxDevice parameters, it can not correct > identification, the serial port can be printed correctly:g_ether > gadget: high-speed config # 2: RNDIS. I suspect that the linux.inf > files are not mismatch 64bit windows OS. Given that everyone here does not use Windows at all, you are going to be on your own here, sorry. If you do come up with an updated .inf file, we will be glad to take a patch. good luck, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
