Re: randconfig build error with next-20141001, in drivers/i2c/algos/i2c-algo-bit.c
Le 07/10/2014 10:58, Oliver Hartkopp a écrit : On 10/06/2014 08:09 PM, Randy Dunlap wrote: On 10/06/14 10:39, Oliver Hartkopp wrote: AFAICS there is 'just' a style problem as 'configs should not enable entire subsystems'. But it finally is a correct and valid Kconfig, right? Yes, right. (..) In the unlikely case that I2C is not enabled, the user should have to enable it instead of a solitary driver enabling it. IOW, if a subsystem is disabled, the user probably wanted it that way and a single driver should not override that setting. Due to the fact that a change to 'depends on I2C' would make the config option invisible (and therefore not selectable) in the case I2C was (unlikely) disabled I would finally vote to leave it as-is. The current Kconfig entry already contains a description that points to the requirement to have I2C and I2C_ALGOBIT to be enabled to compile this driver: config CAN_PEAK_PCIEC bool "PEAK PCAN-ExpressCard Cards" depends on CAN_PEAK_PCI select I2C select I2C_ALGOBIT default y ---help--- Say Y here if you want to use a PCAN-ExpressCard from PEAK-System Technik. This will also automatically select I2C and I2C_ALGO configuration options. AFAIK the PEAK PCAN-ExpressCard is usually used in x86 architecture Laptops, so it's near to an academic discussion as x86 usually selects I2C ;-) @Stephane: When updating the help text to introduce the PCAN-ExpressCard 34 support anyway you might probably add some more information *why* the I2C support is needed (for CAN transceiver settings and status LED). And /s/I2C_ALGO/I2C_ALGOBIT/ :-) Ok! (FYI, I had already prepared the help text for introducing the PCIEC34. I will subst I2C_ALGO as well. I'll prepare the patch asap...) Regards, Stéphane Tnx & best regards, Oliver -- PEAK-System Technik GmbH Sitz der Gesellschaft Darmstadt Handelsregister Darmstadt HRB 9183 Geschaeftsfuehrung: Alexander Gach, Uwe Wilhelm -- -- 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
Re: Questions about i2c_transfer() usage in timer context...
Merci Jean, Thx for the quick answer. I think this will help. Stéphane Le 20/02/2012 14:11, Jean Delvare a écrit : Bonjour Stéphane, On Mon, 20 Feb 2012 14:01:52 +0100, Stephane Grosjean wrote: I'm facing a deadlock regarding a timer callback which is only calling i2c_transfer(), and I wonder if this comes from that call: I first googled and found that i2c_transfer() may sleep (which is forbidden in my timer callback) but when I have a look the beginning of the function, it starts to check if it is in any atomic context, before trying to acquire a lock... So I'm afraid I'm lost and I hope someone will be able to understand to that question: might i2c_transfer() be used in a timer callback or should I handle my periodic call to i2c_tranfer() by means of a delayed work? Depends on the underlying I2C adapter driver. One of the sleep causes is indeed the acquisition of the mutex in i2c_transfer(). However the function then calls a driver specific callback function (adap->algo->master_xfer) which may or may not sleep too depending on the implementation. So if you want your code to be portable, you have to assume that it may sleep, which means you indeed have to use a delayed work. HTH, -- PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, i...@peak-system.com 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
Questions about i2c_transfer() usage in timer context...
Hi, I'm facing a deadlock regarding a timer callback which is only calling i2c_transfer(), and I wonder if this comes from that call: I first googled and found that i2c_transfer() may sleep (which is forbidden in my timer callback) but when I have a look the beginning of the function, it starts to check if it is in any atomic context, before trying to acquire a lock... So I'm afraid I'm lost and I hope someone will be able to understand to that question: might i2c_transfer() be used in a timer callback or should I handle my periodic call to i2c_tranfer() by means of a delayed work? Thanks for your reply, Regards, Stéphane -- PEAK-System Technik GmbH, Otto-Roehm-Strasse 69, D-64293 Darmstadt Geschaeftsleitung: A.Gach/U.Wilhelm,St.Nr.:007/241/13586 FA Darmstadt HRB-9183 Darmstadt, Ust.IdNr.:DE 202220078, WEE-Reg.-Nr.: DE39305391 Tel.+49 (0)6151-817320 / Fax:+49 (0)6151-817329, i...@peak-system.com 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
