Use kobj_to_dev() API instead of container_of().
Signed-off-by: zhouchuangao <[email protected]>
---
drivers/nvme/host/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 468d264..bec6965 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3195,7 +3195,7 @@ static struct attribute *nvme_ns_id_attrs[] = {
static umode_t nvme_ns_id_attrs_are_visible(struct kobject *kobj,
struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvme_ns_ids *ids = &dev_to_ns_head(dev)->ids;
if (a == &dev_attr_uuid.attr) {
@@ -3467,7 +3467,7 @@ static struct attribute *nvme_dev_attrs[] = {
static umode_t nvme_dev_attrs_are_visible(struct kobject *kobj,
struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvme_ctrl *ctrl = dev_get_drvdata(dev);
if (a == &dev_attr_delete_controller.attr && !ctrl->ops->delete_ctrl)
--
2.7.4
On Fri, Jun 18, 2021 at 07:10:58AM -0700, zhouchuangao wrote:
> Use kobj_to_dev() API instead of container_of().
Why? That just makes the code harder to read.
>On Fri, Jun 18, 2021 at 07:10:58AM -0700, zhouchuangao wrote:
>> Use kobj_to_dev() API instead of container_of().
>
>Why? That just makes the code harder to read.
In my opinion, the kobj_to_dev() interface is provided by the kernel so that
we can get device based on kobj without having to pass more parameters.
I think it's easier to use.
Thansk,
zhouchaungao
On Sat, Jun 19, 2021 at 01:01:34PM +0800, 周传高 wrote:
> >On Fri, Jun 18, 2021 at 07:10:58AM -0700, zhouchuangao wrote:
> >> Use kobj_to_dev() API instead of container_of().
> >
> >Why? That just makes the code harder to read.
>
> In my opinion, the kobj_to_dev() interface is provided by the kernel so that
> we can get device based on kobj without having to pass more parameters.
> I think it's easier to use.
This same patch has been proposed and rejected numerous times. Do we
need to place a comment in the code to prevent future requests?
http://lists.infradead.org/pipermail/linux-nvme/2021-March/023316.html
http://lists.infradead.org/pipermail/linux-nvme/2021-February/023060.html
http://lists.infradead.org/pipermail/linux-nvme/2020-September/019462.html
Keith,
On 6/20/21 10:34, Keith Busch wrote:
> On Sat, Jun 19, 2021 at 01:01:34PM +0800, ?ܴ??? wrote:
>>> On Fri, Jun 18, 2021 at 07:10:58AM -0700, zhouchuangao wrote:
>>>> Use kobj_to_dev() API instead of container_of().
>>> Why? That just makes the code harder to read.
>> In my opinion, the kobj_to_dev() interface is provided by the kernel so that
>> we can get device based on kobj without having to pass more parameters.
>> I think it's easier to use.
> This same patch has been proposed and rejected numerous times. Do we
> need to place a comment in the code to prevent future requests?
>
> http://lists.infradead.org/pipermail/linux-nvme/2021-March/023316.html
> http://lists.infradead.org/pipermail/linux-nvme/2021-February/023060.html
> http://lists.infradead.org/pipermail/linux-nvme/2020-September/019462.html
>
> _______________________________________________
> Linux-nvme mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
Just sent a patch with your suggested-by see if that is useful.
On 18.06.21 16:18, Christoph Hellwig wrote:
> On Fri, Jun 18, 2021 at 07:10:58AM -0700, zhouchuangao wrote:
>> Use kobj_to_dev() API instead of container_of().
>
> Why? That just makes the code harder to read.
Why so ? Why to we have kobj_to_dev() at all ?
Do you suggest, we shall get rid of it (and all similar ones) ?
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[email protected] -- +49-151-27565287