On Wed, Aug 14, 2013 at 11:11:27AM +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
Move the call to platform_get_resource adjacent to the
On Tue, Jul 30, 2013 at 04:59:33PM +0900, Jingoo Han wrote:
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.
Signed-off-by: Jingoo Han jg1@samsung.com
Not convincing. I couldn't find a cover letter explaining the motivation
and if
Once, we fix this problem. i planned to rebase and submit.
Is it okey with you?
Perfectly fine. Thanks for the heads up.
signature.asc
Description: Digital signature
it
easier to remember which function to use and to make code more readable,
introduce a new inline function with the proper name and consistent argument
type. Update the kernel-doc for init_completion while we are here.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Linus Walleij linus.wall
Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
---
This is now a tree-wide patch for easier review. I can
on
an AT91 board. More testing welcome.
Looking forward to opinions. If accepted, I'd think it is probably best if this
gets in in one go via Linus directly?
Thanks,
Wolfram
Wolfram Sang (2):
sched: replace INIT_COMPLETION with reinit_completion
tree-wide: use reinit_completion instead
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/net
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/video
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/net/can
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/net
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mtd/nand
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/tty
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/gpu/drm
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/misc
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/pwm/pwm
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mtd/nand
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mmc/host
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c
Briefly looking into ACPI tables we have and mechanisms that we can
use in ACPI case, I doubt we may apply all the ideas, probably some of
them, though I didn't get yet where to read about in details. What I
could say now is that the patch provided by Bin Gao is definitely no
go.
Laurent
On Mon, Jun 17, 2013 at 08:47:35PM +0300, Tuomas Tynkkynen wrote:
Hi,
Latest linux-next head (next-20130617) seems to have some
backwards-incompatible
changes to the i2c core, which breaks the tps* drivers in our boards and cause
panics on boot.
Thanks for pointing out. I am going to
On Tue, Jun 18, 2013 at 01:14:39PM +0300, Tuomas Tynkkynen wrote:
Hi,
Latest linux-next head (next-20130617) seems to have some
backwards-incompatible
changes to the i2c core, which breaks the tps* drivers in our boards and cause
panics on boot.
v2 changes: Don't override platform data
On Tue, Jun 18, 2013 at 01:30:13PM +0300, Mikko Perttunen wrote:
Commit i2c: core: make it possible to match a pure device tree driver
changed semantics of the i2c probing for device tree devices.
Device tree probed devices now get a NULL i2c_device_id pointer.
This causes the regulator name
Hi,
On Wed, Jun 12, 2013 at 04:47:45PM +0200, Christian Ruppert wrote:
On Mon, Jun 10, 2013 at 05:29:55PM +0200, Wolfram Sang wrote:
On Tue, May 14, 2013 at 03:04:02PM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
[rebased to i2c
On Wed, Jun 19, 2013 at 10:27:40AM +0200, Samuel Ortiz wrote:
Hi Lee,
On Wed, Jun 19, 2013 at 09:18:59AM +0100, Lee Jones wrote:
On Tue, 18 Jun 2013, Tuomas Tynkkynen wrote:
Commit i2c: core: make it possible to match a pure device tree driver
changed semantics of the i2c probing
On Mon, Jun 03, 2013 at 10:37:20AM +0300, Oleksandr Dmytryshyn wrote:
We've been lucky not to have any interrupts fire during the suspend
path, otherwise we would have unpredictable behaviour in the kernel.
Based on the logic of the kernel code interrupts from i2c should be
prohibited during
Even you prefer to extend v4l2, you still need this helper.
The idea is just to move the unregister/register from a specific ISP driver
to v4l2.
I think you misunderstood my pionts somehow. Let me clarfiy a little bit:
Current solution:
1. Platform codes(on top of DT/ACPI5/SFI) don't
On Fri, Jun 07, 2013 at 11:09:26AM +0200, Wolfram Sang wrote:
Class based instantiation can cause huge delays when booting. This
mechanism was used when it was not possible to describe slaves on I2C
busses. We now have other mechanisms, so most embedded I2C will not need
classes
Hi Christian,
So, I looked around and found:
http://www.maximintegrated.com/app-notes/index.mvp/id/3268
which after thinking further about it gives me the following
conclusions:
- sda-hold-time is a property/requirement of a device not following
the I2C spec. It is not a
Hi,
Sorry, for delayed reply - I've had problems with my e-mail.
You still have. This message has unwanted linebreaks.
I've tested this patch on our TI K3.4 product kernel with additional
change below:
Thanks.
[0.662567] (null): This adapter will soon drop class based
instantiation
On Wed, Jun 19, 2013 at 04:59:57PM -0700, Seth Heasley wrote:
This patch adds the i801 SMBus Controller DeviceIDs for the Intel Coleto
Creek PCH.
Signed-off-by: Seth Heasley seth.heas...@intel.com
Applied to for-next, thanks!
signature.asc
Description: Digital signature
On Tue, Jun 18, 2013 at 09:44:29AM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com
Okay, I am convinced of the
On Thu, Jun 20, 2013 at 10:04:54PM +0200, Wolfram Sang wrote:
On Tue, Jun 18, 2013 at 09:44:29AM +0200, Christian Ruppert wrote:
This patch makes the SDA hold time configurable through device tree.
Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
Signed-off-by: Pierrick
On Thu, Sep 12, 2013 at 01:04:55PM +0200, Rafael J. Wysocki wrote:
On Thursday, September 12, 2013 12:43:02 PM Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 10:31:45AM +0100, Mark Brown wrote:
On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
On Wed, Sep 11, 2013 at
in the driver won't ever change.
This patch prevents the kernel from getting stuck in this case.
Signed-off-by: Lothar Waßmann l...@karo-electronics.de
Acked-by: Wolfram Sang w...@the-dreams.de
signature.asc
Description: Digital signature
While the bus speed property is really a configuration parameter (and
not a true description of of the hardware) it seems improper to put
driver specific details into the binding document.
OK. Then please change the error message for unsupported bus speeds to
contain the supported ones. I
+Optional properties :
+- i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
allowed
+ through the deglitch circuit. In units of us.
+- i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
allowed
+ through the deglitch circuit. In units of
On Wed, Oct 02, 2013 at 01:46:47PM +0200, Linus Walleij wrote:
Currently the BH1780GLI I2C driver relies on the device tree node
having the right name, but this is fragile. Use the compatible
string to probe the driver instead.
Cc: Wolfram Sang w...@the-dreams.de
Signed-off-by: Linus
On Sun, Sep 29, 2013 at 10:50:58AM +0200, Lars-Peter Clausen wrote:
Hi,
This series removes the redundant driver field from the i2c_client struct. The
field is redundant since the same pointer can be accessed through
to_i2c_driver(client-dev.driver). The commit log suggests that the field
+ i2c-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(i2c-base)) {
+ dev_err(pdev-dev, Could not allocate iomem\n);
devm_ioremap_resource already prints error messages.
+ ret = devm_request_irq(pdev-dev, irq, xiic_isr, 0, pdev-name, i2c);
This is too
+ cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET);
+ cr |= XIIC_CR_DIR_IS_TX_MASK;
+ xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr);
+
Is there no need to clear the bit again when receiving? And did
transferring ever work if this bit was never set before?
signature.asc
Description:
On Fri, Oct 04, 2013 at 11:53:49AM +0200, Michal Simek wrote:
On 10/04/2013 07:46 AM, Wolfram Sang wrote:
+ cr = xiic_getreg32(i2c, XIIC_CR_REG_OFFSET);
+ cr |= XIIC_CR_DIR_IS_TX_MASK;
+ xiic_setreg32(i2c, XIIC_CR_REG_OFFSET, cr);
+
Is there no need to clear the bit again when
On Fri, Oct 04, 2013 at 11:16:20AM +0200, Michal Simek wrote:
On 10/04/2013 07:33 AM, Wolfram Sang wrote:
+ i2c-base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(i2c-base)) {
+ dev_err(pdev-dev, Could not allocate iomem\n);
devm_ioremap_resource already prints
First register the handler, then activate interrupts. You are right,
this needs to be fixed, too.
Do you want me to create separate patch just about moving request irq in
front of
xiic_reinit()? And then devm_ conversion?
Yes, seperate, please.
signature.asc
Description: Digital
On Thu, Aug 15, 2013 at 12:30:25PM +0200, Wolfram Sang wrote:
Use of this function is discouraged in favour of
devm_ioremap_resource(). Don't advertise it.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Ping.
signature.asc
Description: Digital signature
On Mon, Sep 16, 2013 at 02:51:18PM +0100, Mark Brown wrote:
On Mon, Sep 16, 2013 at 02:44:35PM +0200, Linus Walleij wrote:
I've tried to fix this for DT-only I2C devices
and this very driver was the reason.
But a tiresome regression due to drivers relying on this
i2c_device_id not
So in the mean time are you happy with this dummy approach?
No. dummy is reserved for a dummy device in case an i2c slave needs
more than one address. The proper solution would be if
i2c_sysfs_new_device() could recognize the of_device_ids.
signature.asc
Description: Digital signature
Applied, thanks. Please use subject lines appropriate to the subsystem.
That's quite a nut to crack with a generated patch series running over
the whole tree. I wonder if it is really worth the effort?
I think it's probably worth the effort to add something to put rules for
these
On Sat, Nov 16, 2013 at 05:59:15PM +0100, Florian Meier wrote:
I have looked through all bus drivers and in most
cases they have a corresponding line that could be removed.
Although, this patch would break i2c-powermac, because it
relies on the fact that of_node stays NULL.
Any idea how
On Mon, Nov 25, 2013 at 02:43:57PM +0100, Mike Looijmans wrote:
Leaving the mux enabled causes needless I2C traffic on the downstream
bus.
This is a bus. Why is this bad?
signature.asc
Description: Digital signature
On Tue, Nov 26, 2013 at 07:32:00AM +0100, Mike Looijmans wrote:
Leaving the mux enabled causes needless I2C traffic on the downstream
bus. De-selecting after every request causes excess I2C traffic and
switching.
This patch implements a hybrid solution: After 200ms of inactivity,
the mux is
CCing linux-pm, maybe they know more...
The extra I2C traffic consumes extra power. If the bus is terminated
using 2k resistors, approximately 1mA of current (assuming ~2V
signals) is flowing when the bus is pulled low. On low power
designs, this extra power consumption is noticable. There
On Wed, Nov 20, 2013 at 08:23:44PM +0200, Taras Kondratiuk wrote:
I2C IP block expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and
@@ -1142,7 +1142,7 @@ omap_i2c_probe(struct platform_device *pdev)
* Also since the omap_i2c_read_reg uses reg_map_ip_* a
* raw_readw is done.
*/
- rev = __raw_readw(dev-base + 0x04);
+ rev = readw_relaxed(dev-base + 0x04);
dev-scheme =
On Mon, Nov 25, 2013 at 09:01:50AM +0100, Florian Meier wrote:
In order to find I2C devices in the device tree, the platform nodes
have to be known by the I2C core. This requires setting the
dev.of_node parameter of the adapter.
Signed-off-by: Florian Meier florian.me...@koalo.de
Malformed
On Mon, Nov 25, 2013 at 12:01:18PM -0800, Tim Kryger wrote:
Correct a typo that prevented the driver from being built as a module.
Signed-off-by: Tim Kryger tim.kry...@linaro.org
Applied to for-current, thanks!
Have you also tried repeated module loading/unloading?
signature.asc
On Tue, Nov 19, 2013 at 06:14:18PM -0800, Benson Leung wrote:
Hi Wolfram,
On Thu, Nov 14, 2013 at 10:05 AM, Wolfram Sang w...@the-dreams.de wrote:
In the chromeos_laptop driver, I do by-name matching of i2c busses to
find busses and instantiate devices, so there is value to have each
I had looked a bit in that direction, but I think there's currently
no way for a driver to say I won't be needing the bus for a while.
Something like that would be critical for such a pm system to work.
Yes. I wasn't sure if something already existed.
In any case, it doesn't sound like
On Wed, Nov 20, 2013 at 08:23:44PM +0200, Taras Kondratiuk wrote:
I2C IP block expect LE data, but CPU may operate in BE mode.
Need to use endian neutral functions to read/write h/w registers.
I.e instead of __raw_read[lw] and __raw_write[lw] functions code
need to use read[lw]_relaxed and
vincent.ste...@laposte.net
Cc: Wolfram Sang w...@the-dreams.de
Cc: triv...@kernel.org
A fix is in my pull request for Linus today.
signature.asc
Description: Digital signature
On Mon, Nov 25, 2013 at 09:01:50AM +0100, Florian Meier wrote:
In order to find I2C devices in the device tree, the platform nodes
have to be known by the I2C core. This requires setting the
dev.of_node parameter of the adapter.
Signed-off-by: Florian Meier florian.me...@koalo.de
Fixed up
Linus,
here are some easy but needed fixes for i2c drivers since rc1.
Please pull.
Thanks,
Wolfram
The following changes since commit
6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
Jean Delvare (1):
i2c: Not all adapters have a parent
Taras Kondratiuk (1):
i2c: omap: Clear ARDY bit twice
Wolfram Sang (6):
i2c: i2c-designware-platdrv: replace platform_driver_probe to support
deferred probing
i2c: i2c-imx: replace platform_driver_probe to support
The core does this automatically, no need to do this explicitly in drivers.
Those patchces should go via the respective subtrees. Thanks!
Wolfram Sang (4):
drivers/gpu/drm/tilcdc: don't use devm_pinctrl_get_select_default() in
probe
drivers/mmc/host: don't use
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/pwm/pwm
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/mmc/host
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
sound/soc/atmel/atmel_wm8904.c | 8
Since commit ab78029 (drivers/pinctrl: grab default handles from device core),
we can rely on device core for setting the default pins. Compile tested only.
Acked-by: Linus Walleij linus.wall...@linaro.org (personally at LCE13)
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/gpu/drm
On Sun, Oct 13, 2013 at 11:26:16PM +0530, RAGHAVENDRA GANIGA wrote:
From 46aed97f5e5a434e8ec24c14e085a138958ba559 Mon Sep 17 00:00:00 2001
From: Raghavendra Ganiga ravi23gan...@gmail.com
Date: Sun, 13 Oct 2013 19:13:46 +0530
Subject: [PATCH] i2c: i2c-core: fix paranthesis coding style issue in
On Thu, Oct 10, 2013 at 12:39:38PM +0200, Michal Simek wrote:
From: Kedareswara rao Appana appana.durga@xilinx.com
Simplified the probe and remove functions using devm_* functions
Signed-off-by: Kedareswara rao Appana appa...@xilinx.com
Signed-off-by: Michal Simek
Applied, thanks. Please use subject lines appropriate to the subsystem.
That's quite a nut to crack with a generated patch series running over
the whole tree. I wonder if it is really worth the effort?
signature.asc
Description: Digital signature
. The branch can be found here:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git reinit_completion
Looking forward to opinions. If accepted, I'd think it is probably best if this
gets in in one go via Linus directly?
Thanks,
Wolfram
Wolfram Sang (3):
sched: replace
it easier to remember which function to use and to
make code more readable, introduce a new inline function with the proper
name and consistent argument type. Update the kernel-doc for
init_completion while we are here.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Acked-by: Linus Walleij linus.wall
All users are converted over to reinit_completion(). Remove the old
macro now.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
This patch is mainly here for build testing (to spot missed conversions). I am
fine with applying this some cycles later than the rest.
include/linux/completion.h
On Wed, Nov 06, 2013 at 09:25:12AM +0100, Maxime COQUELIN wrote:
This patch adds support to SSC (Synchronous Serial Controller)
I2C driver. This IP also supports SPI protocol, but this is not
the aim of this driver.
This IP is embedded in all ST SoCs for Set-top box platorms, and
supports
On Wed, Nov 06, 2013 at 09:25:13AM +0100, Maxime COQUELIN wrote:
This patch supplies I2C configuration to STiH416 SoC.
Signed-off-by: Maxime Coquelin maxime.coque...@st.com
I suppose the dts patches go via arm-soc.
signature.asc
Description: Digital signature
On Mon, Nov 04, 2013 at 09:29:48AM -0800, James Ralston wrote:
This patch adds the SMBus Device IDs for the Intel Wildcat Point-LP PCH.
Signed-off-by: James Ralston james.d.rals...@intel.com
Applied to for-next, thanks! Please ensure that the introductory message
also goes to the relevant
On Tue, Nov 12, 2013 at 11:57:30AM +0200, Mika Westerberg wrote:
Newer Intel PCHs with LPSS have the same Designware I2C controllers than
Haswell but the ACPI IDs differ. Add these IDs to the driver list.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Applied to for-next,
In the chromeos_laptop driver, I do by-name matching of i2c busses to
find busses and instantiate devices, so there is value to have each
named something predictable.
Any why don't you use fixed bus numbers which you can attach the devices
to?
signature.asc
Description: Digital signature
On Thu, Nov 14, 2013 at 01:02:11PM -0800, Tim Kryger wrote:
This series adds support for the Kona I2C bus found on Broadcom mobile
SoCs like the bcm11351 (aka bcm281xx) and enables it on the bcm28155-ap
board.
It depends upon the following commit:
+ if (!dev-of_node dev-parent)
+ dev-of_node = dev-parent-of_node;
+
That is not enough. Current drivers could then have the assignment
removed and even more important, this behaviour should be documented.
Regards,
Wolfram
signature.asc
Description: Digital signature
On Sun, Nov 17, 2013 at 09:58:51AM +0100, Andreas Werner wrote:
Revision 2:
- delete the pch_err completly instead of changing to pch_dbg
because there is already a pch_dbg at the function who calls
pch_i2c_getack.
- Fixed message line issue
I prefer this below
Is there another reason why pch_i2c_getack returned EPROTO?
May be ENXIO was introduced later?
Imperfect review :)
I think we can just replace the -EIO with -ENXIO or do you want to pick up
the return
vale of pch_i2c_getack and return that ?
The latter. As a rule of thumb, it is usually
On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote:
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
Is there another reason why pch_i2c_getack returned EPROTO?
May be ENXIO was introduced later?
Imperfect review :)
I think we can just replace the -EIO
Sometimes its really usfull to look closely :-)
I can't do this for every patch right from the beginning since my time
is limited. I usually start with letting people sort it out themselves.
signature.asc
Description: Digital signature
On Sun, Nov 17, 2013 at 06:46:20PM +0100, Andreas Werner wrote:
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages if there was no ACK
received.
i2cdetect normally print a table with all the available devices. If there
is no
Linus,
here is the pull request from the i2c subsystem for 3.13:
* new drivers for exynos5, bcm kona, and st micro
* bigger overhauls for drivers mxs and rcar
* typical driver bugfixes, cleanups, improvements
* got rid of the superfluous 'driver' member in i2c_client struct
This touches a few
Actually, can we remove the whole clientdata setting there?
Commit 0998d0631001 (device-core: Ensure drvdata = NULL when no driver is
bound) modified the driver core to always clear out that field. Same seems
to apply if driver probe fails.
Oh, nice, missed that commit. That indeed should
On Fri, Feb 07, 2014 at 10:12:51AM +0530, Naveen Krishna Chatradhi wrote:
This patch adds a new compatible and uses variant struct to support
HSI2C module on Exynos5260. Updates the Documentation dt bindings.
Also resets the module as an init sequence (Needed by Exynos5260).
Signed-off-by:
On Fri, Feb 07, 2014 at 10:13:15AM +0530, Naveen Krishna Chatradhi wrote:
fifo_depth of the HSI2C is not constant
Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
Exynos5260 supports fifo_depth of 16bytes.
This patch configures the fifo_depth based on HSI2C modules version.
On Thu, Mar 06, 2014 at 01:35:59PM +, David Howells wrote:
Add tracepoints into the I2C message transfer function to retrieve the message
sent or received. The following config options must be turned on to make use
of the facility:
CONFIG_FTRACE
On Thu, Mar 06, 2014 at 01:36:06PM +, David Howells wrote:
The SMBUS tracepoints can be enabled thusly:
echo 1 /sys/kernel/debug/tracing/events/i2c/enable
and will dump messages that can be viewed in /sys/kernel/debug/tracing/trace
that look like:
... smbus_read:
On Sun, Feb 09, 2014 at 07:47:40PM +0100, Richard Weinberger wrote:
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger rich...@nod.at
BTW I updated the commit message to be more proper IMO (you didn't
actually remove the symbol, no?)
===
i2c: Remove usage of orphaned
Linus,
here is a Kconfig fix for the I2C subsystem. Please pull.
Thanks,
Wolfram
The following changes since commit fa389e220254c69ffae0d403eac4146171062d08:
Linux 3.14-rc6 (2014-03-09 19:41:57 -0700)
are available in the git repository at:
Hi,
I'll be away from the net and emails from March, 14th until March, 23rd.
For urgent matters, I'll trust the I2C mailing list to take care.
Kind regards,
Wolfram
signature.asc
Description: Digital signature
.
Signed-off-by: Wolfram Sang w...@the-dreams.de
[1] https://lists.01.org/pipermail/kbuild-all/2014-February/003252.html
---
arch/avr32/include/asm/bugs.h | 2 +-
arch/avr32/include/asm/processor.h | 7 +--
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/avr32
From: Wolfram Sang w...@sang-engineering.com
Signed-off-by: Wolfram Sang w...@sang-engineering.com
---
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 64
1 file changed, 64 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
b/drivers/pinctrl/sh-pfc/pfc
On Mon, Feb 24, 2014 at 08:28:20AM +0100, Hans-Christian Egtvedt wrote:
Around Sat 22 Feb 2014 09:28:27 +0100 or thereabout, Wolfram Sang wrote:
Having cpu_data as a parameterless macro can easily cause build failures
because it can be a variable name like in linux/pm_domain.h [1]. So
And for the buffer: %*phN is difficult to read IMO. What about %*ph? Or
%*phD at least?
My problem with that is that it increases the length of the output by 50% and
there's a hard limit on how much output we may produce.
Is it PAGE_SIZE? How is this handled when the buffer is so big
Also, the I2C tracing has first 'f' then 'a', that should be consistent,
too.
Flags first or address first? Do you have a preference (for both)?
I'd say address first, yet no strong preference.
Can we have something like this for 'flags'?
There's a __print_flags() which should
On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote:
The Allwinner A31 SoC using that IP has a reset controller maintaining
it reset unless told otherwise.
Add some optional reset support to the driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
Reviewed-by:
201 - 300 of 7563 matches
Mail list logo
