linux-kernel - Re: [PATCH v2 3/3] edac: Supporting AST2400 and AST2600 edac driver

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: <20201202182349.GJ2951@zn.tnic>
Date:   Wed, 2 Dec 2020 19:23:49 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Andrew Jeffery <andrew@...id.au>
Cc:     Troy Lee <troy_lee@...eedtech.com>, Joel Stanley <joel@....id.au>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Tony Luck <tony.luck@...el.com>,
        Ryan Chen <ryan_chen@...eedtech.com>,
        James Morse <james.morse@....com>,
        "moderated list:ARM/ASPEED MACHINE SUPPORT" 
        <linux-aspeed@...ts.ozlabs.org>,
        open list <linux-kernel@...r.kernel.org>,
        Robert Richter <rrichter@...vell.com>,
        "leetroy@...il.com" <leetroy@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Stefan M Schaeckeler <sschaeck@...co.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        "moderated list:ARM/ASPEED MACHINE SUPPORT" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:EDAC-CORE" <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] edac: Supporting AST2400 and AST2600 edac driver

On Thu, Dec 03, 2020 at 01:32:44AM +1030, Andrew Jeffery wrote:
> On Wed, 2 Dec 2020, at 19:11, Troy Lee wrote:
> > Hi Joel,
> > 
> > Thanks for the suggestion, I'll fix the review and create an new patch 
> > against 
> > latest Linux branch. Those exported function will be referenced in 
> > other driver yet 
> > to be upstream, so should I move those exported functions out of this 
> > patch?
> > 
> 
> Yes, let's leave the exports out of this patch, and add them in when you send 
> the patch that depends on them.

And when you do, almost all new exports are EXPORT_SYMBOL_GPL - not
EXPORT_SYMBOL.

Also, I'd like to see how those exports are going to be used. An EDAC
driver function exported to another driver sounds strange. We have only
one other case like this in the EDAC tree:

drivers/edac/amd64_edac.c:554:EXPORT_SYMBOL_GPL(amd64_get_dram_hole_info);

and even that is not really needed...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette