Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <YpCUzStDnSgQLNFN@debian> <CAHk-=wg0uGAX5DYZq+tY2KeUAR8DtR91YE1y9CkPMKkKOyE4jg@mail.gmail.com>
 <CADVatmNGPbSdRNQuwJEWAaPtqb3vBYRjvsuBpoRUnhEHj=X5GQ@mail.gmail.com>
 <CAHk-=wisQd8yiPX=SsK3eFiakKo713hq4SyqPWsJ-oyAmLFefQ@mail.gmail.com>
 <YpIR67FMtTGCwARZ@debian> <CAHk-=wjuyHE=1wLgHncub8FfgeyYqfWYsy4-YrhAvq9991h_Aw@mail.gmail.com>
In-Reply-To: <CAHk-=wjuyHE=1wLgHncub8FfgeyYqfWYsy4-YrhAvq9991h_Aw@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat, 28 May 2022 11:08:48 -0700
Message-ID: <CAHk-=wi_hJV0V=Ecg2dzbe2P_H1XKTu6VP_AtCH6u=tis31ayg@mail.gmail.com>
Subject: Re: mainline build failure due to f1e4c916f97f ("drm/edid: add EDID
 block count and size helpers")
To:     Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Arnd Bergmann <arnd@arndb.de>,
        Viresh Kumar <vireshk@kernel.org>,
        Shiraz Hashim <shiraz.linux.kernel@gmail.com>
Cc:     Jani Nikula <jani.nikula@intel.com>,
        =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>,
        Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
        Maxime Ripard <mripard@kernel.org>,
        Thomas Zimmermann <tzimmermann@suse.de>,
        David Airlie <airlied@linux.ie>,
        Daniel Vetter <daniel@ffwll.ch>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        SoC Team <soc@kernel.org>
Content-Type: multipart/mixed; boundary="0000000000007e28af05e01651d2"
Precedence: bulk

--0000000000007e28af05e01651d2
Content-Type: text/plain; charset="UTF-8"

On Sat, May 28, 2022 at 10:40 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> So digging a bit deeper - since I have am arm compiler after all - I
> note that 'sizeof(detailed_timings)' is 88.

Hmm.

sizeof() both

    detailed_timings[0].data.other_data.data.range.formula.gtf2

and

    detailed_timings[0].data.other_data.data.range.formula.cvt

is 7.

But the *union* of those things is

    detailed_timings[0].data.other_data.data.range.formula

and its size is 8 (despite having an alignment of just 1).

The attached patch would seem to fix it for me.

Not very much tested, and I have no idea what it is that triggers this
only on spear3xx_defconfig.

Some ARM ABI issue that is triggered by some very particular ARM
compiler flag enabled by that config?

Adding some ARM (and SPEAR, and SoC) people in case they have any idea.

This smells like a compiler bug triggered by "there's a 16-bit member
field in that gtf2 structure, and despite it being packed and aligned
to 1, we somehow still align the size to 2".

I dunno. But marking those unions packed too doesn't seem wrong, and
does seem to fix it.

                  Linus

--0000000000007e28af05e01651d2
Content-Type: text/x-patch; charset="US-ASCII"; name="patch.diff"
Content-Disposition: attachment; filename="patch.diff"
Content-Transfer-Encoding: base64
Content-ID: <f_l3q6oh0p0>
X-Attachment-Id: f_l3q6oh0p0

IGluY2x1ZGUvZHJtL2RybV9lZGlkLmggfCA2ICsrKy0tLQogMSBmaWxlIGNoYW5nZWQsIDMgaW5z
ZXJ0aW9ucygrKSwgMyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9pbmNsdWRlL2RybS9kcm1f
ZWRpZC5oIGIvaW5jbHVkZS9kcm0vZHJtX2VkaWQuaAppbmRleCBjMzIwNGE1OGZiMDkuLmIyNzU2
NzUzMzcwYiAxMDA2NDQKLS0tIGEvaW5jbHVkZS9kcm0vZHJtX2VkaWQuaAorKysgYi9pbmNsdWRl
L2RybS9kcm1fZWRpZC5oCkBAIC0xMjEsNyArMTIxLDcgQEAgc3RydWN0IGRldGFpbGVkX2RhdGFf
bW9uaXRvcl9yYW5nZSB7CiAJCQl1OCBzdXBwb3J0ZWRfc2NhbGluZ3M7CiAJCQl1OCBwcmVmZXJy
ZWRfcmVmcmVzaDsKIAkJfSBfX2F0dHJpYnV0ZV9fKChwYWNrZWQpKSBjdnQ7Ci0JfSBmb3JtdWxh
OworCX0gX19hdHRyaWJ1dGVfXygocGFja2VkKSkgZm9ybXVsYTsKIH0gX19hdHRyaWJ1dGVfXygo
cGFja2VkKSk7CiAKIHN0cnVjdCBkZXRhaWxlZF9kYXRhX3dwaW5kZXggewpAQCAtMTU0LDcgKzE1
NCw3IEBAIHN0cnVjdCBkZXRhaWxlZF9ub25fcGl4ZWwgewogCQlzdHJ1Y3QgZGV0YWlsZWRfZGF0
YV93cGluZGV4IGNvbG9yOwogCQlzdHJ1Y3Qgc3RkX3RpbWluZyB0aW1pbmdzWzZdOwogCQlzdHJ1
Y3QgY3Z0X3RpbWluZyBjdnRbNF07Ci0JfSBkYXRhOworCX0gX19hdHRyaWJ1dGVfXygocGFja2Vk
KSkgZGF0YTsKIH0gX19hdHRyaWJ1dGVfXygocGFja2VkKSk7CiAKICNkZWZpbmUgRURJRF9ERVRB
SUxfRVNUX1RJTUlOR1MgMHhmNwpAQCAtMTcyLDcgKzE3Miw3IEBAIHN0cnVjdCBkZXRhaWxlZF90
aW1pbmcgewogCXVuaW9uIHsKIAkJc3RydWN0IGRldGFpbGVkX3BpeGVsX3RpbWluZyBwaXhlbF9k
YXRhOwogCQlzdHJ1Y3QgZGV0YWlsZWRfbm9uX3BpeGVsIG90aGVyX2RhdGE7Ci0JfSBkYXRhOwor
CX0gX19hdHRyaWJ1dGVfXygocGFja2VkKSkgZGF0YTsKIH0gX19hdHRyaWJ1dGVfXygocGFja2Vk
KSk7CiAKICNkZWZpbmUgRFJNX0VESURfSU5QVVRfU0VSUkFUSU9OX1ZTWU5DICgxIDw8IDApCg==
--0000000000007e28af05e01651d2--