linux-kernel - Re: [PATCH 7/9] serdev: Introduce new bus for serial attached devices

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]

Date:   Thu, 12 Jan 2017 14:13:42 -0600
From:   Rob Herring <robh@...nel.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sebastian Reichel <sre@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        "Dr . H . Nikolaus Schaller" <hns@...delico.com>,
        Peter Hurley <peter@...leysoftware.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Loic Poulain <loic.poulain@...el.com>,
        Pavel Machek <pavel@....cz>, NeilBrown <neil@...wn.name>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/9] serdev: Introduce new bus for serial attached devices

On Sat, Jan 7, 2017 at 8:02 AM, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
> On Fri, 2017-01-06 at 10:26 -0600, Rob Herring wrote:
>> The serdev bus is designed for devices such as Bluetooth, WiFi, GPS
>> and NFC connected to UARTs on host processors. Tradionally these have
>> been handled with tty line disciplines, rfkill, and userspace glue
>> such
>> as hciattach. This approach has many drawbacks since it doesn't fit
>> into the Linux driver model. Handling of sideband signals, power
>> control
>> and firmware loading are the main issues.
>>
>> This creates a serdev bus with controllers (i.e. host serial ports)
>> and
>> attached devices. Typically, these are point to point connections, but
>> some devices have muxing protocols or a h/w mux is conceivable. Any
>> muxing is not yet supported with the serdev bus.

[...]

>> +static int of_serdev_register_devices(struct serdev_controller *ctrl)
>> +{
>> +     struct device_node *node;
>> +     struct serdev_device *serdev = NULL;
>> +     int err;
>> +     bool found = false;
>> +
>> +     for_each_available_child_of_node(ctrl->dev.of_node, node) {
>> +             if (!of_get_property(node, "compatible", NULL))
>> +                     continue;
>> +
>> +             dev_dbg(&ctrl->dev, "adding child %s\n", node-
>> >full_name);
>> +
>> +             serdev = serdev_device_alloc(ctrl);
>> +             if (!serdev)
>> +                     continue;
>> +
>> +             serdev->dev.of_node = node;
>> +
>> +             err = serdev_device_add(serdev);
>> +             if (err) {
>> +                     dev_err(&serdev->dev,
>> +                             "failure adding device. status %d\n",
>> err);
>> +                     serdev_device_put(serdev);
>> +             }
>>
>
>> +             found = true;
>
> Perhaps
>
> } else if (!found)
>  found = true;
>
> Otherwise if we end up with all devices not being added, called will not
> know about it.

At least for now, we really only support 1 device attached. I'm sure
someone will come up with h/w with more than one device. RS-485 allows
it I think or someone could have muxed access.

I just did "else found = true;" as there's no need to check the condition.

>
>
>> +     }
>> +     if (!found)
>> +             return -ENODEV;
>> +
>> +     return 0;
>> +}
>>
>
>
> +/**
>> + * serdev_controller_remove(): remove an serdev controller
>> + * @ctrl:    controller to remove
>> + *
>> + * Remove a serdev controller.  Caller is responsible for calling
>> + * serdev_controller_put() to discard the allocated controller.
>> + */
>> +void serdev_controller_remove(struct serdev_controller *ctrl)
>> +{
>> +     int dummy;
>> +
>>
>
>> +     if (!ctrl)
>> +             return;
>
> By the way, should we take care or caller? What is the best practice
> here?

If the caller, then every caller has to check. Better to check in one place.

Rob