I've switched employer a long time ago and the mentioned email address no
longer exists. Use my personal address to prevent the issue in the future.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-igep.dtsi| 2 +-
arch/arm/boot/dts/omap3-igep0020-common.dts
Hello Geert,
On 8/6/19 9:30 AM, Geert Uytterhoeven wrote:
> On Tue, Aug 6, 2019 at 12:48 AM Javier Martinez Canillas
> wrote:
>> On 8/1/19 4:17 AM, Masahiro Yamada wrote:
>> So I think that we should either:
>>
>> a) take Kieran's patch or b) remove the i
Hello Geert,
On 8/6/19 9:22 AM, Geert Uytterhoeven wrote:
> Hi Javier,
>
> On Tue, Aug 6, 2019 at 12:25 AM Javier Martinez Canillas
> wrote:
>> On 7/31/19 9:44 PM, Wolfram Sang wrote:
>>> Hi Javier,
>>>> The other option is to remove i2c_of_match_d
most drivers will have
>> multiple tables. With the minor change that the I2C device id table is
>> not required anymore by the core, but it will be just very useful to
>> have? Or?
>>
>>> If the former is the correct way to solve this then the patch looks go
e just very useful to
> have? Or?
>
Yes, it won't be needed anymore if you are only instantiating all your devices
from your firmware interface (e.g: OF, ACPI).
>> If the former is the correct way to solve this then the patch looks good to
>> me.
>>
>> Reviewed-by:
e would be used both for
auto-loading and also to match the device when it doesn't have an of_node.
If the former is the correct way to solve this then the patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
: Javier Martinez Canillas
---
drivers/staging/media/imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/imx/Kconfig
b/drivers/staging/media/imx/Kconfig
index 36b276ea2ec..5045e24c470 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
_probe_msg;
> + if (!*p) {
> + *p = kmalloc(size, GFP_KERNEL);
> + if (!*p)
> + goto end;
> + }
> + n = snprintf(*p, size, "%s %s: ", dev_driver_string(dev),
> dev_name(dev));
> + if (n < size)
> + vsnprintf(*p + n, size - n, fmt, args);
I wonder if the vsnprintf() return value should be checked and print a warning
if the message was truncated. Probably 128 is enough for most error messages?
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
rr(dev, err, ...);
>
> Signed-off-by: Andrzej Hajda
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Hi Tianshu and Sakari,
On 9/4/18 1:30 PM, Javier Martinez Canillas wrote:
> Hello,
>
> This series allows the ipu3-cio2 driver to properly expose a subset of the
> media graph even if some drivers for the pending subdevices fail to probe.
>
> Currently the driver exposes a no
.bound
callback. The .complete callback is just removed since is empy after that.
Best regards,
Javier
Javier Martinez Canillas (2):
[media] v4l: allow to register dev nodes for individual v4l2 subdevs
media: intel-ipu3: create pad links and register subdev nodes at bound
time
drivers/media
: 1.2 TPM (device-id 0x0, rev-id 78)
tpm tpm0: TPM is disabled/deactivated (0x6)
ima: No TPM chip found, activating TPM-bypass! (rc=6)
Reported-by: Hans de Goede
Signed-off-by: Javier Martinez Canillas
---
drivers/char/tpm/tpm-interface.c | 3 ++-
1 file changed, 2 insertions(+), 1 delet
Hi Krzysztof,
On Wed, Jul 25, 2018 at 5:53 PM, Krzysztof Kozlowski wrote:
> In case of Device Tree platforms, even though the Samsung PMIC sec
> device is instantiated from DT, the driver is still matched through I2C
> module alias. That is because I2C core always reports an I2C module
> alias i
easier to debug.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
Reviewed-by: Mark Brown
---
Changes since RFC v1:
- Remove unneeded ret variable from deferred_devs_show()
Changes since RFC v2:
- Use DEFINE_SHOW_ATTRIBUTE() macro.
- Don't propagate debugfs_create
On 07/08/2018 03:22 PM, Greg Kroah-Hartman wrote:
> On Sun, Jul 08, 2018 at 03:21:07PM +0200, Greg Kroah-Hartman wrote:
>> On Sun, Jul 08, 2018 at 02:32:56AM +0200, Javier Martinez Canillas wrote:
>>> With Device Trees (DT), the dependencies of the devices are defined in th
easier to debug.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
Reviewed-by: Mark Brown
---
Changes since RFC v1:
- Remove unneeded ret variable from deferred_devs_show()
Changes since RFC v2:
- Use DEFINE_SHOW_ATTRIBUTE() macro.
- Don't propagate debugfs_create
Hi Greg,
On 07/07/2018 05:59 PM, Greg Kroah-Hartman wrote:
> On Thu, Jun 28, 2018 at 12:06:56AM +0200, Javier Martinez Canillas wrote:
>> With Device Trees (DT), the dependencies of the devices are defined in the
>> DT, then the drivers parse that information to lookup the n
Hi Andy,
On 07/04/2018 06:11 PM, Andy Shevchenko wrote:
> On Wed, Jul 4, 2018 at 4:44 PM, Javier Martinez Canillas
> wrote:
>> On 07/04/2018 03:24 PM, Nikolaus Voss wrote:
>
>>> I hope you're still not annoyed...
>> Don't worry for that, it's very
On 07/04/2018 03:24 PM, Nikolaus Voss wrote:
> On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
>> On Wed, Jul 4, 2018 at 2:31 PM, Nikolaus Voss
>> wrote:
>>> On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
>>>>
>>>> On Wed, J
On Wed, Jul 4, 2018 at 2:31 PM, Nikolaus Voss
wrote:
> On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
>>
>> On Wed, Jul 4, 2018 at 1:46 PM, Nikolaus Voss
>> wrote:
>>
>
> [snip]
>
>> But this discussion isn't really related to your patch. I th
On Wed, Jul 4, 2018 at 1:46 PM, Nikolaus Voss
wrote:
[snip]
>>>
>>> Ok, in my opinion it is an elegant way of not bloating the driver when no
>>> explicit handling (e.g. reading DT properties) is needed. Just adding an
>>> of_device_id doesn't change any driver functionality then but only maps
>
On Wed, Jul 4, 2018 at 1:26 PM, Javier Martinez Canillas
wrote:
[snip]
>> Ok, in my opinion it is an elegant way of not bloating the driver when no
>> explicit handling (e.g. reading DT properties) is needed. Just adding an
>> of_device_id doesn't change any driver func
Hi Nikolaus,
On Wed, Jul 4, 2018 at 1:15 PM, Nikolaus Voss
wrote:
> On Wed, 4 Jul 2018, Javier Martinez Canillas wrote:
[snip]
>> I think Nikolaus is correct, assuming that the driver can be used on
>> legacy
>> platforms that register the I2C devices using board files /
d the I2C core now reports of:N*T*Cfoo*
solving (2). So the I2C device table isn't required anymore for {OF,ACPI}-only
drivers, but it's still required for drivers that support legacy board files
that calls i2c_register_board_info() directly. Same for the old .probe callback,
it's
easier to debug.
Signed-off-by: Javier Martinez Canillas
---
Andy, I didn't carry your Reviewed-by tag because it wasn't clear to me
if you had agreed with the patch or not from your last email.
Changes since RFC v1:
- Remove unneeded ret variable from deferred_devs_show()
Changes si
[adding Peter Robinson - Fedora IoT Architect to cc list]
On 06/20/2018 10:46 AM, Javier Martinez Canillas wrote:
> On 06/20/2018 12:51 AM, Greg Kroah-Hartman wrote:
>
> [snip]
>
>>> @@ -233,6 +252,9 @@ void device_unblock_probing(void)
>>> */
>>>
Hi Andy,
On 06/20/2018 01:43 AM, Andy Shevchenko wrote:
> On Wed, Jun 20, 2018 at 1:51 AM, Greg Kroah-Hartman
> wrote:
>> On Tue, Jun 19, 2018 at 10:59:14PM +0200, Javier Martinez Canillas wrote:
>>> For debugging purposes it may be useful to know what are the devices who
atch attempts to tell what was left (if any)
in the queue after the last driver was registered.
Second, is only enabled until late_initcall so it will only print the probe
deferral for built-in drivers and not for modules. This patch registers the
debugfs entry after the probe debugging has been disabled.
> thanks,
>
> greg k-h
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
For debugging purposes it may be useful to know what are the devices whose
probe function was deferred. Add a debugfs entry showing that information.
$ cat /sys/kernel/debug/deferred_devices
4807.i2c:twl@48:bci
musb-hdrc.0.auto
omapdrm.0
Signed-off-by: Javier Martinez Canillas
Hello Andy,
Thanks a lot for your feedback.
On 06/19/2018 09:55 PM, Andy Shevchenko wrote:
> On Tue, Jun 19, 2018 at 10:53 PM, Andy Shevchenko
> wrote:
>> On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
>> wrote:
>>> For debugging purposes it may be
For debugging purposes it may be useful to know what are the devices whose
probe function was deferred. Add a debugfs entry showing that information.
$ cat /sys/kernel/debug/deferred_devices
4807.i2c:twl@48:bci
musb-hdrc.0.auto
omapdrm.0
Signed-off-by: Javier Martinez Canillas
For debugging purposes it may be useful to know what are the devices whose
probe function was deferred. Add a debugfs entry showing that information.
$ cat /sys/kernel/debug/deferred_devices
4807.i2c:twl@48:bci
musb-hdrc.0.auto
omapdrm.0
Signed-off-by: Javier Martinez Canillas
same kernel source tree as the kernel image.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Krzysztof Kozlowski
>
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
Hi Dmitry,
On 05/01/2018 10:57 PM, Dmitry Torokhov wrote:
> From: Javier Martinez Canillas
>
> Commit af503716ac14 ("i2c: core: report OF style module alias for devices
> registered via OF") fixed how the I2C core reports the module alias when
> devices are regist
id mode. Let's do that.
>
> Suggested-by: Javier Martinez Canillas
> Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and
> suspend modes")
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - Use Javier's suggestion of defin
On Tue, Apr 17, 2018 at 7:22 PM, Mark Brown wrote:
> On Tue, Apr 17, 2018 at 10:12:04AM -0700, Douglas Anderson wrote:
>> In of_get_regulation_constraints() it can clearly be seen that the
>> return value of of_map_mode() is assigned to a signed integer. This
>> is important because the first thi
The new-kernel-pkg script is only present when grubby is installed, but it
may not always be the case. So if the script isn't present, attempt to use
the kernel-install script as a fallback instead.
Signed-off-by: Javier Martinez Canillas
---
scripts/package/mkspec | 2 ++
1 file chang
style module alias for devices
registered via OF")
Reported-by: Enric Balletbo i Serra
Signed-off-by: Javier Martinez Canillas
---
Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 6 +-
drivers/input/touchscreen/atmel_mxt_ts.c | 4
2 files changed, 9 inserti
ddr;
> size_t log_size, last_entry_size;
> efi_bool_t truncated;
> - void *tcg2_protocol;
> + void *tcg2_protocol = NULL;
>
> status = efi_call_early(locate_protocol, &tcg2_guid, NULL,
> &tcg2_protocol);
>
Looks go
on of shim are you using? And also would
be good to know if it's the same shim version that Jeremy is using.
> Regards,
>
> Hans
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
gt;> defined in TCG 1.36 spec.
>
Probably a typo, since the latest TCG spec version is the 1.38 [0].
> Where can we get that specification? I don't have that new
> version and couldn't find it from the public internet.
>
> /Jarkko
>
[0]: https://trustedcomputi
ugh right away.
>
> Thanks again!
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Hello Wolfram,
On Sun, Jan 7, 2018 at 2:17 PM, Javier Martinez Canillas
wrote:
>
> On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas
> wrote:
>> The buses should honor the firmware interface used to register the device,
>> but the I2C core reports a MODALIAS of t
On Mon, Mar 5, 2018 at 11:42 AM, Mark Brown wrote:
> On Sat, Mar 03, 2018 at 10:29:00PM +, Sasha Levin wrote:
>> From: Javier Martinez Canillas
>>
>> [ Upstream commit 9ba2da5f5d18daaa365ab5426b05e16f1d114786 ]
>>
>> The driver doesn't have a struct of
On 02/20/2018 12:41 PM, Jarkko Sakkinen wrote:
> Replaced kmalloc() + memcpy() in tpm_eventlog_efi.c and
> tpm_eventlog_of.c.
>
> Signed-off-by: Jarkko Sakkinen
> ---
Looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
So
Hi Wolfram,
On Tue, Jan 16, 2018 at 3:11 PM, Javier Martinez Canillas
wrote:
> Hello Dmitry,
>
> On 01/16/2018 02:55 PM, Dmitry Mastykin wrote:
>> On Sun, 3 Dec 2017 22:40:50 +0100, Javier Martinez Canillas
>> wrote:
>>
>>> The buses should honor the fir
Hello Dmitry,
On 01/16/2018 02:55 PM, Dmitry Mastykin wrote:
> On Sun, 3 Dec 2017 22:40:50 +0100, Javier Martinez Canillas
> wrote:
>
>> The buses should honor the firmware interface used to register the device,
>> but the I2C core reports a MODALIAS of the form i2c: ev
On Sun, Jan 14, 2018 at 11:51 AM, Jonathan Cameron wrote:
> On Wed, 10 Jan 2018 12:01:07 +0100
> Javier Martinez Canillas wrote:
>
>> Hello Jonathan,
>>
>> On Mon, Jan 1, 2018 at 10:53 AM, Jonathan Cameron wrote:
>>
>> [snip]
>>
>> >
&
Hello Dmitry,
On Wed, Jan 10, 2018 at 4:51 AM, Dmitry Mastykin wrote:
> Hello Johnatan,
> May be the issue is the same as Javier Martinez Canillas wrote:
> "What is not correct is to require OF-only drivers to have an I2C
> device ID table just as a workaround to have the
Hello Jonathan,
On Mon, Jan 1, 2018 at 10:53 AM, Jonathan Cameron wrote:
[snip]
>
> I may well be missing some subtle detail of course having spent only a few
> minute looking at this!
>
Your understanding is correct. This change has nothing to do with
module autoloading.
The .probe_new callb
Hello Wolfram,
On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas
wrote:
> The buses should honor the firmware interface used to register the device,
> but the I2C core reports a MODALIAS of the form i2c: even for I2C
> devices registered via OF.
>
> This means that user-s
This flag is only used to warn if CLKRUN_EN wasn't disabled on Braswell
systems, but the only way this can happen is if the code is not correct.
So it's an unnecessary check that just makes the code harder to read.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martinez Canillas
/patch/10119417/
[3]: git.infradead.org/users/jjs/linux-tpmdd.git
Best regards,
Javier
Javier Martinez Canillas (3):
tpm: delete the TPM_TIS_CLK_ENABLE flag
tpm: follow coding style for variable declaration in
tpm_tis_core_init()
tpm: only attempt to disable the LPC CLKRUN if is already en
The coding style says "use just one data declaration per line (no commas
for multiple data declarations)" so follow this convention.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
---
driver
reak other devices that are attached to the LPC bus but don't have
support for the CLKRUN protocol.
Fixes: 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: Javier Martinez Canillas
Tested-by: James Ettle
Tested-by: Jeffery Miller
Reviewed-by: Jarkko Sa
The data field for the entries in the device tables are set but not used.
Signed-off-by: Javier Martinez Canillas
---
Changes in v2:
- Also empty spaces (suggested by Jason Gunthorpe).
drivers/char/tpm/tpm_i2c_infineon.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions
The data field for the entries in the device tables are set but not used.
Signed-off-by: Javier Martinez Canillas
---
drivers/char/tpm/tpm_i2c_infineon.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm_i2c_infineon.c
b/drivers/char/tpm
Hello Peter,
On Fri, Dec 22, 2017 at 12:07 AM, Peter Rosin wrote:
> On 2017-12-21 21:27, Javier Martinez Canillas wrote:
>> Hello Peter,
>>
>> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin wrote:
>>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>>>
Hello Peter,
On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin wrote:
> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>> Current description of the compatible property for at24 is quite vague.
>>
>> Specify an exact list of accepted compatibles and document the - now
>> deprecated - strings which we
Hello Jeffery,
On 12/21/2017 06:25 PM, Jeffery Miller wrote:
> On Thu, Dec 21, 2017 at 6:46 AM, Javier Martinez Canillas
> wrote:
>>
>> I meant linux-tpmdd + the 4 patches in this series.
>
> Javier,
> I applied the four patches to the linux-tpmdd master 46dd3b2
On 12/21/2017 04:39 PM, Shaikh, Azhar wrote:
> HI Javier,
>
>
>> -Original Message-
>> From: linux-integrity-ow...@vger.kernel.org [mailto:linux-integrity-
>> ow...@vger.kernel.org] On Behalf Of Javier Martinez Canillas
>> Sent: Thursday, December 21,
On Thu, Dec 21, 2017 at 2:28 PM, Bartosz Golaszewski wrote:
> 2017-12-21 14:19 GMT+01:00 Javier Martinez Canillas :
>> Hello Bartosz,
>>
>> Nice patch.
>>
>> On Thu, Dec 21, 2017 at 2:08 PM, Bartosz Golaszewski wrote:
>>> Current description of the c
On Thu, Dec 21, 2017 at 2:08 PM, Bartosz Golaszewski wrote:
> Add all supported at24 variants to the of_match table.
>
> Signed-off-by: Bartosz Golaszewski
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
of allowed compatible strings.
>
> Signed-off-by: Bartosz Golaszewski
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
On Thu, Dec 21, 2017 at 2:08 PM, Bartosz Golaszewski wrote:
> Make formatting and style consistent for the entire document.
>
> This patch doesn't change the content of the binding.
>
> Signed-off-by: Bartosz Golaszewski
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
On Thu, Dec 21, 2017 at 2:08 PM, Bartosz Golaszewski wrote:
> "atmel,spd" is reported by checkpatch as undocumented in the device
> tree bindings. Add it to the list of supported compatible strings.
>
> Signed-off-by: Bartosz Golaszewski
> ---
Reviewed-by: Javier
t;catalyst,24c32",
> +"microchip,24c128",
> +"ramtron,24c64",
> +"renesas,r1ex24002",
> +"at,24c08",
> +"at24,24c08"
> +
> + will still work, but are now deprecated.
> +
> + Also: matching by device type alone - while still supported due to
> + implementation details in I2C core - is deprecated as well.
>
I don't think that's correct to mention Linux specific implementation
details in a Device Tree binding. It's supposed to be OS independent
and in theory the same DT binding could be used in other OS /
bootloaders.
With that last paragraph removed, feel free to add:
Reviewed-by: Javier Martinez Canillas
>- reg : the I2C address of the EEPROM
>
Best regards,
Javier
Hello Azhar,
On 12/20/2017 08:15 PM, Shaikh, Azhar wrote:
>
>
>> -Original Message-
>> From: Jason Gunthorpe [mailto:j...@ziepe.ca]
>> Sent: Wednesday, December 20, 2017 10:55 AM
>> To: Javier Martinez Canillas
>> Cc: linux-kernel@vger.kernel
h the previous
patch shared in the other thread and the changes are quite simple so I think
it's OK.
Again thanks a lot for your help and merry Christmas / happy new year.
> Thanks,
> James.
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
On 12/20/2017 06:44 PM, Jason Gunthorpe wrote:
> On Wed, Dec 20, 2017 at 05:45:16PM +0100, Javier Martinez Canillas wrote:
>
>> CHP51 says "LPC Clock Control Using the LPC_CLKRUN# May Not Behave As
>> Expected"
>> and that the implication is that "The SoC m
PI used by in lot of places in the kernel, but it's not
the case here.
But I don't have a strong opinion either, it was Jarkko who questioned
the value of the flag so I can drop this patch too if you disagree with
the change. I'm mostly interested in PATCH 4/4 that's the actual fix
On 12/20/2017 07:08 PM, Jason Gunthorpe wrote:
> On Wed, Dec 20, 2017 at 12:35:35PM +0100, Javier Martinez Canillas wrote:
>> The driver maps the I/O memory address to control the LPC bus CLKRUN_EN,
>> but on the error path the memory is accessed by the .clk_enable handler
&g
Hello Azhar,
On 12/20/2017 04:41 PM, Shaikh, Azhar wrote:
>
>
>> -Original Message-----
>> From: Javier Martinez Canillas [mailto:javi...@redhat.com]
>> Sent: Wednesday, December 20, 2017 7:31 AM
>> To: Shaikh, Azhar ;
>> alexander.stef...@infineon.com
n.com/dgdl/Infineon-TPM+SLB+9665-DS-v10_15-EN.pdf?fileId=5546d4625185e0e201518b83d9273d87
> section 2.3 Power Management). So as Alexander mentioned CLKRUN is disabled
> while TPM transactions are in progress.
>
Yes I do understand that. Please read my answer to Alexander's ema
Hello Alexander,
On 12/20/2017 03:07 PM, alexander.stef...@infineon.com wrote:
>> Hi Hans,
>>
>> Thanks a lot for your feedback.
>>
>> On 12/20/2017 12:43 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 20-12-17 12:35, Javier Martinez Canill
Hi Hans,
Thanks a lot for your feedback.
On 12/20/2017 12:43 PM, Hans de Goede wrote:
> Hi,
>
> On 20-12-17 12:35, Javier Martinez Canillas wrote:
>> Hello,
>>
>> Commit 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
>> added logic i
reak other devices that are attached to the LPC bus but don't have
support for the CLKRUN protocol.
Fixes: 5e572cab92f0 ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: Javier Martinez Canillas
Tested-by: James Ettle
---
This patch fixes the bug reported for the
resources in the inverse
order that were acquired to prevent issues like these.
Signed-off-by: Javier Martinez Canillas
---
drivers/char/tpm/tpm_tis_core.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
The coding style says "use just one data declaration per line (no commas
for multiple data declarations)" so follow this convention.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martinez Canillas
---
drivers/char/tpm/tpm_tis_core.c | 4 +++-
1 file changed, 3 insertions(+),
This flag is only used to warn if CLKRUN_EN wasn't disabled on Braswell
systems, but the only way this can happen is if the code is not correct.
So it's an unnecessary check that just makes the code harder to read.
Suggested-by: Jarkko Sakkinen
Signed-off-by: Javier Martine
gzilla.redhat.com/show_bug.cgi?id=1498987
[1]: https://bugzilla.kernel.org/show_bug.cgi?id=197287
[2]: https://patchwork.kernel.org/patch/10119417/
[3]: git.infradead.org/users/jjs/linux-tpmdd.git
Best regards,
Javier
Javier Martinez Canillas (4):
tpm: fix access attempt to an already un
On 12/19/2017 02:10 PM, Jarkko Sakkinen wrote:
> On Tue, Dec 19, 2017 at 12:34:46AM +0100, Javier Martinez Canillas wrote:
>> Hello Jason,
>>
>> On 12/18/2017 09:19 PM, Jason Gunthorpe wrote:
>>> On Mon, Dec 18, 2017 at 07:34:29PM +, Shaikh, Azhar wrote:
>>&
Hello Jarkko,
On 12/19/2017 01:59 PM, Jarkko Sakkinen wrote:
> James, Javier, thank you for sorting this out. I'll just have couple of
> minor comments on the patch.
>
> On Mon, Dec 18, 2017 at 01:22:28PM +0100, Javier Martinez Canillas wrote:
>> +u32 vendor, intfca
ge is that TPM devices with CLKRUN protocol support could
make use of the CLKRUN power management feature and only systems with
a TPM that doesn't support the CLKRUN protocol will disable it.
The disadvantage is that the struct dmi_system_id array to match will
have to be maintained a
Hello Azhar,
On 12/18/2017 08:34 PM, Shaikh, Azhar wrote:
>
>
>> -Original Message-----
>> From: Javier Martinez Canillas [mailto:javi...@redhat.com]
>> Sent: Monday, December 18, 2017 11:30 AM
>> To: Jason Gunthorpe
>> Cc: Jarkko Sakkinen ; James Ettle
ume - PASS
>
> Let me know if you want any further tests.
>
Great, thanks a lot for testing!
> Many thanks,
> James.
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Hello Jason,
Thanks a lot for your feedback.
On 12/18/2017 06:55 PM, Jason Gunthorpe wrote:
> On Mon, Dec 18, 2017 at 01:29:01PM +0100, Javier Martinez Canillas wrote:
>> On 12/18/2017 01:22 PM, Javier Martinez Canillas wrote:
>>
>> [snip]
>>
>>>
>&g
On 12/18/2017 01:22 PM, Javier Martinez Canillas wrote:
[snip]
>
> James,
>
> Can you please test the following (untested) patch on top of the other two
> mentioned patches to see if it makes a difference for you?
>
I should had tried to at least compile the patch :)
U
17 at 08:08:58PM +0100, Javier Martinez Canillas wrote:
>>>>
>>>>> Although probably reverting the offending commits is the right thing to do
>>>>> until a proper solution is proposed.
>>>>
>>>> Yes, if a fix is not forthcoming s
On 12/16/2017 09:59 PM, Javier Martinez Canillas wrote:
> On 12/16/2017 06:01 PM, Jarkko Sakkinen wrote:
>> On Fri, 2017-12-15 at 10:38 -0700, Jason Gunthorpe wrote:
>>> On Fri, Dec 15, 2017 at 04:56:30PM +0200, Jarkko Sakkinen wrote:
>>>> On Thu, Dec 14, 2017 at 12:
Hello Jarkko,
On 12/17/2017 05:27 PM, Jarkko Sakkinen wrote:
[snip]
>
> Thank you for the lessons :-)
>
You are welcome :)
> Reviewed-by: Jarkko Sakkinen
>
Thanks!
> /Jarkko
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
ikely to come this weekend. So we may end
with Braswell system being non-function for 3 kernel releases...
As mentioned I can write a patch to hide this behavior under a Kconfig option
that's disabled by default (and maybe depend on BROKEN) or a module parameter
until a proper solution is found.
> /Jarkko
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
On 12/15/2017 01:03 PM, Jarkko Sakkinen wrote:
> Hi
>
> Some basic questions about DT, which I'm not expert of.
>
> On Mon, Dec 04, 2017 at 06:39:16PM +0100, Javier Martinez Canillas wrote:
>> The commit 21dc02eab989 ("tpm/tpm_i2c_infineon.c: Add OF att
g the TPM device.
Although probably reverting the offending commits is the right thing to do
until a proper solution is proposed.
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Hello Mauro,
On 12/14/2017 06:02 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 6 Dec 2017 01:33:05 +0100
> Javier Martinez Canillas escreveu:
>
>> Commit f7b4b54e6364 ("[media] tvp5150: add HW input connectors support")
>> added input signals support for the tvp5
>
I already suggested the same [0], but James said that made no difference [1].
> /Jarkko
>
[0]: https://lkml.org/lkml/2017/12/12/268
[1]: https://lkml.org/lkml/2017/12/12/1127
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Hello Jason,
On 12/12/2017 07:57 PM, Jason Gunthorpe wrote:
> On Tue, Dec 12, 2017 at 12:38:00PM +0100, Javier Martinez Canillas wrote:
>
>> I'm not familiar with LPC so please let me know if my assumptions are wrong,
>> but I find suspicious that a driver for a single dev
mand.
Not sure if that will make things better or worse for you, but it would be
good to try in case it makes a difference.
[0]:
http://git.infradead.org/users/jjs/linux-tpmdd.git/commit/667dcc75be864ff4c17cf58891853b7393bba3e2
[1]:
http://git.infradead.org/users/jjs/linux-tpmdd.git/commit/db
>>> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default i
1 - 100 of 2530 matches
Mail list logo
