[PATCH] ARM: dts: omap3-igep: Change email address in copyright notice

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.dtsi | 2

Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables

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 i2c_of

Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables

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

Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables

ill 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 good to >>

Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables

ful 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: Javier Martine

Re: [PATCH RFC] modpost: Support I2C Aliases from OF tables

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

[PATCH] media: staging/imx: Allow driver to build if COMPILE_TEST is enabled

-by: 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

Re: [PATCH 3/3] drivers: use probe_err function in obvious cases

Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat

Re: [PATCH 3/3] drivers: use probe_err function in obvious cases

Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat

Re: [PATCH 2/3] driver core: add deferring probe reason to devices_deferred property

RNEL); > + 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

Re: [PATCH 2/3] driver core: add deferring probe reason to devices_deferred property

RNEL); > + 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

Re: [PATCH 1/3] driver core: add probe_err log helper

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

Re: [PATCH 1/3] driver core: add probe_err log helper

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

Re: [PATCH 0/2] media: intel-ipu3: allow the media graph to be used even if a subdev fails

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

Re: [PATCH 0/2] media: intel-ipu3: allow the media graph to be used even if a subdev fails

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

[PATCH 0/2] media: intel-ipu3: allow the media graph to be used even if a subdev fails

to the .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

[PATCH 0/2] media: intel-ipu3: allow the media graph to be used even if a subdev fails

to the .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

[PATCH] tpm: suppress transmit cmd error logs when TPM 1.2 is disabled/deactivated

(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 deletion(-)

[PATCH] tpm: suppress transmit cmd error logs when TPM 1.2 is disabled/deactivated

(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 deletion(-)

Re: [PATCH] mfd: sec: Export OF module alias table

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

Re: [PATCH] mfd: sec: Export OF module alias table

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

[PATCH v4] driver core: add a debugfs entry to show deferred devices

it 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_file

[PATCH v4] driver core: add a debugfs entry to show deferred devices

it 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_file

Re: [PATCH v3] driver core: add a debugfs entry to show deferred devices

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 def

Re: [PATCH v3] driver core: add a debugfs entry to show deferred devices

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 def

[PATCH v3] driver core: add a debugfs entry to show deferred devices

it 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_file

[PATCH v3] driver core: add a debugfs entry to show deferred devices

it 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_file

Re: [PATCH v2] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH v2] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 hard to get my

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 hard to get my

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 think i

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 think i

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 functiona

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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 functiona

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

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

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

s 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 needed if struct i2c_device_id .driver_d

Re: [PATCH v2 2/2] IIO: st_accel_i2c.c: Use probe_new() instead of probe()

s 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 needed if struct i2c_device_id .driver_d

[PATCH v2] driver core: add a debugfs entry to show deferred devices

it 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 since RFC v2

[PATCH v2] driver core: add a debugfs entry to show deferred devices

it 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 since RFC v2

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

[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) >>> */ >>>

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

[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) >>> */ >>>

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH] driver core: add a debugfs entry to show deferred devices

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

[PATCH] driver core: add a debugfs entry to show deferred devices

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

[PATCH] driver core: add a debugfs entry to show deferred devices

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

Re: [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices

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

Re: [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices

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

[RFC PATCH v2] driver core: add a debugfs entry to show deferred devices

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

[RFC PATCH v2] driver core: add a debugfs entry to show deferred devices

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

[RFC PATCH] driver core: add a debugfs entry to show deferred devices

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

[RFC PATCH] driver core: add a debugfs entry to show deferred devices

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

Re: [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable

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

Re: [PATCH v2] Documentation: dt-bindings: Explicitly mark Samsung Exynos SoC bindings as unstable

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

Re: [PATCH v2] Input: atmel_mxt_ts - add missing compatible strings to OF device table

Hi Dmitry, On 05/01/2018 10:57 PM, Dmitry Torokhov wrote: > From: Javier Martinez Canillas <javi...@redhat.com> > > Commit af503716ac14 ("i2c: core: report OF style module alias for devices > registered via OF") fixed how the I2C core reports the module alias when

Re: [PATCH v2] Input: atmel_mxt_ts - add missing compatible strings to OF device table

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 > d

Re: [PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

t; bits set) as an invalid mode. Let's do that. > > Suggested-by: Javier Martinez Canillas <jav...@dowhile0.org> > Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and > suspend modes") > Signed-off-by: Douglas Anderson <diand...@chromium.org>

Re: [PATCH v2] regulator: Don't return or expect -errno from of_map_mode()

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 defining 0x0 as inva

Re: [PATCH] regulator: Fix return type of of_map_mode()

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

Re: [PATCH] regulator: Fix return type of of_map_mode()

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

[PATCH] kbuild: rpm-pkg: use kernel-install as a fallback for new-kernel-pkg

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 <javi...@redhat.com> --- scripts/package/mksp

[PATCH] kbuild: rpm-pkg: use kernel-install as a fallback for new-kernel-pkg

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 changed, 2

[PATCH] Input: atmel_mxt_ts - add missing compatible strings to OF device table

module alias for devices registered via OF") Reported-by: Enric Balletbo i Serra <enric.balle...@collabora.com> Signed-off-by: Javier Martinez Canillas <javi...@redhat.com> --- Documentation/devicetree/bindings/input/atmel,maxtouch.txt | 6 +- drivers/input/touchscreen/atmel_mxt_ts.c

[PATCH] Input: atmel_mxt_ts - add missing compatible strings to OF device table

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 insertions

Re: [PATCH 1/1] efi/libstub: tpm: zero initialize pointer variables for mixed mode

unsigned long first_entry_addr, last_entry_addr; > size_t log_size, last_entry_size; > efi_bool_t truncated; > - void *tcg2_protocol; > + void *tcg2_protocol = NULL; > > status = efi_call_early(locate_protocol, _guid, NULL, >

Re: [PATCH 1/1] efi/libstub: tpm: zero initialize pointer variables for mixed mode

> size_t log_size, last_entry_size; > efi_bool_t truncated; > - void *tcg2_protocol; > + void *tcg2_protocol = NULL; > > status = efi_call_early(locate_protocol, _guid, NULL, > _protocol); > Looks good to me. Reviewed-by

Re: Regression from efi: call get_event_log before ExitBootServices

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

Re: Regression from efi: call get_event_log before ExitBootServices

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

Re: [PATCH 0/5 V2] tpm: timeouts revamp

ds >> 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://trustedcomputinggroup.or

Re: [PATCH 0/5 V2] tpm: timeouts revamp

ds >> 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://trustedcomputinggroup.or

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

away. > > Thanks again! > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

away. > > Thanks again! > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

Hello Wolfram, On Sun, Jan 7, 2018 at 2:17 PM, Javier Martinez Canillas <jav...@dowhile0.org> wrote: > > On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas > <javi...@redhat.com> wrote: >> The buses should honor the firmware interface used to register the

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

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

Re: [PATCH AUTOSEL for 4.9 111/219] ASoc: rt5645: Add OF device ID table

On Mon, Mar 5, 2018 at 11:42 AM, Mark Brown <broo...@kernel.org> wrote: > On Sat, Mar 03, 2018 at 10:29:00PM +, Sasha Levin wrote: >> From: Javier Martinez Canillas <jav...@osg.samsung.com> >> >> [ Upstream commit 9ba2da5f5d18daaa365ab5426b05e16f1d11478

Re: [PATCH AUTOSEL for 4.9 111/219] ASoc: rt5645: Add OF device ID table

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_devi

Re: [PATCH v2] tpm: use kmemdup() to copy the event log

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 <jarkko.sakki...@linux.intel.com> > --- Looks good to me. Reviewed-by: Javier Martinez Canillas <javi...@r

Re: [PATCH v2] tpm: use kmemdup() to copy the event log

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

Re: i2c: core: report OF style module alias for devices registered via OF

Hi Wolfram, On Tue, Jan 16, 2018 at 3:11 PM, Javier Martinez Canillas <javi...@redhat.com> 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 >> <javi...@redhat.com> wro

Re: i2c: core: report OF style module alias for devices registered via OF

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

Re: i2c: core: report OF style module alias for devices registered via OF

Hello Dmitry, On 01/16/2018 02:55 PM, Dmitry Mastykin wrote: > On Sun, 3 Dec 2017 22:40:50 +0100, Javier Martinez Canillas > <javi...@redhat.com> wrote: > >> The buses should honor the firmware interface used to register the device, >> but the I2C core reports a MOD

Re: i2c: core: report OF style module alias for devices registered via OF

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

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

On Sun, Jan 14, 2018 at 11:51 AM, Jonathan Cameron <ji...@kernel.org> wrote: > On Wed, 10 Jan 2018 12:01:07 +0100 > Javier Martinez Canillas <jav...@dowhile0.org> wrote: > >> Hello Jonathan, >> >> On Mon, Jan 1, 2018 at 10:53 AM, Jonathan Camero

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

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] >> >> > &

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

Hello Dmitry, On Wed, Jan 10, 2018 at 4:51 AM, Dmitry Mastykin <masti...@gmail.com> 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

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

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

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

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.

Re: [PATCH v2] iio: adc: max9611: fix module auto-loading

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

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

Hello Wolfram, On Sun, Dec 3, 2017 at 10:40 PM, Javier Martinez Canillas <javi...@redhat.com> 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.

Re: [PATCH] i2c: core: report OF style module alias for devices registered via OF

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

[PATCH v2 1/3] tpm: delete the TPM_TIS_CLK_ENABLE flag

ed-off-by: Javier Martinez Canillas <javi...@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> --- drivers/char/tpm/tpm_tis.c | 15 --- drivers/char/tpm/tpm_tis_core.c | 2 -- drivers

[PATCH v2 1/3] tpm: delete the TPM_TIS_CLK_ENABLE flag

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 Reviewed

[PATCH v2 0/3] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled

h/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 enabled

  1   2   3   4   5   6   7   8   9   10   >