In order for a serial function to add flags to the poll() mask of their
tty files, propagate the poll() callback to the next layer so it can
return a mask if it sees fit to do so.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 16
drivers/usb/gadget/funct
We shouldn't accept malformed set_line_coding requests.
All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec
available at http://www.usb.org/developers/docs/devclass_docs/
The table is in the file PTSN120.pdf.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/f_acm.c |
If a tty driver wants to notify the user of some exceptional event,
such as a usb cdc acm device set_line_coding event, it needs a way to
modify the mask returned by poll() and possible also add wait queues.
In order to do that, we allow the driver to supply a poll() callback
of its own, which will
The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).
Signed-off-by: Tal Shorer
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/usb/gadget/function/f_acm.c | 19 +++
include/uapi/linux/usb/f_acm.h
GetLineCoding and SetLineCoding are a cdc-acm thing. It doesn't make
sense to have that in the generic u_serial layer. Moreso, f_acm has its
own port_line_coding in its own struct and it uses that, while the one
in struct gserial is set once upon initialization and then never used.
Also, the initia
Initialize acm->port_line_coding with something that makes sense so
that we can return a valid line coding if the host requests
GetLineCoding before requesting SetLineCoding
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/f_acm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
In order for a serial function to implement its own ioctl() calls,
propagate the ioctl() callback to the next layer so it can handle it if
it sees fit to do so.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 15 +++
drivers/usb/gadget/function/u_serial.h | 1
Notify the user with a POLLPRI event when the host issues a
SetLineCoding request so that they can act upon it, for example by
configuring the line coding on a real serial port.
The event is cleared when the user reads the line coding using
USB_F_ACM_GET_LINE_CODING ioctl()
Signed-off-by: Tal Sho
I'm currently working on a project where I'd like to have an omap board
running linux be a usb-to-uart converter (using f_acm), and I've ran
into an issue: there's no way for the application to know if the host
has issued a SetLineCoding requests (after which parity/baudrate should
be changed to ma
On Tue, Jun 13, 2017 at 06:34:16AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
> >
> >
> > On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > > What test causes so many major numbers to be allocated? Is this
> > > in-kernel test code? Do
On Mon, Jun 12, 2017 at 10:29:20PM -0600, Logan Gunthorpe wrote:
>
>
> On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> > What test causes so many major numbers to be allocated? Is this
> > in-kernel test code? Do you really have a system that requires so many
> > different drivers that all wa
On 12/06/17 10:18 PM, Greg Kroah-Hartman wrote:
> What test causes so many major numbers to be allocated? Is this
> in-kernel test code? Do you really have a system that requires so many
> different drivers that all want a dynamic char major?
This is a 0day kernel robot test. I'm not sure the
On Mon, Jun 12, 2017 at 05:34:59PM -0600, Logan Gunthorpe wrote:
> 1) The test we are looking at is overrunning the dynamic char dev major
> numbers by a lot. On a successful run, it gets down to 216 where the
> limit is 234. Thus, there are 18 too many major numbers assigned and the
> fact that th
On Mon, Jun 12, 2017 at 9:02 PM, Tal Shorer wrote:
> On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer wrote:
>> The user can issue USB_F_GET_LINE_CODING to get the current line coding
>> as set by the host (or the default if unset yet).
>>
>> Signed-off-by: Tal Shorer
>> ---
>
>> @@ -764,10 +783,10
On Mon, Jun 12, 2017 at 8:26 PM, Tal Shorer wrote:
> The user can issue USB_F_GET_LINE_CODING to get the current line coding
> as set by the host (or the default if unset yet).
>
> Signed-off-by: Tal Shorer
> ---
> @@ -764,10 +783,10 @@ static struct usb_function *acm_alloc_func(struct
> usb_fu
If a tty driver wants to notify the user of some exceptional event,
such as a usb cdc acm device set_line_coding event, it needs a way to
modify the mask returned by poll() and possible also add wait queues.
In order to do that, we allow the driver to supply a poll() callback
of its own, which will
Initialize acm->port_line_coding with something that makes sense so
that we can return a valid line coding if the host requests
GetLineCoding before requesting SetLineCoding
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/f_acm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
In order for a serial function to add flags to the poll() mask of their
tty files, propagate the poll() callback to the next layer so it can
return a mask if it sees fit to do so.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 16
drivers/usb/gadget/funct
Notify the user with a POLLPRI event when the host issues a
SetLineCoding request so that they can act upon it, for example by
configuring the line coding on a real serial port.
The event is cleared when the user reads the line coding using
USB_F_ACM_GET_LINE_CODING ioctl()
Signed-off-by: Tal Sho
We shouldn't accept malformed set_line_coding requests.
All values were taken from table 17 (section 6.3.11) of the cdc1.2 spec
available at http://www.usb.org/developers/docs/devclass_docs/
The table is in the file PTSN120.pdf.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/f_acm.c |
In order for a serial function to implement its own ioctl() calls,
propagate the ioctl() callback to the next layer so it can handle it if
it sees fit to do so.
Signed-off-by: Tal Shorer
---
drivers/usb/gadget/function/u_serial.c | 15 +++
drivers/usb/gadget/function/u_serial.h | 1
The user can issue USB_F_GET_LINE_CODING to get the current line coding
as set by the host (or the default if unset yet).
Signed-off-by: Tal Shorer
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/usb/gadget/function/f_acm.c | 27 +++
include/uapi/linux/usb/f_acm
GetLineCoding and SetLineCoding are a cdc-acm thing. It doesn't make
sense to have that in the generic u_serial layer. Moreso, f_acm has its
own port_line_coding in its own struct and it uses that, while the one
in struct gserial is set once upon initialization and then never used.
Also, the initia
I'm currently working on a project where I'd like to have an omap board
running linux be a usb-to-uart converter (using f_acm), and I've ran
into an issue: there's no way for the application to know if the host
has issued a SetLineCoding requests (after which parity/baudrate should
be changed to ma
On 6/10/2017 11:01 AM, Borislav Petkov wrote:
On Wed, Jun 07, 2017 at 02:15:39PM -0500, Tom Lendacky wrote:
The boot data and command line data are present in memory in a decrypted
state and are copied early in the boot process. The early page fault
support will map these areas as encrypted, so
25 matches
Mail list logo
