Re: [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED driver
From: Jacek Anaszewski
Date: Sat Jun 01 2019 - 09:59:01 EST
Dan,
On 6/1/19 12:41 AM, Dan Murphy wrote:
Jacek
On 5/31/19 4:57 PM, Jacek Anaszewski wrote:
Dan,
On 5/31/19 11:07 PM, Dan Murphy wrote:
Hello
On 5/31/19 2:44 PM, Jacek Anaszewski wrote:
On 5/31/19 8:23 AM, Lee Jones wrote:
On Thu, 30 May 2019, Jacek Anaszewski wrote:
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.
Here are 2 examples where you have changed immutable branches, which
is 100% of the Pull Requests I have received from you. Using that
record as a benchmark, the situation hardly seems unjust.
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.
You have broken the rules every (100% of the) time.
Yes, I admit, I would lose in court.
[0] https://lore.kernel.org/patchwork/patch/1059075/
[1] https://lore.kernel.org/patchwork/patch/1059080/
[2] https://lore.kernel.org/patchwork/patch/1077066/
So we have 2 choices moving forward; you can either provide me with
assurance that you have learned from this experience and will never
change an *immutable* branch again, or I can continue to handle them,
which has been the preference for some years.
If you choose the former and adaptions need to be made in the future,
the correct thing to do is create a *new*, different pull-request
which has its own *new*, different tag, but uses the original tag as a
base.
I choose the former. That being said:
Hereby I solemnly declare never ever change an immutable branch again.
So how do I proceed with the requested change by Mark B on the
LM36274 driver.
Do I add a patch on top?
Or do I submit a patch to the regulator tree once the PR is pulled?
Won't the change be a dependency for [PATCH v4 1/6] ?
Yes thats why I am asking as we would need to change the branch.
I will need to send another pull request anyway - I haven't created
new one after updating the branch so far, so for now we are free
to change it.
--
Best regards,
Jacek Anaszewski