linux-kernel - Re: [PATCH v3 35/36] net/wan: make FSL_UCC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADRPPNQ4dq1pnvNU71vNEgk1V5ovrT9O2=UMJxG45=ZSRdJ4ig@mail.gmail.com>
Date:   Mon, 4 Nov 2019 14:56:19 -0600
From:   Li Yang <leoyang.li@....com>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Christophe Leroy <christophe.leroy@....fr>,
        Qiang Zhao <qiang.zhao@....com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Scott Wood <oss@...error.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v3 35/36] net/wan: make FSL_UCC_HDLC explicitly depend on PPC32

On Mon, Nov 4, 2019 at 2:39 AM Rasmus Villemoes
<linux@...musvillemoes.dk> wrote:
>
> On 01/11/2019 23.31, Leo Li wrote:
> >
> >
> >> -----Original Message-----
> >> From: Christophe Leroy <christophe.leroy@....fr>
> >> Sent: Friday, November 1, 2019 11:30 AM
> >> To: Rasmus Villemoes <linux@...musvillemoes.dk>; Qiang Zhao
> >> <qiang.zhao@....com>; Leo Li <leoyang.li@....com>
> >> Cc: linuxppc-dev@...ts.ozlabs.org; linux-arm-kernel@...ts.infradead.org;
> >> linux-kernel@...r.kernel.org; Scott Wood <oss@...error.net>;
> >> netdev@...r.kernel.org
> >> Subject: Re: [PATCH v3 35/36] net/wan: make FSL_UCC_HDLC explicitly
> >> depend on PPC32
> >>
> >>
> >>
> >> Le 01/11/2019 à 13:42, Rasmus Villemoes a écrit :
> >>> Currently, FSL_UCC_HDLC depends on QUICC_ENGINE, which in turn
> >> depends
> >>> on PPC32. As preparation for removing the latter and thus allowing the
> >>> core QE code to be built for other architectures, make FSL_UCC_HDLC
> >>> explicitly depend on PPC32.
> >>
> >> Is that really powerpc specific ? Can't the ARM QE perform HDLC on UCC ?
>
> I think the driver would build on ARM. Whether it works I don't know. I
> know it does not build on 64 bit hosts (see kbuild report for v2,23/23).

The problem for arm64 can be easy to fix.  Actually I don't think it
is neccessarily to be compiled on all architectures except powerpc,
arm and arm64.  I am surprised that you made the core QE code compile
for all architecture(although still have some kbuild warnings)

>
> > No.  Actually the HDLC and TDM are the major reason to integrate a QE on the ARM based Layerscape SoCs.
>
> [citation needed].

I got this message from our marketing team.  Also it is reflected on
marketing materials like
https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/layerscape-communication-process/qoriq-layerscape-1043a-and-1023a-multicore-communications-processors:LS1043A

"The QorIQ LS1043A ... integrated QUICC Engine® for legacy glue-less
HDLC, TDM or Profibus support."

>
> > Since Rasmus doesn't have the hardware to test this feature Qiang Zhao probably can help verify the functionality of TDM and we can drop this patch.
>
> No, this patch cannot be dropped. Please see the kbuild complaints for
> v2,23/23 about use of IS_ERR_VALUE on not-sizeof(long) entities. I see
> kbuild has complained about the same thing for v3 since apparently the
> same thing appears in ucc_slow.c. So I'll fix that.

When I made this comment I didn't notice you have removed all the
architectural dependencies for CONFIG_QUICC_ENGINE.  If the
QUICC_ENGINE is only buidable on powerpc, arm and arm64, this change
will not be needed.

BTW, I'm not sure if it is a good idea to make it selectable on these
unrelavent architectures.  Real architectural dependencies and
COMPILE_TEST dependency will be better if we really want to test the
buildability on other platforms.

Regards,
Leo