On Tue, Jul 19, 2016 at 09:08:32AM +0200, Rafał Miłecki wrote:
> We dropped strict MIPS dependency for bcm47xxsflash driver in:
> commit 5651d6aaf489 ("mtd: bcm47xxsflash: use ioremap_cache() instead of
> KSEG0ADDR()") but using ioremap_cache still limits building it to few
> selected architectures only.
>
> A recent commit 57d8f7dd2132 ("bcma: allow enabling serial flash support
> on non-MIPS SoCs") automatically dropped MIPS dependency for
> MTD_BCM47XXSFLASH which broke building e.g. on powerpc and cris.
>
> The bcma change is alright as it doesn't break building bcma code in any
> way. MTD_BCM47XXSFLASH on the other hand should be limited to archs
> which need it and can build it (by providing ioremap_cache).
>
> Fixes: 57d8f7dd2132 ("bcma: allow enabling serial flash support on non-MIPS SoCs")
> Signed-off-by: Rafał Miłecki <zajec5@xxxxxxxxx>
> Cc: Brian Norris <computersforpeace@xxxxxxxxx>
While I might prefer we have a better consistent set of portable I/O
accessors (it's really a mess), it seems quite reasonable to restrict
the damage to ARM and MIPS here if it saves some short-term hassle:
Acked-by: Brian Norris <computersforpeace@xxxxxxxxx>
> ---
> That bcma commit breaking building landed in the wireless-drivers-next.
> Is that possible to get this patch through the same tree?
That's fine with me.
Regards,
Brian
> ---
> drivers/mtd/devices/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
> index f73c416..64a2485 100644
> --- a/drivers/mtd/devices/Kconfig
> +++ b/drivers/mtd/devices/Kconfig
> @@ -114,7 +114,7 @@ config MTD_SST25L
>
> config MTD_BCM47XXSFLASH
> tristate "R/O support for serial flash on BCMA bus"
> - depends on BCMA_SFLASH
> + depends on BCMA_SFLASH && (MIPS || ARM)
> help
> BCMA bus can have various flash memories attached, they are
> registered by bcma as platform devices. This enables driver for
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
