linux-kernel - Re: [PATCH] usb: gadget: Add the console support for usb-to-serial port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VcrxjXTuRyBHDeH8i=DBbfgYoK5_yVJXpXQZrM2vr_wsg@mail.gmail.com>
Date:	Wed, 18 Nov 2015 11:32:18 +0200
From:	Andy Shevchenko <andy.shevchenko@...il.com>
To:	Baolin Wang <baolin.wang@...aro.org>
Cc:	Felipe Balbi <balbi@...com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	r.baldyga@...sung.com, fabio.estevam@...escale.com,
	Philip Oberstaller <Philip.Oberstaller@...tentrio.com>,
	Peter Hurley <peter@...leysoftware.com>,
	scottwood@...escale.com, Mark Brown <broonie@...nel.org>,
	USB <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: gadget: Add the console support for usb-to-serial port

On Wed, Nov 18, 2015 at 4:15 AM, Baolin Wang <baolin.wang@...aro.org> wrote:
> On 17 November 2015 at 21:34, Andy Shevchenko <andy.shevchenko@...il.com> wrote:
>> On Mon, Nov 16, 2015 at 9:05 AM, Baolin Wang <baolin.wang@...aro.org> wrote:
>>> It dose not work when we want to use the usb-to-serial port based
>>> on one usb gadget as a console. Thus this patch adds the console
>>> initialization to support this request.
>>

>>> +#define GS_BUFFER_SIZE         (4096)
>> Redundant parens
> OK. I'll remove it.
>
>>> +#define GS_CONSOLE_BUF_SIZE    (2 * GS_BUFFER_SIZE)
>>> +
>>> +struct gscons_info {
>>> +       struct gs_port          *port;
>>> +       struct tty_driver       *tty_driver;
>>> +       struct work_struct      work;
>>> +       int                     buf_tail;
>>> +       char                    buf[GS_CONSOLE_BUF_SIZE];
>>
>> Can't be malloced once?
> The 'gscons_info' structure is malloced once.

In state of high fragmentation is quite hard to find big memory chunks.
I would split it to two allocations, though if maintainers are okay
with your code, then I'm also okay.

>>> +static struct usb_request *gs_request_new(struct usb_ep *ep, int buffer_size)
>>> +{
>>> +       struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
>>> +
>>> +       if (!req)
>>
>> For sake of readability it's better to have assignment explicitly before 'if'.
>
> But I think it is very easy to understand the assignment here with
> saving code lines.

It's not a function of couple of lines, so, for me makes sense to
explicitly put the assignment here. Especially that one that does
allocations (for pointer arithmetic I could agree to place the
assignment in the definition block).

>>> +static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
>>> +{
>>> +       if (req->status != 0 && req->status != -ECONNRESET)
>>> +               return;
>>
>> Something missed here. Currently it's no-op.
>>
>
> Yeah. I didn't realize what need to do in the callback here, so just
> leave a callback without anything. But maybe something will be added
> if there are some requirements in future.

if ()
..

will be optimized away, why not to remove it?

>>> +       port = ports[port_num].port;
>>> +       if (!port) {
>>> +               pr_err("%s: serial line [%d] not allocated.\n",
>>> +                      __func__, port_num);
>>> +               return -ENODEV;
>>> +       }
>>> +
>>> +       if (!port->port_usb) {
>>> +               pr_err("%s: no port usb.\n", __func__);
>>
>> Starting from here could it be dev_err and so on?
>
> There are no dev_err things and device things in this file, so pr_xxx
> is more reasonable.

This is understandable, but if in case you have device in place why
not to use its name?

>>> +       pr_debug("%s: port[%d] console connect!\n", __func__, port_num);
>>
>> Dynamic debug will add function name if asked.
>
> Sorry, I didn't get your point, you mean print the function name is
> redundant here?

Right.

Just pr_debug("port[%d] …", …);

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/