lkml.org 
[lkml]   [2019]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED driver
    From
    Date
    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@ucw.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.
    >>>>
    >>>> 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.


    Dan

    > In each case, having all the commits in one set (and branch) should
    > simplify the integration.
    >

    \
     
     \ /
      Last update: 2019-06-01 00:41    [W:4.028 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site