Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests

2018-10-04 Thread Daniel Vetter
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.

For next time around: Please keep the note here why we need this and what
the impact is. Otherwise it's not immediately clear why we should backport
this patch to all stable kernels.

I'll gather a few acks and then apply.
-Daniel
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes v1->v2:
>  * Reject all pixel format changing request, not just the invalid ones.
> 
>  drivers/gpu/drm/drm_fb_helper.c | 91 
> -
>  1 file changed, 26 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 16ec93b75dbf..48598d7f673f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
> int cmd,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_ioctl);
>  
> +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1,
> +   const struct fb_var_screeninfo *var_2)
> +{
> + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> +var_1->grayscale == var_2->grayscale &&
> +var_1->red.offset == var_2->red.offset &&
> +var_1->red.length == var_2->red.length &&
> +var_1->red.msb_right == var_2->red.msb_right &&
> +var_1->green.offset == var_2->green.offset &&
> +var_1->green.length == var_2->green.length &&
> +var_1->green.msb_right == var_2->green.msb_right &&
> +var_1->blue.offset == var_2->blue.offset &&
> +var_1->blue.length == var_2->blue.length &&
> +var_1->blue.msb_right == var_2->blue.msb_right &&
> +var_1->transp.offset == var_2->transp.offset &&
> +var_1->transp.length == var_2->transp.length &&
> +var_1->transp.msb_right == var_2->transp.msb_right;
> +}
> +
>  /**
>   * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
>   * @var: screeninfo to check
> @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_framebuffer *fb = fb_helper->fb;
> - int depth;
>  
>   if (var->pixclock != 0 || in_dbg_master())
>   return -EINVAL;
> @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>   return -EINVAL;
>   }
>  
> - switch (var->bits_per_pixel) {
> - case 16:
> - depth = (var->green.length == 6) ? 16 : 15;
> - break;
> - case 32:
> - depth = (var->transp.length > 0) ? 32 : 24;
> - break;
> - default:
> - depth = var->bits_per_pixel;
> - break;
> - }
> -
> - switch (depth) {
> - case 8:
> - var->red.offset = 0;
> - var->green.offset = 0;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 15:
> - var->red.offset = 10;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 5;
> - var->blue.length = 5;
> - var->transp.length = 1;
> - var->transp.offset = 15;
> - break;
> - case 16:
> - var->red.offset = 11;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 6;
> - var->blue.length = 5;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 24:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 32:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 8;
> - var->transp.offset = 24;
> - break;
> - default:
> + /*
> +  * drm fbdev emulation doesn't support changing the pixel format at all,
> +  * so reject all pixel format changing requests.
> +  */
> + if (!drm_fb_pixel_format_equal(var, &info->var)) {
> +   

Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests

2018-10-04 Thread Ville Syrjälä
On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> drm fbdev emulation doesn't support changing the pixel format at all,
> so reject all pixel format changing requests.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes v1->v2:
>  * Reject all pixel format changing request, not just the invalid ones.
> 
>  drivers/gpu/drm/drm_fb_helper.c | 91 
> -
>  1 file changed, 26 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 16ec93b75dbf..48598d7f673f 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned 
> int cmd,
>  }
>  EXPORT_SYMBOL(drm_fb_helper_ioctl);
>  
> +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1,
> +   const struct fb_var_screeninfo *var_2)
> +{
> + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> +var_1->grayscale == var_2->grayscale &&
> +var_1->red.offset == var_2->red.offset &&
> +var_1->red.length == var_2->red.length &&
> +var_1->red.msb_right == var_2->red.msb_right &&
> +var_1->green.offset == var_2->green.offset &&
> +var_1->green.length == var_2->green.length &&
> +var_1->green.msb_right == var_2->green.msb_right &&
> +var_1->blue.offset == var_2->blue.offset &&
> +var_1->blue.length == var_2->blue.length &&
> +var_1->blue.msb_right == var_2->blue.msb_right &&
> +var_1->transp.offset == var_2->transp.offset &&
> +var_1->transp.length == var_2->transp.length &&
> +var_1->transp.msb_right == var_2->transp.msb_right;
> +}

Could have shortened a bit with memcmp() but this works too.

Reviewed-by: Ville Syrjälä 

I suppose we really should be doing the same for most of the rest of
var_screeninfo as we don't allow changing the timings/etc. either.

> +
>  /**
>   * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
>   * @var: screeninfo to check
> @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_framebuffer *fb = fb_helper->fb;
> - int depth;
>  
>   if (var->pixclock != 0 || in_dbg_master())
>   return -EINVAL;
> @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>   return -EINVAL;
>   }
>  
> - switch (var->bits_per_pixel) {
> - case 16:
> - depth = (var->green.length == 6) ? 16 : 15;
> - break;
> - case 32:
> - depth = (var->transp.length > 0) ? 32 : 24;
> - break;
> - default:
> - depth = var->bits_per_pixel;
> - break;
> - }
> -
> - switch (depth) {
> - case 8:
> - var->red.offset = 0;
> - var->green.offset = 0;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 15:
> - var->red.offset = 10;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 5;
> - var->blue.length = 5;
> - var->transp.length = 1;
> - var->transp.offset = 15;
> - break;
> - case 16:
> - var->red.offset = 11;
> - var->green.offset = 5;
> - var->blue.offset = 0;
> - var->red.length = 5;
> - var->green.length = 6;
> - var->blue.length = 5;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 24:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 0;
> - var->transp.offset = 0;
> - break;
> - case 32:
> - var->red.offset = 16;
> - var->green.offset = 8;
> - var->blue.offset = 0;
> - var->red.length = 8;
> - var->green.length = 8;
> - var->blue.length = 8;
> - var->transp.length = 8;
> - var->transp.offset = 24;
> - break;
> - default:
> + /*
> +  * drm fbdev emulation doesn't support changing the pixel format at all,
> +  * so reject all pixel format changing requests.
> +  */
> + if (!drm_fb_pixel_format_equal(var, &info->var)) {
> +  

Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests

2018-10-04 Thread Daniel Vetter
On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > drm fbdev emulation doesn't support changing the pixel format at all,
> > so reject all pixel format changing requests.
> > 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Eugeniy Paltsev 
> > ---
> > Changes v1->v2:
> >  * Reject all pixel format changing request, not just the invalid ones.
> > 
> >  drivers/gpu/drm/drm_fb_helper.c | 91 
> > -
> >  1 file changed, 26 insertions(+), 65 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 16ec93b75dbf..48598d7f673f 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, 
> > unsigned int cmd,
> >  }
> >  EXPORT_SYMBOL(drm_fb_helper_ioctl);
> >  
> > +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo 
> > *var_1,
> > + const struct fb_var_screeninfo *var_2)
> > +{
> > +   return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> > +  var_1->grayscale == var_2->grayscale &&
> > +  var_1->red.offset == var_2->red.offset &&
> > +  var_1->red.length == var_2->red.length &&
> > +  var_1->red.msb_right == var_2->red.msb_right &&
> > +  var_1->green.offset == var_2->green.offset &&
> > +  var_1->green.length == var_2->green.length &&
> > +  var_1->green.msb_right == var_2->green.msb_right &&
> > +  var_1->blue.offset == var_2->blue.offset &&
> > +  var_1->blue.length == var_2->blue.length &&
> > +  var_1->blue.msb_right == var_2->blue.msb_right &&
> > +  var_1->transp.offset == var_2->transp.offset &&
> > +  var_1->transp.length == var_2->transp.length &&
> > +  var_1->transp.msb_right == var_2->transp.msb_right;
> > +}
> 
> Could have shortened a bit with memcmp() but this works too.

I'm always vary of memcmp with structs that might have padding and stuff.

> Reviewed-by: Ville Syrjälä 
> 
> I suppose we really should be doing the same for most of the rest of
> var_screeninfo as we don't allow changing the timings/etc. either.

Timing at least doens't have an immediate correctness impact of userspace
rendering the wrong format :-)

Thanks for review&patch, applied to drm-misc-fixes.
-Daniel

> 
> > +
> >  /**
> >   * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> >   * @var: screeninfo to check
> > @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> > *var,
> >  {
> > struct drm_fb_helper *fb_helper = info->par;
> > struct drm_framebuffer *fb = fb_helper->fb;
> > -   int depth;
> >  
> > if (var->pixclock != 0 || in_dbg_master())
> > return -EINVAL;
> > @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct 
> > fb_var_screeninfo *var,
> > return -EINVAL;
> > }
> >  
> > -   switch (var->bits_per_pixel) {
> > -   case 16:
> > -   depth = (var->green.length == 6) ? 16 : 15;
> > -   break;
> > -   case 32:
> > -   depth = (var->transp.length > 0) ? 32 : 24;
> > -   break;
> > -   default:
> > -   depth = var->bits_per_pixel;
> > -   break;
> > -   }
> > -
> > -   switch (depth) {
> > -   case 8:
> > -   var->red.offset = 0;
> > -   var->green.offset = 0;
> > -   var->blue.offset = 0;
> > -   var->red.length = 8;
> > -   var->green.length = 8;
> > -   var->blue.length = 8;
> > -   var->transp.length = 0;
> > -   var->transp.offset = 0;
> > -   break;
> > -   case 15:
> > -   var->red.offset = 10;
> > -   var->green.offset = 5;
> > -   var->blue.offset = 0;
> > -   var->red.length = 5;
> > -   var->green.length = 5;
> > -   var->blue.length = 5;
> > -   var->transp.length = 1;
> > -   var->transp.offset = 15;
> > -   break;
> > -   case 16:
> > -   var->red.offset = 11;
> > -   var->green.offset = 5;
> > -   var->blue.offset = 0;
> > -   var->red.length = 5;
> > -   var->green.length = 6;
> > -   var->blue.length = 5;
> > -   var->transp.length = 0;
> > -   var->transp.offset = 0;
> > -   break;
> > -   case 24:
> > -   var->red.offset = 16;
> > -   var->green.offset = 8;
> > -   var->blue.offset = 0;
> > -   var->red.length = 8;
> > -   var->green.length = 8;
> > -   var->blue.length = 8;
> > -   var->transp.length = 0;
> > -   var->transp.offset = 0;
> > -   break;
> > -   case 32:
> > -   var->red.offset = 16;
> > -   var->green.offset = 8;
> > -   var->blue.offset = 0;
> > -   var->red.length = 8;
> > -   var->

Re: [PATCH v2] drm: fb-helper: Reject all pixel format changing requests

2018-10-04 Thread Ville Syrjälä
On Thu, Oct 04, 2018 at 12:49:38PM +0200, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 01:34:22PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 03, 2018 at 07:45:38PM +0300, Eugeniy Paltsev wrote:
> > > drm fbdev emulation doesn't support changing the pixel format at all,
> > > so reject all pixel format changing requests.
> > > 
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Eugeniy Paltsev 
> > > ---
> > > Changes v1->v2:
> > >  * Reject all pixel format changing request, not just the invalid ones.
> > > 
> > >  drivers/gpu/drm/drm_fb_helper.c | 91 
> > > -
> > >  1 file changed, 26 insertions(+), 65 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c 
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 16ec93b75dbf..48598d7f673f 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -1580,6 +1580,25 @@ int drm_fb_helper_ioctl(struct fb_info *info, 
> > > unsigned int cmd,
> > >  }
> > >  EXPORT_SYMBOL(drm_fb_helper_ioctl);
> > >  
> > > +static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo 
> > > *var_1,
> > > +   const struct fb_var_screeninfo *var_2)
> > > +{
> > > + return var_1->bits_per_pixel == var_2->bits_per_pixel &&
> > > +var_1->grayscale == var_2->grayscale &&
> > > +var_1->red.offset == var_2->red.offset &&
> > > +var_1->red.length == var_2->red.length &&
> > > +var_1->red.msb_right == var_2->red.msb_right &&
> > > +var_1->green.offset == var_2->green.offset &&
> > > +var_1->green.length == var_2->green.length &&
> > > +var_1->green.msb_right == var_2->green.msb_right &&
> > > +var_1->blue.offset == var_2->blue.offset &&
> > > +var_1->blue.length == var_2->blue.length &&
> > > +var_1->blue.msb_right == var_2->blue.msb_right &&
> > > +var_1->transp.offset == var_2->transp.offset &&
> > > +var_1->transp.length == var_2->transp.length &&
> > > +var_1->transp.msb_right == var_2->transp.msb_right;
> > > +}
> > 
> > Could have shortened a bit with memcmp() but this works too.
> 
> I'm always vary of memcmp with structs that might have padding and stuff.

These are uabi so padding would be rather bad.

> 
> > Reviewed-by: Ville Syrjälä 
> > 
> > I suppose we really should be doing the same for most of the rest of
> > var_screeninfo as we don't allow changing the timings/etc. either.
> 
> Timing at least doens't have an immediate correctness impact of userspace
> rendering the wrong format :-)
> 
> Thanks for review&patch, applied to drm-misc-fixes.
> -Daniel
> 
> > 
> > > +
> > >  /**
> > >   * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var
> > >   * @var: screeninfo to check
> > > @@ -1590,7 +1609,6 @@ int drm_fb_helper_check_var(struct 
> > > fb_var_screeninfo *var,
> > >  {
> > >   struct drm_fb_helper *fb_helper = info->par;
> > >   struct drm_framebuffer *fb = fb_helper->fb;
> > > - int depth;
> > >  
> > >   if (var->pixclock != 0 || in_dbg_master())
> > >   return -EINVAL;
> > > @@ -1610,72 +1628,15 @@ int drm_fb_helper_check_var(struct 
> > > fb_var_screeninfo *var,
> > >   return -EINVAL;
> > >   }
> > >  
> > > - switch (var->bits_per_pixel) {
> > > - case 16:
> > > - depth = (var->green.length == 6) ? 16 : 15;
> > > - break;
> > > - case 32:
> > > - depth = (var->transp.length > 0) ? 32 : 24;
> > > - break;
> > > - default:
> > > - depth = var->bits_per_pixel;
> > > - break;
> > > - }
> > > -
> > > - switch (depth) {
> > > - case 8:
> > > - var->red.offset = 0;
> > > - var->green.offset = 0;
> > > - var->blue.offset = 0;
> > > - var->red.length = 8;
> > > - var->green.length = 8;
> > > - var->blue.length = 8;
> > > - var->transp.length = 0;
> > > - var->transp.offset = 0;
> > > - break;
> > > - case 15:
> > > - var->red.offset = 10;
> > > - var->green.offset = 5;
> > > - var->blue.offset = 0;
> > > - var->red.length = 5;
> > > - var->green.length = 5;
> > > - var->blue.length = 5;
> > > - var->transp.length = 1;
> > > - var->transp.offset = 15;
> > > - break;
> > > - case 16:
> > > - var->red.offset = 11;
> > > - var->green.offset = 5;
> > > - var->blue.offset = 0;
> > > - var->red.length = 5;
> > > - var->green.length = 6;
> > > - var->blue.length = 5;
> > > - var->transp.length = 0;
> > > - var->transp.offset = 0;
> > > - break;
> > > - case 24:
> > > - var->red.offset = 16;
> > > - var->green.offset = 8;
> > > - var->blue.offset = 0;
> > > - var->red.length = 8;
> > > - var->green.length = 8;
> > > - var->blue.length = 8;
> > > - var->transp.length = 0;
> > > - var->tran

[PATCH] ARC: IOC: panic if kernel was started with previously enabled IOC

2018-10-04 Thread Eugeniy Paltsev
Disabling and reconfiguring of IOC are quite a tricky actions because
nobody knows what happens if there're IOC-ahndled tarnsactions in flight
when we're disabling IOC.

And the problem is external DMA masters [that were initialized and set
in a bootlaoder that was executed before we got here] might continue
to send data to memory even at this point and we have no way to prevent
that.

That said it's much safer to not enable IOC at all anywhere before Linux
kernel.

As we can build u-boot with IOC support (mostly for debugging purposes)
let's check that kernel was started with disabled IOC regardless of
our plans to use it or not.

Also while I'm at it, replace hardcoded bits in ARC_REG_IO_COH_PARTIAL
and ARC_REG_IO_COH_ENABLE registers by definitions.

Inspired by: https://lkml.org/lkml/2018/1/19/557

Signed-off-by: Eugeniy Paltsev 
---
 arch/arc/include/asm/cache.h |  2 ++
 arch/arc/mm/cache.c  | 25 ++---
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/arch/arc/include/asm/cache.h b/arch/arc/include/asm/cache.h
index ff7d3232764a..f393b663413e 100644
--- a/arch/arc/include/asm/cache.h
+++ b/arch/arc/include/asm/cache.h
@@ -113,7 +113,9 @@ extern unsigned long perip_base, perip_end;
 
 /* IO coherency related Auxiliary registers */
 #define ARC_REG_IO_COH_ENABLE  0x500
+#define ARC_IO_COH_ENABLE_BIT  BIT(0)
 #define ARC_REG_IO_COH_PARTIAL 0x501
+#define ARC_IO_COH_PARTIAL_BIT BIT(0)
 #define ARC_REG_IO_COH_AP0_BASE0x508
 #define ARC_REG_IO_COH_AP0_SIZE0x509
 
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index f2701c13a66b..ee7b63e9c5e3 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -1144,6 +1144,25 @@ noinline void __init arc_ioc_setup(void)
 {
unsigned int ioc_base, mem_sz;
 
+   /*
+* Disabling and reconfiguring of IOC are quite a tricky actions because
+* nobody knows what happens if there're IOC-ahndled tarnsactions in
+* flight when we're disabling IOC.
+*
+* And the problem is external DMA masters [that were initialized and
+* set in a bootlaoder that was executed before we got here] might
+* continue to send data to memory even at this point and we have
+* no way to prevent that.
+*
+* That said it's much safer to not enable IOC at all anywhere before
+* Linux kernel.
+*/
+   if (read_aux_reg(ARC_REG_IO_COH_ENABLE) & ARC_IO_COH_ENABLE_BIT)
+   panic("kernel was started with previously enabled IOC!\n");
+
+   if (!ioc_enable)
+   return;
+
/*
 * As for today we don't support both IOC and ZONE_HIGHMEM enabled
 * simultaneously. This happens because as of today IOC aperture covers
@@ -1187,8 +1206,8 @@ noinline void __init arc_ioc_setup(void)
panic("IOC Aperture start must be aligned to the size of the 
aperture");
 
write_aux_reg(ARC_REG_IO_COH_AP0_BASE, ioc_base >> 12);
-   write_aux_reg(ARC_REG_IO_COH_PARTIAL, 1);
-   write_aux_reg(ARC_REG_IO_COH_ENABLE, 1);
+   write_aux_reg(ARC_REG_IO_COH_PARTIAL, ARC_IO_COH_PARTIAL_BIT);
+   write_aux_reg(ARC_REG_IO_COH_ENABLE, ARC_IO_COH_ENABLE_BIT);
 
/* Re-enable L1 dcache */
__dc_enable();
@@ -1265,7 +1284,7 @@ void __init arc_cache_init_master(void)
if (is_isa_arcv2() && l2_line_sz && !slc_enable)
arc_slc_disable();
 
-   if (is_isa_arcv2() && ioc_enable)
+   if (is_isa_arcv2())
arc_ioc_setup();
 
if (is_isa_arcv2() && l2_line_sz && slc_enable) {
-- 
2.14.4


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc


Re: [PATCH v3] devres: Explicitly align datai[] to 64-bit

2018-10-04 Thread Alexey Brodkin
Hi Peter,

On Mon, 2018-07-09 at 17:53 +0300, Alexey Brodkin wrote:
> Hi Peter,
> 
> On Mon, 2018-07-09 at 16:49 +0200, Peter Zijlstra wrote:
> > On Mon, Jul 09, 2018 at 02:33:26PM +, Alexey Brodkin wrote:
> > > > In fact, since alloc_dr() uses kmalloc() to allocate the entire thing,
> > > > it is impossible to guarantee a larger alignment than kmalloc does.
> > > 
> > > Well but 4-bytes [which is critical for atomic64_t] should be much less
> > > than a sane cache line length so above should work.
> > 
> > AFAICT ARCH_KMALLOC_MINALIGN ends up being 4 on x86_32 (it doesn't
> > define ARCH_DMA_MINALIGN and doesn't seem to otherwise override the
> > thing).
> > 
> > So unconditionally setting the alignment of devres::data to 8 seems
> > broken.
> 
> Well but then what other options do we have to fix a problem with
> misaligned access to atomic64_t in drm_gpu_scheduler?

Ping!

Should I send v4 with ARCH_KMALLOC_MINALIGN used for alignment
if explicitly set __aligned__(8) will break x86_32?

-Alexey
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc