Re: [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED driver

From: Jacek Anaszewski
Date: Thu May 30 2019 - 16:02:05 EST


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@xxxxxx>

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