Re: [PATCH 09/13] HID: playstation: add DualSense lightbar support

["Barnabás Pőcze" <pobrn@protonmail.com>]

2020. december 29., kedd 20:54 keltezéssel, Roderick Colenbrander írta:

> On Tue, Dec 29, 2020 at 10:59 AM Barnabás Pőcze <pobrn@protonmail.com> wrote:
> >
> > 2020. december 28., hétfő 22:26 keltezéssel, Roderick Colenbrander írta:
> >
> > > [...]
> > > > > +/* Create a DualSense/DualShock4 RGB lightbar represented by a multicolor LED. */
> > > > > +static struct led_classdev_mc *ps_lightbar_create(struct ps_device *ps_dev,
> > > > > +     int (*brightness_set)(struct led_classdev *, enum led_brightness))
> > > > > +{
> > > > > +     struct hid_device *hdev = ps_dev->hdev;
> > > > > +     struct led_classdev_mc *lightbar_mc_dev;
> > > > > +     struct mc_subled *mc_led_info;
> > > > > +     struct led_classdev *led_cdev;
> > > > > +     int ret;
> > > > > +
> > > > > +     lightbar_mc_dev = devm_kzalloc(&hdev->dev, sizeof(*lightbar_mc_dev), GFP_KERNEL);
> > > > > +     if (!lightbar_mc_dev)
> > > > > +             return ERR_PTR(-ENOMEM);
> > > > > +
> > > > > +     mc_led_info = devm_kzalloc(&hdev->dev, 3*sizeof(*mc_led_info), GFP_KERNEL);
> > > > > +     if (!mc_led_info)
> > > > > +             return ERR_PTR(-ENOMEM);
> > > > > +
> > > >
> > > > Is there any reason why these are dynamically allocated?
> > >
> > > No particular reason. I should probably at least not dynamically
> > > allocate 'mc_dev' and pass it in similar to regular LED registration
> > > (previously I had my regular LEDs dynamically allocated). The
> > > mc_led_info I will probably keep dynamic. It feels a bit nasty to have
> > > the caller be aware of these internal details.
> > > [...]
> >
> > Could you please elaborate what you mean by "It feels a bit nasty to have
> > the caller be aware of these internal details."? I don't think I fully understand
> > what you're referring to.
> >
>
> Maybe I misunderstood your original comment. The question was why both
> 'lightbar_mc_dev' and 'mc_led_info' were dynamically allocated. I
> interpreted it as getting rid of some of the dynamic allocation as
> some wasn't needed, but not sure what you had in mind. The code now
> looks like:
>
> struct dualsense {
> ...
>         /* RGB lightbar */
>         struct led_classdev_mc lightbar; (not a pointer anymore)
> }
>
> static int ps_lightbar_register(struct ps_device *ps_dev, struct
> led_classdev_mc *lightbar_mc_dev,
>               int (*brightness_set)(struct led_classdev *, enum led_brightness))
> {
>           struct hid_device *hdev = ps_dev->hdev;
>           struct mc_subled *mc_led_info;
>           struct led_classdev *led_cdev;
>           int ret;
>
>           mc_led_info = devm_kzalloc(&hdev->dev,
> 3*sizeof(*mc_led_info), GFP_KERNEL);
>           if (!mc_led_info)
>                 return -ENOMEM;
>
>           mc_led_info[0].color_index = LED_COLOR_ID_RED;
> ...
>
> In here I kept 'mc_led_info' as dynamically allocated. I didn't think
> it made sense to have the caller know about it. What was your original
> idea?
> [...]

Thanks, I thought you meant something different, but this clears it up. By the way,
my original idea is really the simplest: have a `struct mc_subled[3]` in the dualsense
struct in addition to the multicolor LED, thus no dynamic allocation (apart from
allocating the dualsense struct) is necessary.