Re: [PATCH v5 3/5] serial: fsl_linflexuart: Be consistent with the name
On Wed, Oct 02, 2019 at 01:04:42PM +, Stefan-gabriel Mirea wrote: > --- a/include/uapi/linux/serial_core.h > +++ b/include/uapi/linux/serial_core.h > @@ -290,7 +290,7 @@ > /* Sunix UART */ > #define PORT_SUNIX 121 > > -/* Freescale Linflex UART */ > -#define PORT_LINFLEXUART 121 > +/* Freescale LINFlexD UART */ > +#define PORT_LINFLEXUART 122 This is a different change, and one that should be split out and submitted now, for 5.4. Please do that as the id number is incorrect, don't bury a valid change in the middle of a "marketing renamed the device" patch :) thanks, greg k-h
Re: [PATCH v3 4/7] serial: fsl_linflexuart: Be consistent with the name
On Fri, Aug 23, 2019 at 07:11:37PM +, Stefan-gabriel Mirea wrote: > For consistency reasons, spell the controller name as "LINFlexD" in > comments and documentation. > > Signed-off-by: Stefan-Gabriel Mirea > --- > Documentation/admin-guide/kernel-parameters.txt | 2 +- > drivers/tty/serial/Kconfig | 8 > drivers/tty/serial/fsl_linflexuart.c| 4 ++-- > include/uapi/linux/serial_core.h| 4 ++-- > 4 files changed, 9 insertions(+), 9 deletions(-) Doesn't apply to my tty-next tree :(
Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
On Wed, Aug 07, 2019 at 04:42:17PM +, Stefan-gabriel Mirea wrote: > On 8/6/2019 9:40 PM, gre...@linuxfoundation.org wrote: > > On Tue, Aug 06, 2019 at 05:11:17PM +, Stefan-gabriel Mirea wrote: > >> On 8/5/2019 6:31 PM, gre...@linuxfoundation.org wrote: > >>> On Fri, Aug 02, 2019 at 07:47:23PM +, Stefan-gabriel Mirea wrote: > >>>> > >>>> +/* Freescale Linflex UART */ > >>>> +#define PORT_LINFLEXUART 121 > >>> > >>> Do you really need this modified? > >> > >> Hello Greg, > >> > >> This macro is meant to be assigned to port->type in the config_port > >> method from uart_ops, in order for verify_port to know if the received > >> serial_struct structure was really targeted for a LINFlex port. It > >> needs to be defined outside, to avoid "collisions" with other drivers. > > > > Yes, I know what it goes to, but does anyone in userspace actually use > > it? > > No, we do not use it from userspace, but kept the pattern only for > conformance. > > >> Other than that, I do not see anything wrong with the addition of a > >> define in serial_core.h for this purpose (which is also what most of the > >> serial drivers do, including amba-pl011.c, mentioned in > >> Documentation/driver-api/serial/driver.rst as providing the reference > >> implementation), so please be more specific. > > > > I am getting tired of dealing with merge issues with that list, and no > > one seems to be able to find where they are really needed for userspace, > > especially for new devices. What happens if you do not have use it? > > I see. If I drop its usage completely and leave 'type' from the > uart_port as 0, uart_port_startup() will fail when finding that > uport->type == PORT_UNKNOWN at [1] (there may be other effects as well, > e.g. due to the check in uart_configure_port[2]). > > So I suppose that I need to define some nonzero 'PORT_KNOWN' macro in > the driver and use that one internally for 'type'. Is my understanding > correct? Will there be any problems if I define it to a positive integer > which is already assigned to another driver, according to serial_core.h? Ugh, ok, that's messy, nevermind. Keep the #define in there, I will try to figure out how to move all of these at once sometime in the future... sorry for the noise. greg k-h
Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
On Tue, Aug 06, 2019 at 05:11:17PM +, Stefan-gabriel Mirea wrote: > On 8/5/2019 6:31 PM, gre...@linuxfoundation.org wrote: > > On Fri, Aug 02, 2019 at 07:47:23PM +, Stefan-gabriel Mirea wrote: > >> > >> +/* Freescale Linflex UART */ > >> +#define PORT_LINFLEXUART 121 > > > > Do you really need this modified? > > Hello Greg, > > This macro is meant to be assigned to port->type in the config_port > method from uart_ops, in order for verify_port to know if the received > serial_struct structure was really targeted for a LINFlex port. It > needs to be defined outside, to avoid "collisions" with other drivers. Yes, I know what it goes to, but does anyone in userspace actually use it? > As far as I see, uart_set_info() will actually fail at the > "baud_base < 9600" check[1], right after calling verify_port(), when > performing an ioctl() on "/dev/console" with TIOCSSERIAL using a > serial_struct obtained with TIOCGSERIAL. This happens because this > reduced version of the LINFlex UART driver will not touch the uartclk > field of the uart_port (as there is currently no clock support). > Therefore, the linflex_config/verify_port() functions, along with the > PORT_LINFLEXUART macro, may be indeed unnecessary at this point (and > should be added later). Is this what you mean? No, see below. > Other than that, I do not see anything wrong with the addition of a > define in serial_core.h for this purpose (which is also what most of the > serial drivers do, including amba-pl011.c, mentioned in > Documentation/driver-api/serial/driver.rst as providing the reference > implementation), so please be more specific. I am getting tired of dealing with merge issues with that list, and no one seems to be able to find where they are really needed for userspace, especially for new devices. What happens if you do not have use it? thanks, greg k-h
Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
On Fri, Aug 02, 2019 at 07:47:23PM +, Stefan-gabriel Mirea wrote: > --- a/include/uapi/linux/serial_core.h > +++ b/include/uapi/linux/serial_core.h > @@ -293,4 +293,7 @@ > /* SiFive UART */ > #define PORT_SIFIVE_V0 120 > > +/* Freescale Linflex UART */ > +#define PORT_LINFLEXUART 121 Do you really need this modified? thanks, greg k-h
Re: Documentation: add Kernel Driver Statement to the kernel
On Sat, Oct 14, 2017 at 08:09:59PM +0200, Wolfram Sang wrote: > > > 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? > > That goes without saying, but we still added plain textfiles to > Documentation/ since 2008, so I was wondering... And really, all news one should be in correct markdown format, as it is almost identical to a "normal" text file. Heck, it really is just a "plain" textfile, you can read it as-such, 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: 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 > > 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 > > >> 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
