anyway is a good idea.
I think it could be best to stick with the bootloader configuration if
no platform data nor device tree data are given.
FWIW, the common policy for hwmon drivers is actually to not change the
device configuration unless they really have to.
--
Jean Delvare
, 0 },
No, this is a list of device names, nor driver names, so the use of
DRVNAME is inappropriate. Also, again, if your driver supports the g763
it should be listed here too.
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, g762_id);
--
Jean Delvare
Documentation/hwmon/max6697
create mode 100644 drivers/hwmon/max6697.c
create mode 100644 include/linux/platform_data/max6697.h
Reviewed-by: Jean Delvare kh...@linux-fr.org
Please update lm-sensors' wiki to mention this driver.
--
Jean Delvare
___
devicetree
+
+#include linux/types.h
+
+/*
+ * For all bit masks:
+ * bit 0:local temperature
+ * bit 1..7: remote temperatures
+ */
+struct max6697_platform_data {
+ bool smbus_timeout_disable; /* set to disable smbus timeouts */
SMBus
--
Jean Delvare
ideality_value;
+};
+
+#endif /* MAX6697_H */
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Roeck li...@roeck-us.net
I plan to line this driver up for 3.9. Only change from the code below is to
replace SENSORS_LIMIT with clamp_val. Any objections, make yourself heard.
I am in the process of reviewing this driver, I do have some comments
and hope to be done by tomorrow evening.
--
Jean
On Mon, 15 Oct 2012 10:59:19 +0800, Bo Shen wrote:
On 10/10/2012 10:54, Bo Shen wrote:
On 9/19/2012 23:54, Jean Delvare wrote:
On Wed, 19 Sep 2012 09:28:04 -0600, Stephen Warren wrote:
The problematic code appears to be:
snprintf(adap-name, sizeof(adap-name), i2c-gpio%d, pdev-id
*/
adap-name = dev_name(pdev-dev);
else
snprintf(adap-name, sizeof(adap-name), i2c-gpio%d, pdev-id);
?
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
i2c_adapter *i2c_verify_adapter(struct device *dev);
static inline struct i2c_client *kobj_to_i2c_client(struct kobject *kobj)
{
I am fine with this patch:
Acked-by: Jean Delvare kh...@linux-fr.org
I can merge it if you want, but if it is easier for you to merge it
through a different
everybody happy?
Note that I2C allows clock stretching by the slaves so even without the
extra delay incurred by hardware state switching, the bus operating
frequency is already a maximum rather than a guaranteed valued.
--
Jean Delvare
___
devicetree
of patch
adding DT-support (prepared by Thomas Chou[1]) used i2c-gpio - could we
stick to that name?
[1] https://lkml.org/lkml/2011/2/23/584
Yes, please. The gpio subsystem normalized its driver names to gpio-*,
so we shouldn't use that anywhere else to avoid confusion.
--
Jean Delvare
mode 100644 include/linux/serial_pxa.h
I am not involved in this in any way so please don't include me in the
Cc list.
Thanks,
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
remember the exact date... must have
been in 1986.
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
| 10 ++-
4 files changed, 212 insertions(+), 86 deletions(-)
Applied, thanks.
I'll send all my hwmon patches to Linus later today.
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https
[ADS1015_CONFIG_CHANNELS];
};
#endif /* LINUX_ADS1015_H */
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Thu, 3 Mar 2011 15:09:28 -0700, Grant Likely wrote:
On Thu, Mar 3, 2011 at 3:02 PM, Jean Delvare kh...@linux-fr.org wrote:
I will leave it up to Dirk to decide how much time he wants to spend on
this. He has already been very patient with the driver review process
and I do not want
-device data is better in my opinion.
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
-specific code.
I didn't follow closely why it was needed, but I will trust you and the
code contributor. I have no objection.
--
Jean Delvare
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree
18 matches
Mail list logo
