On Wed 12 Feb 2025 at 08:38, Doug Anderson <dianders@xxxxxxxxxxxx> wrote:
> Hi,
>
> On Tue, Feb 11, 2025 at 9:28 AM Jerome Brunet <jbrunet@xxxxxxxxxxxx> wrote:
>>
>> The auxiliary device creation of this driver is simple enough to
>> use the available auxiliary device creation helper.
>>
>> Use it and remove some boilerplate code.
>>
>> Signed-off-by: Jerome Brunet <jbrunet@xxxxxxxxxxxx>
>> ---
>> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 84 +++++++++--------------------------
>> 1 file changed, 20 insertions(+), 64 deletions(-)
>
> Thanks for creating the helpers and getting rid of some boilerplate!
> This conflicts with commit 574f5ee2c85a ("drm/bridge: ti-sn65dsi86:
> Fix multiple instances") which is in drm-next, though. Please resolve.
Noted. this is based on v6.14-rc1 ATM
>
> Since nothing here is urgent, I would assume patch #1 would land and
> then we'd just wait until it made it to mainline before landing the
> other patches in their respective trees?
That would simplest way to handle it I think. No rush.
I'll rebase when the time comes.
>
>
>> -static int ti_sn65dsi86_add_aux_device(struct ti_sn65dsi86 *pdata,
>> - struct auxiliary_device **aux_out,
>> - const char *name)
>> -{
>> - struct device *dev = pdata->dev;
>> - struct auxiliary_device *aux;
>> - int ret;
>> -
>> - aux = kzalloc(sizeof(*aux), GFP_KERNEL);
>> - if (!aux)
>> - return -ENOMEM;
>> -
>> - aux->name = name;
>> - aux->dev.parent = dev;
>> - aux->dev.release = ti_sn65dsi86_aux_device_release;
>> - device_set_of_node_from_dev(&aux->dev, dev);
>> - ret = auxiliary_device_init(aux);
>> - if (ret) {
>> - kfree(aux);
>> - return ret;
>> - }
>> - ret = devm_add_action_or_reset(dev, ti_sn65dsi86_uninit_aux, aux);
>> - if (ret)
>> - return ret;
>> -
>> - ret = auxiliary_device_add(aux);
>> - if (ret)
>> - return ret;
>> - ret = devm_add_action_or_reset(dev, ti_sn65dsi86_delete_aux, aux);
>> - if (!ret)
>> - *aux_out = aux;
>
> I notice that your new code has one fewer devm_add_action_or_reset()
> than the code here which you're replacing. That means it needs to call
> "uninit" explicitly in one extra place.
... but it needs one memory allocation less ;)
> It still seems clean enough,
> though, so I don't have any real objections to the way you're doing it
> there. ;-)
Both ways are valid indeed. Just a matter of personal taste I guess.
>
> -Doug
--
Jerome
