All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: <linux-mtd@lists.infradead.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] mtd: mtk-quadspi: add support for memory-mapped flash reading
Date: Thu, 7 Nov 2019 17:55:40 +0530	[thread overview]
Message-ID: <efd471a6-daad-a191-5528-62313dd4e4a4@ti.com> (raw)
In-Reply-To: <CAJsYDVJgUNxLhcO9iLKwRZHPQ9FT8XuKQq8ru_djD2nryT5o9A@mail.gmail.com>



On 07/11/19 3:01 PM, Chuanhong Guo wrote:
> Hi!
> 
> On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
>>>       mtk_nor_set_read_mode(mtk_nor);
>>>       mtk_nor_set_addr(mtk_nor, addr);
>>>
>>> +     if (mtk_nor->flash_base) {
>>> +             memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
>>> +             return length;
>>> +     }
>>> +
>>
>> Don't you need to check if access is still within valid memory mapped
>> window?
> 
> The mapped area is 256MB and I don't quite believe there will be such
> a big NOR flash.
> I'll add a check here in the next version.
>


There are 256MB (2GiB) NORs out there in market already. So, pretty
soon, 256MB window won't be big enough :)

>>
>>>       for (i = 0; i < length; i++) {
>>>               ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
>>>               if (ret < 0)
>>> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
>>>       if (IS_ERR(mtk_nor->base))
>>>               return PTR_ERR(mtk_nor->base);
>>>
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> +     mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>>
>> There is a single API now: devm_platform_ioremap_resource().
> 
> Cool. I'll change it.
> Should I add another patch to change the same mapping operation right
> above this piece of code?
> 

That would be nice to do too, please send a separate patch.

-- 
Regards
Vignesh

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: mtk-quadspi: add support for memory-mapped flash reading
Date: Thu, 7 Nov 2019 17:55:40 +0530	[thread overview]
Message-ID: <efd471a6-daad-a191-5528-62313dd4e4a4@ti.com> (raw)
In-Reply-To: <CAJsYDVJgUNxLhcO9iLKwRZHPQ9FT8XuKQq8ru_djD2nryT5o9A@mail.gmail.com>



On 07/11/19 3:01 PM, Chuanhong Guo wrote:
> Hi!
> 
> On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
>>>       mtk_nor_set_read_mode(mtk_nor);
>>>       mtk_nor_set_addr(mtk_nor, addr);
>>>
>>> +     if (mtk_nor->flash_base) {
>>> +             memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
>>> +             return length;
>>> +     }
>>> +
>>
>> Don't you need to check if access is still within valid memory mapped
>> window?
> 
> The mapped area is 256MB and I don't quite believe there will be such
> a big NOR flash.
> I'll add a check here in the next version.
>


There are 256MB (2GiB) NORs out there in market already. So, pretty
soon, 256MB window won't be big enough :)

>>
>>>       for (i = 0; i < length; i++) {
>>>               ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
>>>               if (ret < 0)
>>> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
>>>       if (IS_ERR(mtk_nor->base))
>>>               return PTR_ERR(mtk_nor->base);
>>>
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> +     mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>>
>> There is a single API now: devm_platform_ioremap_resource().
> 
> Cool. I'll change it.
> Should I add another patch to change the same mapping operation right
> above this piece of code?
> 

That would be nice to do too, please send a separate patch.

-- 
Regards
Vignesh

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

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: mtk-quadspi: add support for memory-mapped flash reading
Date: Thu, 7 Nov 2019 17:55:40 +0530	[thread overview]
Message-ID: <efd471a6-daad-a191-5528-62313dd4e4a4@ti.com> (raw)
In-Reply-To: <CAJsYDVJgUNxLhcO9iLKwRZHPQ9FT8XuKQq8ru_djD2nryT5o9A@mail.gmail.com>



On 07/11/19 3:01 PM, Chuanhong Guo wrote:
> Hi!
> 
> On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
>>>       mtk_nor_set_read_mode(mtk_nor);
>>>       mtk_nor_set_addr(mtk_nor, addr);
>>>
>>> +     if (mtk_nor->flash_base) {
>>> +             memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
>>> +             return length;
>>> +     }
>>> +
>>
>> Don't you need to check if access is still within valid memory mapped
>> window?
> 
> The mapped area is 256MB and I don't quite believe there will be such
> a big NOR flash.
> I'll add a check here in the next version.
>


There are 256MB (2GiB) NORs out there in market already. So, pretty
soon, 256MB window won't be big enough :)

>>
>>>       for (i = 0; i < length; i++) {
>>>               ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
>>>               if (ret < 0)
>>> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
>>>       if (IS_ERR(mtk_nor->base))
>>>               return PTR_ERR(mtk_nor->base);
>>>
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> +     mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>>
>> There is a single API now: devm_platform_ioremap_resource().
> 
> Cool. I'll change it.
> Should I add another patch to change the same mapping operation right
> above this piece of code?
> 

That would be nice to do too, please send a separate patch.

-- 
Regards
Vignesh

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Vignesh Raghavendra <vigneshr@ti.com>
To: Chuanhong Guo <gch981213@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Tudor Ambarus <tudor.ambarus@microchip.com>,
	Richard Weinberger <richard@nod.at>,
	open list <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-mtd@lists.infradead.org,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org,
	Brian Norris <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] mtd: mtk-quadspi: add support for memory-mapped flash reading
Date: Thu, 7 Nov 2019 17:55:40 +0530	[thread overview]
Message-ID: <efd471a6-daad-a191-5528-62313dd4e4a4@ti.com> (raw)
In-Reply-To: <CAJsYDVJgUNxLhcO9iLKwRZHPQ9FT8XuKQq8ru_djD2nryT5o9A@mail.gmail.com>



On 07/11/19 3:01 PM, Chuanhong Guo wrote:
> Hi!
> 
> On Thu, Nov 7, 2019 at 2:05 PM Vignesh Raghavendra <vigneshr@ti.com> wrote:
>>> @@ -272,6 +273,11 @@ static ssize_t mtk_nor_read(struct spi_nor *nor, loff_t from, size_t length,
>>>       mtk_nor_set_read_mode(mtk_nor);
>>>       mtk_nor_set_addr(mtk_nor, addr);
>>>
>>> +     if (mtk_nor->flash_base) {
>>> +             memcpy_fromio(buffer, mtk_nor->flash_base + from, length);
>>> +             return length;
>>> +     }
>>> +
>>
>> Don't you need to check if access is still within valid memory mapped
>> window?
> 
> The mapped area is 256MB and I don't quite believe there will be such
> a big NOR flash.
> I'll add a check here in the next version.
>


There are 256MB (2GiB) NORs out there in market already. So, pretty
soon, 256MB window won't be big enough :)

>>
>>>       for (i = 0; i < length; i++) {
>>>               ret = mtk_nor_execute_cmd(mtk_nor, MTK_NOR_PIO_READ_CMD);
>>>               if (ret < 0)
>>> @@ -475,6 +481,11 @@ static int mtk_nor_drv_probe(struct platform_device *pdev)
>>>       if (IS_ERR(mtk_nor->base))
>>>               return PTR_ERR(mtk_nor->base);
>>>
>>> +     res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>> +     mtk_nor->flash_base = devm_ioremap_resource(&pdev->dev, res);
>>
>> There is a single API now: devm_platform_ioremap_resource().
> 
> Cool. I'll change it.
> Should I add another patch to change the same mapping operation right
> above this piece of code?
> 

That would be nice to do too, please send a separate patch.

-- 
Regards
Vignesh

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-11-07 12:25 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 14:07 [PATCH 0/2] mtd: mtk-quadspi: add support for memory-mapped flash reading Chuanhong Guo
2019-11-06 14:07 ` Chuanhong Guo
2019-11-06 14:07 ` Chuanhong Guo
2019-11-06 14:07 ` Chuanhong Guo
2019-11-06 14:07 ` [PATCH 1/2] " Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-07  6:06   ` Vignesh Raghavendra
2019-11-07  6:06     ` Vignesh Raghavendra
2019-11-07  6:06     ` Vignesh Raghavendra
2019-11-07  6:06     ` Vignesh Raghavendra
2019-11-07  9:31     ` Chuanhong Guo
2019-11-07  9:31       ` Chuanhong Guo
2019-11-07  9:31       ` Chuanhong Guo
2019-11-07  9:31       ` Chuanhong Guo
2019-11-07 12:25       ` Vignesh Raghavendra [this message]
2019-11-07 12:25         ` Vignesh Raghavendra
2019-11-07 12:25         ` Vignesh Raghavendra
2019-11-07 12:25         ` Vignesh Raghavendra
2019-11-07 13:23   ` Yingjoe Chen
2019-11-07 13:23     ` Yingjoe Chen
2019-11-07 13:23     ` Yingjoe Chen
2019-11-07 13:23     ` Yingjoe Chen
2019-11-07 15:34     ` Chuanhong Guo
2019-11-07 15:34       ` Chuanhong Guo
2019-11-07 15:34       ` Chuanhong Guo
2019-11-07 15:34       ` Chuanhong Guo
2019-11-08  3:52   ` Chuanhong Guo
2019-11-08  3:52     ` Chuanhong Guo
2019-11-08  3:52     ` Chuanhong Guo
2019-11-08  3:52     ` Chuanhong Guo
2019-11-06 14:07 ` [PATCH 2/2] dt-bindings: mtd: mtk-quadspi: update bindings for mmap flash read Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-06 14:07   ` Chuanhong Guo
2019-11-07  1:09   ` Rob Herring
2019-11-07  1:09     ` Rob Herring
2019-11-07  1:09     ` Rob Herring
2019-11-07  1:09     ` Rob Herring
2019-11-07  9:25     ` Chuanhong Guo
2019-11-07  9:25       ` Chuanhong Guo
2019-11-07  9:25       ` Chuanhong Guo
2019-11-07  9:25       ` Chuanhong Guo
2019-11-08  3:51   ` Chuanhong Guo
2019-11-08  3:51     ` Chuanhong Guo
2019-11-08  3:51     ` Chuanhong Guo
2019-11-08  3:51     ` Chuanhong Guo

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=efd471a6-daad-a191-5528-62313dd4e4a4@ti.com \
    --to=vigneshr@ti.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=gch981213@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=tudor.ambarus@microchip.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.