Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-22 Thread Jani Nikula 
On Thu, 21 Sep 2017, Michal Wajdeczko  wrote:
> If there is an agreement on merging first patch, can someone give it
> r-b and merge ? Note that this patch is prone to rebase conflicts.

Pushed the first patch, thanks.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-21 Thread Jani Nikula 
On Wed, 20 Sep 2017, Joonas Lahtinen  wrote:
> On Wed, 2017-09-20 at 15:01 +0300, Jani Nikula wrote:
>> On Wed, 20 Sep 2017, Joonas Lahtinen  wrote:
>> > On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote:
>> > > We should discourage developers from modifying modparams.
>> > > Introduce special macro for easier tracking of changes done
>> > > in modparams and enforce its use by defining existing modparams
>> > > members as const. Note that defining whole modparams struct
>> > > as const makes checkpatch unhappy.
>> > > 
>> > > v2: rebased
>> > > 
>> > > Credits-to: Coccinelle
>> > > 
>> > > @@
>> > > identifier n;
>> > > expression e;
>> > > @@
>> > > (
>> > > -i915_modparams.n = e;
>> > > +i915_modparams_set(n, e);
>> > 
>> > Not cool with such a brief name, it really needs to be something more
>> > standing out to make the developer think they've failed design if
>> > they're calling the function.
>> > 
>> > 'i915_modparams_force_write' is my current favourite.
>> > 
>> > And we need huge kerneldoc comment for the function about the concerns
>> > expressed by Jani, me and Ville. There must be no potential readers for
>> > the variables while they're being changed, compiler optimizations need
>> > to be watched for etc.
>> > 
>> > Because really, if we change a module parameter variable while somebody
>> > is for example running a loop based on it, we're in deep problems.
>> > 
>> > Might be worthwhile having a i915_modparams_lock to be taken when
>> > sanitization of options begins, and asserting that lock is held when
>> > _force_write() is being called. rw_semaphore sounds like the right
>> > choice here. Many can read but only one can write.
>> > 
>> > Any opinions on that?
>> 
>> It can't protect against users changing the parameters via sysfs, and I
>> think fixing that at the moment would have an air of overengineering.
>> 
>> I'm thinking review and merge patch 1 to fix the i915 name collision,
>> and forget about the rest for now.
>
> Agreed on merging, disagreeing on forgetting next steps.
>
>> Too much controversy, no real rush or
>> pressure to do anything right now beyond patch 1. Don't just do
>> something, stand there.
>
> The controversy seemed to be around compiler optimizations, and that
> doesn't seem to be a worry. The other thing is how to name the
> function, and that's not too bad discussion. It naturally shouldn't
> block merging the first patch.

It's not just that.

> Reviewing the places where the modparams get written/read may only lead
> to improvements as I see it. Any troublesome variables should get moved
> to device state instead of module state. For example while sanitizing
> enable_ppgtt and other user requested kernel parameters, we should copy
> the state to relevant dynamic structures where it'll have an effect, if
> we actually intend to support changing the parameters on the fly.

Please figure out the alternatives to changing module parameters
first. The hurdles introduced in patch 3 aren't going to stop anyone
from adding new ones. I'm not going to tell anyone to stop doing that
until I have a better idea what to do *instead*.

Overall I'm more concerned about the insane total number of module
parameters that we have. We have them primarily because they are
*convenient*, and they are pretty much the only way to force some
behaviour on module probe. Anything you put in i915 debugfs or sysfs is
going to be much less convenient for debugging.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-21 Thread Michal Wajdeczko 
On Wed, 20 Sep 2017 15:07:50 +0200, Joonas Lahtinen  
 wrote:



On Wed, 2017-09-20 at 15:01 +0300, Jani Nikula wrote:
On Wed, 20 Sep 2017, Joonas Lahtinen   
wrote:

> On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote:
> > We should discourage developers from modifying modparams.
> > Introduce special macro for easier tracking of changes done
> > in modparams and enforce its use by defining existing modparams
> > members as const. Note that defining whole modparams struct
> > as const makes checkpatch unhappy.
> >
> > v2: rebased
> >
> > Credits-to: Coccinelle
> >
> > @@
> > identifier n;
> > expression e;
> > @@
> > (
> > - i915_modparams.n = e;
> > + i915_modparams_set(n, e);
>
> Not cool with such a brief name, it really needs to be something more
> standing out to make the developer think they've failed design if
> they're calling the function.
>
> 'i915_modparams_force_write' is my current favourite.
>
> And we need huge kerneldoc comment for the function about the concerns
> expressed by Jani, me and Ville. There must be no potential readers  
for

> the variables while they're being changed, compiler optimizations need
> to be watched for etc.
>
> Because really, if we change a module parameter variable while  
somebody

> is for example running a loop based on it, we're in deep problems.
>
> Might be worthwhile having a i915_modparams_lock to be taken when
> sanitization of options begins, and asserting that lock is held when
> _force_write() is being called. rw_semaphore sounds like the right
> choice here. Many can read but only one can write.
>
> Any opinions on that?

It can't protect against users changing the parameters via sysfs, and I
think fixing that at the moment would have an air of overengineering.

I'm thinking review and merge patch 1 to fix the i915 name collision,
and forget about the rest for now.


Agreed on merging, disagreeing on forgetting next steps.


Too much controversy, no real rush or
pressure to do anything right now beyond patch 1. Don't just do
something, stand there.


The controversy seemed to be around compiler optimizations, and that
doesn't seem to be a worry. The other thing is how to name the
function, and that's not too bad discussion. It naturally shouldn't
block merging the first patch.


If there is an agreement on merging first patch, can someone give it
r-b and merge ? Note that this patch is prone to rebase conflicts.

Michal



Reviewing the places where the modparams get written/read may only lead
to improvements as I see it. Any troublesome variables should get moved
to device state instead of module state. For example while sanitizing
enable_ppgtt and other user requested kernel parameters, we should copy
the state to relevant dynamic structures where it'll have an effect, if
we actually intend to support changing the parameters on the fly.

Regards, Joonas

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Joonas Lahtinen 
On Wed, 2017-09-20 at 15:01 +0300, Jani Nikula wrote:
> On Wed, 20 Sep 2017, Joonas Lahtinen  wrote:
> > On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote:
> > > We should discourage developers from modifying modparams.
> > > Introduce special macro for easier tracking of changes done
> > > in modparams and enforce its use by defining existing modparams
> > > members as const. Note that defining whole modparams struct
> > > as const makes checkpatch unhappy.
> > > 
> > > v2: rebased
> > > 
> > > Credits-to: Coccinelle
> > > 
> > > @@
> > > identifier n;
> > > expression e;
> > > @@
> > > (
> > > - i915_modparams.n = e;
> > > + i915_modparams_set(n, e);
> > 
> > Not cool with such a brief name, it really needs to be something more
> > standing out to make the developer think they've failed design if
> > they're calling the function.
> > 
> > 'i915_modparams_force_write' is my current favourite.
> > 
> > And we need huge kerneldoc comment for the function about the concerns
> > expressed by Jani, me and Ville. There must be no potential readers for
> > the variables while they're being changed, compiler optimizations need
> > to be watched for etc.
> > 
> > Because really, if we change a module parameter variable while somebody
> > is for example running a loop based on it, we're in deep problems.
> > 
> > Might be worthwhile having a i915_modparams_lock to be taken when
> > sanitization of options begins, and asserting that lock is held when
> > _force_write() is being called. rw_semaphore sounds like the right
> > choice here. Many can read but only one can write.
> > 
> > Any opinions on that?
> 
> It can't protect against users changing the parameters via sysfs, and I
> think fixing that at the moment would have an air of overengineering.
> 
> I'm thinking review and merge patch 1 to fix the i915 name collision,
> and forget about the rest for now.

Agreed on merging, disagreeing on forgetting next steps.

> Too much controversy, no real rush or
> pressure to do anything right now beyond patch 1. Don't just do
> something, stand there.

The controversy seemed to be around compiler optimizations, and that
doesn't seem to be a worry. The other thing is how to name the
function, and that's not too bad discussion. It naturally shouldn't
block merging the first patch.

Reviewing the places where the modparams get written/read may only lead
to improvements as I see it. Any troublesome variables should get moved
to device state instead of module state. For example while sanitizing
enable_ppgtt and other user requested kernel parameters, we should copy
the state to relevant dynamic structures where it'll have an effect, if
we actually intend to support changing the parameters on the fly.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Joonas Lahtinen 
On Wed, 2017-09-20 at 15:06 +0300, Joonas Lahtinen wrote:
> On Wed, 2017-09-20 at 11:34 +0300, Jani Nikula wrote:
> > On Tue, 19 Sep 2017, Michal Wajdeczko  wrote:
> > > We should discourage developers from modifying modparams.
> > > Introduce special macro for easier tracking of changes done
> > > in modparams and enforce its use by defining existing modparams
> > > members as const. Note that defining whole modparams struct
> > > as const makes checkpatch unhappy.
> > 
> > Checkpatch is the least of all reasons to not make the modparams struct
> > const.
> > 
> > We can get away with having some fields (such as device info within
> > dev_priv) const, even if that's dubious.
> > 
> > IIUC modifying const data is undefined behaviour at best, could cause
> > subtle bugs through compiler optimizing reads of the data away because
> > it assumes no modifications, and the data gets placed in rodata at
> > worst.
> > 
> > I kinda like the union trick in this patch, but IMO we need to double
> > check what the standard says about it. Making the fellow developers
> > check the standard is always a bad sign, even if it turns out to be fine
> > after all.
> 
> Here's the snippet to describe the three discussed behaviors. Michal's
> code seems to do the right thing:
> 
> https://gcc.godbolt.org/g/6MCNC3
> 
> We just need to make the write function stand out more and have a
> kerneldoc for it.
> 

Umm, and when I don't typo a missing "&", it's more obvious (now with
--Wall -Wextra -Werror):

https://gcc.godbolt.org/g/HszLnw

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Joonas Lahtinen 
On Wed, 2017-09-20 at 11:34 +0300, Jani Nikula wrote:
> On Tue, 19 Sep 2017, Michal Wajdeczko  wrote:
> > We should discourage developers from modifying modparams.
> > Introduce special macro for easier tracking of changes done
> > in modparams and enforce its use by defining existing modparams
> > members as const. Note that defining whole modparams struct
> > as const makes checkpatch unhappy.
> 
> Checkpatch is the least of all reasons to not make the modparams struct
> const.
> 
> We can get away with having some fields (such as device info within
> dev_priv) const, even if that's dubious.
> 
> IIUC modifying const data is undefined behaviour at best, could cause
> subtle bugs through compiler optimizing reads of the data away because
> it assumes no modifications, and the data gets placed in rodata at
> worst.
> 
> I kinda like the union trick in this patch, but IMO we need to double
> check what the standard says about it. Making the fellow developers
> check the standard is always a bad sign, even if it turns out to be fine
> after all.

Here's the snippet to describe the three discussed behaviors. Michal's
code seems to do the right thing:

https://gcc.godbolt.org/g/6MCNC3

We just need to make the write function stand out more and have a
kerneldoc for it.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Jani Nikula 
On Wed, 20 Sep 2017, Joonas Lahtinen  wrote:
> On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote:
>> We should discourage developers from modifying modparams.
>> Introduce special macro for easier tracking of changes done
>> in modparams and enforce its use by defining existing modparams
>> members as const. Note that defining whole modparams struct
>> as const makes checkpatch unhappy.
>> 
>> v2: rebased
>> 
>> Credits-to: Coccinelle
>> 
>> @@
>> identifier n;
>> expression e;
>> @@
>> (
>> -i915_modparams.n = e;
>> +i915_modparams_set(n, e);
>
> Not cool with such a brief name, it really needs to be something more
> standing out to make the developer think they've failed design if
> they're calling the function.
>
> 'i915_modparams_force_write' is my current favourite.
>
> And we need huge kerneldoc comment for the function about the concerns
> expressed by Jani, me and Ville. There must be no potential readers for
> the variables while they're being changed, compiler optimizations need
> to be watched for etc.
>
> Because really, if we change a module parameter variable while somebody
> is for example running a loop based on it, we're in deep problems.
>
> Might be worthwhile having a i915_modparams_lock to be taken when
> sanitization of options begins, and asserting that lock is held when
> _force_write() is being called. rw_semaphore sounds like the right
> choice here. Many can read but only one can write.
>
> Any opinions on that?

It can't protect against users changing the parameters via sysfs, and I
think fixing that at the moment would have an air of overengineering.

I'm thinking review and merge patch 1 to fix the i915 name collision,
and forget about the rest for now. Too much controversy, no real rush or
pressure to do anything right now beyond patch 1. Don't just do
something, stand there.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Ville Syrjälä 
On Wed, Sep 20, 2017 at 11:54:03AM +0200, Michal Wajdeczko wrote:
> On Wed, 20 Sep 2017 10:34:43 +0200, Jani Nikula   
> wrote:
> 
> > On Tue, 19 Sep 2017, Michal Wajdeczko  wrote:
> >> We should discourage developers from modifying modparams.
> >> Introduce special macro for easier tracking of changes done
> >> in modparams and enforce its use by defining existing modparams
> >> members as const. Note that defining whole modparams struct
> >> as const makes checkpatch unhappy.
> >
> > Checkpatch is the least of all reasons to not make the modparams struct
> > const.
> >
> > We can get away with having some fields (such as device info within
> > dev_priv) const, even if that's dubious.
> >
> > IIUC modifying const data is undefined behaviour at best, could cause
> > subtle bugs through compiler optimizing reads of the data away because
> > it assumes no modifications, and the data gets placed in rodata at
> > worst.
> 
> Note that we're forcing modparams to be stored in dedicated section:
> 
> #define __read_mostly __attribute__((__section__(".data..read_mostly")))
> 
> >
> > I kinda like the union trick in this patch, but IMO we need to double
> > check what the standard says about it. Making the fellow developers
> > check the standard is always a bad sign, even if it turns out to be fine
> > after all.
> 
> ISO/IEC 9899: 6.5.2.3
> 
> If the member used to access the contents of a union object is not the same
> as the member last used to store a value in the object, the appropriate  
> part
> of the object representation of the value is reinterpreted as an object
> representation in the new type as described in 6.2.6 (a process sometimes
> called "type punning").

There's a bunch of text in 6.7.3 which may or may not make that part
irrelevant. Very hard to say since there's no explicit example of
this kind in the spec.

-- 
Ville Syrjälä
Intel OTC
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Joonas Lahtinen 
On Tue, 2017-09-19 at 19:38 +, Michal Wajdeczko wrote:
> We should discourage developers from modifying modparams.
> Introduce special macro for easier tracking of changes done
> in modparams and enforce its use by defining existing modparams
> members as const. Note that defining whole modparams struct
> as const makes checkpatch unhappy.
> 
> v2: rebased
> 
> Credits-to: Coccinelle
> 
> @@
> identifier n;
> expression e;
> @@
> (
> - i915_modparams.n = e;
> + i915_modparams_set(n, e);

Not cool with such a brief name, it really needs to be something more
standing out to make the developer think they've failed design if
they're calling the function.

'i915_modparams_force_write' is my current favourite.

And we need huge kerneldoc comment for the function about the concerns
expressed by Jani, me and Ville. There must be no potential readers for
the variables while they're being changed, compiler optimizations need
to be watched for etc.

Because really, if we change a module parameter variable while somebody
is for example running a loop based on it, we're in deep problems.

Might be worthwhile having a i915_modparams_lock to be taken when
sanitization of options begins, and asserting that lock is held when
_force_write() is being called. rw_semaphore sounds like the right
choice here. Many can read but only one can write.

Any opinions on that?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Michal Wajdeczko 
On Wed, 20 Sep 2017 10:34:43 +0200, Jani Nikula   
wrote:



On Tue, 19 Sep 2017, Michal Wajdeczko  wrote:

We should discourage developers from modifying modparams.
Introduce special macro for easier tracking of changes done
in modparams and enforce its use by defining existing modparams
members as const. Note that defining whole modparams struct
as const makes checkpatch unhappy.


Checkpatch is the least of all reasons to not make the modparams struct
const.

We can get away with having some fields (such as device info within
dev_priv) const, even if that's dubious.

IIUC modifying const data is undefined behaviour at best, could cause
subtle bugs through compiler optimizing reads of the data away because
it assumes no modifications, and the data gets placed in rodata at
worst.


Note that we're forcing modparams to be stored in dedicated section:

#define __read_mostly __attribute__((__section__(".data..read_mostly")))



I kinda like the union trick in this patch, but IMO we need to double
check what the standard says about it. Making the fellow developers
check the standard is always a bad sign, even if it turns out to be fine
after all.


ISO/IEC 9899: 6.5.2.3

If the member used to access the contents of a union object is not the same
as the member last used to store a value in the object, the appropriate  
part

of the object representation of the value is reinterpreted as an object
representation in the new type as described in 6.2.6 (a process sometimes
called "type punning").

Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-20 Thread Jani Nikula 
On Tue, 19 Sep 2017, Michal Wajdeczko  wrote:
> We should discourage developers from modifying modparams.
> Introduce special macro for easier tracking of changes done
> in modparams and enforce its use by defining existing modparams
> members as const. Note that defining whole modparams struct
> as const makes checkpatch unhappy.

Checkpatch is the least of all reasons to not make the modparams struct
const.

We can get away with having some fields (such as device info within
dev_priv) const, even if that's dubious.

IIUC modifying const data is undefined behaviour at best, could cause
subtle bugs through compiler optimizing reads of the data away because
it assumes no modifications, and the data gets placed in rodata at
worst.

I kinda like the union trick in this patch, but IMO we need to double
check what the standard says about it. Making the fellow developers
check the standard is always a bad sign, even if it turns out to be fine
after all.

BR,
Jani.

>
> v2: rebased
>
> Credits-to: Coccinelle
>
> @@
> identifier n;
> expression e;
> @@
> (
> - i915_modparams.n = e;
> + i915_modparams_set(n, e);
> )
>
> Signed-off-by: Michal Wajdeczko 
> Cc: Jani Nikula 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Ville Syrjala 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 ++--
>  drivers/gpu/drm/i915/i915_params.c  |  4 ++--
>  drivers/gpu/drm/i915/i915_params.h  |  7 ++-
>  drivers/gpu/drm/i915/intel_fbc.c|  2 +-
>  drivers/gpu/drm/i915/intel_guc_log.c| 10 +-
>  drivers/gpu/drm/i915/intel_gvt.c|  4 ++--
>  drivers/gpu/drm/i915/intel_psr.c|  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
>  drivers/gpu/drm/i915/intel_runtime_pm.c |  4 ++--
>  drivers/gpu/drm/i915/intel_uc.c | 18 ++
>  drivers/gpu/drm/i915/intel_uncore.c | 14 +++---
>  11 files changed, 43 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 7056bb2..99b47c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1032,9 +1032,9 @@ static void i915_driver_cleanup_mmio(struct 
> drm_i915_private *dev_priv)
>  
>  static void intel_sanitize_options(struct drm_i915_private *dev_priv)
>  {
> - i915_modparams.enable_execlists =
> + i915_modparams_set(enable_execlists,
>   intel_sanitize_enable_execlists(dev_priv,
> - 
> i915_modparams.enable_execlists);
> + 
> i915_modparams.enable_execlists));
>  
>   /*
>* i915.enable_ppgtt is read-only, so do an early pass to validate the
> @@ -1042,13 +1042,13 @@ static void intel_sanitize_options(struct 
> drm_i915_private *dev_priv)
>* do this now so that we can print out any log messages once rather
>* than every time we check intel_enable_ppgtt().
>*/
> - i915_modparams.enable_ppgtt =
> + i915_modparams_set(enable_ppgtt,
>   intel_sanitize_enable_ppgtt(dev_priv,
> - i915_modparams.enable_ppgtt);
> + i915_modparams.enable_ppgtt));
>   DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
>  
> - i915_modparams.semaphores =
> - intel_sanitize_semaphores(dev_priv, i915_modparams.semaphores);
> + i915_modparams_set(semaphores,
> + intel_sanitize_semaphores(dev_priv, i915_modparams.semaphores));
>   DRM_DEBUG_DRIVER("use GPU semaphores? %s\n",
>yesno(i915_modparams.semaphores));
>  
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index ec65341..2a8fa9b 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -26,10 +26,10 @@
>  #include "i915_drv.h"
>  
>  #define i915_param_named(name, T, perm, desc) \
> - module_param_named(name, i915_modparams.name, T, perm); \
> + module_param_named(name, i915_modparams.name##_writable, T, perm); \
>   MODULE_PARM_DESC(name, desc)
>  #define i915_param_named_unsafe(name, T, perm, desc) \
> - module_param_named_unsafe(name, i915_modparams.name, T, perm); \
> + module_param_named_unsafe(name, i915_modparams.name##_writable, T, 
> perm); \
>   MODULE_PARM_DESC(name, desc)
>  
>  struct i915_params i915_modparams __read_mostly = {
> diff --git a/drivers/gpu/drm/i915/i915_params.h 
> b/drivers/gpu/drm/i915/i915_params.h
> index a2cbb47..e7b2845 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -70,7 +70,7 @@
>   func(bool, enable_dpcd_backlight); \
>   func(bool, enable_gvt)
>

[Intel-gfx] [PATCH v6 3/3] drm/i915: Make i915_modparams members const

2017-09-19 Thread Michal Wajdeczko 
We should discourage developers from modifying modparams.
Introduce special macro for easier tracking of changes done
in modparams and enforce its use by defining existing modparams
members as const. Note that defining whole modparams struct
as const makes checkpatch unhappy.

v2: rebased

Credits-to: Coccinelle

@@
identifier n;
expression e;
@@
(
-   i915_modparams.n = e;
+   i915_modparams_set(n, e);
)

Signed-off-by: Michal Wajdeczko 
Cc: Jani Nikula 
Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Ville Syrjala 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 12 ++--
 drivers/gpu/drm/i915/i915_params.c  |  4 ++--
 drivers/gpu/drm/i915/i915_params.h  |  7 ++-
 drivers/gpu/drm/i915/intel_fbc.c|  2 +-
 drivers/gpu/drm/i915/intel_guc_log.c| 10 +-
 drivers/gpu/drm/i915/intel_gvt.c|  4 ++--
 drivers/gpu/drm/i915/intel_psr.c|  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c |  4 ++--
 drivers/gpu/drm/i915/intel_uc.c | 18 ++
 drivers/gpu/drm/i915/intel_uncore.c | 14 +++---
 11 files changed, 43 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7056bb2..99b47c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1032,9 +1032,9 @@ static void i915_driver_cleanup_mmio(struct 
drm_i915_private *dev_priv)
 
 static void intel_sanitize_options(struct drm_i915_private *dev_priv)
 {
-   i915_modparams.enable_execlists =
+   i915_modparams_set(enable_execlists,
intel_sanitize_enable_execlists(dev_priv,
-   
i915_modparams.enable_execlists);
+   
i915_modparams.enable_execlists));
 
/*
 * i915.enable_ppgtt is read-only, so do an early pass to validate the
@@ -1042,13 +1042,13 @@ static void intel_sanitize_options(struct 
drm_i915_private *dev_priv)
 * do this now so that we can print out any log messages once rather
 * than every time we check intel_enable_ppgtt().
 */
-   i915_modparams.enable_ppgtt =
+   i915_modparams_set(enable_ppgtt,
intel_sanitize_enable_ppgtt(dev_priv,
-   i915_modparams.enable_ppgtt);
+   i915_modparams.enable_ppgtt));
DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915_modparams.enable_ppgtt);
 
-   i915_modparams.semaphores =
-   intel_sanitize_semaphores(dev_priv, i915_modparams.semaphores);
+   i915_modparams_set(semaphores,
+   intel_sanitize_semaphores(dev_priv, i915_modparams.semaphores));
DRM_DEBUG_DRIVER("use GPU semaphores? %s\n",
 yesno(i915_modparams.semaphores));
 
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index ec65341..2a8fa9b 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -26,10 +26,10 @@
 #include "i915_drv.h"
 
 #define i915_param_named(name, T, perm, desc) \
-   module_param_named(name, i915_modparams.name, T, perm); \
+   module_param_named(name, i915_modparams.name##_writable, T, perm); \
MODULE_PARM_DESC(name, desc)
 #define i915_param_named_unsafe(name, T, perm, desc) \
-   module_param_named_unsafe(name, i915_modparams.name, T, perm); \
+   module_param_named_unsafe(name, i915_modparams.name##_writable, T, 
perm); \
MODULE_PARM_DESC(name, desc)
 
 struct i915_params i915_modparams __read_mostly = {
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index a2cbb47..e7b2845 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -70,7 +70,7 @@
func(bool, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
-#define MEMBER(T, member) T member
+#define MEMBER(T, member) union { const T member; T member##_writable; }
 struct i915_params {
I915_PARAMS_FOR_EACH(MEMBER);
 };
@@ -78,5 +78,10 @@ struct i915_params {
 
 extern struct i915_params i915_modparams __read_mostly;
 
+#define i915_modparams_set(name, value)\
+({ \
+   i915_modparams.name##_writable = value; \
+})
+
 #endif
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 8e3a055..13fa354 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1355,7 +1355,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
if (need_fbc_vtd_wa(dev_priv))
mkwrite_device_info(dev_priv)->has_fbc = false;
 
-   i915_modparams.enable_fbc