[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c0b2929e-ca14-3341-6e47-57f6fe49d4e6@redhat.com>
Date: Fri, 16 Feb 2018 12:21:42 +0100
From: Hans de Goede <hdegoede@...hat.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Darren Hart <dvhart@...radead.org>,
Andy Shevchenko <andy@...radead.org>,
MyungJoo Ham <myungjoo.ham@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Mathias Nyman <mathias.nyman@...el.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
USB <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 02/12] usb: typec: Start using ERR_PTR
Hi,
On 16-02-18 12:07, Andy Shevchenko wrote:
> On Fri, Feb 16, 2018 at 12:47 PM, Hans de Goede <hdegoede@...hat.com> wrote:
>> From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
>>
>> In order to allow the USB Type-C Class driver take care of
>> things like muxes and other possible dependencies for the
>> port drivers, returning ERR_PTR instead of NULL from the
>> registration functions in case of failure.
>>
>> The reason for taking over control of the muxes for example
>> is because handling them in the port drivers would be just
>> boilerplate.
>
>> void typec_unregister_altmode(struct typec_altmode *alt)
>> {
>> - if (alt)
>> - device_unregister(&alt->dev);
>> + device_unregister(&alt->dev);
>> }
>
> But it's a pattern to guarantee that unregister type of functions are
> NULL (or ERR_PTR) aware.
Agreed this needs an if (!IS_ERR_OR_NULL()), will fix for v2.
Regards,
Hans
>
>
>> void typec_unregister_partner(struct typec_partner *partner)
>> {
>> - if (partner)
>> - device_unregister(&partner->dev);
>> + device_unregister(&partner->dev);
>> }
>
> Ditto.
>
Powered by blists - more mailing lists