Linux-mtd Archive on lore.kernel.org
 help / color / Atom feed
From: "Álvaro Fernández Rojas" <noltari@gmail.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	vigneshr@ti.com, richard@nod.at, linus.walleij@linaro.org,
	linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org,
	tsbogend@alpha.franken.de, bcm-kernel-feedback-list@broadcom.com,
	Jonas Gorski <jonas.gorski@gmail.com>,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] mtd: parsers: bcm63xx: simplify CFE detection
Date: Fri, 12 Jun 2020 09:30:27 +0200
Message-ID: <CBDB2BF7-07CB-4231-B200-86DE2BFE86A0@gmail.com> (raw)
In-Reply-To: <20200612090252.02581c21@xps13>

Hi Miquèl,

> El 12 jun 2020, a las 9:02, Miquel Raynal <miquel.raynal@bootlin.com> escribió:
> 
> Hi Álvaro,
> 
> Álvaro Fernández Rojas <noltari@gmail.com> wrote on Thu, 11 Jun 2020
> 18:14:20 +0200:
> 
>> Hi Florian,
>> 
>>> El 11 jun 2020, a las 17:42, Florian Fainelli <f.fainelli@gmail.com> escribió:
>>> 
>>> 
>>> 
>>> On 6/11/2020 8:16 AM, Álvaro Fernández Rojas wrote:  
>>>> Hi Miquel,
>>>> 
>>>>> El 11 jun 2020, a las 9:55, Miquel Raynal <miquel.raynal@bootlin.com> escribió:
>>>>> 
>>>>> Hi Álvaro,
>>>>> 
>>>>> Álvaro Fernández Rojas <noltari@gmail.com> wrote on Mon,  8 Jun 2020
>>>>> 18:06:49 +0200:
>>>>> 
>>>>>> Instead of trying to parse CFE version string, which is customized by some
>>>>>> vendors, let's just check that "CFE1" was passed on argument 3.
>>>>>> 
>>>>>> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
>>>>>> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
>>>>>> ---
>>>>>> v2: use CFE_EPTSEAL definition and avoid using an additional funtion.
>>>>>> 
>>>>>> drivers/mtd/parsers/bcm63xxpart.c | 29 ++++-------------------------
>>>>>> 1 file changed, 4 insertions(+), 25 deletions(-)
>>>>>> 
>>>>>> diff --git a/drivers/mtd/parsers/bcm63xxpart.c b/drivers/mtd/parsers/bcm63xxpart.c
>>>>>> index 78f90c6c18fd..493a75b2f266 100644
>>>>>> --- a/drivers/mtd/parsers/bcm63xxpart.c
>>>>>> +++ b/drivers/mtd/parsers/bcm63xxpart.c
>>>>>> @@ -22,6 +22,9 @@
>>>>>> #include <linux/mtd/partitions.h>
>>>>>> #include <linux/of.h>
>>>>>> 
>>>>>> +#include <asm/bootinfo.h>
>>>>>> +#include <asm/fw/cfe/cfe_api.h>  
>>>>> 
>>>>> Are you sure both includes are needed?  
>>>> 
>>>> asm/bootinfo.h is needed for fw_arg3 and asm/fw/cfe/cfe_api.h is needed for CFE_EPTSEAL.
>>>> 
>>>>> 
>>>>> I don't think it is a good habit to include asm/ headers, are you sure
>>>>> there is not another header doing it just fine?  
>>>> 
>>>> Both are needed unless you want to add another definition of CFE_EPTSEAL value.
>>>> There are currently two CFE magic definitions, the one in asm/fw/cfe/cfe_api.h and another one in bcm47xxpart.c:
>>>> https://github.com/torvalds/linux/blob/master/arch/mips/include/asm/fw/cfe/cfe_api.h#L28
>>>> https://github.com/torvalds/linux/blob/master/drivers/mtd/parsers/bcm47xxpart.c#L33  
>>> 
>>> The caveat with that approach is that this reduces the compilation
>>> surface to MIPS and BMIPS_GENERIC and BCM63XX only, which is a bit
>>> small. If we could move the CFE definitions to a shared header, and
>>> consolidate the value used by bcm47xxpart.c as well, that would allow us
>>> to build the bcm63xxpart.c file with COMPILE_TEST on other
>>> architectures. This does not really have functional value, but for
>>> maintainers like Miquel, it allows them to quickly test their entire
>>> drivers/mtd/ directory.  
>> 
>> I don’t think fw_arg3 available on non mips archs, is it?
>> I’m happy to move it to a shared header (which would be a good location for this?), but if I’m right it would still be restricted to MIPS.
> 
> Restricting a definition to MIPS, even if it makes sense for you is
> very limiting for me. I need to be able to build as much drivers as I
> can from my laptop and verify they at least compile correctly. If I need
> a MIPS toolchain, an ARC toolchain, a PowerPC, an ARM, an ARM64 and
> whatever other funky toolchain to do just that in X steps: it's very
> painful. We have been adding COMPILE_TEST dependencies on as much
> drivers as we could and we want to continue moving forward. Using such
> include would need to drop the COMPILE_TEST condition from Kconfig and
> this is not something I am willing to do.

I totally understand and agree with your point, but I still think that there could be a solution which would be valid for both of us.

> 
> Thanks for your understanding :)

The current way of detecting CFE isn’t the proper one.
Thank you for understanding that too.

> Miquèl

Best regards,
Álvaro.



______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply index

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-08  9:40 [PATCH 0/2] " Álvaro Fernández Rojas
2020-06-08  9:40 ` [PATCH 1/2] MIPS: BCM63xx: add helper function to detect CFE Álvaro Fernández Rojas
2020-06-08  9:40 ` [PATCH 2/2] mtd: parsers: bcm63xx: simplify CFE detection Álvaro Fernández Rojas
2020-06-08 16:06 ` [PATCH v2] " Álvaro Fernández Rojas
2020-06-11  7:55   ` Miquel Raynal
2020-06-11 15:16     ` Álvaro Fernández Rojas
2020-06-11 15:42       ` Florian Fainelli
2020-06-11 15:46         ` Miquel Raynal
2020-06-11 16:14         ` Álvaro Fernández Rojas
2020-06-12  7:02           ` Miquel Raynal
2020-06-12  7:30             ` Álvaro Fernández Rojas [this message]
2020-06-12  7:33               ` Miquel Raynal
2020-06-12  7:37                 ` Álvaro Fernández Rojas
2020-06-12  7:35   ` [PATCH v3] " Álvaro Fernández Rojas
2020-06-15  8:54     ` Miquel Raynal
2020-06-15  9:17     ` [PATCH v4] " Álvaro Fernández Rojas
2020-06-15 16:30       ` Florian Fainelli
2020-06-15 17:38       ` Miquel Raynal
2020-08-14  8:56       ` Guenter Roeck
2020-09-22  3:18         ` Naresh Kamboju
2020-09-22  3:26           ` Guenter Roeck
2020-09-28 14:16             ` Miquel Raynal
2020-09-28 19:35               ` Florian Fainelli
2020-09-29 17:27               ` [PATCH] mtd: parsers: bcm63xx: Do not make it modular Florian Fainelli
2020-10-02  7:15                 ` Miquel Raynal
2020-10-11 14:14                 ` Guenter Roeck
2020-10-12  7:04                   ` Miquel Raynal
2020-10-12 13:24                     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CBDB2BF7-07CB-4231-B200-86DE2BFE86A0@gmail.com \
    --to=noltari@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=jonas.gorski@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=tsbogend@alpha.franken.de \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-mtd Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mtd/0 linux-mtd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mtd linux-mtd/ https://lore.kernel.org/linux-mtd \
		linux-mtd@lists.infradead.org
	public-inbox-index linux-mtd

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mtd


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git