Fix typo in f2fs documentation.
Signed-off-by: Ed Tsai
---
Documentation/filesystems/f2fs.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/f2fs.rst
b/Documentation/filesystems/f2fs.rst
index dae15c96e659..e1cda214058e 100644
--- a/Documentation
s and newer kernel use ACPI, older bios
match your driver,
people upgrading from kernels more than about a year old don't notice since
they move from "old"
names to "acpi names" which are identical.
> * simsw:
> * similar to mpcie-reset (still experimental, ...) ...
> * seems to be really bound to M2 ports
Not experimental. Works reliably. Just don't toggle them during bootup (as your
driver was doing in
the past - current driver doesn't do this anymore - problem resolved)
The GPIO lines are wired to a SIM swap chip which does all the work. The LTE
cards don't know or see
what is happening
Regards
Ed W
On 22/10/2020 10:22, Enrico Weigelt, metux IT consult wrote:
> On 21.10.20 23:41, Ed Wildgoose wrote:
>
> Hi,
>
>> The pcengines bios/firmware includes ACPI tables (since 4.10.0.1) which
>> will cause the kernel to automatically create led + gpio_key devices for
>>
On 14/10/2020 12:29, Hans de Goede wrote:
> Hi,
>
> On 10/14/20 1:21 PM, Ed W wrote:
>> On 14/10/2020 09:41, Hans de Goede wrote:
>>>
>>> So I have a suggested compromise:
>>>
>>> Keep the current LED/gpio setup code, but make executing it condit
for APU5 is extremely similar to APU2-4, but
many lines are moved around and there are simply more
modems/resets/sim-swap lines to breakout.
Also added APU6, which is essentially APU4 with a different ethernet
interface
Signed-off-by: Ed Wildgoose
---
drivers/platform/x86/pcengines-apuv2.c
for older bios.
Signed-off-by: Ed Wildgoose
---
drivers/platform/x86/pcengines-apuv2.c | 115 +++--
1 file changed, 90 insertions(+), 25 deletions(-)
diff --git a/drivers/platform/x86/pcengines-apuv2.c
b/drivers/platform/x86/pcengines-apuv2.c
index c37349f97..45f7a89de 100644
s clumsy using the existing detection mechanism,
I think whatever I
come up with you should kick back and recommend a new board detection
structure, but perhaps we can
shortcut that step with a few comments up front?
Cheers
Ed W
On 13/10/2020 09:48, Hans de Goede wrote:
> On 10/12/20 9:39 PM, Enrico Weigelt, metux IT consult wrote:
>> On 22.09.20 00:17, Ed W wrote:
>>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>>> variant of the APU 2-4
>>> boards
On 12/10/2020 20:39, Enrico Weigelt, metux IT consult wrote:
> On 22.09.20 00:17, Ed W wrote:
>> Hi, I've been adding support for the PC Engines APU5 board, which is a
>> variant of the APU 2-4 boards
>> with some nice features. The current platform driver for pce
do you have an
opinion?
However, perhaps it's already acceptable as is?
Kind regards
Ed W
On 21/09/2020 09:40, Ed W wrote:
> On 21/09/2020 08:55, Andy Shevchenko wrote:
>> On Sun, Sep 20, 2020 at 11:33 PM Ed Wildgoose wrote:
>>> Schematics show that the GPIO number is
The original commit appears to have the logic reversed in
amd_fch_gpio_get_direction. Also confirmed by observing the value of
"direction" in the sys tree.
Signed-off-by: Ed Wildgoose
Fixes: e09d168f13f0 ("gpio: AMD G-Series PCH gpio driver")
---
drivers/gpio/gpio-amd-
xport() to achieve this, but I concede I'm really not
clear how to
implement this in the platform module as currently structured... Any tips
please?
Thanks
Ed W
of the GPIOs for APU5 is extremely similar to APU2-4, but
many lines are moved around and there are simply more
modems/resets/sim-swap lines to breakout.
Signed-off-by: Ed Wildgoose
---
drivers/platform/x86/pcengines-apuv2.c | 175 +++--
1 file changed, 136 insertions(+), 39
;leds-apu' driver to get the
same set of led devices as created by the kernel with a modern bios.
Signed-off-by: Ed Wildgoose
---
drivers/platform/x86/pcengines-apuv2.c | 76 +-
1 file changed, 1 insertion(+), 75 deletions(-)
diff --git a/drivers/platform/x86/pcengines-
On 21/09/2020 08:55, Andy Shevchenko wrote:
On Sun, Sep 20, 2020 at 11:33 PM Ed Wildgoose wrote:
Schematics show that the GPIO number is 55 (not 59). Trivial typo.
Does it still DEVSLP0? Perhaps you need to drop that part as well.
...
In the PCEngines schematic it's labelled as
The original commit appears to have the logic reversed in
amd_fch_gpio_get_direction. Also confirmed by observing the value of
"direction" in the sys tree.
Signed-off-by: Ed Wildgoose
---
drivers/gpio/gpio-amd-fch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Schematics show that the GPIO number is 55 (not 59). Trivial typo.
Signed-off-by: Ed Wildgoose
---
drivers/platform/x86/pcengines-apuv2.c | 2 +-
include/linux/platform_data/gpio/gpio-amd-fch.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86
From: Ed Maste
This header is part of the jsmn json parser, introduced in 867a979a83.
Correct the SPDX tag to indicate that it is under the MIT license.
Signed-off-by: Ed Maste
Acked-by: Andi Kleen
---
tools/perf/pmu-events/jsmn.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c38f21..9a0c0838 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2568,7 +2568,7 @@ F:
Documentation/devicetree/bindings/eeprom/at24.txt
F: drivers/misc/eeprom/at24.c
ATA OVER ETHERNET (AOE) DRIVER
-M: "Ed L. Cashin"
+M:
On Tue, Jan 22, 2019 at 6:29 PM Omar Sandoval wrote:
...
> Now entry is uninitialized here when we assign it to d->debugfs.
Thanks for noticing that.
> What is the proposed semantic of O_BENEATH with absolute paths -- I
> believe you don't have an openat(2) on FreeBSD (but please feel free to
> correct me)?
openat(2) is necessary for capability mode (since open(2) is not permitted),
but it turns out it was actually added to FreeBSD earlier than
On Tue, 9 Oct 2018 at 02:53, Aleksa Sarai wrote:
>
> +#ifndef O_BENEATH
> +#define O_BENEATH 0004000 /* *Not* the same as capsicum's
> O_BENEATH! */
> +#endif
I had originally followed up privately to Aleksa about this comment (to
suggest that it's outdated and should be removed), but t
On 02/19/2018 01:16 PM, Aishwarya Pant wrote:
Documentation has been compiled from git commit logs and descriptions in
Documentation/aoe/aoe.txt. This should be useful for scripting and
tracking changes in the ABI.
I don't see any problems with v3. Thank you.
--
Ed
> On Feb 17, 2018, at 9:37 AM, Julia Lawall wrote:
>
>
>
>> On Fri, 16 Feb 2018, Ed Cashin wrote:
>>
>>> On 02/16/2018 10:39 AM, Aishwarya Pant wrote:
>>> Documentation has been compiled from git commit logs and descriptions in
>>> D
:
+ (RO) The name of the network interface on the localhost through
+ which we are communicating with the remote AoE device.
I'd recommend changing that to, "network interfaces".
Thanks!
--
Ed
Good luck in your efforts, and thanks for your work on static analysis.
> On Jan 27, 2018, at 9:12 PM, Jia-Ju Bai wrote:
>
>
>
>> On 2018/1/28 1:48, Ed Cashin wrote:
>> If the tool cannot tell whether the protected state is manipulated by
>> *another* piece of
If the tool cannot tell whether the protected state is manipulated by *another*
piece of code called in atomic context, then it's insufficient.
> On Jan 26, 2018, at 4:37 AM, Jia-Ju Bai wrote:
>
> After checking all possible call chains to aoenet_rcv(),
> my tool finds that aoenet_rcv() is neve
On 01/17/2018 10:41 AM, Jens Axboe wrote:
...
Applied, thanks Arnd/Tina.
Thank you for the CC. Sorry for the lack of response in November.
--
Ed
On 13/01/18 11:59, Nuno Gonçalves wrote:
> Dear Ed,
>
> Thanks.
>
> Tested-by: Nuno Goncalves
>
> I just would like to report a aditional issue I find, which I am not
> sure if it is intend behaviour or not. If I set bauds 1152000,
> 150, 200, 250, 300,
reaches 67 without finding
an acceptable rate.
Fix this by setting the upper boundary of the loop appropriately to
avoid overflow.
Reported-by: Nuno Goncalves
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_dw.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a
On 11/01/18 18:03, Ed Blake wrote:
> On 11/01/18 17:55, Nuno Gonçalves wrote:
>> So, for me clk_round_rate() always returns 2400, and only the loop
>> variable i changes, so the search is monotonic, from the highest baud
>> to the lowest (increasing divider).
>>
On 11/01/18 17:55, Nuno Gonçalves wrote:
> So, for me clk_round_rate() always returns 2400, and only the loop
> variable i changes, so the search is monotonic, from the highest baud
> to the lowest (increasing divider).
>
> I am using a Allwiner H2+, with the serial port configuration from
> su
rs if the
> current one would already mean a rate below min_rate (that it, this is
> the closer).
It terminates the search as soon as the rate returned from
clk_round_rate() is lower than i * min_rate, which is too soon.
> So in fact we also break when the closer divider have been found.
&
AX + 1;
> + break;
> + }
> +
> + if (rate <= i * max_rate)
> break;
> }
> if (i <= UART_DIV_MAX) {
--
Ed
On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote:
> To recap: a dual-socket Xeon (E5 v4) server system had been running a
> bunch of KVM workloads just fine for over 6 weeks. Suddenly hard
> lockups occurred on cpu 13 in task_numa_migrate(), and cpu 0 in
> idle_balance(). That conditi
and
state machine used for synchronizing timer death. Using del_timer_sync()
will already do the right thing.
Looks OK to me, thanks.
--
Ed
problem with
an upstream kernel or any other, yet to my limited understanding of
the evidence it appears there may indeed be a real problem lurking in
there.
I will follow up with the grsec folks.
> On Thu, Nov 2, 2017 at 5:51 PM, Ed Swierk wrote:
>> Ping?
>>
>> On Wed,
Ping?
On Wed, Oct 25, 2017 at 9:35 PM, Ed Swierk wrote:
>
> Ping?
>
> On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote:
> >
> > Ping for Peter, Ingo and other sched maintainers:
> >
> > I'd appreciate any feedback on this hard lockup issue, whic
Ping?
On Mon, Oct 16, 2017 at 4:11 PM, Ed Swierk wrote:
>
> Ping for Peter, Ingo and other sched maintainers:
>
> I'd appreciate any feedback on this hard lockup issue, which occurred
> on a system running kernel 4.4.52-grsec.
>
> To recap: a dual-socket Xeon (E5
ardless of whether
it's the cpu task_numa_migrate() is running on.
Is this a plausible theory?
This is the only instance of a hard lockup among a number of identical
systems running the same kernel, so I'm not seeing an easy way to
reproduce this issue, but any suggestions would be welcome.
--Ed
Continuing the conversation with the voices in my head...
On Mon, Oct 9, 2017 at 10:45 PM, Ed Swierk wrote:
> Based on the addresses in the stack and registers, here's what I think
> happened.
>
> On cpu 13:
>
> - task_numa_fault() calls task_numa_migrate(), which select
On Fri, Oct 6, 2017 at 6:25 PM, Ed Swierk wrote:
> I'm trying to untangle a series of problems that suddenly occurred on
> a dual-socket Xeon server system that had been running a bunch of KVM
> workloads just fine for over 6 weeks (4.4.52-grsec kernel,
> Debian-derived userspac
I'm trying to untangle a series of problems that suddenly occurred on
a dual-socket Xeon server system that had been running a bunch of KVM
workloads just fine for over 6 weeks (4.4.52-grsec kernel,
Debian-derived userspace).
Here are the highlights, with timestamps in seconds:
[3851435] NMI watc
On 05/10/17 16:43, Ed Blake wrote:
> On 05/10/17 16:26, James Hogan wrote:
>> On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote:
>>> I'm not sure how this is supposed to work, but the issue seems to be
>>> that without this patch the parent irq isn't b
On 05/10/17 16:26, James Hogan wrote:
> On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote:
>>
>> I'm not sure how this is supposed to work, but the issue seems to be
>> that without this patch the parent irq isn't being masked. This is
>> causing the
On 04/10/17 15:03, James Hogan wrote:
> Hi Ed,
>
> On Mon, Oct 02, 2017 at 10:55:59AM +0100, Ed Blake wrote:
>> Pass on peripheral (RTC/IR/WD) irq masks and unmasks to the parent
>> interrupt controller, as well as setting / clearing the relevant bits
>> in the IRQ_ROU
Hi James,
Thanks for the review.
On 04/10/17 14:14, James Hogan wrote:
> Hi Ed,
>
> On Mon, Oct 02, 2017 at 10:55:58AM +0100, Ed Blake wrote:
>> Set all sys wake polarities to active high during initial setup. The
>> default is active low, which currently causes the '
This patch set contains fixes for various issues in the irq-imgpdc
driver.
Ed Blake (4):
irqchip: imgpdc: Avoid unbalanced irq wake disable
irqchip: imgpdc: Avoid immediate wake event during set_wake
irqchip: imgpdc: Set sys wake polarities to active high
irqchip: imgpdc: Pass on
disable the sys wake to flush the stale wake event
3) Set SYS_WAKE_CONFIG back to the original value
Signed-off-by: Ed Blake
---
drivers/irqchip/irq-imgpdc.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/irqchip/irq-imgpdc.c b/drivers/irqchip/irq-imgpdc.c
n the noirq phase) and because the peripheral interrupt is
disabled at that point, the core marks it as pending and masks it out.
This mask must be passed to the parent controller to be effective.
Signed-off-by: Ed Blake
---
drivers/irqchip/irq-imgpdc.c | 10 ++
1 file changed, 10 inser
t in other platforms the wake capability of the PDC is used, when
the parent isn't required to support wake and we need to avoid
unbalanced wake disables in this case.
Signed-off-by: Ed Blake
---
drivers/irqchip/irq-imgpdc.c | 62
1 file changed
Set all sys wake polarities to active high during initial setup. The
default is active low, which currently causes the 'flow_type' passed
into the set_type function to be effectively inverted.
Signed-off-by: Ed Blake
---
drivers/irqchip/irq-imgpdc.c | 10 --
1 file
Hi,
It works with 14-rc2, so I rebuilt 13.4 with the commit included again and
its behaving too :-/
Something strange must have happened in the original 13.4 build or my hw
was in a strange state (for two boots...)
Sorry for the noise.
Thanks
Ed Tomlinson
On Saturday, September 30, 2017
Hi
It looks to be this commit. 4.14-rc2 is building
Thanks
Ed
commit 2890decfd9969cac21067ca0c734fbccaf74d634
Author: Zhang, Jerry
Date: Fri Jul 14 18:20:17 2017 +0800
drm/amdgpu: read reg in each iterator of psp_wait_for loop
v2: fix the SOS loading failure for PSP v3.1
C2PMSG_81),
RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_81),
0, true);
-#endif
return ret;
}
---
Thanks
Ed
On Saturday, September 30, 2017 10:24:17 AM EDT, Greg KH wrote:
On Sat, Sep 30, 2017 at 09:49:28AM -0400, Ed Tomlinson wrote:
Hi,
This build causes very
dmesg.
Reverting the changes to:
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|3
drivers/gpu/drm/amd/amdgpu/psp_v3_1.c |2
fixes the issue here.
Thanks
Ed Tomlinson
On Thursday, September 28, 2017 4:33:02 AM EDT, Greg KH wrote:
I'm announcing the release o
On all supported platforms, the TS Reading (TSR) field in the
Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78
degrees C) are plausible, so don't mask out the topmost bit. And the
register itself is 16 bits wide, so use readw() rather than readl().
Signed-off-by: Ed S
configure it, and the dynamic shutdown state
should not prevent the driver from loading. The ETS flag itself
indicates whether the thermal sensor is enabled, so use it instead of
the TSDSS flag on all hardware platforms.
Signed-off-by: Ed Swierk
---
drivers/thermal/intel_pch_thermal.c | 4 ++--
1 file
On 2 May 2017 at 11:22, Dmitry Torokhov wrote:
> On May 1, 2017 6:14:54 PM PDT, Ed Bordin wrote:
>>On 2 May 2017 at 07:35, Greg Kroah-Hartman
>>wrote:
>>> 4.10-stable review patch. If anyone has any objections, please let
>>me know.
>>
>>Minor query (
On 2 May 2017 at 07:35, Greg Kroah-Hartman wrote:
> 4.10-stable review patch. If anyone has any objections, please let me know.
Minor query (that I probably should have raised earlier): is there any
data to support the comment that the DMI_PRODUCT_NAME "P65xRP" matches
all of "P650RS, 650RP6, Sa
Works for me. Thanks for the fix!
On 14 April 2017 at 08:51, Dmitry Torokhov wrote:
> Clevo P650RS and other similar devices require i8042 to be reset in order
> to detect Synaptics touchpad.
>
> Reported-by: Paweł Bylica
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=190301
> Signed-of
er, TRUN);
spin_lock_init(&lock);
- t.data = TRUN;
- t.function = discover_timer;
die = 0;
case TRUN:
spin_lock_irqsave(&lock, flags);
This change looks OK to me, thanks.
--
Ed
On Saturday, February 4, 2017 2:59:05 AM EST, Greg KH wrote:
On Fri, Feb 03, 2017 at 11:07:08PM -0500, Ed Tomlinson wrote:
Hi,
Any reports of 4.9.7 breaking X?
I run arch and keep it up to date. With todays updates and
4.9.7 built here
X will not start kde correctly. Reverting to 4.9.6
of stable git's 4.9.{6|7}.
Suggestions on what to look for or to try reverting (via git)
xorg-server is 1.19.1-1
xf86-video-amdgpu 1.2.0-2
mesa is 13.0.4-1
kernel is x86_64
Thanks
Ed
On Thursday, February 2, 2017 5:10:47 AM EST, Greg KH wrote:
I'm announcing the release of the 4.
ffic leak into another VM or a host application, and vice versa. And logging
those FilterInput messages for non-local traffic just looks like sloppy
security.
Is there some way to stop all local protocols from handling packets received on
an interface--a protocol-agnostic equivalent of
net.ipv6.conf.INTF.disable_ipv6? Would it be reasonable to implement one?
--Ed
Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_port.c | 12 ++--
include/linux/serial_8250.h | 4
include/linux
set_ldisc() function no longer tries to enable/disable IrDA SIR
mode if not supported by the hardware configuration.
Ed Blake (2):
serial: 8250: Expose set_ldisc function
serial: 8250_dw: Add support for IrDA SIR mode
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_dw.c
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline, if IrDA SIR mode is supported by the hardware
configuration.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_dw.c | 24
1 file changed, 24 insertions(+)
diff --git a
On 10/27/16 17:56, Andy Shevchenko wrote:
On Thu, 2016-10-27 at 17:38 +0100, Ed Blake wrote:
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline.
Thanks for the patch.
Consider that not all implementations based on 8250_dw support IRDA
feature. I
Add a set_ldisc function to enable/disable IrDA SIR mode according to
the new line discipline.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_dw.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250
Expose set_ldisc() function so that it can be overridden with a
platform specific implementation.
Signed-off-by: Ed Blake
---
drivers/tty/serial/8250/8250_core.c | 3 +++
drivers/tty/serial/8250/8250_port.c | 12 ++--
include/linux/serial_8250.h | 4
include/linux
t one interrupt (not even a separate one for tx, as far as I can
tell) pegged to CPU 0 (the default smp_affinity). I must be missing some
other major configuration tweak, perhaps specific to 10G.
Can you run a test on the EBB6800 with the interfaces in 10G mode?
--Ed
On 8/31/16 14:20, Aaro Koskinen wrote:
> On Wed, Aug 31, 2016 at 09:20:07AM -0700, Ed Swierk wrote:
>> Here's my workaround:
>
> [...]
>
>> -static int cvm_oct_poll(struct oct_rx_group *rx_group, int budget)
>> +static int cvm_oct_poll(int group, int budget)
&
counters increasing?
>
> With receive_group_order=4 you should see 16 IRQs.
I see the 16 IRQs, and the first one does increase. But packets don't make
it to the application.
--Ed
ed to set receive_group_order > 0. But any value between 1 and 4
seems to break rx altogether. When I ping another host I see both
request and response on the wire, and the interface counters increase,
but the response doesn't make it back to ping.
Is some other configuration needed to make use of multiple rx groups?
--Ed
bus: don't BUG() on user mode induced condition")
>> Reported-by: Richard Schütz
>> Cc:
>> Signed-off-by: Jan Beulich
>> Tested-by: Richard Schütz
>
> Reviewed-by: Juergen Gross
Confirmed that this patch fixes xenstore-read, xenstore-ls et al, on
stable kernel 4.4.17.
It should also go to 4.7, 4.6, 4.1, 3.18.
--Ed
On 08/17/2016 05:14 AM, Fam Zheng wrote:
...
Of course, the plan is to write patches on top. I'm not cleaning up anything
here because I'm concerned callers may double free (and I didn't look hard into
that).
Aside from Huck's concerns, the changes looked OK from aoe's perspective.
--
Ed
, as several of those areas
overlap each other, never mind devices.
> I don't know what kernel convention is to handle these sorts of
> defects?
>
> Is the use of the memmap kernel command line an appropriate work
> around?
It works for me, though I would like to know if there's another approach.
--Ed
On Wed, Jul 13, 2016 at 9:19 AM, Ed Swierk wrote:
> v9: Include command duration in existing error messages rather than
> logging an extra debug message. Rebase onto Jarkko's tree.
Incidentally, with Jarkko's tree the tpm_tis module refuses to
initialize (with or without force=1)
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 5e3c1b6..a
Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant
code. Return all errors to the caller rather than swallowing them
(e.g. when tpm_transmit_cmd() returns nonzero).
Signed-off-by: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 74 +++-
1 file
: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 148 ++-
drivers/char/tpm/tpm_tis_core.c | 32 +++--
include/linux/tpm.h | 3 +-
3 files changed, 94 insertions(+), 89 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers
chip-specific override of command durations as well as protocol
timeouts
- overrides ST19NP18 TPM command duration to avoid lockups
Ed Swierk (5):
tpm_tis: Improve reporting of IO errors
tpm: Add optional logging of TPM command durations
tpm: Clean up reading of timeout and duration capabil
to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).
Signed-off-b
Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
On 06/29/2016 09:59 PM, Fam Zheng wrote:
It is documented that KOBJ_ADD should be generated after the object's
attributes and children are ready. We can achieve this with the new
disk_gen_uevents interface.
Looks like an improvement, thanks!
--
Ed
Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant
code. Return all errors to the caller rather than swallowing them
(e.g. when tpm_transmit_cmd() returns nonzero).
Signed-off-by: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 74 +++-
1 file
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..c
: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 143 +--
drivers/char/tpm/tpm_tis.c | 35 +++---
include/linux/tpm.h | 3 +-
3 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers
both timeouts and
durations via a single callback.
This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
timeouts
- overrides ST19NP18 TPM command duration to avoid lockups
Ed
to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).
Signed-off-b
Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
On Mon, Jun 20, 2016 at 6:54 PM, Ed Swierk wrote:
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -461,9 +461,19 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id,
> cap_t *cap,
> tpm_cmd.params.getcap_in.subcap_size
Call tpm_getcap() from tpm_get_timeouts() to eliminate redundant
code. Return all errors to the caller rather than swallowing them
(e.g. when tpm_transmit_cmd() returns nonzero).
Signed-off-by: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 74 +++-
1 file
Mysterious TPM behavior can be difficult to track down through all the
layers of software. Add error messages for conditions that should
never happen. Also include the manufacturer ID along with other chip
data printed during init.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
single callback.
This series
- improves TPM command error reporting
- adds optional logging of TPM command durations
- allows chip-specific override of command durations as well as protocol
timeouts
- overrides ST19NP18 TPM command duration to avoid lockups
Ed Swierk (5):
tpm_tis: Improve
: Ed Swierk
---
drivers/char/tpm/tpm-interface.c | 143 +--
drivers/char/tpm/tpm_tis.c | 35 +++---
include/linux/tpm.h | 3 +-
3 files changed, 88 insertions(+), 93 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers
to know whether any commands are immune to being blocked by
this process. So it seems safest to ignore the chip's reported command
durations, and use a value much higher than any observed duration,
like 180 sec (which is the duration this chip reports for "long"
commands).
Signed-off-b
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..c
el configured with DYNAMIC_DEBUG=y.
Signed-off-by: Ed Swierk
Reviewed-by: Jarkko Sakkinen
---
drivers/char/tpm/tpm-interface.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index c50637d..c
1 - 100 of 599 matches
Mail list logo
