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  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]
Date:   Wed, 21 Jul 2021 15:10:29 +0200
From:   Mauro Carvalho Chehab <>
To:     Arnd Bergmann <>
Cc:     Bjorn Helgaas <>,
        Linuxarm <>,
        Mauro Carvalho Chehab <>,
        Krzysztof WilczyƄski 
        <>, Alex Dewar <>,
        Henry Styles <>,
        Jaehoon Chung <>,
        Kevin Hilman <>,
        Lorenzo Pieralisi <>,
        Manivannan Sadhasivam <>,
        Paul Walmsley <>,
        Rob Herring <>,
        Wesley Sheng <>,
        Linux Kernel Mailing List <>,
        linux-pci <>
Subject: Re: [PATCH v7 11/10] PCI: kirin: Allow building it as a module

Em Wed, 21 Jul 2021 13:55:07 +0200
Arnd Bergmann <> escreveu:

> On Wed, Jul 21, 2021 at 12:15 PM Mauro Carvalho Chehab
> <> wrote:
> >
> > There's nothing preventing this driver to be loaded as a
> > module. So, change its config from bool to tristate.
> >
> > Signed-off-by: Mauro Carvalho Chehab <>  
> No objections from me, but I wonder if you would also consider making the
> module removable. It's currently marked as 'builtin_platform_driver',
> so you can load but not remove it. Rob has done some bug fixes that make
> it possible to remove similar drivers, so it's probably not much work
> here either.

Yeah, I can probably work on a patch to unbind/remove this driver.

Never actually tried to write a patch removing the PCIe BUS, so no
idea if the refcounts for the in-board Ethernet NIC, M.2 and mini-PCIe
slots will be properly handled. If refcount is handled properly, I
guess a patch like that won't be hard, at least for Kirin 970 PHY.

The Kirin 960 PHY will require a small change at the current version,
as it currently misses the power_off logic.

I also need to double-check if devm resources will be freed at the 
driver removal time, as, with some past tests with media devices,
we had some issues with that.


Powered by blists - more mailing lists