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>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v1] x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"
Date: Thu, 28 Dec 2017 16:24:32 +0100	[thread overview]
Message-ID: <20171228152431.2zmikdjurx6356ng@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1712281453270.8594@hadrien>


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

> 
> 
> On Thu, 28 Dec 2017, Ingo Molnar wrote:
> 
> >
> > * Julia Lawall <julia.lawall@lip6.fr> wrote:
> >
> > > > > [...] There does seem to be a few cases where the field actually does hold an
> > > > > integer.  I guess this is not a problem?
> > > >
> > > > Could you point to such an example?
> > >
> > > drivers/thermal/intel_soc_dts_thermal.c:#define BYT_SOC_DTS_APIC_IRQ	86
> > >
> > > and then:
> > >
> > > static const struct x86_cpu_id soc_thermal_ids[] = {
> > >         { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_SILVERMONT1, 0,
> > >                 BYT_SOC_DTS_APIC_IRQ},
> > >         {}
> > > };
> > >
> > > and finally:
> > >
> > >  soc_dts_thres_irq = (int)match_cpu->driver_data;
> > >
> > > Also:
> > >
> > > arch/x86/kernel/apic/apic.c
> > >
> > > #define DEADLINE_MODEL_MATCH_REV(model, rev)    \
> > > 	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)rev
> > > }
> > >
> > > DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_BROADWELL_X,      0x0b000020),
> > > DEADLINE_MODEL_MATCH_REV ( INTEL_FAM6_HASWELL_CORE,     0x22),
> > > etc. (all 2-digit numbers in the remaining case).
> >
> > Ok - I think in these cases the resulting long->pointer type conversion is a _lot_
> > less dangerous than the pointer->long conversion which caused the regression.
> >
> > So unless the resulting code is excessively ugly, this feels like the right
> > approach to me.
> 
> The problem is that this case will inevitably have a cast somewhere.

That's OK as long as the cast is dominantly (long)->(pointer), because that 
doesn't really risk losing the underlying type.

It's the (pointer)->(pointer) and (pointer)->(long) conversions that are the most 
dangerous ones.

> [...]  Many of the values put into the driver_data field really are const, so 
> the type has to be const void *.  When the value is extracted from the 
> structure, there will thus need to be a cast on it, and the current cast
> 
> ddata = (struct bt_sfi_data *)id->driver_data;
> 
> works fine, whether the original structure is const or not.

So since this data structure is not size critical, I'd really suggest using two or 
three fields:

	->driver_data.ptr
	->driver_data.const_ptr
	->driver_data.long

that way the fundamental types remains.

> 
> I also got a couple of complaints about non-pointer types:
> 
> arch/x86/kernel/apic/apic.c:621:9: warning: cast from pointer to integer
> of different size [-Wpointer-to-int-cast]
>    rev = (u32)m->driver_data;
> 
> drivers/thermal/intel_soc_dts_thermal.c:68:22: warning: cast from pointer
> to integer of different size [-Wpointer-to-int-cast]
>   soc_dts_thres_irq = (int)match_cpu->driver_data;

These could use driver_data.long or so?

Thanks,

	Ingo

  reply	other threads:[~2017-12-28 15:24 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
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 [this message]
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=20171228152431.2zmikdjurx6356ng@gmail.com \
    --to=mingo@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.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=torvalds@linux-foundation.org \
    --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.