diff mbox series

[v3,2/4] spi: bcm63xx-spi: allow building for BMIPS

Message ID 20200616070223.3401282-3-noltari@gmail.com (mailing list archive)
State New, archived
Headers show
Series spi: bcm63xx: add BMIPS support | expand

Commit Message

Álvaro Fernández Rojas June 16, 2020, 7:02 a.m. UTC
bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
BCM6368 and BCM63268).

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
 v3: no changes
 v2: no changes

 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Mark Brown June 16, 2020, 5:07 p.m. UTC | #1
On Tue, Jun 16, 2020 at 09:02:21AM +0200, Álvaro Fernández Rojas wrote:
> bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
> BCM6368 and BCM63268).

Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code.  Modifying existing
commits creates problems for other users building on top of those
commits so it's best practice to only change pubished git commits if
absolutely essential.
Florian Fainelli June 16, 2020, 5:15 p.m. UTC | #2
On 6/16/2020 10:07 AM, Mark Brown wrote:
> On Tue, Jun 16, 2020 at 09:02:21AM +0200, Álvaro Fernández Rojas wrote:
>> bcm63xx-spi controller is present on several BMIPS SoCs (BCM6358, BCM6362,
>> BCM6368 and BCM63268).
> 
> Please do not submit new versions of already applied patches, please
> submit incremental updates to the existing code.  Modifying existing
> commits creates problems for other users building on top of those
> commits so it's best practice to only change pubished git commits if
> absolutely essential.
> 

In Alvaro's defense, you applied the patches despite me requesting that
specific changes be made (use the optional reset control API variant).

Having a FAQ entry about what your expectations as a subsystem
maintainer are (ala netdev-FAQ.rst) could save you time along the way.
Mark Brown June 16, 2020, 5:25 p.m. UTC | #3
On Tue, Jun 16, 2020 at 10:15:15AM -0700, Florian Fainelli wrote:
> On 6/16/2020 10:07 AM, Mark Brown wrote:

> > Please do not submit new versions of already applied patches, please
> > submit incremental updates to the existing code.  Modifying existing
> > commits creates problems for other users building on top of those
> > commits so it's best practice to only change pubished git commits if
> > absolutely essential.

> In Alvaro's defense, you applied the patches despite me requesting that
> specific changes be made (use the optional reset control API variant).

I applied only the two patches that you'd acked, not the reset patches
which had problems.

> Having a FAQ entry about what your expectations as a subsystem
> maintainer are (ala netdev-FAQ.rst) could save you time along the way.

Incremental updates are the default AFAICT?
Florian Fainelli June 16, 2020, 5:31 p.m. UTC | #4
On 6/16/2020 10:25 AM, Mark Brown wrote:
> On Tue, Jun 16, 2020 at 10:15:15AM -0700, Florian Fainelli wrote:
>> On 6/16/2020 10:07 AM, Mark Brown wrote:
> 
>>> Please do not submit new versions of already applied patches, please
>>> submit incremental updates to the existing code.  Modifying existing
>>> commits creates problems for other users building on top of those
>>> commits so it's best practice to only change pubished git commits if
>>> absolutely essential.
> 
>> In Alvaro's defense, you applied the patches despite me requesting that
>> specific changes be made (use the optional reset control API variant).
> 
> I applied only the two patches that you'd acked, not the reset patches
> which had problems.

Indeed, sorry for not reading your commit message properly, I believe I
request that before, cannot the "applied" response just reply with the
patches *applied* and not *all* part of the series?

> 
>> Having a FAQ entry about what your expectations as a subsystem
>> maintainer are (ala netdev-FAQ.rst) could save you time along the way.
> 
> Incremental updates are the default AFAICT?
> 

It really depends if the maintainer is willing to rewrite his tree
history, some people do, some people do not, especially if nothing has
been submitted to Linus yet.
Mark Brown June 16, 2020, 6:30 p.m. UTC | #5
On Tue, Jun 16, 2020 at 10:31:16AM -0700, Florian Fainelli wrote:
> On 6/16/2020 10:25 AM, Mark Brown wrote:

> >> In Alvaro's defense, you applied the patches despite me requesting that
> >> specific changes be made (use the optional reset control API variant).

> > I applied only the two patches that you'd acked, not the reset patches
> > which had problems.

> Indeed, sorry for not reading your commit message properly, I believe I
> request that before, cannot the "applied" response just reply with the
> patches *applied* and not *all* part of the series?

You might've mentioned it to someone else using b4 but not me - AFAICT
it's not configurable.  I can see arguments either way TBH, but I do
agree that the current output could be confusing and if nothing else the
wording could be better.
diff mbox series

Patch

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 8f1f8fca79e3..a9896e388355 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -149,7 +149,7 @@  config SPI_BCM2835AUX
 
 config SPI_BCM63XX
 	tristate "Broadcom BCM63xx SPI controller"
-	depends on BCM63XX || COMPILE_TEST
+	depends on BCM63XX || BMIPS_GENERIC || COMPILE_TEST
 	help
 	  Enable support for the SPI controller on the Broadcom BCM63xx SoCs.