ACK/Cmnt: [PATCH 1/4][Unstable][SRU Disco] UBUNTU: [Config] Bump CMA_SIZE_MBYTES to 32 on arm64

Stefan Bader stefan.bader at canonical.com
Fri Jun 28 16:19:19 UTC 2019


On 28.06.19 18:02, dann frazier wrote:
> On Fri, Jun 28, 2019 at 9:38 AM Seth Forshee <seth.forshee at canonical.com> wrote:
>>
>> On Fri, Jun 28, 2019 at 05:20:18PM +0200, Stefan Bader wrote:
>>> On 25.06.19 23:17, dann frazier wrote:
>>>> On Tue, Jun 4, 2019 at 3:00 PM dann frazier <dann.frazier at canonical.com> wrote:
>>>>>
>>>>> BugLink: http://bugs.launchpad.net/bugs/1823753
>>>>>
>>>>> This aligns us with the upstream defconfig which was bumped to 32 for
>>>>> the VC4 SoC in commit 7304a9a99d7b15fd69b3f00f7e16206bba110b35
>>>>> ("arm64: defconfig: Increase CMA size for VC4")
>>>>
>>>> btw, do I need to do anything to be sure the equivalent is applied to
>>>> debian.hwe{-edge}/ in the HWE package?
>>>
>>> Config subdirectory gets copied into hwe, so it should propagate automatically.
>>> I am just a bit confused by Seth's comment in his ACK. Is that something that
>>> should be done for Disco, too?
>>
>> I think so -- it' unlikely the value will get accidetnally changed, but
>> if it does it's only going to get caught if you enforce the value.
>>
>> And really, what's the point of updating the annotations in a stable
>> release if you don't enforce the value? Annotations are only really used
>> for config review and enforcing config values, and we don't do config
>> reviews for stable releases.
> 
> Reasonable - would you like me to submit a v2 for disco w/ that
> enforcement in-place (i.e. cherry-picking what you applied to
> unstable)?
> 
>  -dann
> 
Might be simplest if we pick from unstable

Acked-by: Stefan Bader <stefan.bader at canonical.com>

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


More information about the kernel-team mailing list