On Thu, Jul 16, 2020 at 06:18:17PM +0100, Lad Prabhakar wrote:
> Add PCIe{0,1} device nodes for R8A774E1 SoC.
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Hmm, doesn't apply on top of 5.8-rc6 for me. Is there a branch to pull
for easier review?
signature.asc
On Thu, Jul 16, 2020 at 06:18:16PM +0100, Lad Prabhakar wrote:
> Add PCIe support for the RZ/G2H (a.k.a. R8A774E1).
>
> Signed-off-by: Lad Prabhakar
> Reviewed-by: Marian-Cristian Rotariu
>
Reviewed-by: Wolfram Sang
signature.asc
Description: PGP signature
> This patch series adds support for the following peripherals on RZ/G2H SoC
> * PCIe
> * SATA
> * USB2
> * USB3
> * Audio
> * VIN
> * CSI
Nice. But please update your recipients list. No need to have the i2c
mailing list in there.
signature.asc
Description: PGP signature
On Fri, Jul 17, 2020 at 08:44:57PM +0900, Yoshihiro Shimoda wrote:
> To avoid unexpected behaviors, it's better to exit if request_irq()
> failed.
>
> Suggested-by: Vinod Koul
> Signed-off-by: Yoshihiro Shimoda
Makes sense to me.
Reviewed-by: Wolfram Sang
signature.asc
D
hy instances, needs to check whether one of
> phy instances is initialized. However, if we backport this patch to v5.1
> or less, we don't need to check it because such kernel have single
> phy instance.
>
> Reported-by: Wolfram Sang
> Reported-by: Geert Uytterhoeven
> Fixes: 9f
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wolfram Sang
> Cc: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
On Tue, Jul 07, 2020 at 11:04:03AM -0700, Randy Dunlap wrote:
> Drop doubled word "new".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wolfram Sang
> Cc: linux-...@vger.kernel.org
Reviewed-by: Wolfram Sang
Hi Rob,
> > > The I2C/SMBUS framework already provides a mechanism to enable SMBus-Alert
> > > by naming an IRQ line "smbus_alert". However, on stm32, the SMBus-Alert is
> > > part of the i2c IRQ. Using the smbus_alert naming here would lead to
> > > having
> > > 2 handlers (the handler of the
> Hi, it does change the behavior actually. By checking for the device node
> pointer, it would proceed and create the port for a NULL device node, which
> is not the desired behavior.
Brown paper bag, please...
signature.asc
Description: PGP signature
> +- pinctrl
> + add extra pinctrl to configure SCL/SDA pins to GPIO function for bus
> + recovery, call it "gpio" or "recovery" state
I think we should stick with "gpio" only. That is what at91 and imx have
in their bindings. pxa uses "recovery" as a pinctrl state name but I
can't find
On Fri, Jun 19, 2020 at 05:19:00PM +0300, Codrin Ciubotariu wrote:
> GPIO recovery has been added already for some I2C bus drivers, such as
> imx, pxa and at91. These drivers use similar bindings and have more or
> less the same code for recovery. For this reason, we aim to move the
> GPIO bus
):
i2c: eg20t: Load module automatically if ID matches
Chris Packham (1):
i2c: algo-pca: Add 0x78 as SCL stuck low status for PCA9665
Ricardo Ribalda (1):
i2c: designware: platdrv: Set class based on DMI
Wolfram Sang (3):
i2c: slave-eeprom: update documentation
i2c
On Tue, Jun 23, 2020 at 01:06:46PM +0100, John Keeping wrote:
> Enable i2c transactions in irq disabled contexts like poweroff where the
> PMIC is connected via i2c.
>
> Signed-off-by: John Keeping
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Tue, Jun 09, 2020 at 03:15:55PM -0500, Eddie James wrote:
> Ports should be defined in the devicetree if they are to be enabled on
> the system.
The patch description does not really fit anymore, does it? There is no
change in behaviour, we just remove a redundant check.
>
> Signed-off-by:
On Wed, Jun 10, 2020 at 01:59:01PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable i is being initialized with a value that is
> never read and it is being updated later with a new value. The
> initialization is redundant and can be removed.
>
> Addresses-Coverity: ("Unused
On Thu, Jul 02, 2020 at 12:33:21PM +0200, Ricardo Ribalda wrote:
> Current AMD's zen-based APUs use this core for some of its i2c-buses.
>
> With this patch we re-enable autodetection of hwmon-alike devices, so
> lm-sensors will be able to work automatically.
>
> It does not affect the boot-time
On Thu, Jul 02, 2020 at 10:39:11AM +1200, Chris Packham wrote:
> The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
> low, this differs to the PCA9564 which uses 90h for this indication.
> Treat either 0x78 or 0x90 as an indication that the SCL line is stuck.
>
> Based on
nk:
https://lore.kernel.org/linux-i2c/859e8211-2c56-8dd5-d6fb-33e4358e4...@pengutronix.de/T/#mf24d7070d7e0c8f17b6be6ceb51df94b7d7613b3
Reviewed-by: Krzysztof Kozlowski
Acked-by: Andy Shevchenko
Signed-off-by: Wolfram Sang
---
Greg, could you pick this one up as well?
Change since v1:
* add two
The doubled 'however' is confusing. Simplify the comment a little and
reformat the paragraph.
Signed-off-by: Wolfram Sang
Acked-by: Luis Chamberlain
---
Changes since v1:
* removed uneeded empty line (sorry!)
* added Luis' ack
drivers/base/firmware_loader/main.c | 12 ++--
1 file
> Any conclusion on this? I'm still suggesting that just treating 0x78
> and 0x90 as SCL stuck for either chip is the cleanest solution. I
> think I could do something with a fall-through that repeats the check
> with an if which wouldn't be too ugly.
I tried as well and also came up with code
On Thu, Jun 25, 2020 at 09:39:26AM +0200, Alain Volmat wrote:
> SMBus Host-Notify protocol, from the adapter point of view
> consist of receiving a message from a client, including the
> client address and some other data.
>
> It can be simply handled by creating a new slave device
> and
> I've just prepared the 1st new serie with only the HostNotify bits in it.
> (basically, the core part, the dt-bindings with the enable-host-notify, and
> the usage within i2c-stm32f7).
Cool, thanks!
> You mentioned in the other thread that you still have some more review comment
> I believe.
On Wed, Jul 01, 2020 at 09:31:14AM +0100, Lee Jones wrote:
> ... as is the case when !CONFIG_ACPI.
>
> Fixes the following W=1 kernel build warning:
>
> drivers/misc/eeprom/at24.c:228:36: warning: ‘at24_acpi_ids’ defined but not
> used [-Wunused-const-variable=]
>
> Cc
> However, that probably means that for most patches I am getting, the
> better fix would be to remove the error checking? (I assume most people
> put the error check in there to be on the "safe side" without having a
> real argument to really do it.)
Kindly asking for more input here: A better
On Thu, Jun 25, 2020 at 09:39:28AM +0200, Alain Volmat wrote:
> Add a new binding of the i2c-stm32f7 driver to enable the handling
> of the SMBUS-Alert.
>
> The I2C/SMBUS framework already provides a mechanism to enable SMBus-Alert
> by naming an IRQ line "smbus_alert". However, on stm32, the
On Thu, Jun 25, 2020 at 09:39:25AM +0200, Alain Volmat wrote:
> This serie adds SMBus Alert and SMBus Host-Notify features for the
> i2c-stm32f7.
If it is not too much work for you, I think it makes sense to split the
series into two, i.e. HostNotify and SMBusAlert parts.
signature.asc
Hi Alain,
> Ok, understood. Fine for me that way as well. I am just a little worrying that
> the "host-notify" can now be present in both controller AND slave nodes
> and might be a bit hard to understand. At the same time I don't have a better
> proposal for naming the binding for the
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here. Clicking on a link to understand what a
Hi Alain,
> > So, as mentioned in the other review, I'd like to evaluate other
> > possibilities for the above:
> >
> > - One option is to enable it globally in probe(). Then you lose the
> > possibility to have a device at address 0x08.
>
> I'd prefer avoid this solution to not lose the
> > > @@ -270,7 +270,7 @@ EXPORT_SYMBOL_GPL(eeprom_93cx6_readb);
> > > * @eeprom: Pointer to eeprom structure
> > > * @byte: Index from where we should start reading
> > > * @data: target pointer where the information will have to be stored
> > > - * @words: Number of bytes that should be
Hi Alexander,
thanks for trying to fix this, yet I have some doubts.
On Mon, Jun 29, 2020 at 10:31:21PM +0200, Alexander A. Klimov wrote:
> Rationale:
> https://lore.kernel.org/linux-doc/20200626110706.7b5d4...@lwn.net/
I think we need some text here. Clicking on a link to understand what a
> I saw it with the mv64xxx (Allwinner) and omap (Beaglebone) drivers.
> From a quick look, it seems like quite a few others have the same
> problem.
Okay, well, to be fair, both drivers don't advertise
I2C_SMBUS_BLOCK_DATA. The client driver should check for that. Anyhow,
it makes sense to have
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here.
Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
Signed-off-by: Wolfram Sang
---
Only build tested, I don't have the HW. Please let me know if I
I am preparing to add RECV_LEN support to Renesas I2C drivers. On my
way, I found these two peculiarities. Let's discuss them.
Wolfram Sang (2):
i2c: mlxcpld: check correct size of maximum RECV_LEN packet
i2c: octeon: check correct size of maximum RECV_LEN packet
drivers/i2c/busses/i2c
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. I don't see a reason to add 1 here. Also, fix the errno
to what is suggested for this error.
Fixes: c9bfdc7c16cb ("i2c: mlxcpld: Add support for smbus block read
transaction")
Signed-off-by: Wo
> @@ -270,7 +270,7 @@ EXPORT_SYMBOL_GPL(eeprom_93cx6_readb);
> * @eeprom: Pointer to eeprom structure
> * @byte: Index from where we should start reading
> * @data: target pointer where the information will have to be stored
> - * @words: Number of bytes that should be read.
> + * @bytes:
Linus,
This I2C pull request contains a 5.8 regression fix for the Designware
driver, a register bitfield fix for the fsi driver, and a missing sanity
check for the I2C core.
Please pull.
Thanks,
Wolfram
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux
On Sat, Jun 13, 2020 at 11:41:09AM +0100, Mans Rullgard wrote:
> If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
> them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued
Out of interest, which driver did you use?
> on some random device to return an arbitrary value in
On Tue, Jun 09, 2020 at 03:15:54PM -0500, Eddie James wrote:
> The port number field in the status register was not correct, so fix it.
>
> Fixes: d6ffb6300116 ("i2c: Add FSI-attached I2C master algorithm")
> Signed-off-by: Eddie James
> Signed-off-by: Joel Stanley
Applied to for-current,
The doubled 'however' is confusing. Simplify the comment a little and
reformat the paragraph.
Signed-off-by: Wolfram Sang
---
drivers/base/firmware_loader/main.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/base/firmware_loader/main.c
b/drivers/base
it.
Signed-off-by: Wolfram Sang
---
This is only build tested because I wanted to get your opinions first. I
couldn't find any explanation about yoyo, so I am entering unknown
territory here.
drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Wed, Jun 24, 2020 at 01:46:55PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 24, 2020 at 11:12:39AM +0200, Ricardo Ribalda wrote:
> > Current AMD's zen-based APUs use this core for some of its i2c-buses.
> >
> > With this patch we re-enable autodetection of hwmon-alike devices, so
> >
Hi Chris,
thanks for the patch!
On Mon, Jun 22, 2020 at 10:57:05AM +1200, Chris Packham wrote:
> The PCA9665 datasheet says that I2CSTA = 78h indicates that SCL is stuck
> low, this differs to the PCA9564 which uses 90h for this indication.
> Treat either 0x78 or 0x90 as an indication that the
Hi Andy,
> > Maybe your case was like Krzysztof's case where the issue turned out to
> > be the extra interrupt on deregistering after a deferred probe? He
> > thought it was the initial interrupt but it wasn't.
>
> Commit
>
On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> I want to remove the above API this cycle, and just a few patches have
> not made it into 5.8-rc1. They have been reviewed and most had been
> promised to get into linux-next, but well, things happen. So, I hope it
):
MAINTAINERS: Add robert and myself as qcom i2c cci maintainers
Wolfram Sang (6):
drm: encoder_slave: fix refcouting error for modules
drm: encoder_slave: use new I2C API
x86/platform/intel-mid: convert to use i2c_new_client_device()
video: backlight: tosa_lcd: convert to use
On Fri, Jun 12, 2020 at 05:26:35PM -0400, Keyur Patel wrote:
> Fix spelling mistake in the comments with help of `codespell`.
> seperate ==> separate
>
> Signed-off-by: Keyur Patel
Applied to for-current, thanks!
signature.asc
Description: PGP signature
On Mon, Jun 15, 2020 at 09:58:09AM +0200, Wolfram Sang wrote:
> I want to remove the above API this cycle, and just a few patches have
> not made it into 5.8-rc1. They have been reviewed and most had been
> promised to get into linux-next, but well, things happen. So, I hope it
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_s
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
Reviewed-by: Daniel Thompson
---
I'd like to push it via I2C for 5.8-rc2.
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
minor exception is the media documentation patch which I simply have
missed so far, but it is trivial.
And then, finally, there is the removal of the old API as the final
patch. Phew, that's been a long ride.
I am open for comments, of course.
Happy hacking,
Wolfram
Wolfram Sang (6):
drm
we use this condensed error check.
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b
On Mon, Jun 15, 2020 at 06:40:29PM +0800, qiangming.xia wrote:
> Hi, Wolfram
> Do you have time to take a look at this? Thanks.
Please resend and CC Qii Wang who is now the maintainer of this driver.
signature.asc
Description: PGP signature
module_put() balances try_module_get(), not request_module(). Fix the
error path to match that.
Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.")
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_s
minor exception is the media documentation patch which I simply have
missed so far, but it is trivial.
And then, finally, there is the removal of the old API as the final
patch. Phew, that's been a long ride.
I am open for comments, of course.
Happy hacking,
Wolfram
Wolfram Sang (6):
drm
Move away from the deprecated API and advertise the new one.
Signed-off-by: Wolfram Sang
Cc: Mauro Carvalho Chehab
---
I'd like to push it via I2C for 5.8-rc2.
Documentation/driver-api/media/v4l2-subdev.rst| 2 +-
Documentation/userspace-api/media/conf_nitpick.py | 2 +-
2 files changed
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
Reviewed-by: Andy Shevchenko
---
I'd like to push it via I2C for 5.8-rc2.
arch/x86/platform/intel-mid/sfi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch
Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang
Reviewed-by: Daniel Thompson
---
I'd like to push it via I2C for 5.8-rc2.
drivers/video/backlight/tosa_lcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
All in-tree users have been converted to the new i2c_new_client_device
function, so remove this deprecated one.
Signed-off-by: Wolfram Sang
---
I'd like to push it via I2C for 5.8-rc2.
drivers/i2c/i2c-core-base.c | 25 -
include/linux/i2c.h | 8 +++-
2
we use this condensed error check.
Signed-off-by: Wolfram Sang
Reviewed-by: Emil Velikov
---
I'd like to push it via I2C for 5.8-rc2.
drivers/gpu/drm/drm_encoder_slave.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_encoder_slave.c
b
On Mon, Jun 15, 2020 at 06:33:40AM +, Aisheng Dong wrote:
> > From: Wolfram Sang
> > Sent: Sunday, June 14, 2020 5:12 PM
> >
> > On Mon, Jun 01, 2020 at 02:16:40PM +0800, Dinghao Liu wrote:
> > > pm_runtime_get_sync() increments the runtime PM usage co
On Mon, Jun 15, 2020 at 06:31:28AM +, Aisheng Dong wrote:
> > From: Andy Duan
> > Sent: Monday, June 15, 2020 10:49 AM
> >
> > From: wu000...@umn.edu Sent: Sunday, June 14,
> > 2020 6:12 AM
> > > From: Qiushi Wu
> > >
> > > pm_runtime_get_sync() increments the runtime PM usage counter even
Hi Geert and Rafael,
> > I've always[*] considered a pm_runtime_get_sync() failure to be fatal
> > (or: cannot happen), and that there's nothing that can be done to
> > recover. Hence I never checked the function's return value.
> > Was that wrong?
>
> No, it wasn't. It is the right thing to
Hi Merlijn,
> My question is -- what would the best way to integrate support in the
> korad-kap driver? Some flag to enable quircks for this device?
I'd go this way. If the rest of the protocol is largely the same, it
makes sense to me to have a quirk to fix up the in/out communication and
> > If interrupt fires early, the dspi_interrupt() could complete
> > (dspi->xfer_done) before its initialization happens.
> >
> > Fixes: 4f5ee75ea171 ("spi: spi-fsl-dspi: Replace interruptible wait queue
> > with a simple completion")
> > Cc:
> > Signed-off-by: Krzysztof Kozlowski
> > ---
>
On Mon, Jun 01, 2020 at 02:16:40PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a corresponding decrement is
> needed on the error handling path to keep the counter balanced.
Can you point me to a discussion
On Sat, Jun 13, 2020 at 04:59:23PM -0500, wu000...@umn.edu wrote:
> From: Qiushi Wu
>
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus call pm_runtime_put_noidle()
> if pm_runtime_get_sync() fails.
Can you point me to a discussion where
Hi Linux-PM,
both in the I2C subsystem and also for Renesas drivers I maintain, I am
starting to get boilerplate patches doing some pm_runtime_put_* variant
because a failing pm_runtime_get is supposed to increase the ref
counters? Really? This feels wrong and unintuitive to me. I expect there
> > There is no extra interrupt when registering a shared interrupt handler
> > since 2011. Update the Kconfig text to make it clear and to avoid wrong
> > assumptions when debugging issues found by it.
> >
>
> I'm not sure.
> I have recently fixed a bug in the IIO sensor during ->probe() due to
or Qualcomm CCI I2C controller
Viresh Kumar (1):
i2c: sh_mobile: simplify code and remove false compilation warning
Wan Ahmad Zainie (2):
i2c: designware: Calculate SCL timing parameter for Fast Mode Plus
i2c: designware: Calculate SCL timing parameter for High Speed Mode
Wolfram
On Fri, Jun 12, 2020 at 02:18:06PM +0200, Marc Kleine-Budde wrote:
> On 6/12/20 1:51 PM, Wolfram Sang wrote:
> >
> >> This basically kills the concept of devm for interrupts. Some other
> >
> > It only works when you can ensure you have all interrupts disabled (a
nk:
https://lore.kernel.org/linux-i2c/859e8211-2c56-8dd5-d6fb-33e4358e4...@pengutronix.de/T/#mf24d7070d7e0c8f17b6be6ceb51df94b7d7613b3
Signed-off-by: Wolfram Sang
---
I'd think this could go in via one of tglx' trees?
lib/Kconfig.debug | 8
1 file changed, 4 insertions(+), 4 deletion
> This basically kills the concept of devm for interrupts. Some other
It only works when you can ensure you have all interrupts disabled (and
none pending) in remove() or the error paths of probe() etc.
signature.asc
Description: PGP signature
On Fri, Jun 12, 2020 at 11:29:41AM +0200, Krzysztof Kozlowski wrote:
> On Fri, Jun 12, 2020 at 11:05:17AM +0200, Wolfram Sang wrote:
> > On Wed, Jun 10, 2020 at 03:46:42PM +0200, Krzysztof Kozlowski wrote:
> > > If interrupt comes early (could be triggered with
On Wed, Jun 10, 2020 at 03:46:42PM +0200, Krzysztof Kozlowski wrote:
> If interrupt comes early (could be triggered with CONFIG_DEBUG_SHIRQ),
That code is disabled since 2011 (6d83f94db95c ("genirq: Disable the
SHIRQ_DEBUG call in request_threaded_irq for now"))? So, you had this
without fake
On Sun, Jun 07, 2020 at 08:28:12PM +0200, Max Staudt wrote:
> This has been found by the Kernel Test Robot:
> http://lkml.iu.edu/hypermail/linux/kernel/2006.0/06862.html
>
> With CONFIG_AMIGA_PCMCIA=n, io_mm.h does not pull in amigahw.h and
> ZTWO_VADDR is undefined. Add forgotten include to
On Thu, Jun 04, 2020 at 10:39:57AM -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary parentheses around _bus_.
>
> This issue was found with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Using 2.35.2-2, I can use bash-completion when unmounting a USB drive
which was mounted to a directory containing spaces.
The 'gawk' issues was properly fixed, too, check #933934
Maybe someone wants to verify, yet I think this can be closed.
signature.asc
Description: PGP signature
On Tue, Mar 17, 2020 at 10:39:16AM +0100, Lubomir Rintel wrote:
> A conversion of the i2c-pxa binding to DT schema format using json-schema.
>
> This also cleans ups some errors in the binding: The compatible string
> description suggested that "mmp" in "mrvl,mmp-twsi" is to be substituted
> with
On Tue, Jun 02, 2020 at 09:38:23PM +0200, Lubomir Rintel wrote:
> The bus recovery patch regresses on OLPC XO-1.75 that has no pinctrl in
> its DT.
>
> Fixes: 7c9ec2c52518 ("i2c: pxa: implement generic i2c bus recovery")'
> Signed-off-by: Lubomir Rintel
Applied to for-next, thanks!
On Wed, May 27, 2020 at 11:08:17PM +0300, Tali Perry wrote:
> This patch set adds i2c controller support
> for the Nuvoton NPCM Baseboard Management Controller (BMC).
>
> NPCM7xx includes 16 I2C controllers. This driver operates the controller.
> This module also includes a slave mode.
>
> ---
> Easier to just duplicate the define here which Joel's patches do.
Well, seems this case is closed then. Thanks everyone!
signature.asc
Description: PGP signature
> Almost after an year, wondering on how you reached this patch now :)
Another developer sent the same patch. And last time I was unsure if I
liked the new code better (for reasons I can't recall anymore); this
time it was clear to me.
signature.asc
Description: PGP signature
On Thu, May 28, 2020 at 12:33:10PM +0300, Serge Semin wrote:
> Jarkko, Wolfram, the merge window is upon us, please review/merge in/whatever
> the patchset.
>
> Initially this has been a small patchset which embedded the Baikal-T1
> System I2C support into the DW APB I2C driver as is by using a
On Sat, May 30, 2020 at 01:09:30PM +0200, Wolfram Sang wrote:
> On Thu, May 28, 2020 at 12:33:18PM +0300, Serge Semin wrote:
> > Seeing the DW I2C driver is using flags-based accessors with two
> > conditional clauses it would be better to replace them with the regmap
>
> > WARNING: DT binding documents should be licensed (GPL-2.0-only OR
> > BSD-2-Clause)
> >
>
> Hope you don't mind me answering on a question for Rob. That warning concerns
> new bindings and bindings converted by a person eligible to change the
> license.
> Otherwise by default any
On Thu, May 28, 2020 at 12:33:18PM +0300, Serge Semin wrote:
> Seeing the DW I2C driver is using flags-based accessors with two
> conditional clauses it would be better to replace them with the regmap
> API IO methods and to initialize the regmap object with read/write
> callbacks specific to the
Just double checking:
> Signed-off-by: Serge Semin
> Reviewed-by: Rob Herring
Rob, what about this checkpatch warning?
WARNING: DT binding documents should be licensed (GPL-2.0-only OR BSD-2-Clause)
signature.asc
Description: PGP signature
> + addr = reg & 0x3FFFU;
> + snprintf(unit_addr, sizeof(unit_addr), "%x", addr);
Hmm, this hardcoded value will not work if we ever need to add another
bit. I hope this will never happen, though.
> + if ((reg & (1U << 31)) && addr > 0x3ff)
Same here with bit 31. I
On Wed, Apr 29, 2020 at 08:40:17PM +0800, Zhen Lei wrote:
> The warning is caused by the branches "if (pd->pos == -1)" and
> "if (pd->pos == 0)", because they appear after "real_pos = pd->pos - 2",
> so the compiler doesn't known the value of real_pos is negative through
> these two branches.
>
>
er board (R-Car H2). Dumping register sets
produces identical results.
Tested-by: Wolfram Sang
And code is actually cleaner now.
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Sun, Mar 22, 2020 at 05:00:40PM +0100, Wolfram Sang wrote:
> On Fri, Dec 06, 2019 at 03:53:49PM +0800, Chuhong Yuan wrote:
> > The driver forgets to call pci_release_regions() in probe failure
> > and remove.
> > Add the missed calls to fix it.
> >
> > Sign
On Wed, May 06, 2020 at 05:01:10PM +0800, Samuel Zou wrote:
> Fixes coccicheck warning:
>
> drivers/i2c/busses/i2c-nvidia-gpu.c:280:1-3: WARNING: PTR_ERR_OR_ZERO can be
> used
>
> Reported-by: Hulk Robot
> Signed-off-by: Samuel Zou
Thanks, but has been fixed already with
On Tue, May 05, 2020 at 08:22:30PM +0530, Aishwarya Ramakrishnan wrote:
> PTR_ERR_OR_ZERO contains if(IS_ERR(...)) + PTR_ERR.
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by: Aishwarya Ramakrishnan
Applied to for-next, thanks!
signature.asc
Description: PGP
On Sat, May 23, 2020 at 10:51:55PM +0800, Dejin Zheng wrote:
> It will call devm_request_irq() after platform_get_irq() function
> in many drivers, sometimes, it is not right for the error handling
> of these two functions in some drivers. so provide this function
> to simplify the driver.
>
>
> +static int stm32f7_i2c_reg_client(struct i2c_client *client)
> +{
> + struct stm32f7_i2c_dev *i2c_dev = i2c_get_adapdata(client->adapter);
> + int ret;
> +
> + if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
> + /* Only enable on the first device registration */
> +
On Tue, May 05, 2020 at 07:51:09AM +0200, Alain Volmat wrote:
> Addition of two callbacks reg_client and unreg_client that can be
> implemented by adapter drivers in order to take action whenever a
> client is being registered to it.
>
> Signed-off-by: Alain Volmat
Sorry, but NACK. After years
Adding Benjamin who mainly implemented this.
On Tue, May 05, 2020 at 07:51:08AM +0200, Alain Volmat wrote:
> SMBus Host-Notify protocol, from the adapter point of view
> consist of receiving a message from a client, including the
> client address and some other data.
>
> It can be simply
> You know about
> devm_platform_get_and_ioremap_resource()
> usage.
> Maybe that's the way to go. Because as of today there is no way to pass
> position of irq resource.
>
> But I expect it will come in near future.
Has been tried, has been nacked:
> > According to the Hardware User's Manual Rev. 1.00, the registers do exist
> > on all RZ/G1, except for RZ/G1E (see below).
> >
> >"(automatic transmission can be used as a hardware function, but this is
> > not meaningful for actual use cases)."
> >
> > (whatever that comment may
801 - 900 of 16193 matches
Mail list logo
