[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <9f4ce33a-38b6-fc51-7632-27196b2947b3@roeck-us.net>
Date: Thu, 1 Oct 2020 08:24:04 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Xu Yilun <yilun.xu@...el.com>
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
Subject: Re: [PATCH v3 0/2] add Intel MAX 10 BMC MFD driver & hwmon sub driver
On 10/1/20 7:08 AM, Xu Yilun wrote:
> 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?
>
Thanks for letting me know. I applied the hwmon driver.
Thanks,
Guenter
> 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