[v2,0/3] HiSilicon v3xx SFC driver

Message

John Garry Dec. 9, 2019, 2:08 p.m. UTC

This patchset introduces support for the HiSilicon SFC V3XX driver.

Whilst the kernel tree already includes support for a "HiSilicon SFC
driver", that is for different HW. Indeed, as mentioned in patch #1, the
naming for that driver could be better, as it should support more memory
technologies than SPI NOR (as I have been told), and it is actually known
internally as FMC. As such, maybe "hisi-fmc" would have been better, but
we can't change that now.

I used V3XX in this driver name, as that is the unique versioning for
this HW.

As for the driver itself, it is quite simple. Only ACPI firmware is
supported, and we assume m25p80 compatible SPI NOR part will be used.

DMA is not supported, and we just use polling mode for operation
completion notification. The driver uses the SPI MEM OPs.

Changes from v1:
- Add ACPI kconfig dependency
- Fix up header comment style
- Change macros naming style
- Try to enforce aligned accesses in hisi_sfc_v3xx_adjust_op_size()

John Garry (3):
  mtd: spi-nor: hisi-sfc: Try to provide some clarity on which SFC we
    are
  spi: Add HiSilicon v3xx SPI NOR flash controller driver
  MAINTAINERS: Add a maintainer for the HiSilicon v3xx SFC driver

 MAINTAINERS                     |   6 +
 drivers/mtd/spi-nor/Kconfig     |   4 +-
 drivers/mtd/spi-nor/hisi-sfc.c  |   2 +-
 drivers/spi/Kconfig             |   9 +
 drivers/spi/Makefile            |   1 +
 drivers/spi/spi-hisi-sfc-v3xx.c | 284 ++++++++++++++++++++++++++++++++
 6 files changed, 303 insertions(+), 3 deletions(-)
 create mode 100644 drivers/spi/spi-hisi-sfc-v3xx.c

Comments

John Garry Dec. 16, 2019, 2:52 p.m. UTC | #1

On 09/12/2019 14:08, John Garry wrote:
> This patchset introduces support for the HiSilicon SFC V3XX driver.
> 

Hi guys,

Just a friendly reminder on this series.

Thanks,
John

> Whilst the kernel tree already includes support for a "HiSilicon SFC
> driver", that is for different HW. Indeed, as mentioned in patch #1, the
> naming for that driver could be better, as it should support more memory
> technologies than SPI NOR (as I have been told), and it is actually known
> internally as FMC. As such, maybe "hisi-fmc" would have been better, but
> we can't change that now.
> 
> I used V3XX in this driver name, as that is the unique versioning for
> this HW.
> 
> As for the driver itself, it is quite simple. Only ACPI firmware is
> supported, and we assume m25p80 compatible SPI NOR part will be used.
> 
> DMA is not supported, and we just use polling mode for operation
> completion notification. The driver uses the SPI MEM OPs.
> 
> Changes from v1:
> - Add ACPI kconfig dependency
> - Fix up header comment style
> - Change macros naming style
> - Try to enforce aligned accesses in hisi_sfc_v3xx_adjust_op_size()
> 
> John Garry (3):
>    mtd: spi-nor: hisi-sfc: Try to provide some clarity on which SFC we
>      are
>    spi: Add HiSilicon v3xx SPI NOR flash controller driver
>    MAINTAINERS: Add a maintainer for the HiSilicon v3xx SFC driver
> 
>   MAINTAINERS                     |   6 +
>   drivers/mtd/spi-nor/Kconfig     |   4 +-
>   drivers/mtd/spi-nor/hisi-sfc.c  |   2 +-
>   drivers/spi/Kconfig             |   9 +
>   drivers/spi/Makefile            |   1 +
>   drivers/spi/spi-hisi-sfc-v3xx.c | 284 ++++++++++++++++++++++++++++++++
>   6 files changed, 303 insertions(+), 3 deletions(-)
>   create mode 100644 drivers/spi/spi-hisi-sfc-v3xx.c
>

Mark Brown Dec. 16, 2019, 2:56 p.m. UTC | #2

On Mon, Dec 16, 2019 at 02:52:23PM +0000, John Garry wrote:
> On 09/12/2019 14:08, John Garry wrote:
> > This patchset introduces support for the HiSilicon SFC V3XX driver.
> > 
> 
> Hi guys,
> 
> Just a friendly reminder on this series.

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.