Re: [PATCH v5 1/3] open: add close_range()
On Sat, Jun 6, 2020 at 6:55 AM Szabolcs Nagy wrote: > > * Kyle Evans [2020-06-05 21:54:56 -0500]: > > On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy wrote: > > > this api needs a documentation patch if there isn't yet. > > > > > > currently there is no libc interface contract in place that > > > says which calls may use libc internal fds e.g. i've seen > > > > > > openlog(...) // opens libc internal syslog fd > > > ... > > > fork() > > > closefrom(...) // close syslog fd > > > open(...) // something that reuses the closed fd > > > syslog(...) // unsafe: uses the wrong fd > > > execve(...) > > > > > > syslog uses a libc internal fd that the user trampled on and > > > this can go bad in many ways depending on what libc apis are > > > used between closefrom (or equivalent) and exec. > > > > > > > Documentation is good. :-) I think you'll find that while this example > > seems to be innocuous on FreeBSD (and likely other *BSD), this is an > > atypical scenario and generally not advised. You would usually not > > start closing until you're actually ready to exec/fail. > > it's a recent bug https://bugs.kde.org/show_bug.cgi?id=420921 > > but not the first closefrom bug i saw: it is a fundamentally > unsafe operation that frees resources owned by others. > Yes, close() is an inherently unsafe operation, and they managed this bug without even having closefrom/close_range. I'm not entirely convinced folks are going to spontaneously develop a need to massively close things just because close_range exists. If they have a need, they're already doing it with what they have available and causing bugs like the above. > > > > The code snippet above is one way of working around the problem that > > > > file > > > > descriptors are not cloexec by default. This is aggravated by the fact > > > > that > > > > we can't just switch them over without massively regressing userspace. > > > > For > > > > > > why is a switch_to_cloexec_range worse than close_range? > > > the former seems safer to me. (and allows libc calls > > > to be made between such switch and exec: libc internal > > > fds have to be cloexec anyway) > > > > > > > I wouldn't say it's worse, but it only solves half the problem. While > > closefrom -> exec is the most common usage by a long shot, there are > > also times (e.g. post-fork without intent to exec for a daemon/service > > type) that you want to go ahead and close everything except maybe a > > pipe fd that you've opened for IPC. While uncommon, there's no reason > > this needs to devolve into a loop to close 'all the fds' when you can > > instead introduce close_range to solve both the exec case and other > > less common scenarios. > > the syslog example shows why post-fork closefrom without > intent to exec does not work: there is no contract about > which api calls behave like syslog, so calling anything > after closefrom can be broken. > I think that example shows one scenario where it's not safe, that's again in firmly "don't do that" territory. You can close arbitrary fds very early or very late, but not somewhere in the middle of an even remotely complex application. This problem exists with or without close_range. Like I said before, this is already done quite successfully now, along with other not-even-forked uses. e.g. OpenSSH sshd will closefrom() just after argument parsing: https://github.com/openbsd/src/blob/master/usr.bin/ssh/sshd.c#L1582 > libc can introduce new api contracts e.g. that some apis > don't use fds internally or after a closefrom call some > apis behave differently, if this is the expected direction > then it would be nice to propose that on the libc-coord > at openwall.com list. > I suspect it's likely better to document that one should close arbitrary fds very early or very late instead. Documenting which APIs are inherently unsafe before/after would seem to be fraught with peril -- you can enumerate what in libc is a potential problem, but there are other libs in use by applications that will also use fds internally and potentially cause problems, but we can't possibly raise awareness of all of them. We can, however, raise awareness of the valid and incredibly useful use-cases. > > Coordination with libc is generally not much of an issue, because this > > is really one of the last things you do before exec() or swiftly > > failing miserably. Applications that currently loop over all fd <= > > maxfd and close(fd) right now are subject to the very same > > constraints, this is just a
Re: [PATCH v5 1/3] open: add close_range()
On Fri, Jun 5, 2020 at 9:54 PM Kyle Evans wrote: > > On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy wrote: > > > > * Christian Brauner [2020-06-02 22:42:17 > > +0200]: > > > [... snip ...] > > > > > > First, it helps to close all file descriptors of an exec()ing task. This > > > can be done safely via (quoting Al's example from [1] verbatim): > > > > > > /* that exec is sensitive */ > > > unshare(CLONE_FILES); > > > /* we don't want anything past stderr here */ > > > close_range(3, ~0U); > > > execve(); > > > > this api needs a documentation patch if there isn't yet. > > > > currently there is no libc interface contract in place that > > says which calls may use libc internal fds e.g. i've seen > > > > openlog(...) // opens libc internal syslog fd > > ... > > fork() > > closefrom(...) // close syslog fd > > open(...) // something that reuses the closed fd > > syslog(...) // unsafe: uses the wrong fd > > execve(...) > > > > syslog uses a libc internal fd that the user trampled on and > > this can go bad in many ways depending on what libc apis are > > used between closefrom (or equivalent) and exec. > > > > Documentation is good. :-) I think you'll find that while this example > seems to be innocuous on FreeBSD (and likely other *BSD), this is an > atypical scenario and generally not advised. You would usually not > start closing until you're actually ready to exec/fail. > Minor correction: not innocuous here, either; O_CLOFORK is not yet a thing. :-)
Re: [PATCH v5 1/3] open: add close_range()
On Fri, Jun 5, 2020 at 9:55 AM Szabolcs Nagy wrote: > > * Christian Brauner [2020-06-02 22:42:17 > +0200]: > > [... snip ...] > > > > First, it helps to close all file descriptors of an exec()ing task. This > > can be done safely via (quoting Al's example from [1] verbatim): > > > > /* that exec is sensitive */ > > unshare(CLONE_FILES); > > /* we don't want anything past stderr here */ > > close_range(3, ~0U); > > execve(); > > this api needs a documentation patch if there isn't yet. > > currently there is no libc interface contract in place that > says which calls may use libc internal fds e.g. i've seen > > openlog(...) // opens libc internal syslog fd > ... > fork() > closefrom(...) // close syslog fd > open(...) // something that reuses the closed fd > syslog(...) // unsafe: uses the wrong fd > execve(...) > > syslog uses a libc internal fd that the user trampled on and > this can go bad in many ways depending on what libc apis are > used between closefrom (or equivalent) and exec. > Documentation is good. :-) I think you'll find that while this example seems to be innocuous on FreeBSD (and likely other *BSD), this is an atypical scenario and generally not advised. You would usually not start closing until you're actually ready to exec/fail. > > The code snippet above is one way of working around the problem that file > > descriptors are not cloexec by default. This is aggravated by the fact that > > we can't just switch them over without massively regressing userspace. For > > why is a switch_to_cloexec_range worse than close_range? > the former seems safer to me. (and allows libc calls > to be made between such switch and exec: libc internal > fds have to be cloexec anyway) > I wouldn't say it's worse, but it only solves half the problem. While closefrom -> exec is the most common usage by a long shot, there are also times (e.g. post-fork without intent to exec for a daemon/service type) that you want to go ahead and close everything except maybe a pipe fd that you've opened for IPC. While uncommon, there's no reason this needs to devolve into a loop to close 'all the fds' when you can instead introduce close_range to solve both the exec case and other less common scenarios. > > a whole class of programs having an in-kernel method of closing all file > > descriptors is very helpful (e.g. demons, service managers, programming > > language standard libraries, container managers etc.). > > (Please note, unshare(CLONE_FILES) should only be needed if the calling > > task is multi-threaded and shares the file descriptor table with another > > thread in which case two threads could race with one thread allocating file > > descriptors and the other one closing them via close_range(). For the > > general case close_range() before the execve() is sufficient.) > > > > Second, it allows userspace to avoid implementing closing all file > > descriptors by parsing through /proc//fd/* and calling close() on each > > file descriptor. From looking at various large(ish) userspace code bases > > this or similar patterns are very common in: > > - service managers (cf. [4]) > > - libcs (cf. [6]) > > - container runtimes (cf. [5]) > > - programming language runtimes/standard libraries > > - Python (cf. [2]) > > - Rust (cf. [7], [8]) > > As Dmitry pointed out there's even a long-standing glibc bug about missing > > kernel support for this task (cf. [3]). > > In addition, the syscall will also work for tasks that do not have procfs > > mounted and on kernels that do not have procfs support compiled in. In such > > situations the only way to make sure that all file descriptors are closed > > is to call close() on each file descriptor up to UINT_MAX or RLIMIT_NOFILE, > > OPEN_MAX trickery (cf. comment [8] on Rust). > > close_range still seems like a bad operation to expose. > > if users really want closing behaviour (instead of marking > fds cloexec) then they likely need coordination with libc > and other libraries. > > e.g. this usage does not work: > > maxfd = findmaxfd(); > call_that_may_leak_fds(); > close_range(maxfd,~0U); > > as far as i can tell only the close right before exec works. I don't have much to say on this one, except that's also an unusual case. I don't know that I'd anticipate close_range getting used for that kind of cleanup job (I've never seen a similar use of closefrom), which seems to just be papering over application/library bugs. Coordination with libc is generally not much of an issue, because this is really one of the last things you do before exec() or swiftly failing miserably. Applications that currently loop over all fd <= maxfd and close(fd) right now are subject to the very same constraints, this is just a much more efficient way and debugger-friendly way to accomplish it. You've absolutely not lived life until you've had to watch thousands of close() calls painfully scroll by in truss/strace. Thank, Kyle Evans
Re: [linux-sunxi] Re: [PATCH v2 14/16] arm: dts: sun8i: h3: enable H3 sid controller
On Thu, Apr 19, 2018 at 10:13 AM, Icenowy Zheng <icen...@aosc.io> wrote:
>
>
> 于 2018年4月19日 GMT+08:00 下午11:11:22, Kyle Evans <kev...@freebsd.org> 写到:
>>On Mon, Jan 29, 2018 at 6:03 AM, Philipp Rossak <embe...@gmail.com>
>>wrote:
>>>
>>>
>>> On 29.01.2018 10:52, Maxime Ripard wrote:
>>>>
>>>> On Mon, Jan 29, 2018 at 12:29:17AM +0100, Philipp Rossak wrote:
>>>>>
>>>>> This patch enables the the sid controller in the H3. It can be used
>>>>> for thermal calibration data.
>>>>>
>>>>> Signed-off-by: Philipp Rossak <embe...@gmail.com>
>>>>> ---
>>>>> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>>>> 1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 3f83f6a27c74..9bb5cc29fec5 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -72,6 +72,13 @@
>>>>> };
>>>>> };
>>>>> + soc {
>>>>> + sid: eeprom@1c14000 {
>>>>> + compatible = "allwinner,sun8i-h3-sid";
>>>>> + reg = <0x01c14000 0x400>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>
>>>>
>>>> Shouldn't you also use a nvmem-cells property to the THS node?
>>>>
>>>> Maxime
>>>>
>>>
>>> Oh seems like I forgot that.
>>> As related to the wiki [1] this should be 64 bit wide at the address
>>0x34. I
>>> will add that in the next version.
>>>
>>>
>>> [1]: http://linux-sunxi.org/SID_Register_Guide#eFUSE
>>>
>>> Thanks,
>>> Philipp
>>>
>>
>>Hi,
>>
>>Any chance this will see a v3 soon? I'm kind of interested in sid node
>>for h3. =)
>
> This patch is independent and can be easily sent out
> by its own.
>
Right- I had considered doing so, but wanted to make sure I wasn't
going to collide with this series if a v3 is imminent.
Re: [linux-sunxi] Re: [PATCH v2 14/16] arm: dts: sun8i: h3: enable H3 sid controller
On Thu, Apr 19, 2018 at 10:13 AM, Icenowy Zheng wrote:
>
>
> 于 2018年4月19日 GMT+08:00 下午11:11:22, Kyle Evans 写到:
>>On Mon, Jan 29, 2018 at 6:03 AM, Philipp Rossak
>>wrote:
>>>
>>>
>>> On 29.01.2018 10:52, Maxime Ripard wrote:
>>>>
>>>> On Mon, Jan 29, 2018 at 12:29:17AM +0100, Philipp Rossak wrote:
>>>>>
>>>>> This patch enables the the sid controller in the H3. It can be used
>>>>> for thermal calibration data.
>>>>>
>>>>> Signed-off-by: Philipp Rossak
>>>>> ---
>>>>> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>>>> 1 file changed, 7 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 3f83f6a27c74..9bb5cc29fec5 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -72,6 +72,13 @@
>>>>> };
>>>>> };
>>>>> + soc {
>>>>> + sid: eeprom@1c14000 {
>>>>> + compatible = "allwinner,sun8i-h3-sid";
>>>>> + reg = <0x01c14000 0x400>;
>>>>> + };
>>>>> + };
>>>>> +
>>>>
>>>>
>>>> Shouldn't you also use a nvmem-cells property to the THS node?
>>>>
>>>> Maxime
>>>>
>>>
>>> Oh seems like I forgot that.
>>> As related to the wiki [1] this should be 64 bit wide at the address
>>0x34. I
>>> will add that in the next version.
>>>
>>>
>>> [1]: http://linux-sunxi.org/SID_Register_Guide#eFUSE
>>>
>>> Thanks,
>>> Philipp
>>>
>>
>>Hi,
>>
>>Any chance this will see a v3 soon? I'm kind of interested in sid node
>>for h3. =)
>
> This patch is independent and can be easily sent out
> by its own.
>
Right- I had considered doing so, but wanted to make sure I wasn't
going to collide with this series if a v3 is imminent.
Re: [linux-sunxi] Re: [PATCH v2 14/16] arm: dts: sun8i: h3: enable H3 sid controller
On Mon, Jan 29, 2018 at 6:03 AM, Philipp Rossak <embe...@gmail.com> wrote:
>
>
> On 29.01.2018 10:52, Maxime Ripard wrote:
>>
>> On Mon, Jan 29, 2018 at 12:29:17AM +0100, Philipp Rossak wrote:
>>>
>>> This patch enables the the sid controller in the H3. It can be used
>>> for thermal calibration data.
>>>
>>> Signed-off-by: Philipp Rossak <embe...@gmail.com>
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 3f83f6a27c74..9bb5cc29fec5 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -72,6 +72,13 @@
>>> };
>>> };
>>> + soc {
>>> + sid: eeprom@1c14000 {
>>> + compatible = "allwinner,sun8i-h3-sid";
>>> + reg = <0x01c14000 0x400>;
>>> + };
>>> + };
>>> +
>>
>>
>> Shouldn't you also use a nvmem-cells property to the THS node?
>>
>> Maxime
>>
>
> Oh seems like I forgot that.
> As related to the wiki [1] this should be 64 bit wide at the address 0x34. I
> will add that in the next version.
>
>
> [1]: http://linux-sunxi.org/SID_Register_Guide#eFUSE
>
> Thanks,
> Philipp
>
Hi,
Any chance this will see a v3 soon? I'm kind of interested in sid node
for h3. =)
Thanks,
Kyle Evans
Re: [linux-sunxi] Re: [PATCH v2 14/16] arm: dts: sun8i: h3: enable H3 sid controller
On Mon, Jan 29, 2018 at 6:03 AM, Philipp Rossak wrote:
>
>
> On 29.01.2018 10:52, Maxime Ripard wrote:
>>
>> On Mon, Jan 29, 2018 at 12:29:17AM +0100, Philipp Rossak wrote:
>>>
>>> This patch enables the the sid controller in the H3. It can be used
>>> for thermal calibration data.
>>>
>>> Signed-off-by: Philipp Rossak
>>> ---
>>> arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> index 3f83f6a27c74..9bb5cc29fec5 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>> @@ -72,6 +72,13 @@
>>> };
>>> };
>>> + soc {
>>> + sid: eeprom@1c14000 {
>>> + compatible = "allwinner,sun8i-h3-sid";
>>> + reg = <0x01c14000 0x400>;
>>> + };
>>> + };
>>> +
>>
>>
>> Shouldn't you also use a nvmem-cells property to the THS node?
>>
>> Maxime
>>
>
> Oh seems like I forgot that.
> As related to the wiki [1] this should be 64 bit wide at the address 0x34. I
> will add that in the next version.
>
>
> [1]: http://linux-sunxi.org/SID_Register_Guide#eFUSE
>
> Thanks,
> Philipp
>
Hi,
Any chance this will see a v3 soon? I'm kind of interested in sid node
for h3. =)
Thanks,
Kyle Evans
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Tue, Jan 9, 2018 at 7:34 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Mon, Jan 08, 2018 at 09:30:57AM -0600, Kyle Evans wrote: >> On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot <m...@bidouilliste.com> >> >> wrote: >> >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> >> > >> >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> >> > >> >> >> > Hi Maxime, >> >> >> > >> >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> >> >> > >> >> >> > > Hi, >> >> >> > > >> >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> >> > > > <maxime.rip...@free-electrons.com> wrote: >> >> >> > > > > Hi Kyle, >> >> >> > > > > >> >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu >> >> >> > > > > wrote: >> >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> >> > > > >> rootkey and >> >> >> > > > >> thermal calibration data, add node to describe it. >> >> >> > > > >> >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but >> >> >> > > > >> it is >> >> >> > > > >> supported in an external driver for FreeBSD. >> >> >> > > > >> >> >> >> > > > >> Signed-off-by: Kyle Evans <kevan...@ksu.edu> >> >> >> > > > > >> >> >> > > > > The patch looks fine in itself, but we've had a number of >> >> >> > > > > issues with >> >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> >> > > > > rather >> >> >> > > > > have something that works in Linux too if possible. >> >> >> > > > >> >> >> > > > I have a patch that I think should make it work fine on Linux >> >> >> > > > [1], but >> >> >> > > > I'm afraid I have little to no capability to test it myself and >> >> >> > > > so I >> >> >> > > > did not add it as well. >> >> >> > > > >> >> >> > > > I do know that the rootkey is offset 0x200 into the given space >> >> >> > > > [2], >> >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> >> > > > needed. >> >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space >> >> >> > > > as the >> >> >> > > > H3, but I do know that thermal data can be found at 0x34 and >> >> >> > > > 0x38 in >> >> >> > > > this space. >> >> >> > > >> >> >> > > Then maybe we should leave it aside until someone takes some time >> >> >> > > on >> >> >> > > the A83t. >> >> >> > >> >> >> > Take some time on the Linux driver and do not apply this patch for >> >> >> > now you mean ? >> >> >> >> >> >> Yep. >> >> >> >> >> >> Maxime >> >> > >> >> > Since linux doesn't have the compatible in it's driver what would >> >> > be the harm to add the node in the DTS ? If a quirks is needed because >> >> > some region is weird this would go in the driver right ? I don't see a >> >> > technical problem for adding this node right now. >> >> > If Kyle confirm the lenght of the region and that no quirk is needed >> >> > will it be enough ? >> >> >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> >> node currently says nothing about how much efuse space there is. The >> >> memory region covers that and the control section, and the size matches >> >> what the memory map says. >> >> >> >> The size and offset of the efuse space would be dealt with in the driver. >> > >> > Let's merge it then. >> > >> > Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> >> >> What does the timeline for these things normally look like? I'm new to >> these parts. =) > > We're one week away from the merge window, so it's a bit late for it > to be merged in 4.16, but it'll be in 4.17. > > Maxime > Hi, It's been two months and this still hasn't quite landed in sunxi/for-next. =( May I ask the status on this? Thanks, Kyle Evans
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Tue, Jan 9, 2018 at 7:34 AM, Maxime Ripard wrote: > On Mon, Jan 08, 2018 at 09:30:57AM -0600, Kyle Evans wrote: >> On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard >> wrote: >> > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot >> >> wrote: >> >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> >> > Maxime Ripard wrote: >> >> > >> >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> >> > >> >> >> > Hi Maxime, >> >> >> > >> >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> >> > Maxime Ripard wrote: >> >> >> > >> >> >> > > Hi, >> >> >> > > >> >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> >> > > > wrote: >> >> >> > > > > Hi Kyle, >> >> >> > > > > >> >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu >> >> >> > > > > wrote: >> >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> >> > > > >> rootkey and >> >> >> > > > >> thermal calibration data, add node to describe it. >> >> >> > > > >> >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but >> >> >> > > > >> it is >> >> >> > > > >> supported in an external driver for FreeBSD. >> >> >> > > > >> >> >> >> > > > >> Signed-off-by: Kyle Evans >> >> >> > > > > >> >> >> > > > > The patch looks fine in itself, but we've had a number of >> >> >> > > > > issues with >> >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> >> > > > > rather >> >> >> > > > > have something that works in Linux too if possible. >> >> >> > > > >> >> >> > > > I have a patch that I think should make it work fine on Linux >> >> >> > > > [1], but >> >> >> > > > I'm afraid I have little to no capability to test it myself and >> >> >> > > > so I >> >> >> > > > did not add it as well. >> >> >> > > > >> >> >> > > > I do know that the rootkey is offset 0x200 into the given space >> >> >> > > > [2], >> >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> >> > > > needed. >> >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space >> >> >> > > > as the >> >> >> > > > H3, but I do know that thermal data can be found at 0x34 and >> >> >> > > > 0x38 in >> >> >> > > > this space. >> >> >> > > >> >> >> > > Then maybe we should leave it aside until someone takes some time >> >> >> > > on >> >> >> > > the A83t. >> >> >> > >> >> >> > Take some time on the Linux driver and do not apply this patch for >> >> >> > now you mean ? >> >> >> >> >> >> Yep. >> >> >> >> >> >> Maxime >> >> > >> >> > Since linux doesn't have the compatible in it's driver what would >> >> > be the harm to add the node in the DTS ? If a quirks is needed because >> >> > some region is weird this would go in the driver right ? I don't see a >> >> > technical problem for adding this node right now. >> >> > If Kyle confirm the lenght of the region and that no quirk is needed >> >> > will it be enough ? >> >> >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> >> node currently says nothing about how much efuse space there is. The >> >> memory region covers that and the control section, and the size matches >> >> what the memory map says. >> >> >> >> The size and offset of the efuse space would be dealt with in the driver. >> > >> > Let's merge it then. >> > >> > Acked-by: Maxime Ripard >> >> What does the timeline for these things normally look like? I'm new to >> these parts. =) > > We're one week away from the merge window, so it's a bit late for it > to be merged in 4.16, but it'll be in 4.17. > > Maxime > Hi, It's been two months and this still hasn't quite landed in sunxi/for-next. =( May I ask the status on this? Thanks, Kyle Evans
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Tue, Jan 9, 2018 at 7:34 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Mon, Jan 08, 2018 at 09:30:57AM -0600, Kyle Evans wrote: >> On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot <m...@bidouilliste.com> >> >> wrote: >> >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> >> > >> >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> >> > >> >> >> > Hi Maxime, >> >> >> > >> >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> >> >> > >> >> >> > > Hi, >> >> >> > > >> >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> >> > > > <maxime.rip...@free-electrons.com> wrote: >> >> >> > > > > Hi Kyle, >> >> >> > > > > >> >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu >> >> >> > > > > wrote: >> >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> >> > > > >> rootkey and >> >> >> > > > >> thermal calibration data, add node to describe it. >> >> >> > > > >> >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but >> >> >> > > > >> it is >> >> >> > > > >> supported in an external driver for FreeBSD. >> >> >> > > > >> >> >> >> > > > >> Signed-off-by: Kyle Evans <kevan...@ksu.edu> >> >> >> > > > > >> >> >> > > > > The patch looks fine in itself, but we've had a number of >> >> >> > > > > issues with >> >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> >> > > > > rather >> >> >> > > > > have something that works in Linux too if possible. >> >> >> > > > >> >> >> > > > I have a patch that I think should make it work fine on Linux >> >> >> > > > [1], but >> >> >> > > > I'm afraid I have little to no capability to test it myself and >> >> >> > > > so I >> >> >> > > > did not add it as well. >> >> >> > > > >> >> >> > > > I do know that the rootkey is offset 0x200 into the given space >> >> >> > > > [2], >> >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> >> > > > needed. >> >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space >> >> >> > > > as the >> >> >> > > > H3, but I do know that thermal data can be found at 0x34 and >> >> >> > > > 0x38 in >> >> >> > > > this space. >> >> >> > > >> >> >> > > Then maybe we should leave it aside until someone takes some time >> >> >> > > on >> >> >> > > the A83t. >> >> >> > >> >> >> > Take some time on the Linux driver and do not apply this patch for >> >> >> > now you mean ? >> >> >> >> >> >> Yep. >> >> >> >> >> >> Maxime >> >> > >> >> > Since linux doesn't have the compatible in it's driver what would >> >> > be the harm to add the node in the DTS ? If a quirks is needed because >> >> > some region is weird this would go in the driver right ? I don't see a >> >> > technical problem for adding this node right now. >> >> > If Kyle confirm the lenght of the region and that no quirk is needed >> >> > will it be enough ? >> >> >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> >> node currently says nothing about how much efuse space there is. The >> >> memory region covers that and the control section, and the size matches >> >> what the memory map says. >> >> >> >> The size and offset of the efuse space would be dealt with in the driver. >> > >> > Let's merge it then. >> > >> > Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> >> >> What does the timeline for these things normally look like? I'm new to >> these parts. =) > > We're one week away from the merge window, so it's a bit late for it > to be merged in 4.16, but it'll be in 4.17. Ok, cool, that makes sense. Thanks!
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Tue, Jan 9, 2018 at 7:34 AM, Maxime Ripard wrote: > On Mon, Jan 08, 2018 at 09:30:57AM -0600, Kyle Evans wrote: >> On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard >> wrote: >> > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot >> >> wrote: >> >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> >> > Maxime Ripard wrote: >> >> > >> >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> >> > >> >> >> > Hi Maxime, >> >> >> > >> >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> >> > Maxime Ripard wrote: >> >> >> > >> >> >> > > Hi, >> >> >> > > >> >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> >> > > > wrote: >> >> >> > > > > Hi Kyle, >> >> >> > > > > >> >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu >> >> >> > > > > wrote: >> >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> >> > > > >> rootkey and >> >> >> > > > >> thermal calibration data, add node to describe it. >> >> >> > > > >> >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but >> >> >> > > > >> it is >> >> >> > > > >> supported in an external driver for FreeBSD. >> >> >> > > > >> >> >> >> > > > >> Signed-off-by: Kyle Evans >> >> >> > > > > >> >> >> > > > > The patch looks fine in itself, but we've had a number of >> >> >> > > > > issues with >> >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> >> > > > > rather >> >> >> > > > > have something that works in Linux too if possible. >> >> >> > > > >> >> >> > > > I have a patch that I think should make it work fine on Linux >> >> >> > > > [1], but >> >> >> > > > I'm afraid I have little to no capability to test it myself and >> >> >> > > > so I >> >> >> > > > did not add it as well. >> >> >> > > > >> >> >> > > > I do know that the rootkey is offset 0x200 into the given space >> >> >> > > > [2], >> >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> >> > > > needed. >> >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space >> >> >> > > > as the >> >> >> > > > H3, but I do know that thermal data can be found at 0x34 and >> >> >> > > > 0x38 in >> >> >> > > > this space. >> >> >> > > >> >> >> > > Then maybe we should leave it aside until someone takes some time >> >> >> > > on >> >> >> > > the A83t. >> >> >> > >> >> >> > Take some time on the Linux driver and do not apply this patch for >> >> >> > now you mean ? >> >> >> >> >> >> Yep. >> >> >> >> >> >> Maxime >> >> > >> >> > Since linux doesn't have the compatible in it's driver what would >> >> > be the harm to add the node in the DTS ? If a quirks is needed because >> >> > some region is weird this would go in the driver right ? I don't see a >> >> > technical problem for adding this node right now. >> >> > If Kyle confirm the lenght of the region and that no quirk is needed >> >> > will it be enough ? >> >> >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> >> node currently says nothing about how much efuse space there is. The >> >> memory region covers that and the control section, and the size matches >> >> what the memory map says. >> >> >> >> The size and offset of the efuse space would be dealt with in the driver. >> > >> > Let's merge it then. >> > >> > Acked-by: Maxime Ripard >> >> What does the timeline for these things normally look like? I'm new to >> these parts. =) > > We're one week away from the merge window, so it's a bit late for it > to be merged in 4.16, but it'll be in 4.17. Ok, cool, that makes sense. Thanks!
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot <m...@bidouilliste.com> >> wrote: >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> > >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> > >> >> > Hi Maxime, >> >> > >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> > Maxime Ripard <maxime.rip...@free-electrons.com> wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> > > > <maxime.rip...@free-electrons.com> wrote: >> >> > > > > Hi Kyle, >> >> > > > > >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> > > > >> rootkey and >> >> > > > >> thermal calibration data, add node to describe it. >> >> > > > >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> >> > > > >> supported in an external driver for FreeBSD. >> >> > > > >> >> >> > > > >> Signed-off-by: Kyle Evans <kevan...@ksu.edu> >> >> > > > > >> >> > > > > The patch looks fine in itself, but we've had a number of issues >> >> > > > > with >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> > > > > rather >> >> > > > > have something that works in Linux too if possible. >> >> > > > >> >> > > > I have a patch that I think should make it work fine on Linux [1], >> >> > > > but >> >> > > > I'm afraid I have little to no capability to test it myself and so I >> >> > > > did not add it as well. >> >> > > > >> >> > > > I do know that the rootkey is offset 0x200 into the given space [2], >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> > > > needed. >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as >> >> > > > the >> >> > > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in >> >> > > > this space. >> >> > > >> >> > > Then maybe we should leave it aside until someone takes some time on >> >> > > the A83t. >> >> > >> >> > Take some time on the Linux driver and do not apply this patch for >> >> > now you mean ? >> >> >> >> Yep. >> >> >> >> Maxime >> > >> > Since linux doesn't have the compatible in it's driver what would >> > be the harm to add the node in the DTS ? If a quirks is needed because >> > some region is weird this would go in the driver right ? I don't see a >> > technical problem for adding this node right now. >> > If Kyle confirm the lenght of the region and that no quirk is needed >> > will it be enough ? >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> node currently says nothing about how much efuse space there is. The >> memory region covers that and the control section, and the size matches >> what the memory map says. >> >> The size and offset of the efuse space would be dealt with in the driver. > > Let's merge it then. > > Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com> > > Maxime Hi, What does the timeline for these things normally look like? I'm new to these parts. =) Thanks, Kyle Evans
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Jan 4, 2018 at 8:01 AM, Maxime Ripard wrote: > On Fri, Dec 22, 2017 at 06:11:52PM +0800, Chen-Yu Tsai wrote: >> On Fri, Dec 22, 2017 at 6:07 PM, Emmanuel Vadot >> wrote: >> > On Fri, 22 Dec 2017 09:35:08 +0100 >> > Maxime Ripard wrote: >> > >> >> On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote: >> >> > >> >> > Hi Maxime, >> >> > >> >> > On Thu, 21 Dec 2017 16:26:30 +0100 >> >> > Maxime Ripard wrote: >> >> > >> >> > > Hi, >> >> > > >> >> > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> >> > > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> >> > > > wrote: >> >> > > > > Hi Kyle, >> >> > > > > >> >> > > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> >> > > > >> Allwinner a83t has a 1 KB sid block with efuse for security >> >> > > > >> rootkey and >> >> > > > >> thermal calibration data, add node to describe it. >> >> > > > >> >> >> > > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> >> > > > >> supported in an external driver for FreeBSD. >> >> > > > >> >> >> > > > >> Signed-off-by: Kyle Evans >> >> > > > > >> >> > > > > The patch looks fine in itself, but we've had a number of issues >> >> > > > > with >> >> > > > > the register layout (and access patterns) in the past, so I'd >> >> > > > > rather >> >> > > > > have something that works in Linux too if possible. >> >> > > > >> >> > > > I have a patch that I think should make it work fine on Linux [1], >> >> > > > but >> >> > > > I'm afraid I have little to no capability to test it myself and so I >> >> > > > did not add it as well. >> >> > > > >> >> > > > I do know that the rootkey is offset 0x200 into the given space [2], >> >> > > > as is the case with the H3, and that the readout quirk is not >> >> > > > needed. >> >> > > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as >> >> > > > the >> >> > > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in >> >> > > > this space. >> >> > > >> >> > > Then maybe we should leave it aside until someone takes some time on >> >> > > the A83t. >> >> > >> >> > Take some time on the Linux driver and do not apply this patch for >> >> > now you mean ? >> >> >> >> Yep. >> >> >> >> Maxime >> > >> > Since linux doesn't have the compatible in it's driver what would >> > be the harm to add the node in the DTS ? If a quirks is needed because >> > some region is weird this would go in the driver right ? I don't see a >> > technical problem for adding this node right now. >> > If Kyle confirm the lenght of the region and that no quirk is needed >> > will it be enough ? >> >> I guess I wasn't very clear. I'm OK with the patch going in. The device >> node currently says nothing about how much efuse space there is. The >> memory region covers that and the control section, and the size matches >> what the memory map says. >> >> The size and offset of the efuse space would be dealt with in the driver. > > Let's merge it then. > > Acked-by: Maxime Ripard > > Maxime Hi, What does the timeline for these things normally look like? I'm new to these parts. =) Thanks, Kyle Evans
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Dec 21, 2017 at 9:26 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > Hi, > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> <maxime.rip...@free-electrons.com> wrote: >> > Hi Kyle, >> > >> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and >> >> thermal calibration data, add node to describe it. >> >> >> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> >> supported in an external driver for FreeBSD. >> >> >> >> Signed-off-by: Kyle Evans <kevan...@ksu.edu> >> > >> > The patch looks fine in itself, but we've had a number of issues with >> > the register layout (and access patterns) in the past, so I'd rather >> > have something that works in Linux too if possible. >> >> I have a patch that I think should make it work fine on Linux [1], but >> I'm afraid I have little to no capability to test it myself and so I >> did not add it as well. >> >> I do know that the rootkey is offset 0x200 into the given space [2], >> as is the case with the H3, and that the readout quirk is not needed. >> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the >> H3, but I do know that thermal data can be found at 0x34 and 0x38 in >> this space. > > Then maybe we should leave it aside until someone takes some time on > the A83t. The good news is that the binding itself looks fine, so as > far as FreeBSD goes, there shouldn't be anything preventing you from > using it I guess. Yeah, we've had this exact binding in our own copy of DTS up until a recent point when we flipped the switch to pulling DT from Mainline Linux and trying to upstream changes instead of having a bunch of local modifications in our tree. > Chen-Yu, what do you think? > > Thanks! > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Dec 21, 2017 at 9:26 AM, Maxime Ripard wrote: > Hi, > > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote: >> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard >> wrote: >> > Hi Kyle, >> > >> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and >> >> thermal calibration data, add node to describe it. >> >> >> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> >> supported in an external driver for FreeBSD. >> >> >> >> Signed-off-by: Kyle Evans >> > >> > The patch looks fine in itself, but we've had a number of issues with >> > the register layout (and access patterns) in the past, so I'd rather >> > have something that works in Linux too if possible. >> >> I have a patch that I think should make it work fine on Linux [1], but >> I'm afraid I have little to no capability to test it myself and so I >> did not add it as well. >> >> I do know that the rootkey is offset 0x200 into the given space [2], >> as is the case with the H3, and that the readout quirk is not needed. >> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the >> H3, but I do know that thermal data can be found at 0x34 and 0x38 in >> this space. > > Then maybe we should leave it aside until someone takes some time on > the A83t. The good news is that the binding itself looks fine, so as > far as FreeBSD goes, there shouldn't be anything preventing you from > using it I guess. Yeah, we've had this exact binding in our own copy of DTS up until a recent point when we flipped the switch to pulling DT from Mainline Linux and trying to upstream changes instead of having a bunch of local modifications in our tree. > Chen-Yu, what do you think? > > Thanks! > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > Hi Kyle, > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and >> thermal calibration data, add node to describe it. >> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> supported in an external driver for FreeBSD. >> >> Signed-off-by: Kyle Evans <kevan...@ksu.edu> > > The patch looks fine in itself, but we've had a number of issues with > the register layout (and access patterns) in the past, so I'd rather > have something that works in Linux too if possible. Hello! I have a patch that I think should make it work fine on Linux [1], but I'm afraid I have little to no capability to test it myself and so I did not add it as well. I do know that the rootkey is offset 0x200 into the given space [2], as is the case with the H3, and that the readout quirk is not needed. I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the H3, but I do know that thermal data can be found at 0x34 and 0x38 in this space. [1] https://people.freebsd.org/~kevans/sunxi-sid.diff [2] https://svnweb.freebsd.org/base/head/sys/arm/allwinner/aw_sid.c?view=markup#l56
Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard wrote: > Hi Kyle, > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevan...@ksu.edu wrote: >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and >> thermal calibration data, add node to describe it. >> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is >> supported in an external driver for FreeBSD. >> >> Signed-off-by: Kyle Evans > > The patch looks fine in itself, but we've had a number of issues with > the register layout (and access patterns) in the past, so I'd rather > have something that works in Linux too if possible. Hello! I have a patch that I think should make it work fine on Linux [1], but I'm afraid I have little to no capability to test it myself and so I did not add it as well. I do know that the rootkey is offset 0x200 into the given space [2], as is the case with the H3, and that the readout quirk is not needed. I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the H3, but I do know that thermal data can be found at 0x34 and 0x38 in this space. [1] https://people.freebsd.org/~kevans/sunxi-sid.diff [2] https://svnweb.freebsd.org/base/head/sys/arm/allwinner/aw_sid.c?view=markup#l56
Re: toshiba_acpi: Unknown key 14b
What symbols go with the keys? Is it just one key, or two? I'm helping out another guy who has key 160 unknown and was planning on putting up a patch for that. On 06/01/2014 06:02 AM, Peter Senna Tschudin wrote: Hi, I'm using: 3.15.0-rc7-next-20140530 On a: Toshiba R830-10p And dmesg started to show: toshiba_acpi: Unknown key 14b toshiba_acpi: Unknown key 14d How can I help make this useful? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: toshiba_acpi: Unknown key 14b
What symbols go with the keys? Is it just one key, or two? I'm helping out another guy who has key 160 unknown and was planning on putting up a patch for that. On 06/01/2014 06:02 AM, Peter Senna Tschudin wrote: Hi, I'm using: 3.15.0-rc7-next-20140530 On a: Toshiba R830-10p And dmesg started to show: toshiba_acpi: Unknown key 14b toshiba_acpi: Unknown key 14d How can I help make this useful? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hp-wmi; Limit hotkey enable funtion
This patch is a supplement to commit
b253c9d1d858a3f115f791ee4fe2b9399ae7dbbd
Signed-off-by: Kyle Evans
---
drivers/platform/x86/hp-wmi.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 97bb05e..b65014f 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -996,6 +997,17 @@ static struct platform_driver hp_wmi_driver = {
.remove = __exit_p(hp_wmi_bios_remove),
};
+static struct dmi_system_id __initdata tx2_dmi_table[] = {
+ {
+ .ident = "tx2",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "tx2"),
+ },
+ },
+ { }
+};
+
static int __init hp_wmi_init(void)
{
int err;
@@ -1010,7 +1022,9 @@ static int __init hp_wmi_init(void)
if (err)
return err;
- hp_wmi_enable_hotkeys();
+ if (dmi_check_system(tx2_dmi_table)) {
+ hp_wmi_enable_hotkeys();
+ {
}
if (bios_capable) {
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hp-wmi; Limit hotkey enable funtion
This patch is a supplement to commit
b253c9d1d858a3f115f791ee4fe2b9399ae7dbbd
Signed-off-by: Kyle Evans kvan...@gmail.com
---
drivers/platform/x86/hp-wmi.c | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 97bb05e..b65014f 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -35,6 +35,7 @@
#include linux/input/sparse-keymap.h
#include linux/platform_device.h
#include linux/acpi.h
+#include linux/dmi.h
#include linux/rfkill.h
#include linux/string.h
@@ -996,6 +997,17 @@ static struct platform_driver hp_wmi_driver = {
.remove = __exit_p(hp_wmi_bios_remove),
};
+static struct dmi_system_id __initdata tx2_dmi_table[] = {
+ {
+ .ident = tx2,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Hewlett-Packard),
+ DMI_MATCH(DMI_PRODUCT_NAME, tx2),
+ },
+ },
+ { }
+};
+
static int __init hp_wmi_init(void)
{
int err;
@@ -1010,7 +1022,9 @@ static int __init hp_wmi_init(void)
if (err)
return err;
- hp_wmi_enable_hotkeys();
+ if (dmi_check_system(tx2_dmi_table)) {
+ hp_wmi_enable_hotkeys();
+ {
}
if (bios_capable) {
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/18/2013 11:58 AM, Matthew Garrett wrote: On Thu, 2013-04-18 at 09:55 -0400, Kyle Evans wrote: 0x9(write), or SHKS, is essentially ec_write(SFHK,Arg0). Arg0 turns out Oh - try changing int query = 1 to int query=0x6e That only works if I also change: -#define HPWMI_BIOS_QUERY 0x8 +#define HPWMI_BIOS_QUERY 0x9 But then we are still faced with a hardware detection problem I would assume. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/17/2013 01:59 PM, Matthew Garrett wrote:
On Wed, 2013-04-17 at 11:37 -0400, Kyle Evans wrote:
On 04/16/2013 12:26 PM, Matthew Garrett wrote:
Can you try this patch?
No dice. I have a dmi check patch that I will send in a day or two if
you don't find what you are looking for.
DMI's almost certainly the wrong solution. According to your DSDT, EC
register 0xe6 is called SFHK. That's written to by the SSHK method,
which in turn is executed by SHKS which should be called by the
hp_wmi_query call added there. Any chance you can try to figure out why
that's not happening?
I am not fully understanding how the bios query ID gets translated into
the method. As far as I can tell this happens under HWMC. But, if I
trace through that, 0x8(write) and 0x9(read) do not exist. However,
0x9(read) does have a method that works when I query it, GHKS. I do not
find the method for 0x8(write).
0x9(write), or SHKS, is essentially ec_write(SFHK,Arg0). Arg0 turns out
to be whatever data is sent in the 0x9 buffer.
...
CreateDWordField (Arg1, 0x10, DDWD)
If (LEqual (CMDT, 0x09))
{
Store (SHKS (DDWD), Local2)
...
I tried writing 0x60, and I tried writing 0x0e just to see if it if a
subset of that register is needed to enable the keys and it seems I need
the full 0x6e. I only find two places in the DSDT with that value, both
in the WQAE buffer and I can't see how that is used.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/17/2013 01:59 PM, Matthew Garrett wrote:
On Wed, 2013-04-17 at 11:37 -0400, Kyle Evans wrote:
On 04/16/2013 12:26 PM, Matthew Garrett wrote:
Can you try this patch?
No dice. I have a dmi check patch that I will send in a day or two if
you don't find what you are looking for.
DMI's almost certainly the wrong solution. According to your DSDT, EC
register 0xe6 is called SFHK. That's written to by the SSHK method,
which in turn is executed by SHKS which should be called by the
hp_wmi_query call added there. Any chance you can try to figure out why
that's not happening?
I am not fully understanding how the bios query ID gets translated into
the method. As far as I can tell this happens under HWMC. But, if I
trace through that, 0x8(write) and 0x9(read) do not exist. However,
0x9(read) does have a method that works when I query it, GHKS. I do not
find the method for 0x8(write).
0x9(write), or SHKS, is essentially ec_write(SFHK,Arg0). Arg0 turns out
to be whatever data is sent in the 0x9 buffer.
...
CreateDWordField (Arg1, 0x10, DDWD)
If (LEqual (CMDT, 0x09))
{
Store (SHKS (DDWD), Local2)
...
I tried writing 0x60, and I tried writing 0x0e just to see if it if a
subset of that register is needed to enable the keys and it seems I need
the full 0x6e. I only find two places in the DSDT with that value, both
in the WQAE buffer and I can't see how that is used.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/18/2013 11:58 AM, Matthew Garrett wrote: On Thu, 2013-04-18 at 09:55 -0400, Kyle Evans wrote: 0x9(write), or SHKS, is essentially ec_write(SFHK,Arg0). Arg0 turns out Oh - try changing int query = 1 to int query=0x6e That only works if I also change: -#define HPWMI_BIOS_QUERY 0x8 +#define HPWMI_BIOS_QUERY 0x9 But then we are still faced with a hardware detection problem I would assume. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/17/2013 01:59 PM, Matthew Garrett wrote: On Wed, 2013-04-17 at 11:37 -0400, Kyle Evans wrote: On 04/16/2013 12:26 PM, Matthew Garrett wrote: Can you try this patch? No dice. I have a dmi check patch that I will send in a day or two if you don't find what you are looking for. DMI's almost certainly the wrong solution. According to your DSDT, EC register 0xe6 is called SFHK. That's written to by the SSHK method, which in turn is executed by SHKS which should be called by the hp_wmi_query call added there. Any chance you can try to figure out why that's not happening? I see, I don't know how I missed that before. I think because I was searching for e6 instead of E6. I'm sure we can crack this the right way now. I'll do some digging. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/16/2013 12:26 PM, Matthew Garrett wrote: Can you try this patch? No dice. I have a dmi check patch that I will send in a day or two if you don't find what you are looking for. Currently, I am based on the torvalds master, but I can base off something else if you'd like. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/16/2013 12:26 PM, Matthew Garrett wrote: Can you try this patch? No dice. I have a dmi check patch that I will send in a day or two if you don't find what you are looking for. Currently, I am based on the torvalds master, but I can base off something else if you'd like. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/17/2013 01:59 PM, Matthew Garrett wrote: On Wed, 2013-04-17 at 11:37 -0400, Kyle Evans wrote: On 04/16/2013 12:26 PM, Matthew Garrett wrote: Can you try this patch? No dice. I have a dmi check patch that I will send in a day or two if you don't find what you are looking for. DMI's almost certainly the wrong solution. According to your DSDT, EC register 0xe6 is called SFHK. That's written to by the SSHK method, which in turn is executed by SHKS which should be called by the hp_wmi_query call added there. Any chance you can try to figure out why that's not happening? I see, I don't know how I missed that before. I think because I was searching for e6 instead of E6. I'm sure we can crack this the right way now. I'll do some digging. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/13/2013 12:21 PM, Matthew Garrett wrote:
On Sat, 2013-04-13 at 08:36 -0400, Kyle Evans wrote:
Sure, sorry about that. I was hoping the GUID would be enough. I'll see
what I can come up with.
Sure there's no WMI method that makes the EC write? It's a little weird
for WMI drivers to have to hit the EC directly.
I have no idea, I didn't know what a DSDT was before trying to get these
buttons working.
...A quick grep reveals acpi_wmi_ec_space_handler, is that what I should
use? It calls ec_write itself, but has more function parameters and of
course error checking to make sure you don't screw up those extra
parameters. Seems inefficient to me. Or, maybe like it was designed for
an automated code routine.
Looking further, I don't see any other drivers that use it, ec_write
seems to be the standard.
Your call though, you are the master in this domain and you wrote the
driver.
static acpi_status
acpi_wmi_ec_space_handler(u32 function, acpi_physical_address address,
u32 bits, u64 *value,
void *handler_context, void *region_context)
{
int result = 0, i = 0;
u8 temp = 0;
if ((address > 0xFF) || !value)
return AE_BAD_PARAMETER;
if (function != ACPI_READ && function != ACPI_WRITE)
return AE_BAD_PARAMETER;
if (bits != 8)
return AE_BAD_PARAMETER;
if (function == ACPI_READ) {
result = ec_read(address, );
(*value) |= ((u64)temp) << i;
} else {
temp = 0xff & ((*value) >> i);
result = ec_write(address, temp);
}
switch (result) {
case -EINVAL:
return AE_BAD_PARAMETER;
break;
case -ENODEV:
return AE_NOT_FOUND;
break;
case -ETIME:
return AE_TIME;
break;
default:
return AE_OK;
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
Sure, sorry about that. I was hoping the GUID would be enough. I'll see what I can come up with. On 04/12/2013 09:35 PM, Matthew Garrett wrote: On Sat, 2013-04-13 at 03:31 +0200, Pali Rohár wrote: all Fn keys, wifi switch, web and mute buttons not working anymore on my notebook HP EliteBook 8460p. I bisected git commit which broke all above keys: fabf85e3ca15d5b94058f391dac8df870cdd427a When I reverted that commit after reboot buttons started working again. Can you fix it or revert that broken commit? This is critical problem, which caused my notebook to be unusable... Sure, I'll revert that. Kyle, can you look into figuring out a way to only run this on machines that need it? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
Sure, sorry about that. I was hoping the GUID would be enough. I'll see what I can come up with. On 04/12/2013 09:35 PM, Matthew Garrett wrote: On Sat, 2013-04-13 at 03:31 +0200, Pali Rohár wrote: all Fn keys, wifi switch, web and mute buttons not working anymore on my notebook HP EliteBook 8460p. I bisected git commit which broke all above keys: fabf85e3ca15d5b94058f391dac8df870cdd427a When I reverted that commit after reboot buttons started working again. Can you fix it or revert that broken commit? This is critical problem, which caused my notebook to be unusable... Sure, I'll revert that. Kyle, can you look into figuring out a way to only run this on machines that need it? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG: Fn keys not working on EliteBook 8460p after fabf85e3ca15d5b94058f391dac8df870cdd427a
On 04/13/2013 12:21 PM, Matthew Garrett wrote:
On Sat, 2013-04-13 at 08:36 -0400, Kyle Evans wrote:
Sure, sorry about that. I was hoping the GUID would be enough. I'll see
what I can come up with.
Sure there's no WMI method that makes the EC write? It's a little weird
for WMI drivers to have to hit the EC directly.
I have no idea, I didn't know what a DSDT was before trying to get these
buttons working.
...A quick grep reveals acpi_wmi_ec_space_handler, is that what I should
use? It calls ec_write itself, but has more function parameters and of
course error checking to make sure you don't screw up those extra
parameters. Seems inefficient to me. Or, maybe like it was designed for
an automated code routine.
Looking further, I don't see any other drivers that use it, ec_write
seems to be the standard.
Your call though, you are the master in this domain and you wrote the
driver.
static acpi_status
acpi_wmi_ec_space_handler(u32 function, acpi_physical_address address,
u32 bits, u64 *value,
void *handler_context, void *region_context)
{
int result = 0, i = 0;
u8 temp = 0;
if ((address 0xFF) || !value)
return AE_BAD_PARAMETER;
if (function != ACPI_READ function != ACPI_WRITE)
return AE_BAD_PARAMETER;
if (bits != 8)
return AE_BAD_PARAMETER;
if (function == ACPI_READ) {
result = ec_read(address, temp);
(*value) |= ((u64)temp) i;
} else {
temp = 0xff ((*value) i);
result = ec_write(address, temp);
}
switch (result) {
case -EINVAL:
return AE_BAD_PARAMETER;
break;
case -ENODEV:
return AE_NOT_FOUND;
break;
case -ETIME:
return AE_TIME;
break;
default:
return AE_OK;
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
