Hi Andi, hi everyone,
thank you for reviewing and waiting. I had a small personal hiatus over
Easter but now I am back. This series needs another cycle, so no need to
hurry. I will address some of the review comments but not all. The
conversion (and API improvements) are some bigger tasks, so
> Kind of odd though to change function names but not parameter names of
> those very same functions.
Ouch, this is definitely a valid point. Seems like this series will need
a respin after all. Will wait for further comments, though.
Thanks!
signature.asc
Description: PGP signature
> Acked-by: Nicolas Ferre # for at91
> Probably file names themselves will need some care, in a second time.
Totally true. I am aware of that. But one step after the other...
signature.asc
Description: PGP signature
performed incrementally along with API changes/improvements. All these
changes here are simple search/replace results.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-amd-mp2-plat.c | 2 +-
drivers/i2c/busses/i2c-at91-master.c | 2 +-
drivers/i2c/busses/i2c-at91-slave.c
hacking,
Wolfram
Wolfram Sang (64):
i2c: reword i2c_algorithm according to newest specification
i2c: ali15x3: reword according to newest specification
i2c: altera: reword according to newest specification
i2c: amd-mp2-pci: reword according to newest specification
i2c: aspeed: reword
On Mon, Oct 02, 2023 at 08:55:30AM +0200, Luca Weiss wrote:
> Document the compatible for the CCI block found on SC7280 SoC.
>
> Reviewed-by: Bryan O'Donoghue
> Signed-off-by: Luca Weiss
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Sat, Apr 17, 2021 at 02:46:52PM +0800, Qii Wang wrote:
> The parameters of tSU,STA/tHD,STA/tSU,STOP maybe out of spec due
> to device clock-stretch or circuit loss, we could get a suitable
> scl_int_delay_ns from i2c_timings to compensate these parameters
> to meet the spec via EXT_CONF
On Sat, Apr 17, 2021 at 02:46:51PM +0800, Qii Wang wrote:
> The right flag is apdma_sync when apdma remove hand-shake signel.
>
> Signed-off-by: Qii Wang
Added:
Fixes: 05f6f7271a38 ("i2c: mediatek: Fix apdma and i2c hand-shake timeout")
and applied to for-next, thanks!
signature.asc
On Sat, Apr 17, 2021 at 02:46:50PM +0800, Qii Wang wrote:
> There are some omissions in the previous patch about replacing
> I2C_MAX_FAST_MODE__FREQ with I2C_MAX_FAST_MODE_PLUS_FREQ and
> need to fix it.
>
> Fixes: b44658e755b5("i2c: mediatek: Send i2c master code at more than 1MHz")
>
Linus,
here is one more driver bugfix for I2C.
Please pull.
Thanks,
Wolfram
The following changes since commit d434405aaab7d0ebc516b68a8fc4100922d7f5ef:
Linux 5.12-rc7 (2021-04-11 15:16:13 -0700)
are available in the Git repository at:
On Thu, Apr 15, 2021 at 11:38:02AM +0200, Krzysztof Kozlowski wrote:
> Use of_device_get_match_data() to make the code slightly smaller.
>
> Signed-off-by: Krzysztof Kozlowski
Applied to for-next, thanks!
signature.asc
Description: PGP signature
Hi Bence,
On Mon, Apr 12, 2021 at 11:53:02AM +, Bence Csókás wrote:
> While the preamble field _is_ technically big-endian, its value is always
> 0x2A2A,
> which is the same in either endianness, therefore it should be u16 instead.
Why should it be u16? I don't see it.
I thought the fix
On Thu, Apr 15, 2021 at 10:33:19AM +1200, Chris Packham wrote:
> I've tested on T2081 and P2041 based systems with a number of i2c and smbus
> devices.
>
> I've included some clean ups provided by Andy Shevchenko to make applying the
> series easier.
Applied to for-next, thanks!
signature.asc
On Thu, Apr 15, 2021 at 04:15:07PM +0800, Jie Deng wrote:
> On 2021/4/15 15:28, Wolfram Sang wrote:
>
> > > Now that we were able to catch you, I will use the opportunity to
> > > clarify the doubts I had.
> > >
> > > - struct mute
> Now that we were able to catch you, I will use the opportunity to
> clarify the doubts I had.
>
> - struct mutex lock in struct virtio_i2c, I don't think this is
> required since the core takes care of locking in absence of this.
This is likely correct.
> - Use of I2C_CLASS_DEPRECATED
> I didn't forget this. It is a very small change. I'm not sure if the
> maintainer Wolfram
>
> has any comments so that I can address them together in one version.
Noted. I'll have a look in the next days.
signature.asc
Description: PGP signature
> > > Platform data is a legacy interface to supply device properties
> > > to the driver. In this case we don't have anymore in-kernel users
> > > for it. Just remove it for good.
> > >
> > > Signed-off-by: Andy Shevchenko
> >
> >
On Thu, Apr 08, 2021 at 07:06:38PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> these functions.
>
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will result in
>
On Thu, Apr 08, 2021 at 08:56:48PM +0800, Li Huafei wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here. Fix
> it by replacing it with pm_runtime_resume_and_get to keep usage counter
> balanced.
>
>
On Thu, Apr 08, 2021 at 08:59:15PM +0800, Li Huafei wrote:
> pm_runtime_get_sync will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here. Fix
> it by replacing it with pm_runtime_resume_and_get to keep usage counter
> balanced.
>
>
On Thu, Apr 08, 2021 at 07:29:10PM +0800, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
>
>
On Thu, Apr 08, 2021 at 07:23:52PM +0800, Pu Lehui wrote:
> pm_runtime_get_sync() will increment pm usage counter even it failed.
> Forgetting to putting operation will result in reference leak here.
> Fix it by replacing it with pm_runtime_resume_and_get() to keep usage
> counter balanced.
>
>
On Thu, Apr 08, 2021 at 07:19:30PM +0800, Ye Weihua wrote:
> The PM reference count is not expected to be incremented on return in
> ipi2c_imx_master_enable().
>
> However, pm_runtime_get_sync() will increment the PM reference count
> even on failure. forgetting to put the reference again will
On Wed, Apr 07, 2021 at 11:30:30AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the rumtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not
On Tue, Dec 01, 2020 at 05:29:24PM +0800, Qinglang Miao wrote:
> pm_runtime_get_sync will increment the PM reference count
> even failed. Forgetting to putting operation will result
> in a reference leak here.
>
> Replace it with pm_runtime_resume_and_get to keep usage
> counter balanced.
>
>
On Mon, Apr 12, 2021 at 08:03:14PM +0800, Qii Wang wrote:
> On Wed, 2021-04-07 at 20:19 +0200, Wolfram Sang wrote:
> > > Due to clock stretch, our HW IP cannot meet the ac-timing
> > > spec(tSU;STA,tSU;STO).
> > > There isn't a same delay for clock stretching, so
On Tue, Apr 13, 2021 at 05:48:21PM +0800, Yang Li wrote:
> Fix the following versioncheck warnings:
> ./drivers/i2c/busses/i2c-xgene-slimpro.c: 22 linux/version.h not needed.
> ./drivers/i2c/busses/i2c-brcmstb.c: 25 linux/version.h not needed.
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang
On Tue, Apr 13, 2021 at 05:09:56PM +1200, Chris Packham wrote:
> Add Chris Packham as FREESCALE MPC I2C maintainer.
>
> Signed-off-by: Chris Packham
Applied to for-next, thanks for stepping up, much appreciated!
signature.asc
Description: PGP signature
e last entry in mpc_i2c_dividers_8xxx. Checking for div being NULL
> after the loop is redundant so remove the check.
>
> Reported-by: Wolfram Sang
> Signed-off-by: Chris Packham
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Tue, Apr 13, 2021 at 05:09:53PM +1200, Chris Packham wrote:
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> received. This
> Yongjun[1] into the original patch. If Wei's patch is applied on top
> of whats already in i2c/for-next then this patch can be ignored.
I applied Wei's patch instead. It was easier.
signature.asc
Description: PGP signature
Hi Chris,
> Yep I plan on being around. I've got access to a couple of designs with
> P2040 and T2081 so hopefully that's sufficient to deal with any
> regressions. One issue is a lack of different i2c devices (the systems
> we have tend to use the same devices) but hopefully any reports of
>
On Mon, Mar 29, 2021 at 02:52:04PM +1300, Chris Packham wrote:
> All the in-tree dts files that use one of the compatible strings from
> i2c-mpc.c provide an interrupt property. By making this mandatory we
> can simplify the code.
>
> Signed-off-by: Chris Packham
After I applied this patch,
On Mon, Mar 29, 2021 at 02:52:06PM +1300, Chris Packham wrote:
> The fsl-i2c controller will generate an interrupt after every byte
> transferred. Make use of this interrupt to drive a state machine which
> allows the next part of a transfer to happen as soon as the interrupt is
> received. This
On Sun, Mar 21, 2021 at 06:38:32PM -0700, Dmitry Torokhov wrote:
> More and more drivers rely on devres to manage their resources, however
> if bus' probe() and release() methods are not trivial and control some
> of resources as well (for example enable or disable clocks, or attach
> device to a
On Mon, Mar 29, 2021 at 01:50:35PM +0300, Heikki Krogerus wrote:
> Hi,
>
> The old device property API (device_add_properties()) is going to be
> removed. These prepare the i2c subsystem and drivers for the change.
> The change is fairly trivial in case of i2c. All we need to do is add
> complete
Shevchenko (1):
i2c: designware: Adjust bus_freq_hz when refuse high speed mode set
Bhaskar Chowdhury (1):
i2c: stm32f4: Mundane typo fix
Hao Fang (1):
i2c: hix5hd2: use the correct HiSilicon copyright
Krzysztof Kozlowski (1):
i2c: exynos5: correct top kerneldoc
Wolfram Sang (4
> Can we add this later if needed?
> Because in such case additionally printing bus_freq_hz will be fine, no?
Yes, we can do that.
> But putting max to each frequency representation in the list of strings sounds
> good to me.
It is not important to me if we are going to change that later
The following commit has been merged into the timers/core branch of tip:
Commit-ID: fe8324f37cfebf72e2669e97b9d76ea9794d2972
Gitweb:
https://git.kernel.org/tip/fe8324f37cfebf72e2669e97b9d76ea9794d2972
Author:Wolfram Sang
AuthorDate:Thu, 11 Mar 2021 10:09:18 +01:00
The following commit has been merged into the timers/core branch of tip:
Commit-ID: 68c70aae06e9660473a00fd7d68e0b53f4d7b6f4
Gitweb:
https://git.kernel.org/tip/68c70aae06e9660473a00fd7d68e0b53f4d7b6f4
Author:Wolfram Sang
AuthorDate:Tue, 09 Mar 2021 10:44:48 +01:00
On Mon, Mar 29, 2021 at 01:50:35PM +0300, Heikki Krogerus wrote:
> Hi,
>
> The old device property API (device_add_properties()) is going to be
> removed. These prepare the i2c subsystem and drivers for the change.
> The change is fairly trivial in case of i2c. All we need to do is add
> complete
On Tue, Mar 30, 2021 at 03:58:56PM +0200, Max Staudt wrote:
> This looks great, thank you for constifying this.
>
> Finally it's clean again, yet much more flexible than the original
> platform_data approach when I first submitted the driver.
I read this as "Reviewed-by" ;)
signature.asc
On Thu, Apr 08, 2021 at 07:17:20PM +0800, Yicong Yang wrote:
> Add maintainer for HiSilicon I2C driver.
Only if you need to resend, then you can squash this into the previous
patch. If not, I can do it when applying.
signature.asc
Description: PGP signature
> +const char *i2c_freq_mode_string(u32 bus_freq_hz)
> +{
> + switch (bus_freq_hz) {
> + case I2C_MAX_STANDARD_MODE_FREQ:
> + return "Standard Mode (100 kHz)";
Sorry, I just noticed just now. Shouldn't we also support lower
frequencies than the maximum one? I.e.
if
> Reason for temp variable is for me it's confusing to see statement like
> "rate_khz = rate_khz / 1000".
Yes. And with this clearer calculation, we can maybe skip the HZ_PER_KHZ
define completely and just use plain '1000' as a factor/divider because
it then becomes obvious. I still find the
> > I guess exporting will save few dozens of bytes if the function is used more
> > than once. (All strings will be duplicated or multiplied in that case)
> >
>
> yes, that's one concern. since we don't need this to perform fast, an inline
> one maybe unnecessary.
Exactly. I also don't see an
> Due to clock stretch, our HW IP cannot meet the ac-timing
> spec(tSU;STA,tSU;STO).
> There isn't a same delay for clock stretching, so we need pass a
> parameter which can be found through measurement to meet most
> conditions.
What about using this existing binding?
-
On Fri, Mar 12, 2021 at 12:53:27PM +0100, Alain Volmat wrote:
> Avoid CONFIG_PM preprocessor check for pm suspend/resume
> callbacks and identify the functions with __maybe_unused.
>
> Signed-off-by: Alain Volmat
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Mon, Apr 05, 2021 at 08:14:05PM +0200, Krzysztof Kozlowski wrote:
> The top comment is not a kerneldoc, as W=1 build reports:
>
> drivers/i2c/busses/i2c-exynos5.c:39: warning:
> expecting prototype for i2c(). Prototype was for HSI2C_CTL() instead
>
> Signed-off-by: Krzysztof Kozlowski
On Wed, Mar 31, 2021 at 09:36:25PM +0800, Yicong Yang wrote:
> Add driver and MAINTAINERS for HiSilicon I2C controller on Kunpeng SoC. Also
> provide the devm_*() variants for adding the I2C adapters. Add a public
> api to provide I2C frequency mode strings and convert designware driver
> to use
On Wed, Mar 31, 2021 at 09:36:26PM +0800, Yicong Yang wrote:
> Some I2C controller drivers will only unregister the I2C
> adapter in their .remove() callback, which can be done
> by simply using a managed variant to add the I2C adapter.
>
> So add the managed functions for adding the I2C adapter.
Only super minor stuff. Thanks to all the contributors and reviewers!
> +#define HZ_PER_KHZ 1000
KHZ_PER_HZ?
> + ret = devm_i2c_add_adapter(dev, adapter);
> + if (ret) {
> + dev_err(dev, "failed to add i2c adapter, ret = %d\n", ret);
No need to print that. The core
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 10bd0b0..7268180 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -47,6 +47,26 @@ typedef int (*i2c_slave_cb_t)(struct i2c_client *client,
> #define I2C_MAX_HIGH_SPEED_MODE_FREQ 340
> #define
On Sat, Mar 13, 2021 at 04:04:24PM +0800, qii.w...@mediatek.com wrote:
> From: Qii Wang
>
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the spec via EXT_CONF
> What is the plan for merging this patch / this series ?
I'll take the series via I2C.
signature.asc
Description: PGP signature
> Thanks for explanation. The follow up question is - can I take it
> independently via ARM Samsung/S3C tree?
Is it possible to just ack it, so I can take this all via I2C? Or will
there be merge conflicts. I can provide an immutable branch, of course.
signature.asc
Description: PGP signature
On Mon, Mar 29, 2021 at 01:50:39PM +0300, Heikki Krogerus wrote:
> Additional device properties are always just a part of a
> software fwnode. If the device properties are constant, the
> software node can also be constant.
>
> Signed-off-by: Heikki Krogerus
> Cc: Jonathan Cameron
> Cc: Daniel
On Mon, Mar 29, 2021 at 01:50:37PM +0300, Heikki Krogerus wrote:
> Additional device properties are always just a part of a
> software fwnode. If the device properties are constant, the
> software node can also be constant.
>
> Signed-off-by: Heikki Krogerus
> Cc: Sekhar Nori
> Cc: Bartosz
> I think these go via I2C tree.
Good, I'll apply it this weekend. Until then, let's hope we can get some
more acks.
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 06:48:51PM +0300, Andy Shevchenko wrote:
> Platform data is a legacy interface to supply device properties
> to the driver. In this case we don't have anymore in-kernel users
> for it. Just remove it for good.
>
> Signed-off-by: Andy Shevchenko
Acked-b
On Wed, Mar 31, 2021 at 09:51:41AM +0200, Wolfram Sang wrote:
> They return 0 always, so save some lines and code.
>
> Signed-off-by: Wolfram Sang
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 09:51:40AM +0200, Wolfram Sang wrote:
> Since commit bc1c2048abbe ("i2c: bpmp-tegra: Ignore unknown I2C_M
> flags") we don't need to mask out flags and can keep the input variable
> as is to save quite some lines.
>
> Signed-off-by: Wolfram S
> driver). In any case I guess the procedure is pretty much standard, i.e. Lee
> creates an immutable branch that Wolfram can pull into his tree.
Yes, that would be my favourite.
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 01:46:22PM +0300, Andy Shevchenko wrote:
> Since we have generic definitions for bus frequencies, let's use them.
>
> Cc: Wolfram Sang
> Signed-off-by: Andy Shevchenko
> Acked-by: Khalil Blaiech
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 07:37:30PM +0530, Sanket Goswami wrote:
> The Latest AMD NAVI GPU card has an integrated Type-C controller and
> Designware I2C with PCI Interface. The PD controller for USB Type-C can
> be accessed over I2C. The client driver is part of the USB Type-C UCSI
> driver.
>
>
On Wed, Mar 31, 2021 at 02:05:10PM +0300, Andy Shevchenko wrote:
> When hardware doesn't support High Speed Mode, we forget bus_freq_hz
> timing adjustment. This makes the timings and real registers being
> unsynchronized. Adjust bus_freq_hz when refuse high speed mode set.
>
> Fixes:
On Wed, Mar 31, 2021 at 07:19:21PM +, Bence Csókás wrote:
> Create an i2c_adapter for CP2615's I2C master interface
>
> Signed-off-by: Bence Csókás
Switched to '__packed', add some more 'static', added , and
applied to for-next, thanks!
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 07:19:20PM +, Bence Csókás wrote:
> This quirk signifies that the adapter cannot do a repeated
> START, it always issues a STOP condition after transfers.
>
> Suggested-by: Wolfram Sang
> Signed-off-by: Bence Csókás
Applied to for-next, thanks!
Hi Linus,
> I am a great supporter of this idea.
Great, thanks!
> When other debugging tools for GPIO got DT bindings it was concluded that
> it is possible to create bindings like this for debugging without even
> specifying
> any formal bindings. They are just for debugging after all.
So, I
> > drivers/i2c/busses/i2c-cp2615.c:78:5: warning: symbol 'cp2615_init_iop_msg'
> > was not declared. Should it be static?
> > drivers/i2c/busses/i2c-cp2615.c:96:5: warning: symbol 'cp2615_init_i2c_msg'
> > was not declared. Should it be static?
> > drivers/i2c/busses/i2c-cp2615.c:102:5:
From: Wolfram Sang
Signed-off-by: Wolfram Sang
Reviewed-by: Niklas Söderlund
Reviewed-by: Geert Uytterhoeven
---
Changes since v1:
* rebased to -next (other SoCs have been added meanwhile)
* added tags from Niklas and Geert (thanks!)
Documentation/devicetree/bindings/timer/renesas,tmu.yaml
Oh, and are you willing to maintain the driver? If so, please add an
entry to the MAINTAINERS file. Thanks!
signature.asc
Description: PGP signature
> properties in those nodes.
This looks like a nice cleanup!
Reviewed-by: Wolfram Sang # for the I2C parts
Which tree should this go into? I can offer I2C but am also fine with
another one...
signature.asc
Description: PGP signature
On Tue, Mar 30, 2021 at 02:37:14PM +0800, Hao Fang wrote:
> s/Hisilicon/HiSilicon/g.
> It should use capital S, according to
> https://www.hisilicon.com/en/terms-of-use.
>
> Signed-off-by: Hao Fang
Applied to for-current, thanks!
signature.asc
Description: PGP signature
us
> make i2c_recover_bus() to return -EBUSY instead.
>
> Suggested-by: Wolfram Sang
> Signed-off-by: Dmitry Osipenko
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Wed, Mar 24, 2021 at 07:36:10PM +0530, Bhaskar Chowdhury wrote:
>
> s/postion/position/
>
> Signed-off-by: Bhaskar Chowdhury
Applied to for-current, thanks! Please check older commits to this
driver for the proper subject prefix, i.e. "i2c: " in I2C.
signature.asc
Description: PGP
They return 0 always, so save some lines and code.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-tegra-bpmp.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra-bpmp.c
b/drivers/i2c/busses/i2c-tegra-bpmp.c
index
While reviewing a patch for this driver, I noticed that we can remove
quite some lines here. Not tested on HW, because I don't have it. Builds
fine, though. I'd appreciate tests / reviews. Thanks!
Wolfram Sang (2):
i2c: tegra-bpmp: don't modify input variable in xlate_flags
i2c: tegra-bpmp
Since commit bc1c2048abbe ("i2c: bpmp-tegra: Ignore unknown I2C_M
flags") we don't need to mask out flags and can keep the input variable
as is to save quite some lines.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-tegra-bpmp.c | 32 -
1 file
On Fri, Mar 19, 2021 at 06:12:13PM +0800, 周琰杰 (Zhou Yanjie) wrote:
> Only send "X1000_I2C_DC_STOP" when last byte, or it will cause
> error when I2C write operation.
>
> Fixes: 21575a7a8d4c ("I2C: JZ4780: Add support for the X1000.")
>
> Reported-by: 杨文龙 (Yang Wenlong)
> Tested-by: 杨文龙 (Yang
Hi,
> > Any write operation? I wonder then why nobody noticed before?
>
>
> The standard I2C communication should look like this:
>
> Read:
>
> device_addr + w, reg_addr, device_addr + r, data;
>
> Write:
>
> device_addr + w, reg_addr, data;
>
>
> But without this patch, it looks like
On Thu, Mar 18, 2021 at 11:52:10AM +, Bence Csókás wrote:
> Create an i2c_adapter for CP2615's I2C master interface by
> implementing parts of the CP2615's I/O Protocol (IOP)
>
> Signed-off-by: Bence Csókás
So, my code checkers report:
SPARSE
drivers/i2c/busses/i2c-cp2615.c:88:21:
> > +snipplet which analyzes an I2C bus at 400KHz on a Renesas Salvator-XS
> > board,
>
>snippet
Thanks!
>
> > +the following settings are used: The isolated CPU shall be CPU1 because it
> > is a
> > +big core in a big.LITTLE setup. Because CPU1 is the default, we don't need
> > a
> >
Hi Andy,
> I would like to look at it closer, but don't have time right now. So,
> some kind of a shallow review.
Still, thanks for that!
> But the idea is, let's say, interesting.
:)
> > +The binding documentation is in the ``misc`` folder of the Kernel binding
> > +documentation.
>
> Can't
to comments. If somebody has a pointer how to detect if
a task was requested to be killed (while irqs and preemption are
disabled), I'd appreciate that to avoid the currently unkillable
sub-process.
All the best,
Wolfram
Wolfram Sang (1):
misc: add simple logic analyzer using polling
This is a simple logic analyzer using GPIO polling. It comes with a
script to isolate a CPU for polling. While this is definately not a
production level analyzer, it can be a helpful first view when remote
debugging. Read the documentation for details.
Signed-off-by: Wolfram Sang
---
.../dev
On Mon, Mar 29, 2021 at 10:05:46PM +0300, Dmitry Osipenko wrote:
> The i2c_recover_bus() returns -EOPNOTSUPP if bus recovery isn't wired up,
> which the case for older Tegra SoCs at the moment. This error code is then
> propagated to I2C client and might be confusing, thus return -EIO instead.
On Wed, Mar 17, 2021 at 02:53:54PM +0800, Clark Wang wrote:
> From: Gao Pan
>
> use subsys_initcall for i2c driver to improve i2c driver probe priority
>
> Signed-off-by: Gao Pan
I usually don't take subsys_initcall patches anymore. In most cases, the
client drivers can be fixed instead. If
by: Christophe Leroy
Acked-by: Wolfram Sang # for I2C
signature.asc
Description: PGP signature
On Fri, Mar 19, 2021 at 12:25:43AM +0800, 周琰杰 (Zhou Yanjie) wrote:
> Only send "X1000_I2C_DC_STOP" when last byte, or it will cause
> error when I2C write operation.
Any write operation? I wonder then why nobody noticed before?
> - while ((i2c_sta & JZ4780_I2C_STA_TFNF) &&
>
> tSU,STA/tHD,STA/tSU,STOP maybe out of spec due to device
> clock-stretching or circuit loss, we could get device
> clock-stretch time from dts to adjust these parameters
> to meet the spec via EXT_CONF register.
>
> Signed-off-by: Qii Wang
I will look at this next and think about it. New
On Fri, Mar 05, 2021 at 07:28:30PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The ACPI_MODULE_NAME() definition is only used by the message
> printing macros from ACPICA that are not used by the code in
> question, so it is redundant. Drop it.
>
> No functional impact.
>
>
On Fri, Feb 05, 2021 at 09:51:44AM +0100, Alain Volmat wrote:
> To help debugging issues, add the address of the slave being
> accessed when getting an error.
>
> Signed-off-by: Alain Volmat
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Fri, Feb 05, 2021 at 09:51:43AM +0100, Alain Volmat wrote:
> Enable the analog filter for all I2C nodes of the stm32mp151.
>
> Signed-off-by: Alain Volmat
I usually don't take DTS patches, but they can go in now via arm-soc as
I applied the patches to the driver.
signature.asc
On Fri, Feb 05, 2021 at 09:51:42AM +0100, Alain Volmat wrote:
> Add the support for the i2c-digital-filter binding, allowing to enable
> the digital filter via the device-tree and indicate its value in the DT.
>
> Signed-off-by: Alain Volmat
Applied to for-next, thanks!
signature.asc
On Fri, Feb 05, 2021 at 09:51:41AM +0100, Alain Volmat wrote:
> Replace driver internally coded enabling/disabling of the
> analog-filter with the DT binding "i2c-analog-filter".
>
> Signed-off-by: Alain Volmat
Applied to for-next, thanks!
signature.asc
Description: PGP signature
> Signed-off-by: Pierre-Yves MORDRET
Please use "Reviewed-by" or "Acked-by" next time, then I will see it
in patchwork as taken care of. Thanks!
signature.asc
Description: PGP signature
Hi Bence,
> You are right, sorry, I am still familiarizing myself with `git send-email`
No worries, the progress from your first to your second version was
really great! You can add such information e.g. using the "--annotate"
parameter og git-send-email.
> GPLv2 or later is fine by me. If I
> Probably depends on the device implementation. I've got multiple other
> I2C/SMBUS devices and the LM81 seems to be the one that objects.
For the recored, there was just a similar case with a DA9063, but that
one luckily had a bit to switch from SMBus to I2C mode, i.e. no timeout
handling:
> The polling code is from pre-git times. Like 2005 and earlier.
> I'd say it is about time to get rid of it. Any out-of-tree users
> had more than 15 years to upstream their code, after all.
Parts of the polling mode might be interesting for the atomic_xfer mode
maybe? Which is not implemented
1 - 100 of 7563 matches
Mail list logo
