th
option -f. But then there are plenty of ways to corrupt any device that
way, regardless of the driver (or even without any driver bound to the
device, if you run multiple i2c-dev-based user-space tools in
parallel.) So I'd say this is not relevant.
--
Jean Delvare
SUSE L3 Support
--
To unsub
Hi Corentin,
On Wed, 18 Nov 2015 13:55:56 +0100, LABBE Corentin wrote:
> The simple_strtoul function is marked as obsolete.
> This patch replace it by kstrtou8.
>
> Signed-off-by: LABBE Corentin
Reviewed-by: Jean Delvare
Tested-by: Jean Delvare
Note: when there's a singl
* error code that it could return are invalid
> > according
> > +* to Documentation/i2c/fault-codes
>
> -> …codes.
>
> > + */
> > + if (kstrtou8(p + 1, 16, &data->byte))
> > +
turn are invalid according
> + * to Documentation/i2c/fault-codes
> + */
> + err = kstrtou8(p + 1, 16, &data->byte);
> + if (err)
> + return -EPROTO;
>
8 B/s with 1-byte page (default)
> 3.9 KB/s with 128-byte* page (via platform data)
>
> *limited to 31-bytes by I2C_SMBUS_BLOCK_MAX - 1.
>
> Signed-off-by: Nate Case
> Signed-off-by: Aaron Sierra
> Reviewed-by: Jean Delvare
> ---
> v2 - Account for changes related
*/
> + use_smbus = I2C_SMBUS_BYTE_DATA;
> + } else if (i2c_check_functionality(client->adapter,
> I2C_FUNC_SMBUS_READ_I2C_BLOCK)) {
> use_smbus = I2C_SMBUS_I2C_BLOCK_DATA;
> } else
I2C_SMBUS_BLOCK_MAX;
if (use_smbus && write_max > smbus_limit)
write_max = smbus_limit;
This might not even be slower, and IMHO it is easier to understand.
> at24->write_max = write_max;
>
>
On Thu, 5 Nov 2015 11:40:25 -0800, Alexandra Yates wrote:
> Adding Intel codename Lewisburg platform device IDs for SMBus.
>
> Signed-off-by: Alexandra Yates
> Reviewed-by: Jean Delvare
> ---
> Documentation/i2c/busses/i2c-i801 | 1 +
> drivers/i2c/busses/Kconfig
While in general I am in favor of passing error values down the stack,
here I'm not sure. kstrtou8 could return -ERANGE or -EINVAL which makes
no sense as an i2c adapter fault code. According to
Documentation/i2c/fault-codes, -EPROTO or -EIO would be more
appropriate.
>
use_smbus_write = I2C_SMBUS_BYTE_DATA;
> chip.page_size = 1;
> @@ -599,7 +692,8 @@ static int at24_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> if (write_max > io_limit)
> write_max = io_limit;
> if (use_smbus && write_max > I2C_SMBUS_BLOCK_MAX)
> - write_max = I2C_SMBUS_BLOCK_MAX;
> + write_max = I2C_SMBUS_BLOCK_MAX -
> + !!(chip.flags & AT24_FLAG_ADDR16);
This test still looks wrong to me when AT24_FLAG_ADDR16 is set. If
write_max is 33 you'll properly clip it to 31. However if it's 32
you'll leave it at 32 and the subsequent block write attempts of 33
bytes will fail.
> at24->write_max = write_max;
>
> /* buffer (data + address at the beginning) */
Otherwise looks "good", assuming the user understands the risks and
limitations.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
VICE(PCI_VENDOR_ID_INTEL,
> PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_SMBUS) },
... and now in the middle of the last list? I would appreciate more
consistency.
These are all details of course, overall the changes look good, so you
can add:
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BAYTRAIL_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LBG_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_LBG_SSKU_SMBUS) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS) }
if (chip.flags & AT24_FLAG_ADDR16)
> - return -EPFNOSUPPORT;
> -
> - if (i2c_check_functionality(client->adapter,
> + if (chip.flags & AT24_FLAG_ADDR16) {
> + /*
> + * This will be slow, but b
Hi Aaron,
On Mon, 2 Nov 2015 10:35:22 -0600 (CST), Aaron Sierra wrote:
> - Original Message -
> > From: "Jean Delvare"
> > Sent: Monday, November 2, 2015 7:42:09 AM
> > On Thu, 3 Sep 2015 14:52:35 -0500 (CDT), Aaron Sierra wrote:
> > > @@ -612,
t address devices.
> + */
> + use_smbus_write = I2C_SMBUS_BYTE_DATA;
> + chip.page_size = 1;
> + } else if (!(chip.flags & AT24_FLAG_ADDR16) &&
> + i2c_check_functionality(client->
ion. Your micro-controllers
need to have a slave I2C address if you want to be able to talk to them
from the Pi. Check the python code and the hardware documentation, the
slave address is certainly mentioned there.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line &q
e first place? You only need to
steal one byte from the data buffer for the extra address byte, so
I'd expect write_max to be capped at I2C_SMBUS_BLOCK_MAX - 1.
> at24->write_max = write_max;
>
> /* buffer (data + address at
xact list of commands included in your specific case depends what
the packager decided to do. I suppose that commands that are not
relevant on the Raspberry Pi are not included in the package.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux
Le Monday 26 October 2015 à 13:31 +0200, Mika Westerberg a écrit :
> On Mon, Oct 26, 2015 at 01:26:56PM +0200, Jarkko Nikula wrote:
> > Add missing entries into i2c-i801 documentation and Kconfig about recently
> > added Intel DNV and Broxton.
> >
> > Suggested-by: Jean
MBUS) },
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_DNV_SMBUS) },
> + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BROXTON_SMBUS) },
> { 0, }
> };
>
Does this one not have FEATURE_TCO as DNV does? If it does, you'll need
to add a line for it in the swit
> priv->features |= FEATURE_SMBUS_PEC;
Looks good, but please also update Documentation/i2c/busses/i2c-i801
and drivers/i2c/busses/Kconfig.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Le Friday 25 September 2015 à 14:37 +0100, Matt Fleming a écrit :
> On Fri, 25 Sep, at 09:36:10AM, Jean Delvare wrote:
> > On Wed, 12 Aug 2015 08:42:18 -0700, Jim Davis wrote:
> > > Building with the attached random configuration file,
> > >
> >
Hi Guenter,
Le Friday 25 September 2015 à 06:29 -0700, Guenter Roeck a écrit :
> On 09/25/2015 01:10 AM, Jean Delvare wrote:
> > ITCO_WDT selects I2C_I801 but does not select its dependencies (I2C.)
> > This can result in link-time failures:
> >
> > drivers/built-in.
2C as well.
Reported-by: Jim Davis
Signed-off-by: Jean Delvare
Fixes: 2a7a0e9bf7 ("watchdog: iTCO_wdt: Add support for TCO on Intel
Sunrisepoint")
Cc: Matt Fleming
Cc: Guenter Roeck
Cc: Lee Jones
Cc: Wim Van Sebroeck
---
drivers/watchdog/Kconfig |2 +-
1 file changed, 1 insert
`i2c_new_device'
Sorry for the late reply. The error is caused by the following
combination of options:
CONFIG_I2C=m
CONFIG_I2C_I801=y
I can reproduce it even with mainline now. This is caused by
CONFIG_ITCO_WDT=y, which selects CONFIG_I2C_I801=y without selecting
its dependencies (CONFIG_I
On Tue, 22 Sep 2015 13:41:27 -0400, Benjamin Tissoires wrote:
> Hi All,
>
> any estimate when anybody will be able to review this series?
It's on my to-do list, hopefully this week or early next week. For the
core part it's probably better if Wolfram can do the review.
--
J
0x0008
> #define I2C_FUNC_NOSTART 0x0010 /* I2C_M_NOSTART */
> #define I2C_FUNC_SLAVE 0x0020
> +#define I2C_FUNC_NO_CLK_STRETCH 0x0040 /* No check for SCL
> low */
> #define I2C_FUNC_SMBUS_BLOCK_PROC_CALL 0x8000 /* SM
The first part of the comment is wrong since November 2007, delete it.
The second part of the comment is related to I2C_PEC, not I2C_SLAVE, so
move it where it belongs.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
drivers/i2c/i2c-dev.c | 17 +++--
1 file changed, 7
ot;Warning: only %d/%d messages were sent\n",
> nmsgs_sent, nmsgs);
> }
> @@ -311,10 +314,17 @@ int main(int argc, char *argv[])
>
> print_msgs(msgs, nmsgs_sent, PRINT_READ_BUF | (verbose ? PRINT_HEADER |
> PRINT_WRITE_BUF : 0));
>
> - /* let Linux
644
> index 000..27f4d7a
> --- /dev/null
> +++ b/tools/i2ctransfer.c
> @@ -0,0 +1,320 @@
> +/*
> +i2ctransfer.c - A user-space program to send concatenated i2c messages
> +Copyright (C) 2015 Wolfram Sang
> +Copyright (C) 2015 Renesas Electronics Corporation
&g
On Thu, 10 Sep 2015 20:00:12 +0200, Wolfram Sang wrote:
> On Tue, Sep 08, 2015 at 11:05:49AM +0200, Jean Delvare wrote:
> > The ioctl is named I2C_RDWR for "I2C read/write". But references to it
> > were misspelled "rdrw". Fix them.
> >
> > Si
The ioctl is named I2C_RDWR for "I2C read/write". But references to it
were misspelled "rdrw". Fix them.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
drivers/i2c/i2c-dev.c|6 +++---
fs/compat_ioctl.c|2 +-
include/uapi/linux/i2c-dev.h
e usage cli API is still a moving target.
> >
> > I don't think it is anymore TBH. Not more than any other tool.
> >
> > Waiving to Jean \o_ :)
>
> OK, let me wave as well \\O//
Review in progress, will continue tomorrow.
--
Jean Delvare
SUSE L3 Support
--
To u
On Wed, 29 Jul 2015 10:58:13 -0400, Benjamin Tissoires wrote:
> On Sat, Jul 25, 2015 at 5:38 PM, Jean Delvare wrote:
> > On Sat, 25 Jul 2015 12:22:02 -0400, Benjamin Tissoires wrote:
> >> On Sat, Jul 25, 2015 at 12:11 PM, Jean Delvare wrote:
> >> > Hi Benjamin,
>
On Sat, 25 Jul 2015 12:22:02 -0400, Benjamin Tissoires wrote:
> On Sat, Jul 25, 2015 at 12:11 PM, Jean Delvare wrote:
> > Hi Benjamin,
> >
> > On Tue, 21 Jul 2015 17:24:55 -0400, Benjamin Tissoires wrote:
> >> So please disregard this series, I will send a v4 hope
Hi Benjamin,
On Tue, 21 Jul 2015 17:24:55 -0400, Benjamin Tissoires wrote:
> So please disregard this series, I will send a v4 hopefully soonish.
>From v2 directly to v4? Did I miss something?
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubs
tscl = { 0x80, PORT_STAT, 1 },
> + },
> };
>
> static int type = -1;
> @@ -103,4 +110,5 @@ MODULE_PARM_DESC(type,
> " 5 = ADM1025, ADM1030 and ADM1031 evaluation boards\n"
> " 6 = Barco LPT->DVI (K5800236) adapter\n"
> " 7
On Tue, 7 Jul 2015 16:16:38 -0400, Benjamin Tissoires wrote:
> On Jul 07 2015 or thereabouts, Jean Delvare wrote:
> > So you use the same driver callback for SMBus Alert and SMBus Host
> > Notify. This makes some sense, but if a given driver supports both, how
> > does it know
CFLAGS and LDFLAGS on the command line, and
this works for the whole package. Do you really need to set different
CFLAGS (or LDFLAGS) for different parts of i2c-tools? Seems overkill to
me.
If you really need that then this should be done consistently for all
"modules": not just tools b
ient, data->flag);
> - else
> - dev_warn(&client->dev, "no driver alert()!\n");
> - } else
> - dev_dbg(&client->dev, "alert with no driver\n");
> - device_unlock(dev);
> + if (i2c_alert(c
On Tue, 7 Jul 2015 10:23:33 -0400, Benjamin Tissoires wrote:
> Hi Jean,
>
> On Jun 29 2015 or thereabouts, Jean Delvare wrote:
> > Hi Benjamin,
> >
> > On Tue, 23 Jun 2015 14:58:18 -0400, Benjamin Tissoires wrote:
> > > SMBus Host Notify allows a slave d
On Tue, 7 Jul 2015 17:22:33 +0200, Jean Delvare wrote:
> Hi Matwey,
>
> On Mon, 29 Jun 2015 21:14:47 +0300, Matwey V. Kornilov wrote:
> > Move eeprog to separate subdir and implement Module.mk for it
> >
> > Signed-off-by: Matwey V. Kornilov
> > ---
e idea, I'll redo it myself. Some SVN magic is
needed to handle file moves properly anyway.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
0644
> --- a/include/uapi/linux/i2c.h
> +++ b/include/uapi/linux/i2c.h
> @@ -100,6 +100,7 @@ struct i2c_msg {
> #define I2C_FUNC_SMBUS_WRITE_BLOCK_DATA 0x0200
> #define I2C_FUNC_SMBUS_READ_I2C_BLOCK0x0400 /* I2C-like block
> xfer */
> #define I2C_FUNC_SMBUS_WRITE_I2C_BLOCK 0x0
+install: install-eepromer
> +
> +uninstall: uninstall-eepromer
I don't think it makes sense to integrate eeprom and eepromer in the
main build system if the plan is to get rid of them. I'd rather only
integrate eeprog, so that distributions ship only that and everybody
uses only that
l Thimm) has noticed as
well and is already looking at the problem.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
a switch which will
> only link functions from libi2c statically.
>
> Signed-off-by: Wolfram Sang
> ---
> Makefile| 4
> tools/Module.mk | 4
> 2 files changed, 8 insertions(+)
> (...)
Applied, thanks!
--
Jean Delvare
SUSE L3 Support
--
To unsubscrib
at's much better than my proposal.
I'm wondering if we should make it even more flexible, but I'm not sure
if it's worth the effort... Are you calling "make install" after that?
I guess not.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
erived from
lm-sensors' Makefile, which itself was designed based on the paper
"Recursive Make Considered Harmful" - the one you just mentioned. Ah,
irony ;-)
i2c-tools's Makefile is modular. Not recursive.
> external projects if embrace it or no. Honestly I think that a
>
On Wed, 17 Jun 2015 11:23:38 +0200, Angelo Compagnucci wrote:
> Please, please, find that time! I really would like to package
> i2c-tools 3.1 with python3 support in buildroot!
OK, releasing i2c-tools 3.1.2 was easy after all, it's done now.
--
Jean Delvare
SUSE L3 Support
--
To
Hi Angelo,
On Tue, 26 May 2015 09:56:47 +0200, Angelo Compagnucci wrote:
> Dear Jean Delvare,
>
> Now that python3 support was added to python-smbus, could you release
> a new stable version with it?
>
> This way, py-smbus with python3 support could be included in
> distr
shouldn't this -Llib rather been written
-L$(LIB_DIR)?
Also it might make sense to check if USE_STATIC_LIB is set when
BUILD_STATIC_LIB isn't and complain about it?
>
> TOOLS_TARGETS:= i2cdetect i2cdump i2cset i2cget
>
--
Jean Delvare
SUSE L3 Support
--
To unsubscrib
_SERVERWORKS,
> PCI_DEVICE_ID_SERVERWORKS_OSB4) },
> { PCI_DEVICE(PCI_VENDOR_ID_SERVERWORKS,
Probably too late but anyway:
Acked-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Chi", "Jone",
+ "GCT Semiconductor Inc.", "Hong Kong Zetta Device Technology",
+ "Unimemory Technology(s) Pte Ltd", "Cuso", "Kuso",
+ "Uniquify Inc.", "Skymedi Corporation", "Core Chance Co. Ltd"
,
"Teradiant Networks",
+ "Memorysolution GmbH (former Peak Electronics)", "Litchfield Communication",
"Accton Technology", "Teradiant Networks",
"Scaleo Chip (former Europe Technologies)", "Cortina Systems", "RAM
Components&quo
;
- if (parity($ai) == 0) {
- $ai |= 0x80;
- }
- return (manufacturer_ddr3($ai, $first), \@bytes);
+ return (manufacturer_common($ai, $first), \@bytes);
}
sub manufacturer_data(@)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the l
& 0x7F) - 1];
$manufacturer =~ s/ \(former .*\)$// if $opt_side_by_side;
$manufacturer .= "? (Invalid parity)" if parity($count) != 1;
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
rs
+or ($code & 0x7F) - 1 >= @{$vendors[$count & 0x7F]};
$manufacturer = $vendors[$count & 0x7F][($code & 0x7F) - 1];
$manufacturer =~ s/ \(former .*\)$// if $opt_side_by_side;
$manufacturer .= "? (Invalid parity)"
t;= @{$vendors[$count & 0x7F]};
It is equivalent but more obviously correct as it matches the array
access on the following line.
Also, even after your fix, I think the code is not completely safe, as
we still don't check for ($code & 0x7F) being 0, nor do we verify that
$count & 0
as aligned.
As the driver maintainer, I am fine with both unaligned or tab-aligned.
Space-aligned as I did originally was not a good idea, I admit.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
| 9 +
> > drivers/i2c/busses/Makefile| 1 +
> > drivers/i2c/busses/i2c-mt65xx.c| 748
> > +
> > 4 files changed, 799 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt
> > create mode 100644 drivers/i2c/busses/i2c-mt65xx.c
>
> Why have you sent me this?
Mind you, I was wondering exactly the same ;-)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
minor
optimization, but I may be wrong. Adding Daniel to Cc, he added that
code to the i2c-i801 driver. Daniel, any comment on this?
Equally mysterious to me is:
priv->status |= status;
in i801_isr() where it would seem that a simple "=" would suffice.
--
Jean De
esting
> > and some
> > more beautification. However, I've been using it already to test the
> > i2c_quirk
> > infrastructure and Renesas I2C controllers.
>
> Jean, my tests went well and so I want to brush it up for inclusion into
> i2c-tools upstream. Any show-stoppers
Hi Ellen,
On Wed, 15 Apr 2015 13:46:17 -0700, Ellen Wang wrote:
> On 4/15/2015 5:08 AM, Jean Delvare wrote:
> > On Mon, 13 Apr 2015 17:11:59 -0700, Ellen Wang wrote:
> >> On a CRC error while using hardware-supported PEC, an additional
> >> error bit is set in the aux
on other matters but I'll look into this ASAP. A
quick comparison between our patches suggests that yours only clears
the PEC status bit while mine also reports the error properly to the
caller, so mine might be a better working base. Maybe you could review
and/or test my patch as a repl
atters
that they are meaningful. As much as possible you should pass error
codes from the lower layers. parport_claim_or_block() and
i2c_bit_add_bus() return proper error codes so you should record and
transmit them. Only parport_register_device() does not, so you have to
craft one and -ENODEV seems appropriate to me.
Note: I can test this driver.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
hael S. Tsirkin
>
> Acked-by: Wolfram Sang
>
> I don't know if I should take it. If so, let me know.
Don't, the series was nacked meanwhile.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the bo
.h,
> +names for the bridge ID and the subvendor ID in include/uapi/linux/pci_ids.h,
> and then add a case for your subdevice ID at the right place in
> drivers/pci/quirks.c. Then please give it very good testing, to make sure
> that the unhidden SMBus doesn't conflict with e.g
0x0f12
> #define PCI_DEVICE_ID_INTEL_BRASWELL_SMBUS 0x2292
> #define PCI_DEVICE_ID_INTEL_COUGARPOINT_SMBUS 0x1c22
No objection from me.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscrib
slave_addr whether the address
is a 7-bit or 10-bit one. But please do that by passing a flag (e.g.
tenbit as above) to it, not funcs.
> You'll also need to update the Usage: strings for the various tools.
Correct, and the manual pages too.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t my thing (as a developer, I mean.)
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
kula
> ---
> Changes from v2:
> - over 80 characters long pcim_iomap_regions line splitted
> - gotos and error labels removed
> ---
> drivers/i2c/busses/i2c-i801.c | 25 +----
> 1 file changed, 9 insertions(+), 16 deletions(-)
> (...)
Reviewed-by: Jean Delvar
usses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -1324,7 +1324,7 @@ static int i801_resume(struct pci_dev *dev)
> {
> pci_set_power_state(dev, PCI_D0);
> pci_restore_state(dev);
> - return pci_enable_device(dev);
> + return 0;
> }
> #else
>
Hi Jarkko,
On Fri, 13 Feb 2015 13:13:18 +0200, Jarkko Nikula wrote:
> On 02/13/2015 12:33 PM, Jean Delvare wrote:
> > This looks reasonable but have you tested this change on a range of
> > actual laptops to make sure it has no unexpected side effect?
>
> Unfortunately I hav
On Fri, 13 Feb 2015 13:47:07 +0200, Jarkko Nikula wrote:
> On 02/13/2015 12:47 PM, Jean Delvare wrote:
> > On Wed, 11 Feb 2015 14:32:08 +0200, Jarkko Nikula wrote:
> >> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> >> index 5fb354
;
> exit:
> return err;
> }
Now that the exit path is empty, wouldn't it make sense to return
directly on error? My understanding is that this is one of the benefits
of managed device resources.
> @@ -1301,8 +1300,6 @@ static void i801_remove(struct pci_dev *dev)
> i2c_del_adap
#else
> #define i801_suspend NULL
This looks reasonable but have you tested this change on a range of
actual laptops to make sure it has no unexpected side effect?
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the
tures & FEATURE_IRQ)
> - free_irq(dev->irq, priv);
> pci_release_region(dev, SMBBAR);
>
> - kfree(priv);
> /*
>* do not call pci_disable_device(dev) since it can cause hard hangs on
>* some systems during power-off (eg. Fujitsu-Siemens Lifebook E8010)
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
x-0x%Lx\n", priv->smba,
> + dev_err(&dev->dev,
> + "Failed to request SMBus region 0x%lx-0x%Lx\n",
> + priv->smba,
> (unsigned long long)pci_resource_end(dev, SMBBAR));
>
riv->features & FEATURE_IRQ)
> - free_irq(dev->irq, priv);
> pci_release_region(dev, SMBBAR);
>
> - kfree(priv);
> /*
>* do not call pci_disable_device(dev) since it can cause hard hangs on
>* some systems during power
h
that.
Reviewed-by: Jean Delvare
>
> Signed-off-by: Jarkko Nikula
> ---
> drivers/i2c/busses/i2c-i801.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 8fafb254e42a..e31aa987b
olve the deadlock due to the i2c bus topology and
i2c-based muxing. If I am correct then it would be clearer to make that
two separate patches with better descriptions.
And if I'm wrong then the patch needs a better description too ;-)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from th
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.
I2C bus drivers which implement slave support must select
I2C_SLAVE.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
Changes since v2:
* Added missing #if around
On Mon, 26 Jan 2015 19:05:09 +0100, Wolfram Sang wrote:
> On Mon, Jan 26, 2015 at 07:00:47PM +0100, Jean Delvare wrote:
> > Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
> > included unconditionally, even when it is not needed.
> >
> > Signed-o
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.
Signed-off-by: Jean Delvare
Cc: Wolfram Sang
---
Changes since v1:
* Let I2C_RCAR select I2C_SLAVE
Wolfram, you mentioned i2c-sh_mobile but that driver doesn't se
what about bus drivers with slave mode support must select
CONFIG_I2C_SLAVE? This solves my problem nicely, and makes no change
compared to the current situation for people using slave mode.
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
agree that
it seems overkill given the small amount of code.
> Mabye #ifdef is a good start. I could do it as well, I don't mind.
Something like this?
From: Jean Delvare
Subject: i2c: Only include slave support if selected
Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it
On Thu, 22 Jan 2015 14:28:10 +0100, Michael Mercier wrote:
> I have only tested read_i2c_block_data write_i2c_block_data for python
> 3.2 and python 2.7.
>
> I think you can push these patchs upstream.
I committed both patches. I also added python 3 support to the stable
branc
ly include it when
CONFIG_I2C_SLAVE is set. Alternatively the code could be moved to a
separate module altogether. What do you think?
Thanks,
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@
3.2 and python 2.7.
>
> I think you can push these patchs upstream.
Great, thanks for testing :)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; LDFLAGS="$(LDFLAGS) -Llib -li2c"
$(PYTHON) setup.py
all-python: $(INCLUDE_DIR)/i2c/smbus.h
$(DISTUTILS) build
But please keep in mind that my python knowledge is non-existent so it
might be plain wrong. Hopefully Angelo can comment on this.
--
Jean Delvare
SUSE L3 Support
--
To unsu
/python3.2/dist-packages/smbus.cpython-32mu.so: undefined
> symbol: i2c_smbus_process_call
>
> Any idea?
Not really, again I know nothing about python. But didn't you have the
same problem with Angelo's patch?
Maybe Angelo has an idea.
--
Jean Delvare
SUSE L3 Support
--
T
Hi Angelo,
On Mon, 19 Jan 2015 16:13:26 +0100, Angelo Compagnucci wrote:
> Dear Jean Delvare,
>
> Attached you can find a patch that implements py-smbus for python3
> with python2 backward compatibility.
> This patch is not heavily tested, but it wors well for me.
Thanks a lot f
hich makes
py-smbus work for both python version 2 and version 3, I can't apply
it. I don't think it makes sense to break compatibility with one
version to make the other one work.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Wolfram,
On Mon, 19 Jan 2015 10:31:38 +0100, Wolfram Sang wrote:
> Having the maintainer on CC helps to see i2c-tools related messages in
> the bulk of messages for the Linux kernel I2C subsystem.
>
> Signed-off-by: Wolfram Sang
> Cc: Jean Delvare
> ---
> README | 2 ++
gt; into a hard hang.
Turns an invisible memory leak into a visible bug, giving you the
opportunity to fix it. You should be grateful ;-)
That being said, if this completion serves no other purpose then it
can go away, I don't mind.
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list
Hi Guenter,
On Wed, 14 Jan 2015 08:24:43 -0800, Guenter Roeck wrote:
> On Wed, Jan 14, 2015 at 04:15:25PM +0100, Jean Delvare wrote:
> > I did that. On my system the i2c-i801 driver instantiates an
> > i2c-mux-gpio device. Unloading the i2c-i801 driver removes that device
> &
On Wed, 14 Jan 2015 15:54:52 +0200, Pantelis Antoniou wrote:
> On Jan 14, 2015, at 15:49 , Jean Delvare wrote:
> > That being said, nobody complained about this in 11 years, so I would
> > be surprised if it was plain wrong. I'd rather question the test code.
> > Wh
other subsystems.
In fact I'm not sure what purpose the completion serves exactly. I
expected it to delay the i2c adapter removal until no sysfs user of it
was left (as the comment suggests.) However I just tested unloading an
i2c bus driver while its adapter's new_device attribute was
Hi Uwe,
On Tue, 25 Nov 2014 22:14:32 +0100, Uwe Kleine-König wrote:
> On Wed, Jan 08, 2014 at 02:28:49PM +0100, Jean Delvare wrote:
> > Having looked at the code in deeper detail, I think I understand what
> > is going on. The problem is with:
> >
> > i2c_set_ad
1 - 100 of 1704 matches
Mail list logo
