All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, Darren Hart <dvhart@infradead.org>,
	platform-driver-x86@vger.kernel.org,
	Bhumika Goyal <bhumirks@gmail.com>
Subject: Re: [PATCH v1] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"
Date: Thu, 28 Dec 2017 12:12:16 +0100	[thread overview]
Message-ID: <20171228111216.6ebgmcdert4lgkof@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1712281133530.2220@hadrien>


* Julia Lawall <julia.lawall@lip6.fr> wrote:

> 
> 
> On Thu, 28 Dec 2017, Ingo Molnar wrote:
> 
> >
> > * Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > The annoying static analyzer follow up patches make a pain rather then
> > > fixing issues.
> > >
> > > The one done by commit 276c87054751
> > >
> > > ("x86/platform/intel-mid: Make 'bt_sfi_data' const")
> > >
> > > made an obvious regression [BugLink] since the struct bt_sfi_data used
> > > as a temporary container for important data that is used to fill
> > > 'parent' and 'name' fields in struct platform_device_info.
> > >
> > > That's why revert the commit which had been apparently done w/o reading
> > > the code.
> > >
> > > BugLink: https://github.com/andy-shev/linux/issues/20
> > > Cc: Bhumika Goyal <bhumirks@gmail.com>
> > > Cc: julia.lawall@lip6.fr
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > >  arch/x86/platform/intel-mid/device_libs/platform_bt.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/x86/platform/intel-mid/device_libs/platform_bt.c b/arch/x86/platform/intel-mid/device_libs/platform_bt.c
> > > index dc036e511f48..5a0483e7bf66 100644
> > > --- a/arch/x86/platform/intel-mid/device_libs/platform_bt.c
> > > +++ b/arch/x86/platform/intel-mid/device_libs/platform_bt.c
> > > @@ -60,7 +60,7 @@ static int __init tng_bt_sfi_setup(struct bt_sfi_data *ddata)
> > >  	return 0;
> > >  }
> > >
> > > -static const struct bt_sfi_data tng_bt_sfi_data __initdata = {
> > > +static struct bt_sfi_data tng_bt_sfi_data __initdata = {
> > >  	.setup	= tng_bt_sfi_setup,
> > >  };
> >
> > This is nasty, why didn't the compiler warn about this bug?
> >
> > Normally when using a const data structure for a non-const purpose. (Unless
> > there's a type cast which loses the type - one of the many reasons why type casts
> > should be avoided.)
> 
> Indeed, because there is a cast:
> 
> #define ICPU(model, ddata)      \
>         { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (kernel_ulong_t)&ddata }
> 
> static const struct x86_cpu_id bt_sfi_cpu_ids[] = {
> 	ICPU(INTEL_FAM6_ATOM_MERRIFIELD, tng_bt_sfi_data),
>         {}
> };

So the type is the following, in include/linux/mod_devicetable.h:

struct x86_cpu_id {
        __u16 vendor;
        __u16 family;
        __u16 model;
        __u16 feature;  /* bit index */
        kernel_ulong_t driver_data;
};

Is there a syntactic method that would allow the conversion to kernel_ulong_t, but 
would preserve any const-ness?

Barring that, maybe we could convert driver_data to 'void *', fix up all users, 
and not force the type - this would allow the preservation of the const attribute, 
I think.

BTW., a quick grep suggests similar type casting patterns here:

arch/x86/platform/intel-mid/pwr.c:      { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_PENWELL), (kernel_ulong_t)&pnw_info },
arch/x86/platform/intel-mid/pwr.c:      { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_TANGIER), (kernel_ulong_t)&tng_info },

Thanks,

	Ingo

  reply	other threads:[~2017-12-28 11:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 10:08 [PATCH v1] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const" Andy Shevchenko
2017-12-28 10:28 ` Ingo Molnar
2017-12-28 10:34   ` Julia Lawall
2017-12-28 11:12     ` Ingo Molnar [this message]
2017-12-28 11:23       ` Julia Lawall
2017-12-28 11:59         ` Ingo Molnar
2017-12-28 12:12   ` Andy Shevchenko
2017-12-28 12:17     ` Ingo Molnar
2017-12-28 12:25       ` Julia Lawall
2017-12-28 12:29         ` Ingo Molnar
2017-12-28 12:37           ` Julia Lawall
2017-12-28 12:53             ` Ingo Molnar
2017-12-28 14:00               ` Julia Lawall
2017-12-28 15:24                 ` Ingo Molnar
2017-12-28 15:28                   ` Julia Lawall
2017-12-28 21:22                   ` Julia Lawall
2018-01-01 15:15                   ` Julia Lawall

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=20171228111216.6ebgmcdert4lgkof@gmail.com \
    --to=mingo@kernel.org \
    --cc=andi@firstfloor.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhumirks@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=hpa@zytor.com \
    --cc=julia.lawall@lip6.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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.