ACK/Cmnt: [SRU][H/raspi][PATCH] UBUNTU: [Config] raspi: Set BCM_VCIO=y

[Stefan Bader]

On 11.05.21 09:13, Juerg Haefliger wrote:
> On Tue, 11 May 2021 08:20:24 +0200
> Stefan Bader <stefan.bader at canonical.com> wrote:
> 
>> On 10.05.21 15:22, Juerg Haefliger wrote:
>>> On Mon, 10 May 2021 06:15:56 -0600
>>> Tim Gardner <tim.gardner at canonical.com> wrote:
>>>    
>>>> Acked-by: Tim Gardner <tim.gardner at canonical.com>
>>>>
>>>> Don't you also have to drop vcio from the ABI files lest you get the
>>>> always amusing build failure message "EE: Missing modules (start begging
>>>> for mercy)".
>>>
>>> Yes. But if I include that change in this patch then it is dropped during
>>> cranky open. Which reminds me that I should work on a cranky open fix for
>>> that... And we should fix the ABI check to not complain about 'm' -> 'y'
>>> changes (which is also on my todo list somewhere).
>>
>> Not really needed.
> 
> I beg to disagree.
> 
> 
>> If the changes which drop modules from abi files are there
>> one can just move the open commit before the patch that modifies the abi.
> 
> Which is a rebase and we can't force-push the main kernels, or can we? And
> the cranker needs to realize that the open commit has to be moved...
> 
> 
>> Of
>> course one could put such a logic into open. On the other hand I have the
>> feeling the more we put into tools the less people will double check what they
>> do or even know it. I know that volume more and more requires doing things
>> quickly but making everything handled automatically maybe will make us pay a
>> different price at other stages.
> 
> Disabling a module is a very explicit operation and there shouldn't be any
> manual fixups necessary after (or during) an open commit to please the ABI
> checker, IMO. We do have the modules.ignore concept, so why not simply add a
> modules.ignore file that lists the module that is removed and make it part
> of the remove-module commit? And then make cranky a little smarter to preserve
> modules.ignore across opens. So no need to move the open commit (which I
> personally find very ugly anyways).
> 
> I'm not cranking kernels that often anymore but how often do you guys trip
> over this after closing the release when running test builds? And isn't the
> fixup then to drop the module from the ABI list rather than moving the open
> commit (and redo the whole thing)?

I can only speak for myself but I try to always do a

git log -- debian*/abi

to see whether some non cranking change meddled with abi. No by moving the open 
commit before the applied drop commit, git actually changes the following patch 
to apply to the new files.

-Stefan
> 
> ...Juerg
> 
> 
>> -Stefan
>>
>>>
>>> ...Juerg
>>>
>>>    
>>>> rtg
>>>>
>>>> On 5/10/21 2:06 AM, Juerg Haefliger wrote:
>>>>> BugLink: https://bugs.launchpad.net/bugs/1927505
>>>>>
>>>>> This driver was accidentally turned into a module during a raspberrypi
>>>>> update. Change it back to built-in since the driver isn't loaded
>>>>> automatically.
>>>>>
>>>>> Signed-off-by: Juerg Haefliger <juergh at canonical.com>
>>>>> ---
>>>>>     debian.raspi/config/config.common.ubuntu | 2 +-
>>>>>     1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/debian.raspi/config/config.common.ubuntu b/debian.raspi/config/config.common.ubuntu
>>>>> index 27b26cac1f35..5a771a6dc437 100644
>>>>> --- a/debian.raspi/config/config.common.ubuntu
>>>>> +++ b/debian.raspi/config/config.common.ubuntu
>>>>> @@ -766,7 +766,7 @@ CONFIG_BCMGENET=y
>>>>>     CONFIG_BCM_KONA_USB2_PHY=m
>>>>>     CONFIG_BCM_NET_PHYLIB=y
>>>>>     CONFIG_BCM_SBA_RAID=m
>>>>> -CONFIG_BCM_VCIO=m
>>>>> +CONFIG_BCM_VCIO=y
>>>>>     CONFIG_BCM_VC_SM_CMA=m
>>>>>     CONFIG_BCM_VIDEOCORE=y
>>>>>     CONFIG_BD70528_WATCHDOG=m
>>>>>       
>>>>   
>>>
>>>    
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20210511/56836410/attachment.sig>