RE: [RFC PATCH v8 04/10] dpll: netlink: Add DPLL framework base functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From: Jiri Pirko <jiri@xxxxxxxxxxx>
>Sent: Wednesday, June 21, 2023 3:08 PM
>
>Wed, Jun 21, 2023 at 01:53:24PM CEST, jiri@xxxxxxxxxxx wrote:
>>Wed, Jun 21, 2023 at 01:18:59PM CEST, poros@xxxxxxxxxx wrote:
>>>Arkadiusz Kubalewski píše v Pá 09. 06. 2023 v 14:18 +0200:
>>>> From: Vadim Fedorenko <vadim.fedorenko@xxxxxxxxx>
>>
>>[...]
>>
>>Could you perhaps cut out the text you don't comment? Saves some time
>>finding your reply.
>>
>>
>>>> +static int
>>>> +dpll_set_from_nlattr(struct dpll_device *dpll, struct genl_info
>>>> *info)
>>>> +{
>>>> +       const struct dpll_device_ops *ops = dpll_device_ops(dpll);
>>>> +       struct nlattr *tb[DPLL_A_MAX + 1];
>>>> +       int ret = 0;
>>>> +
>>>> +       nla_parse(tb, DPLL_A_MAX, genlmsg_data(info->genlhdr),
>>>> +                 genlmsg_len(info->genlhdr), NULL, info->extack);
>>>> +       if (tb[DPLL_A_MODE]) {
>>>Hi,
>>>
>>>Here should be something like:
>>>               if (!ops->mode_set)
>>>                       return -EOPNOTSUPP;
>>
>>Why? All drivers implement that.
>>I believe that it's actullaly better that way. For a called setting up
>>the same mode it is the dpll in, there should be 0 return by the driver.
>>Note that driver holds this value. I'd like to keep this code as it is.
>
>Actually, you are correct Petr, my mistake. Actually, no driver
>implements this. Arkadiusz, could you please remove this op and
>possibly any other unused  op? It will be added when needed.
>
>Thanks!
>

Sorry, didn't have time for such change, added only check as suggested by
Petr.
If you think this is a big issue, we could change it for next version.

Thank you!
Arkadiusz

>
>>
>>[...]




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux