Re: [PATCH 18/18] spi: (RFC, don't apply) report OF style modalias when probing using DT

[Javier Martinez Canillas <javier@xxxxxxxxxxxxxxx>]

On 08/20/2015 11:08 PM, Brian Norris wrote:
> On Thu, Aug 20, 2015 at 11:36:34AM -0700, Mark Brown wrote:
>> On Thu, Aug 20, 2015 at 09:07:31AM +0200, Javier Martinez Canillas wrote:
>>> From: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx>
>>>
>>> An SPI driver that supports both OF and legacy platforms, will have
>>> both an OF and SPI ID table. This means that when built as a module,
>>> the aliases will be filled from both tables, e.g:
>>
>> This is tagged as something that can't be applied but you've not
>> explained why it can't be applied or what comments might be useful :(
>

As Brian pointed out it was in the cover letter so I thought it would
just be duplicated information. But you are right, I should had added
a brief note as well just to make the patch self contained.
 
> I believe that's mostly addressed in the cover letter [1].
> 
>   Patch #18 changes the logic of spi_uevent() to report an OF modalias
>   if the device was registered using OF. But this patch is included in
>   the series only as an RFC for illustration purposes since changing
>   that without first applying all the other patches in this series, will
>   break module autoloading for the drivers of devices registered using
>   OF but that lacks an of_match_table. I'll repost patch #18 once all
>   the patches in this series have landed.
> 
> IOW, it's labeled as such mostly for safety, since it has quite a few
> distributed dependencies.
>

That's correct. If is merged before the other patches, module autoloading
will break for the drivers that are relying on the current behavior.

I just added for illustration purposes to show what was the plan.

> Brian
> 
> [1] https://lkml.org/lkml/2015/8/20/109
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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