From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Usyskin, Alexander" <alexander.usyskin@intel.com>
Cc: "Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Poosa, Karthik" <karthik.poosa@intel.com>,
"Abliyev, Reuven" <reuven.abliyev@intel.com>,
"Weil, Oren jer" <oren.jer.weil@intel.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 01/12] mtd: core: always create master device
Date: Wed, 09 Apr 2025 11:59:57 +0200 [thread overview]
Message-ID: <87zfgpejtu.fsf@bootlin.com> (raw)
In-Reply-To: <CY5PR11MB63661044DCB37577A12B5DF9EDAA2@CY5PR11MB6366.namprd11.prod.outlook.com> (Alexander Usyskin's message of "Mon, 7 Apr 2025 12:47:07 +0000")
Hello,
> The mtd_master is completely different class to avoid mtd tree disturbances.
> It is real kernel device object, I'm not sure how we can do 'link to'
> magic here.
Maybe we can add that later if someone needs.
> About MTD_PARTITIONED_MASTER - we can treat it as another partition and
> create master device plus whole device partition as it's child with all other
> partitions as children of master device.
> For unpartitioned device this mean that we create master device and partition
> regardless of MTD_PARTITIONED_MASTER flag.
I am not sure I follow you. I am proposing to create the mtd_master
device in all cases. I believe this is the future-proof approach. Can
you make this change?
Regarding the hierarchy, I indeed agree with what you propose:
mtd_master parent of whole partition device (if any) parent of
partitions.
Thanks,
Miquèl
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: "Usyskin, Alexander" <alexander.usyskin@intel.com>
Cc: "Richard Weinberger" <richard@nod.at>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
"De Marchi, Lucas" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Poosa, Karthik" <karthik.poosa@intel.com>,
"Abliyev, Reuven" <reuven.abliyev@intel.com>,
"Weil, Oren jer" <oren.jer.weil@intel.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v7 01/12] mtd: core: always create master device
Date: Wed, 09 Apr 2025 11:59:57 +0200 [thread overview]
Message-ID: <87zfgpejtu.fsf@bootlin.com> (raw)
In-Reply-To: <CY5PR11MB63661044DCB37577A12B5DF9EDAA2@CY5PR11MB6366.namprd11.prod.outlook.com> (Alexander Usyskin's message of "Mon, 7 Apr 2025 12:47:07 +0000")
Hello,
> The mtd_master is completely different class to avoid mtd tree disturbances.
> It is real kernel device object, I'm not sure how we can do 'link to'
> magic here.
Maybe we can add that later if someone needs.
> About MTD_PARTITIONED_MASTER - we can treat it as another partition and
> create master device plus whole device partition as it's child with all other
> partitions as children of master device.
> For unpartitioned device this mean that we create master device and partition
> regardless of MTD_PARTITIONED_MASTER flag.
I am not sure I follow you. I am proposing to create the mtd_master
device in all cases. I believe this is the future-proof approach. Can
you make this change?
Regarding the hierarchy, I indeed agree with what you propose:
mtd_master parent of whole partition device (if any) parent of
partitions.
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2025-04-09 10:31 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-26 15:26 [PATCH v7 00/12] mtd: add driver for Intel discrete graphics Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 01/12] mtd: core: always create master device Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-04-01 15:00 ` Miquel Raynal
2025-04-01 15:00 ` Miquel Raynal
2025-04-07 12:47 ` Usyskin, Alexander
2025-04-07 12:47 ` Usyskin, Alexander
2025-04-09 9:59 ` Miquel Raynal [this message]
2025-04-09 9:59 ` Miquel Raynal
2025-04-10 9:44 ` Usyskin, Alexander
2025-04-10 9:44 ` Usyskin, Alexander
2025-04-10 14:12 ` Usyskin, Alexander
2025-04-10 14:12 ` Usyskin, Alexander
2025-04-29 9:23 ` Miquel Raynal
2025-04-29 9:23 ` Miquel Raynal
2025-05-06 11:07 ` Usyskin, Alexander
2025-05-06 11:07 ` Usyskin, Alexander
2025-05-12 8:25 ` Miquel Raynal
2025-05-12 8:25 ` Miquel Raynal
2025-03-26 15:26 ` [PATCH v7 02/12] mtd: add driver for intel graphics non-volatile memory device Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 03/12] mtd: intel-dg: implement region enumeration Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 04/12] mtd: intel-dg: implement access functions Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 05/12] mtd: intel-dg: register with mtd Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 06/12] mtd: intel-dg: align 64bit read and write Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 07/12] mtd: intel-dg: wake card on operations Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 08/12] drm/i915/nvm: add nvm device for discrete graphics Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 09/12] drm/i915/nvm: add support for access mode Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 10/12] drm/xe/nvm: add on-die non-volatile memory device Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 11/12] drm/xe/nvm: add support for access mode Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 15:26 ` [PATCH v7 12/12] drm/xe/nvm: add support for non-posted erase Alexander Usyskin
2025-03-26 15:26 ` Alexander Usyskin
2025-03-26 16:09 ` ✗ Fi.CI.CHECKPATCH: warning for mtd: add driver for Intel discrete graphics (rev7) Patchwork
2025-03-26 16:09 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-03-26 16:32 ` ✓ i915.CI.BAT: success " Patchwork
2025-03-26 18:55 ` ✗ i915.CI.Full: failure " Patchwork
2025-03-26 19:22 ` [PATCH v7 00/12] mtd: add driver for Intel discrete graphics Rodrigo Vivi
2025-03-26 19:22 ` Rodrigo Vivi
2025-04-09 9:33 ` Usyskin, Alexander
2025-04-09 9:33 ` Usyskin, Alexander
2025-04-10 14:30 ` ✗ Fi.CI.BUILD: failure for mtd: add driver for Intel discrete graphics (rev8) Patchwork
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=87zfgpejtu.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=airlied@gmail.com \
--cc=alexander.usyskin@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=karthik.poosa@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=oren.jer.weil@intel.com \
--cc=reuven.abliyev@intel.com \
--cc=richard@nod.at \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.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
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.