Re: [PATCH] of: spi: Export single device registration method and accessors (v2)

[Grant Likely <grant.likely@xxxxxxxxxxxx>]

On Fri, Nov 21, 2014 at 3:44 PM, Pantelis Antoniou
<panto@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Hi Grant,
>
>> On Nov 21, 2014, at 17:33 , Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
>>
>> On Wed, 29 Oct 2014 12:22:04 +0000
>> , Mark Brown <broonie@xxxxxxxxxx>
>> wrote:
>>> On Wed, Oct 29, 2014 at 01:48:06PM +0200, Pantelis Antoniou wrote:
>>>>> On Oct 29, 2014, at 12:14 , Mark Brown <broonie@xxxxxxxxxx> wrote:
>>>
>>>>> This feels like there is an abstraction problem somewhere, whatever code
>>>>> is supposed to use this is going to need to be taught about each
>>>>> individual bus which is going to be tedious, I would expect that we'd
>>>>> have something like the bus being able to provide a callback which will
>>>>> get invoked whenever a new node appears on the parent node for the bus.
>>>
>>>> Thereâ EURO (tm)s a whole patchset that does exactly this.
>>>> Look at "OF: spi: Add OF notifier handlerâ EURO  and youâ EURO (tm)ll where this is used.
>>>
>>> I deleted that unread I'm afraid; one of the reasons that you should use
>>> subject lines matching the styles for the subsystems is that it's one of
>>> the things people use to filter out things that actually need attention,
>>> if things are busy things that at first glance don't look terribly
>>> relevant (like changes to the OF core in this case) are likely to get
>>> looked at less urgently or just skipped.
>>>
>>> A quick glance suggests that this is adding code inside the SPI core so
>>> it's still not explaining why anything is being exported, can you
>>> clarify please?
>>
>> I have the same question. This doesn't look like it should be exporting
>> symbols.
>>
>> Also, the way the patch is written causes a lot of code changes to get
>> interleaved in the diff. It would be better to split into two patches;
>> one that creates the new of_register_spi_device(), and a separate patch
>> to add the other new functions. It would be certainly easier to review
>> that way.
>>
>
> The diff does make a mess of things; it's not that complex of a patch.
>
> Your wish shall be granted. I'll respin this over the weekend.

I've fixed it in my tree by moving the match functions into the second
patch. The diffs are much easier to read now. I'll post the new
versions to the list shortly, but if you can test that would be
fantastic.

g.

>
>>>
>>>>> SubmittingPatches says.  Please also try to keep your CC list sane,
>>>>> CCing random people just means that you're increasing the volume of mail
>>>>> they have to process.  I'm surprised kernel.org accepts so many CCs.
>>>
>>>>> I have to say I don't recall ever seeing v1...
>>>
>>>> All of them are in the CC list for a reason.
>>>
>>> This is a single, standalone SPI patch - you didn't send it as part of a
>>> series (which is the only reason I read it).
>>
>> Yes, this is part of the OF overlay series. It should have at least been
>> marked as [PATCH 7/8] and that it replaced the previous, buggy, patch 7.
>>
>> g.
>>
>
> Regards
>
> -- Pantelis
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html