[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c75025f5-a984-78fa-2737-d10027e5741c@gmail.com>
Date: Thu, 30 May 2019 21:58:19 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: Dan Murphy <dmurphy@...com>, Pavel Machek <pavel@....cz>,
broonie@...nel.org, lgirdwood@...il.com,
linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED
driver
On 5/30/19 9:38 AM, Lee Jones wrote:
> On Wed, 29 May 2019, Jacek Anaszewski wrote:
>
>> On 5/29/19 3:58 PM, Lee Jones wrote:
>>> On Fri, 24 May 2019, Jacek Anaszewski wrote:
>>>
>>>> Hi,
>>>>
>>>> On 5/23/19 9:09 PM, Dan Murphy wrote:
>>>>> Pavel
>>>>>
>>>>> Thanks for the review
>>>>>
>>>>> On 5/23/19 7:50 AM, Pavel Machek wrote:
>>>>>> Hi!
>>>>>>
>>>>>>> +++ b/drivers/leds/leds-lm36274.c
>>>>>>
>>>>>>> +static int lm36274_parse_dt(struct lm36274 *lm36274_data)
>>>>>>> +{
>>>>>>> + struct fwnode_handle *child = NULL;
>>>>>>> + char label[LED_MAX_NAME_SIZE];
>>>>>>> + struct device *dev = &lm36274_data->pdev->dev;
>>>>>>> + const char *name;
>>>>>>> + int child_cnt;
>>>>>>> + int ret = -EINVAL;
>>>>>>> +
>>>>>>> + /* There should only be 1 node */
>>>>>>> + child_cnt = device_get_child_node_count(dev);
>>>>>>> + if (child_cnt != 1)
>>>>>>> + return ret;
>>>>>>
>>>>>> I'd do explicit "return -EINVAL" here.
>>>>>>
>>>>>
>>>>> ACK
>>>>>
>>>>>>> +static int lm36274_probe(struct platform_device *pdev)
>>>>>>> +{
>>>>>>> + struct ti_lmu *lmu = dev_get_drvdata(pdev->dev.parent);
>>>>>>> + struct lm36274 *lm36274_data;
>>>>>>> + int ret;
>>>>>>> +
>>>>>>> + lm36274_data = devm_kzalloc(&pdev->dev, sizeof(*lm36274_data),
>>>>>>> + GFP_KERNEL);
>>>>>>> + if (!lm36274_data) {
>>>>>>> + ret = -ENOMEM;
>>>>>>> + return ret;
>>>>>>> + }
>>>>>>
>>>>>> And certainly do "return -ENOMEM" explicitly here.
>>>>>>
>>>>>
>>>>> ACK
>>>>>
>>>>>> Acked-by: Pavel Machek <pavel@....cz>
>>>>
>>>> I've done all amendments requested by Pavel and updated branch
>>>> ib-leds-mfd-regulator on linux-leds.git, but in the same time
>>>
>>> What do you mean by updated? You cannot update an 'ib' (immutable
>>> branch). Immutable means that it cannot change, by definition.
>>
>> We have already talked about that. Nobody has pulled so the branch
>> could have been safely updated.
>
> You have no sure way to know that. And since I have no way to know,
> or faith that you won't update it again, pulling it now/at all would
> seem like a foolish thing to do.
Sorry, but you are simply unjust. You're pretending to portray the
situation as if I have been notoriously causing merge conflicts in
linux-next which did not take place.
Just to recap what this discussion is about:
On 7 Apr 2019:
1. I sent pull request [0].
2. 45 minutes later I updated it after discovering one omission [1].
It was rather small chance for it to be pulled as quickly as that.
And even if it happened it wouldn't have been much harmful - we
wouldn't have lost e.g. weeks of testing in linux-next due to that
fact.
On 21 May 2019:
3. I sent another pull request [2] to you and REGULATOR maintainers.
After it turned out that lack of feedback from REGULATOR maintainers
was caused by failing to send them the exact copies of patches to
review, I informed you about possible need for updating the branch.
Afterwards I received a reply from you saying that you hadn't pulled
the branch anyway. At that point I was sure that neither MFD nor
REGULATOR tree contains the patches. And only after that I updated
the branch.
> Until you can provide me with an assurance that you will not keep
> updating/changing the supposedly immutable pull-requests you send out,
> I won't be pulling any more in.
I can just uphold the assurance which is implicitly assumed for anyone
who has never broken acclaimed rules. As justified above.
[0] https://lore.kernel.org/patchwork/patch/1059075/
[1] https://lore.kernel.org/patchwork/patch/1059080/
[2] https://lore.kernel.org/patchwork/patch/1077066/
--
Best regards,
Jacek Anaszewski
Powered by blists - more mailing lists