Hot plug support for aspeed-smc driver

Hot plug support for aspeed-smc driver

[Shakeeb B K]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

Hi All,

We have a use case for dynamic enabling/disabling access to spi nor flash
using an external mux.
This is mainly for data flash access over spi controller.

Since we use aspeed-smc driver for both fmc and smc, we cannot make it
loadable as of now.
Is there any way to handle this other than writing a new implementation for
spi controller?

Thanks,
Shakeeb

[-- Attachment #2: Type: text/html, Size: 492 bytes --]

Re: Hot plug support for aspeed-smc driver

[Phil Eichinger]

On 2021-01-15 11:41, Shakeeb B K wrote:
> Hi All,
> 
> We have a use case for dynamic enabling/disabling access to spi nor
> flash using an external mux.
> This is mainly for data flash access over spi controller.
> 
> Since we use aspeed-smc driver for both fmc and smc, we cannot make it
> loadable as of now.
> Is there any way to handle this other than writing a new
> implementation for spi controller?

Hi Shakeeb,

You can use manual driver binding and unbinding to accomplish this (see 
also: https://lwn.net/Articles/143397/).

Example for spi1:
echo 1e630000.spi > /sys/bus/platform/drivers/aspeed-smc/unbind
[change mux]
echo 1e630000.spi > /sys/bus/platform/drivers/aspeed-smc/bind

Cheers
Phil

Re: Hot plug support for aspeed-smc driver

[Konstantin Klubnichkin]

[-- Attachment #1: Type: text/html, Size: 2609 bytes --]

Re: Hot plug support for aspeed-smc driver

[Shakeeb B K]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

Thanks for this patch, this seems workable for us. Will test it out.

Regards,
Shakeeb

On Fri, Jan 15, 2021 at 4:38 PM Konstantin Klubnichkin <
kitsok@yandex-team.ru> wrote:

> Hello!
> Yes.
> I've patched SMC driver to not de-instantiate what it created if faulty
> flash is detected.
> With this patch the driver loads with error and then, when I need to
> access SPI flash, I just de-instantiate/instantiate flash device via sysfs
> like this:
>
> SPI_DEV="1e630000.spi"
> SPI_PATH="/sys/bus/platform/drivers/aspeed-smc"
> echo $SPI_DEV > $SPI_PATH/unbind # Unbind device
> echo $SPI_DEV > $SPI_PATH/bind # Bind device
>
> Here is the patch
>
> ======================================================================================
> diff --git a/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> b/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> index 0805dca..40a9c5c 100644
> --- a/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> +++ b/drivers/mtd/spi-nor/controllers/aspeed-smc.c
> @@ -1321,8 +1321,11 @@ static int aspeed_smc_setup_flash(struct
> aspeed_smc_controller *controller,
> }
>
> if (ret) {
> - of_node_put(child);
> - aspeed_smc_unregister(controller);
> + /* As it's the controller we're flying on, it doesn't make sense to
> unregister in case of errors:
> + If we don't have flash with rootfs - we'll die in kernel panic due to
> missing rootfs.
> + If BMC chip is OK and others are missing - it's fine, we can continue.
> + */
> + return 0;
> }
>
> return ret;
> --
> 2.7.4
>
> ======================================================================================
>
>
>
>
> 15.01.2021, 13:43, "Shakeeb B K" <shakeebbk@gmail.com>:
>
> Hi All,
>
> We have a use case for dynamic enabling/disabling access to spi nor flash
> using an external mux.
> This is mainly for data flash access over spi controller.
>
> Since we use aspeed-smc driver for both fmc and smc, we cannot make it
> loadable as of now.
> Is there any way to handle this other than writing a new implementation
> for spi controller?
>
> Thanks,
> Shakeeb
>
>
>
> --
> Best regards,
> Konstantin Klubnichkin,
> lead firmware engineer,
> server hardware R&D group,
> Yandex Moscow office.
> tel: +7-903-510-33-33
>
>

[-- Attachment #2: Type: text/html, Size: 3206 bytes --]