linux-kernel - Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory Processor

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Aug 2017 22:38:17 +0200
From:   Pavel Machek <pavel@....cz>
To:     Andrey Smirnov <andrew.smirnov@...il.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>,
        Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Lee Jones <lee.jones@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH v6 1/2] platform: Add driver for RAVE Supervisory
 Processor

Hi!

> >> +                 * 9  -> Illegal Trap
> >> +                 * 10 -> Unknown
> >> +                 * 11 -> Crew Panel Requested
> >
> > Anyway... If you move management chip to .. I don't know, i2c, the
> > path would change. Also it would be different path on N900. Userland
> > should not have to deal with this.
> >
> > And... this should really be string, as the list will need to grow on
> > different hardware.
> 
> I think we have a misunderstanding, with this part of the patch set I
> am not trying to propose a generic ABI that would be useful for any
> other driver but this one. Hence the lack of concern for different

Yes, but sorry, that's no-go.  Kernel should hide differences between
different machiens, and it should be rather easy in this case.

> hardware paths (it's not going to change for this device) and device
> specific codes instead of generic strings. I can see how my choice of
> generic name such as "reset_reason" might suggest that, so I apologize
> for any confusion I might have caused. If said generic name is
> unacceptable I can change it to "rave_reset_reason" or something
> similar and if that is undesirable as well I am happy to drop this
> part of the patch and re-visit this later.

Ok, can we do the re-visit thing? You may want to contact these people:

Date: Wed, 30 Aug 2017 12:59:55 +0200
From: Pavel Machek <pavel@....cz>
To: Vadim Pasternak <vadimp@...lanox.com>
Cc: lee.jones@...aro.org, robh+dt@...nel.org,
devicetree@...r.kernel.org,
        j.anaszewski@...sung.com, rpurdie@...ys.net,
	linux-leds@...r.kernel.org,
	        jiri@...nulli.us, gregkh@...uxfoundation.org,
		platform-driver-x86@...r.kernel.org
Subject: Re: [patch v4 1/2] mfd: Add Mellanox regmap core driver

They are currently trying to add driver, including

>  Cause of reset nodes:
>  - cpu_kernel_panic
>  - cpu_shutdown
>  - bmc_warm_reset

...which sounds very similar to what you are doing.
		
> > Plus we'll really need better explanations. What is difference between
> > "normal power off" and "host requested"?
> >
> 
> Short answer: I don't know, since this is as much information that ICD
> for that device gave me.
> 
> Long answer:  It probably can be discerned from the source code of the
> firmware/schematic as well as by bothering the right people, but since
> I get a feeling that this attribute is not really desirable in its
> current from, I'll punt doing that.

Ok.

> >> +             The following values are valid:
> >> +                 * 0  -> SD card
> >> +                 * 1  -> eMMC
> >> +                 * 2  -> SPI NOR
> >> +
> >> +             NOTE: Setting boot source on RDU1 hardware is
> >> +             currently not implemented
> >
> > Same comments apply here.
> 
> Yep, same comment for me as well :-)

Ok :-).

Best regards,
							Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)