Set fwnode of disk devices to 'block', 'boot0' and 'boot1' subnodes of
the mmc-card. This is done in preparation for having the eMMC act as
NVMEM provider.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/mmc/core/block.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index f701efb1fa785..fc1a9f31bd253 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -2413,6 +2413,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
int area_type,
unsigned int part_type)
{
+ struct fwnode_handle *fwnode;
+ struct device *ddev;
struct mmc_blk_data *md;
int devidx, ret;
char cap_str[10];
@@ -2509,6 +2511,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
blk_queue_write_cache(md->queue.queue, cache_enabled, fua_enabled);
+ ddev = disk_to_dev(md->disk);
+ fwnode = device_get_named_child_node(subname ? md->parent->parent :
+ md->parent,
+ subname ? subname : "block");
+ ddev->fwnode = fwnode;
+
string_get_size((u64)size, 512, STRING_UNITS_2,
cap_str, sizeof(cap_str));
pr_info("%s: %s %s %s%s\n",
--
2.41.0On Thu, 20 Jul 2023 at 00:02, Daniel Golle <daniel@makrotopia.org> wrote:
>
> Set fwnode of disk devices to 'block', 'boot0' and 'boot1' subnodes of
> the mmc-card. This is done in preparation for having the eMMC act as
> NVMEM provider.
Sorry, but I don't quite understand what you are trying to do here.
Maybe you should re-order the patches in the series so it becomes
clear why this is needed?
Moreover, I don't see any DT docs being updated as a part of the
series, which looks like it is needed too. That would also help to
understand what you are proposing, I think.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> ---
> drivers/mmc/core/block.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index f701efb1fa785..fc1a9f31bd253 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -2413,6 +2413,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
> int area_type,
> unsigned int part_type)
> {
> + struct fwnode_handle *fwnode;
> + struct device *ddev;
> struct mmc_blk_data *md;
> int devidx, ret;
> char cap_str[10];
> @@ -2509,6 +2511,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
>
> blk_queue_write_cache(md->queue.queue, cache_enabled, fua_enabled);
>
> + ddev = disk_to_dev(md->disk);
> + fwnode = device_get_named_child_node(subname ? md->parent->parent :
> + md->parent,
> + subname ? subname : "block");
> + ddev->fwnode = fwnode;
> +
> string_get_size((u64)size, 512, STRING_UNITS_2,
> cap_str, sizeof(cap_str));
> pr_info("%s: %s %s %s%s\n",
Kind regards
Uffe
Hi Ulf,
thank you for reviewing and suggesting ways to improve this series!
On Mon, Aug 07, 2023 at 03:48:31PM +0200, Ulf Hansson wrote:
> On Thu, 20 Jul 2023 at 00:02, Daniel Golle <daniel@makrotopia.org> wrote:
> >
> > Set fwnode of disk devices to 'block', 'boot0' and 'boot1' subnodes of
> > the mmc-card. This is done in preparation for having the eMMC act as
> > NVMEM provider.
>
> Sorry, but I don't quite understand what you are trying to do here.
> Maybe you should re-order the patches in the series so it becomes
> clear why this is needed?
>
> Moreover, I don't see any DT docs being updated as a part of the
> series, which looks like it is needed too. That would also help to
> understand what you are proposing, I think.
I've prepared a tree on Github which now also includes commits adding
dt-bindings for block devices and partitions, so they can be referenced
as nvmem-cells provider.
The dt-schema addition supposedly explaining this specific patch:
https://github.com/dangowrt/linux/commit/b399a758f0e1c444ae9443dc80902a30de54af09
The whole tree:
https://github.com/dangowrt/linux/commits/for-nvmem-next
Most comments have been addressed, however, I still depend on using
either a class_interface *or* adding calls to add/remove the NVMEM
representation of a block device to block/genhd.c as well as
block/partitions/core.c, simply because afaik there isn't any better
way for in-kernel users of block devices to be notified about the
creation or removal of a block device.
Cheers
Daniel
>
> >
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> > drivers/mmc/core/block.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > index f701efb1fa785..fc1a9f31bd253 100644
> > --- a/drivers/mmc/core/block.c
> > +++ b/drivers/mmc/core/block.c
> > @@ -2413,6 +2413,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
> > int area_type,
> > unsigned int part_type)
> > {
> > + struct fwnode_handle *fwnode;
> > + struct device *ddev;
> > struct mmc_blk_data *md;
> > int devidx, ret;
> > char cap_str[10];
> > @@ -2509,6 +2511,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct mmc_card *card,
> >
> > blk_queue_write_cache(md->queue.queue, cache_enabled, fua_enabled);
> >
> > + ddev = disk_to_dev(md->disk);
> > + fwnode = device_get_named_child_node(subname ? md->parent->parent :
> > + md->parent,
> > + subname ? subname : "block");
> > + ddev->fwnode = fwnode;
> > +
> > string_get_size((u64)size, 512, STRING_UNITS_2,
> > cap_str, sizeof(cap_str));
> > pr_info("%s: %s %s %s%s\n",
>
> Kind regards
> Uffe
On Tue, 8 Aug 2023 at 03:02, Daniel Golle <daniel@makrotopia.org> wrote: > > Hi Ulf, > > thank you for reviewing and suggesting ways to improve this series! > > On Mon, Aug 07, 2023 at 03:48:31PM +0200, Ulf Hansson wrote: > > On Thu, 20 Jul 2023 at 00:02, Daniel Golle <daniel@makrotopia.org> wrote: > > > > > > Set fwnode of disk devices to 'block', 'boot0' and 'boot1' subnodes of > > > the mmc-card. This is done in preparation for having the eMMC act as > > > NVMEM provider. > > > > Sorry, but I don't quite understand what you are trying to do here. > > Maybe you should re-order the patches in the series so it becomes > > clear why this is needed? > > > > Moreover, I don't see any DT docs being updated as a part of the > > series, which looks like it is needed too. That would also help to > > understand what you are proposing, I think. > > I've prepared a tree on Github which now also includes commits adding > dt-bindings for block devices and partitions, so they can be referenced > as nvmem-cells provider. > > The dt-schema addition supposedly explaining this specific patch: > > https://github.com/dangowrt/linux/commit/b399a758f0e1c444ae9443dc80902a30de54af09 > > The whole tree: > > https://github.com/dangowrt/linux/commits/for-nvmem-next Thanks for sharing. However, allow people to review, I suggest you post a new version with the updated DT bindings included. The point is, we really need confirmation from the DT maintainers - otherwise this is simply a no go. > > Most comments have been addressed, however, I still depend on using > either a class_interface *or* adding calls to add/remove the NVMEM > representation of a block device to block/genhd.c as well as > block/partitions/core.c, simply because afaik there isn't any better > way for in-kernel users of block devices to be notified about the > creation or removal of a block device. Okay, so that needs further discussions then. I will try to chim in. [...] Kind regards Uffe
© 2016 - 2025 Red Hat, Inc.