[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201001140834.GA5471@yilunxu-OptiPlex-7050>
Date: Thu, 1 Oct 2020 22:08:34 +0800
From: Xu Yilun <yilun.xu@...el.com>
To: Guenter Roeck <linux@...ck-us.net>
Cc: lee.jones@...aro.org, jdelvare@...e.com,
linux-hwmon@...r.kernel.org, linux-kernel@...r.kernel.org,
trix@...hat.com, matthew.gerlach@...ux.intel.com,
russell.h.weight@...el.com, lgoncalv@...hat.com, hao.wu@...el.com,
mdf@...nel.org, yilun.xu@...el.com
Subject: Re: [PATCH v3 0/2] add Intel MAX 10 BMC MFD driver & hwmon sub driver
Hi Guenter,
On Wed, Sep 30, 2020 at 01:52:49PM -0700, Guenter Roeck wrote:
> On Mon, Sep 21, 2020 at 02:17:49PM +0800, Xu Yilun wrote:
> > I recently realized that maintainers may have trouble to apply patches to
> > their trees if the patches depend on other being-reviewed patches. So I'm
> > trying to wrapper the 2 patches into one patchset and let all the
> > maintainers see the dependencies.
> >
> > But the patch version is then not aligned between the 2 patches. I'm not
> > sure how to handle it. I just picked the smaller number on Subject, but
> > you could still see their own version changes in commit message of each
> > patch. Sorry if it makes confusing.
> >
>
> If you started with separate patches, it would be much better to pick
> the larger number, and add a note into the individual patch(es) stating
> the reason for the gap. Everything else is highly confusing. I would not
> be surprised if no one in the mfd world even looks at the mfd patch
> since it went back from v6 (?) to v3 according to its subject line.
I got it. Thanks for your guide.
Fortunately, the mfd maintainer has replied and applied the mfd patch
(the previous separate one). And I see you added a Reviewed-by for the hwmon
patch, so I assume I don't have to do anything more, is it?
I'll take care of the version number next time.
Thanks,
Yilun
>
> Thanks,
> Guenter
>
> >
> > Patch #1 implements the basic functions of the BMC chip for some Intel
> > FPGA PCIe Acceleration Cards (PAC). The BMC is implemented using the
> > Intel MAX 10 CPLD.
> >
> > This BMC chip is connected to the FPGA by a SPI bus. To provide direct
> > register access from the FPGA, the "SPI slave to Avalon Master Bridge"
> > (spi-avmm) IP is integrated in the chip. It converts encoded streams of
> > bytes from the host to the internal register read/write on the Avalon
> > bus. So This driver uses the regmap-spi-avmm for register accessing.
> >
> > Patch #2 adds support for the hwmon sub device in Intel MAX 10 BMC
> >
> >
> > Xu Yilun (2):
> > mfd: intel-m10-bmc: add Intel MAX 10 BMC chip support for Intel FPGA
> > PAC
> > hwmon: intel-m10-bmc-hwmon: add hwmon support for Intel MAX 10 BMC
> >
> > .../ABI/testing/sysfs-driver-intel-m10-bmc | 15 +
> > Documentation/hwmon/index.rst | 1 +
> > Documentation/hwmon/intel-m10-bmc-hwmon.rst | 78 +++++
> > drivers/hwmon/Kconfig | 11 +
> > drivers/hwmon/Makefile | 1 +
> > drivers/hwmon/intel-m10-bmc-hwmon.c | 334 +++++++++++++++++++++
> > drivers/mfd/Kconfig | 13 +
> > drivers/mfd/Makefile | 2 +
> > drivers/mfd/intel-m10-bmc.c | 164 ++++++++++
> > include/linux/mfd/intel-m10-bmc.h | 65 ++++
> > 10 files changed, 684 insertions(+)
> > create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
> > create mode 100644 Documentation/hwmon/intel-m10-bmc-hwmon.rst
> > create mode 100644 drivers/hwmon/intel-m10-bmc-hwmon.c
> > create mode 100644 drivers/mfd/intel-m10-bmc.c
> > create mode 100644 include/linux/mfd/intel-m10-bmc.h
> >
> > --
> > 2.7.4
> >
Powered by blists - more mailing lists