On Sat, Sep 19, 2020 at 09:01:12AM +0800, tiantao (H) wrote:
>
>
> 在 2020/9/19 5:09, w...@kernel.org 写道:
> >
> > > static inline struct i2c_client *kobj_to_i2c_client(struct kobject
> > > *kobj)
> > > {
> > > - struct device * const dev = container_of(kobj, struct device, kobj);
> > > + str
> static inline struct i2c_client *kobj_to_i2c_client(struct kobject *kobj)
> {
> - struct device * const dev = container_of(kobj, struct device, kobj);
> + struct device * const dev = kobj_to_dev(kobj);
> return to_i2c_client(dev);
Can't we make this a oneliner then merging the l
On Tue, Sep 15, 2020 at 11:11:41AM +0200, Alain Volmat wrote:
> Name slave slots in order to ease code maintenance.
>
> Signed-off-by: Alain Volmat
Applied to for-next, thanks!
signature.asc
Description: PGP signature
On Tue, Sep 15, 2020 at 11:11:30AM +0200, Alain Volmat wrote:
> Commit 68302245720a ("i2c: stm32f7: Add SMBus Host-Notify protocol support")
> added a new slot specific for handling host-notify however failed
> to update the previous slot ID leading to having the 7bit address
> only slot with the w
On Thu, Sep 17, 2020 at 07:55:41PM +0800, Qii Wang wrote:
> The max frequency of mediatek i2c controller driver is
> I2C_MAX_HIGH_SPEED_MODE_FREQ, not I2C_MAX_FAST_MODE_PLUS_FREQ.
> Fix it.
>
> Fixes: 90224e6468e1 ("i2c: drivers: Use generic definitions
> for bus frequencies")
> Reviewed-by: Yingj
On Thu, Sep 17, 2020 at 07:55:42PM +0800, Qii Wang wrote:
> The master code needs to being sent when the speed is more than
> I2C_MAX_FAST_MODE_PLUS_FREQ, not I2C_MAX_FAST_MODE_FREQ in the
> latest I2C-bus specification and user manual.
>
> Signed-off-by: Qii Wang
Applied to for-current, thanks!
Hi Eddie,
> + switch (event) {
> + case I2C_SLAVE_STOP:
> + command_size = panel->idx;
> + fallthrough;
> + case I2C_SLAVE_WRITE_REQUESTED:
> + panel->idx = 0;
> + break;
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (panel->i
On Thu, Aug 06, 2020 at 11:48:37AM +0200, Matthias Brugger wrote:
> The struct i2c_spec_values have it's members documented but is missing the
> starting '@', which leads to warings like:
>
> drivers/i2c/busses/i2c-mt65xx.c:267: warning: Function parameter or member
> 'min_low_ns' not described in
On Wed, Aug 05, 2020 at 06:52:18PM +0800, Qii Wang wrote:
> This series are based on 5.8-rc1 and we provide four i2c patches
> to support mt8192 SoC.
>
> Main changes compared to v2:
> --delete unused I2C_DMA_4G_MODE
>
> Main changes compared to v1:
> --modify the commit with access more than 8GB
> > The other thing would be to convert the PXA driver and see if our
> > generic support can help their advanced use case or if we are missing
> > something. Codrin, do you have maybe time and interest to do that? That
> > would be awesome!
>
> Naturally, these would be the next steps. I can do
On Tue, Jun 16, 2020 at 07:41:30PM -0400, Jeffrey Lin wrote:
> Value of /sys/devices/platform/lis3lv02d/position when
> Horizontal: (36,-108,-1152)
> Left elevated: (-432,-126,-1062)
> Front elevated: (36,594,-936)
> Upside down:(-126,-252,1098)
>
> Signed-off-by: Jeffrey
On Fri, Jul 17, 2020 at 08:52:47PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn
> > > -static inline u32 mtk_i2c_set_4g_mode(dma_addr_t addr)
> > > -{
> > > - return (addr & BIT_ULL(32)) ? I2C_DMA_4G_MODE : I2C_DMA_CLR_FLAG;
> >
> > I think you missed my comment in the last version:
> > I2C_DMA_4G_MODE is no longer needed, you can delete it.
> >
> > Regards,
> > Matthias
>
Codrin, everyone
> This patch series was previously sent as a RFC. Significant changes
> since RFC:
> - "recovery" pinctrl state marked as deprecared in bindings;
> - move to "gpio" pinctrl state done after the call to prepare_recovery()
> callback;
> - glitch protection when SDA gpio is taken a
On Tue, Aug 04, 2020 at 12:59:26PM +0300, Codrin Ciubotariu wrote:
> Make the Microchip at91 driver the first to use the generic GPIO bus
> recovery support from the I2C core and discard the driver implementation.
>
> Signed-off-by: Codrin Ciubotariu
Applied to for-next, thanks!
signature.asc
On Tue, Aug 04, 2020 at 12:59:25PM +0300, Codrin Ciubotariu wrote:
> Even if I2C bus GPIO recovery is optional, devm_gpiod_get() can return
> -EPROBE_DEFER, so we should at least treat that. This ends up with
> i2c_register_adapter() to be able to return -EPROBE_DEFER.
>
> Signed-off-by: Codrin Ci
On Tue, Aug 04, 2020 at 12:59:24PM +0300, Codrin Ciubotariu wrote:
> Multiple I2C bus drivers use similar bindings to obtain information needed
> for I2C recovery. For example, for platforms using device-tree, the
> properties look something like this:
>
> &i2c {
> ...
> pinctrl-names
On Tue, Aug 04, 2020 at 12:59:23PM +0300, Codrin Ciubotariu wrote:
> The I2C GPIO bus recovery properties consist of two GPIOS and one extra
> pinctrl state ("gpio" or "recovery"). "recovery" pinctrl state is
> considered deprecated and "gpio" should be used instead.
> Not all are mandatory for rec
> > Nice diffstat! I will try using this new functionality with another
> > controller next week.
> >
>
> Thanks, this would be great! I tested this on a sam9x60, with the HW
> feature for the 9 pulses disabled, with a picky audio codec as I2C device.
> Please let me know of the result.
I'll s
> > This is correct but I think the code flow is/was confusing. Can you drop
> > this 'return' and use 'else if' for the next code block? I think this is
> > more readable.
>
> Ok, it makes sense. Should I make a separate patch for this only?
I am fine if this is included in this change.
> One
> I agree will all your suggestions, except with the removal of if
> (bri->recover_bus) . If you agree with this, I can send the next version
> and remove the RFC.
Yes, sure. That was a brown paper bag thingie from my side. Please go
ahead!
signature.asc
Description: PGP signature
On Tue, May 05, 2015 at 06:32:22PM +0200, Geert Uytterhoeven wrote:
> The GPIO subsystem provides dummy GPIO consumer functions if GPIOLIB is
> not enabled. Hence drivers that depend on GPIOLIB, but use GPIO consumer
> functionality only, can still be compiled if GPIOLIB is not enabled.
>
> Relax
On Mon, May 11, 2015 at 12:44:28PM -0700, Doug Anderson wrote:
> Although unlikely, it is remotely possible for an i2c command to need
> more than 200ms complete. Unlike smbus, i2c devices can clock stretch
> for an unspecified amount of time. The longest time I've seen
> specified for a device is
On Wed, May 06, 2015 at 01:29:08PM +0300, Mika Westerberg wrote:
> Following what DT already does. If the device does not have ACPI Interrupt
> resource but instead it has one or more GpioInt resources listed below it,
> we take the first GpioInt resource, convert it to suitable Linux IRQ number
>
On Wed, May 06, 2015 at 01:29:07PM +0300, Mika Westerberg wrote:
> This is the convention used in most parts of the kernel including DT
> counterpart of I2C slave enumeration. To make things consistent do the same
> for ACPI I2C slave enumeration path as well.
>
> Signed-off-by: Mika Westerberg
> + if (i2c->irq_stat & I2C_RS_TRANSFER)
> + dev_dbg(i2c->dev, "addr: %x, restart transfer interrupt.\n",
> + msgs->addr);
I'd tend to leave out this debug message. But you may leave it if you
like. Rest of the patch looks okay.
Thanks!
signature.asc
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Please sort the includes to avoid dupl
On Wed, May 06, 2015 at 04:37:05PM +0800, Eddie Huang wrote:
> From: Xudong Chen
>
> Add devicetree bindings for Mediatek Soc I2C driver.
>
> Signed-off-by: Xudong Chen
> Signed-off-by: Eddie Huang
Sascha, Uwe: Can you ack these patches if you are fine with them?
Would be nice since you did q
28 matches
Mail list logo
