Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Ricard Wanderlof wrote: > The designers of this IP apparantly did not have Linux in mind when they > designed the controller, since it does all the low level stuff > autonomously (in the right IP configuration it can even remap flash blocks > transparently),

Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Boris Brezillon wrote: > I also agree on this aspect. Though what you consider an evolution with > these 'high-level' controllers is in my opinion a regression. > > By supporting only a subset of what NAND chips actually support, and > preventing any

Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Boris Brezillon wrote: > Hm, I think it's changing now that a lot of SoCs are advertised to be > running Linux. But you're right in that existing IPs might not support > this low-level mode. Faraday (the IP vendor in the present case) advertise

Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

Greg K-H wrote: > Thanks for the long response, but I think you have to realize that > creating a new api for something that has been "how things work" since > the 1970's should not be taken lightly. No matter if it was a bug or > not, changing user-visable behavior is not a trivial thing. But

Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

Greg K-H wrote: > I think we need more review for the rest of the series. This does > change the way serial ports work in a non-traditional way (i.e. using > sysfs instead of terminal settings). But the problem is that the current status quo is fundamentally broken for those hardware devices in

Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

Greg K-H wrote: > We see devices that are "obviously" not the real vid/pid all the time in > the wild. There's nothing "illegal" about another company using your > vid/pid, look at all of the ones out there already that use the FTDI > vendor id yet are "clones", same with pl2303 devices. But

Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open

A quick background for Greg and others who haven't seen the Sept-Oct discussion between me and Johan on the linux-usb ML: I am the hardware engineer who designed the FT2232D-based DUART28C adapter board, and it was my desire to have this custom FT2232D adapter supported in mainline Linux that

Re: [PATCH 1/5] tty: add port flag to suppress ready signalling on open

> Add a NORDY port flag to suppress raising the modem-control lines on > open to signal DTE readiness. > > This can be used to implement a NORDY termios control flag to complement > HUPCL, which controls lowering of the modem-control lines on final > close. > > Initially drivers can export the

Re: [PATCH 1/5] tty: add port flag to suppress ready signalling on open

On 11/30/20, Jiri Slaby wrote: > port can be const here. > [...] > We have assign_bit() for these cases these days. Johan's patch adding test and set accessor inline functions for the new flag follows the style of the existing accessor inline functions for previously existing flags, for the sake

Re: [PATCH 0/5] tty: add flag to suppress ready signalling on open

On 11/30/20, Jiri Slaby wrote: > The difference to other control flags is that open raises DTR/RTS in any > case (i.e. including O_NONBLOCK) Yes, this is the exact root-cause problem I am trying to fix, with Johan's help. > -- provided baud rate is set (and it is > for casual serials). That

Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

On 12/2/20, Johan Hovold wrote: > Also let me know if you prefer to hold this off for 5.12. The change is > minimal, self-contained and low-risk, but it is a new interface and late > in the release cycle as Andy pointed out. Hold off for 5.12? Did you perhaps mean 5.11? I understand how this

Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

Greg K-H wrote: > our job is to make Linux work for everyone. But as your refusal to accept the purely additive (zero impact on anything other than specific hw in question) patch adding support for a new hardware device clearly indicates, your job is NOT to make Linux work for everyone, but

Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Ricard Wanderlof wrote: > The designers of this IP apparantly did not have Linux in mind when they > designed the controller, since it does all the low level stuff > autonomously (in the right IP configuration it can even remap flash blocks > transparently), with no way of intervening.

Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Boris Brezillon wrote: > I also agree on this aspect. Though what you consider an evolution with > these 'high-level' controllers is in my opinion a regression. > > By supporting only a subset of what NAND chips actually support, and > preventing any raw access, you just limit the

Re: [PATCH 3/4] mtd: nand: Add support for Evatronix NANDFLASH-CTRL

On 6/9/16, Boris Brezillon wrote: > Hm, I think it's changing now that a lot of SoCs are advertised to be > running Linux. But you're right in that existing IPs might not support > this low-level mode. Faraday (the IP vendor in the present case) advertise Linux support as well, but they never