linux-kernel - RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error reporting driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4256125352774a7898fe284927b41c2d@DM2PR03MB574.namprd03.prod.outlook.com>
Date:	Tue, 1 Jul 2014 04:16:48 +0000
From:	"Bharat.Bhushan@...escale.com" <Bharat.Bhushan@...escale.com>
To:	Scott Wood <scottwood@...escale.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error
 reporting driver



> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 01, 2014 2:30 AM
> To: Bhushan Bharat-R65777
> Cc: Greg Kroah-Hartman; linuxppc-dev@...ts.ozlabs.org; linux-
> kernel@...r.kernel.org
> Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency Fabric error
> reporting driver
> 
> On Sun, 2014-06-29 at 23:58 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, June 04, 2014 10:38 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: Greg Kroah-Hartman; linuxppc-dev@...ts.ozlabs.org; linux-
> > > kernel@...r.kernel.org
> > > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency
> > > Fabric error reporting driver
> > >
> > > On Wed, 2014-06-04 at 12:04 -0500, Bhushan Bharat-R65777 wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, June 04, 2014 10:12 PM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Greg Kroah-Hartman; linuxppc-dev@...ts.ozlabs.org; linux-
> > > > > kernel@...r.kernel.org
> > > > > Subject: Re: [RESEND PATCH] memory: Freescale CoreNet Coherency
> > > > > Fabric error reporting driver
> > > > >
> > > > > On Wed, 2014-06-04 at 03:17 -0500, Bhushan Bharat-R65777 wrote:
> > > > > > > +static int ccf_remove(struct platform_device *pdev) {
> > > > > > > +	struct ccf_private *ccf = dev_get_drvdata(&pdev->dev);
> > > > > > > +
> > > > > > > +	switch (ccf->info->version) {
> > > > > > > +	case CCF1:
> > > > > > > +		iowrite32be(0, &ccf->err_regs->errdis);
> > > > > > > +		break;
> > > > > > > +
> > > > > > > +	case CCF2:
> > > > > > > +		iowrite32be(0, &ccf->err_regs->errinten);
> > > > > >
> > > > > > Do you think it is same to disable detection bits in
> > > > > > ccf->err_regs-
> > > >errdis?
> > > > >
> > > > > Disabling the interrupt is what we're aiming for here, but ccf1
> > > > > doesn't provide a way to do that separate from disabling detection.
> > > >
> > > > What I wanted to say that do we also need to disable detection
> > > > (set ERRDET_LAE | ERRDET_CV bits in errdis) apart from clearing
> > > > errinten on
> > > > ccf2 ?
> > >
> > > I don't think we "need" to.  You could argue that we should for
> > > consistency, though I think there's value in errors continuing to be
> > > detected even without the driver (e.g. can dump the registers in a
> debugger).
> >
> > Yes this comment was for consistency. Also IIUC, the state which is left when
> the driver is removed is not default reset behavior.
> 
> How many drivers leave the hardware in pristine reset state when exiting?

I do not know :)

>  And
> you could argue that having detection off by default is poor hardware design
> (enabling interrupts is another matter of course).

Ok, then can you please add a comment in _remove() function describing why detection is still enabled.

Thanks
-Bharat

> 
> > If we want errors to be detected then should not we have a sysfs interface?
> 
> That may be useful but it's beyond the scope of what I'm doing with this patch.
> We currently don't log machine checks anywhere but via printk either.
> 
> BTW, I thought I had sent v2 of this, but I don't see it anywhere...
> I'll respin soon.
> 
> -Scott
>