* [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 8:57 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 8:57 UTC (permalink / raw) To: linux-arm-kernel This patch renames structures, variables and functions to indicate support for various MC13xxx chips. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> --- drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- 1 file changed, 63 insertions(+), 72 deletions(-) diff --git a/drivers/hwmon/mc13783-adc.c b/drivers/hwmon/mc13783-adc.c index 982d862..abffdfe 100644 --- a/drivers/hwmon/mc13783-adc.c +++ b/drivers/hwmon/mc13783-adc.c @@ -28,30 +28,28 @@ #include <linux/init.h> #include <linux/err.h> -#define DRIVER_NAME "mc13783-adc" - /* platform device id driver data */ #define MC13783_ADC_16CHANS 1 -#define MC13783_ADC_BPDIV2 2 +#define MC13892_ADC_BPDIV2 2 -struct mc13783_adc_priv { +struct mc13xxx_adc_priv { struct mc13xxx *mc13xxx; struct device *hwmon_dev; char name[10]; }; -static ssize_t mc13783_adc_show_name(struct device *dev, struct device_attribute +static ssize_t mc13xxx_adc_show_name(struct device *dev, struct device_attribute *devattr, char *buf) { - struct mc13783_adc_priv *priv = dev_get_drvdata(dev); + struct mc13xxx_adc_priv *priv = dev_get_drvdata(dev); return sprintf(buf, "%s\n", priv->name); } -static int mc13783_adc_read(struct device *dev, +static int mc13xxx_adc_read(struct device *dev, struct device_attribute *devattr, unsigned int *val) { - struct mc13783_adc_priv *priv = dev_get_drvdata(dev); + struct mc13xxx_adc_priv *priv = dev_get_drvdata(dev); struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); unsigned int channel = attr->index; unsigned int sample[4]; @@ -70,18 +68,18 @@ static int mc13783_adc_read(struct device *dev, return 0; } -static ssize_t mc13783_adc_read_bp(struct device *dev, +static ssize_t mc13xxx_adc_read_bp(struct device *dev, struct device_attribute *devattr, char *buf) { unsigned val; struct platform_device *pdev = to_platform_device(dev); kernel_ulong_t driver_data = platform_get_device_id(pdev)->driver_data; - int ret = mc13783_adc_read(dev, devattr, &val); + int ret = mc13xxx_adc_read(dev, devattr, &val); if (ret) return ret; - if (driver_data & MC13783_ADC_BPDIV2) + if (driver_data & MC13892_ADC_BPDIV2) val = DIV_ROUND_CLOSEST(val * 9, 2); else /* @@ -93,11 +91,11 @@ static ssize_t mc13783_adc_read_bp(struct device *dev, return sprintf(buf, "%u\n", val); } -static ssize_t mc13783_adc_read_gp(struct device *dev, +static ssize_t mc13xxx_adc_read_gp(struct device *dev, struct device_attribute *devattr, char *buf) { unsigned val; - int ret = mc13783_adc_read(dev, devattr, &val); + int ret = mc13xxx_adc_read(dev, devattr, &val); if (ret) return ret; @@ -111,21 +109,21 @@ static ssize_t mc13783_adc_read_gp(struct device *dev, return sprintf(buf, "%u\n", val); } -static DEVICE_ATTR(name, S_IRUGO, mc13783_adc_show_name, NULL); -static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, mc13783_adc_read_bp, NULL, 2); -static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, mc13783_adc_read_gp, NULL, 5); -static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, mc13783_adc_read_gp, NULL, 6); -static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, mc13783_adc_read_gp, NULL, 7); -static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, mc13783_adc_read_gp, NULL, 8); -static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, mc13783_adc_read_gp, NULL, 9); -static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, mc13783_adc_read_gp, NULL, 10); -static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, mc13783_adc_read_gp, NULL, 11); -static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, mc13783_adc_read_gp, NULL, 12); -static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, mc13783_adc_read_gp, NULL, 13); -static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, mc13783_adc_read_gp, NULL, 14); -static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, mc13783_adc_read_gp, NULL, 15); - -static struct attribute *mc13783_attr_base[] = { +static DEVICE_ATTR(name, S_IRUGO, mc13xxx_adc_show_name, NULL); +static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, mc13xxx_adc_read_bp, NULL, 2); +static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 5); +static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 6); +static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 7); +static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 8); +static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 9); +static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 10); +static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 11); +static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 12); +static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 13); +static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 14); +static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 15); + +static struct attribute *mc13xxx_attr_base[] = { &dev_attr_name.attr, &sensor_dev_attr_in2_input.dev_attr.attr, &sensor_dev_attr_in5_input.dev_attr.attr, @@ -134,12 +132,12 @@ static struct attribute *mc13783_attr_base[] = { NULL }; -static const struct attribute_group mc13783_group_base = { - .attrs = mc13783_attr_base, +static const struct attribute_group mc13xxx_group_base = { + .attrs = mc13xxx_attr_base, }; /* these are only used if MC13783_ADC_16CHANS is provided in driver data */ -static struct attribute *mc13783_attr_16chans[] = { +static struct attribute *mc13xxx_attr_16chans[] = { &sensor_dev_attr_in8_input.dev_attr.attr, &sensor_dev_attr_in9_input.dev_attr.attr, &sensor_dev_attr_in10_input.dev_attr.attr, @@ -147,12 +145,12 @@ static struct attribute *mc13783_attr_16chans[] = { NULL }; -static const struct attribute_group mc13783_group_16chans = { - .attrs = mc13783_attr_16chans, +static const struct attribute_group mc13xxx_group_16chans = { + .attrs = mc13xxx_attr_16chans, }; /* last four channels may be occupied by the touchscreen */ -static struct attribute *mc13783_attr_ts[] = { +static struct attribute *mc13xxx_attr_ts[] = { &sensor_dev_attr_in12_input.dev_attr.attr, &sensor_dev_attr_in13_input.dev_attr.attr, &sensor_dev_attr_in14_input.dev_attr.attr, @@ -160,21 +158,21 @@ static struct attribute *mc13783_attr_ts[] = { NULL }; -static const struct attribute_group mc13783_group_ts = { - .attrs = mc13783_attr_ts, +static const struct attribute_group mc13xxx_group_ts = { + .attrs = mc13xxx_attr_ts, }; -static int mc13783_adc_use_touchscreen(struct platform_device *pdev) +static int mc13xxx_adc_use_touchscreen(struct platform_device *pdev) { - struct mc13783_adc_priv *priv = platform_get_drvdata(pdev); + struct mc13xxx_adc_priv *priv = platform_get_drvdata(pdev); unsigned flags = mc13xxx_get_flags(priv->mc13xxx); return flags & MC13XXX_USE_TOUCHSCREEN; } -static int __init mc13783_adc_probe(struct platform_device *pdev) +static int __init mc13xxx_adc_probe(struct platform_device *pdev) { - struct mc13783_adc_priv *priv; + struct mc13xxx_adc_priv *priv; int ret; const struct platform_device_id *id = platform_get_device_id(pdev); char *dash; @@ -192,19 +190,19 @@ static int __init mc13783_adc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, priv); /* Register sysfs hooks */ - ret = sysfs_create_group(&pdev->dev.kobj, &mc13783_group_base); + ret = sysfs_create_group(&pdev->dev.kobj, &mc13xxx_group_base); if (ret) return ret; if (id->driver_data & MC13783_ADC_16CHANS) { ret = sysfs_create_group(&pdev->dev.kobj, - &mc13783_group_16chans); + &mc13xxx_group_16chans); if (ret) goto out_err_create_16chans; } - if (!mc13783_adc_use_touchscreen(pdev)) { - ret = sysfs_create_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) { + ret = sysfs_create_group(&pdev->dev.kobj, &mc13xxx_group_ts); if (ret) goto out_err_create_ts; } @@ -221,60 +219,53 @@ static int __init mc13783_adc_probe(struct platform_device *pdev) out_err_register: - if (!mc13783_adc_use_touchscreen(pdev)) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_ts); out_err_create_ts: if (id->driver_data & MC13783_ADC_16CHANS) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_16chans); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_16chans); out_err_create_16chans: - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_base); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_base); return ret; } -static int mc13783_adc_remove(struct platform_device *pdev) +static int mc13xxx_adc_remove(struct platform_device *pdev) { - struct mc13783_adc_priv *priv = platform_get_drvdata(pdev); + struct mc13xxx_adc_priv *priv = platform_get_drvdata(pdev); kernel_ulong_t driver_data = platform_get_device_id(pdev)->driver_data; hwmon_device_unregister(priv->hwmon_dev); - if (!mc13783_adc_use_touchscreen(pdev)) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_ts); if (driver_data & MC13783_ADC_16CHANS) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_16chans); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_16chans); - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_base); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_base); return 0; } -static const struct platform_device_id mc13783_adc_idtable[] = { - { - .name = "mc13783-adc", - .driver_data = MC13783_ADC_16CHANS, - }, { - .name = "mc13892-adc", - .driver_data = MC13783_ADC_BPDIV2, - }, { - /* sentinel */ - } +static const struct platform_device_id mc13xxx_adc_idtable[] = { + { "mc13783-adc", MC13783_ADC_16CHANS, }, + { "mc13892-adc", MC13892_ADC_BPDIV2, }, + { } }; -MODULE_DEVICE_TABLE(platform, mc13783_adc_idtable); +MODULE_DEVICE_TABLE(platform, mc13xxx_adc_idtable); -static struct platform_driver mc13783_adc_driver = { - .remove = mc13783_adc_remove, +static struct platform_driver mc13xxx_adc_driver = { .driver = { .owner = THIS_MODULE, - .name = DRIVER_NAME, + .name = "mc13xxx-adc", }, - .id_table = mc13783_adc_idtable, + .remove = mc13xxx_adc_remove, + .id_table = mc13xxx_adc_idtable, }; +module_platform_driver_probe(mc13xxx_adc_driver, mc13xxx_adc_probe); -module_platform_driver_probe(mc13783_adc_driver, mc13783_adc_probe); - -MODULE_DESCRIPTION("MC13783 ADC driver"); +MODULE_DESCRIPTION("MC13XXX ADC driver"); MODULE_AUTHOR("Luotao Fu <l.fu@pengutronix.de>"); MODULE_LICENSE("GPL"); -- 1.8.1.5 _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 8:57 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 8:57 UTC (permalink / raw) To: linux-arm-kernel This patch renames structures, variables and functions to indicate support for various MC13xxx chips. Signed-off-by: Alexander Shiyan <shc_work@mail.ru> --- drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- 1 file changed, 63 insertions(+), 72 deletions(-) diff --git a/drivers/hwmon/mc13783-adc.c b/drivers/hwmon/mc13783-adc.c index 982d862..abffdfe 100644 --- a/drivers/hwmon/mc13783-adc.c +++ b/drivers/hwmon/mc13783-adc.c @@ -28,30 +28,28 @@ #include <linux/init.h> #include <linux/err.h> -#define DRIVER_NAME "mc13783-adc" - /* platform device id driver data */ #define MC13783_ADC_16CHANS 1 -#define MC13783_ADC_BPDIV2 2 +#define MC13892_ADC_BPDIV2 2 -struct mc13783_adc_priv { +struct mc13xxx_adc_priv { struct mc13xxx *mc13xxx; struct device *hwmon_dev; char name[10]; }; -static ssize_t mc13783_adc_show_name(struct device *dev, struct device_attribute +static ssize_t mc13xxx_adc_show_name(struct device *dev, struct device_attribute *devattr, char *buf) { - struct mc13783_adc_priv *priv = dev_get_drvdata(dev); + struct mc13xxx_adc_priv *priv = dev_get_drvdata(dev); return sprintf(buf, "%s\n", priv->name); } -static int mc13783_adc_read(struct device *dev, +static int mc13xxx_adc_read(struct device *dev, struct device_attribute *devattr, unsigned int *val) { - struct mc13783_adc_priv *priv = dev_get_drvdata(dev); + struct mc13xxx_adc_priv *priv = dev_get_drvdata(dev); struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr); unsigned int channel = attr->index; unsigned int sample[4]; @@ -70,18 +68,18 @@ static int mc13783_adc_read(struct device *dev, return 0; } -static ssize_t mc13783_adc_read_bp(struct device *dev, +static ssize_t mc13xxx_adc_read_bp(struct device *dev, struct device_attribute *devattr, char *buf) { unsigned val; struct platform_device *pdev = to_platform_device(dev); kernel_ulong_t driver_data = platform_get_device_id(pdev)->driver_data; - int ret = mc13783_adc_read(dev, devattr, &val); + int ret = mc13xxx_adc_read(dev, devattr, &val); if (ret) return ret; - if (driver_data & MC13783_ADC_BPDIV2) + if (driver_data & MC13892_ADC_BPDIV2) val = DIV_ROUND_CLOSEST(val * 9, 2); else /* @@ -93,11 +91,11 @@ static ssize_t mc13783_adc_read_bp(struct device *dev, return sprintf(buf, "%u\n", val); } -static ssize_t mc13783_adc_read_gp(struct device *dev, +static ssize_t mc13xxx_adc_read_gp(struct device *dev, struct device_attribute *devattr, char *buf) { unsigned val; - int ret = mc13783_adc_read(dev, devattr, &val); + int ret = mc13xxx_adc_read(dev, devattr, &val); if (ret) return ret; @@ -111,21 +109,21 @@ static ssize_t mc13783_adc_read_gp(struct device *dev, return sprintf(buf, "%u\n", val); } -static DEVICE_ATTR(name, S_IRUGO, mc13783_adc_show_name, NULL); -static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, mc13783_adc_read_bp, NULL, 2); -static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, mc13783_adc_read_gp, NULL, 5); -static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, mc13783_adc_read_gp, NULL, 6); -static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, mc13783_adc_read_gp, NULL, 7); -static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, mc13783_adc_read_gp, NULL, 8); -static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, mc13783_adc_read_gp, NULL, 9); -static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, mc13783_adc_read_gp, NULL, 10); -static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, mc13783_adc_read_gp, NULL, 11); -static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, mc13783_adc_read_gp, NULL, 12); -static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, mc13783_adc_read_gp, NULL, 13); -static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, mc13783_adc_read_gp, NULL, 14); -static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, mc13783_adc_read_gp, NULL, 15); - -static struct attribute *mc13783_attr_base[] = { +static DEVICE_ATTR(name, S_IRUGO, mc13xxx_adc_show_name, NULL); +static SENSOR_DEVICE_ATTR(in2_input, S_IRUGO, mc13xxx_adc_read_bp, NULL, 2); +static SENSOR_DEVICE_ATTR(in5_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 5); +static SENSOR_DEVICE_ATTR(in6_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 6); +static SENSOR_DEVICE_ATTR(in7_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 7); +static SENSOR_DEVICE_ATTR(in8_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 8); +static SENSOR_DEVICE_ATTR(in9_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 9); +static SENSOR_DEVICE_ATTR(in10_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 10); +static SENSOR_DEVICE_ATTR(in11_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 11); +static SENSOR_DEVICE_ATTR(in12_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 12); +static SENSOR_DEVICE_ATTR(in13_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 13); +static SENSOR_DEVICE_ATTR(in14_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 14); +static SENSOR_DEVICE_ATTR(in15_input, S_IRUGO, mc13xxx_adc_read_gp, NULL, 15); + +static struct attribute *mc13xxx_attr_base[] = { &dev_attr_name.attr, &sensor_dev_attr_in2_input.dev_attr.attr, &sensor_dev_attr_in5_input.dev_attr.attr, @@ -134,12 +132,12 @@ static struct attribute *mc13783_attr_base[] = { NULL }; -static const struct attribute_group mc13783_group_base = { - .attrs = mc13783_attr_base, +static const struct attribute_group mc13xxx_group_base = { + .attrs = mc13xxx_attr_base, }; /* these are only used if MC13783_ADC_16CHANS is provided in driver data */ -static struct attribute *mc13783_attr_16chans[] = { +static struct attribute *mc13xxx_attr_16chans[] = { &sensor_dev_attr_in8_input.dev_attr.attr, &sensor_dev_attr_in9_input.dev_attr.attr, &sensor_dev_attr_in10_input.dev_attr.attr, @@ -147,12 +145,12 @@ static struct attribute *mc13783_attr_16chans[] = { NULL }; -static const struct attribute_group mc13783_group_16chans = { - .attrs = mc13783_attr_16chans, +static const struct attribute_group mc13xxx_group_16chans = { + .attrs = mc13xxx_attr_16chans, }; /* last four channels may be occupied by the touchscreen */ -static struct attribute *mc13783_attr_ts[] = { +static struct attribute *mc13xxx_attr_ts[] = { &sensor_dev_attr_in12_input.dev_attr.attr, &sensor_dev_attr_in13_input.dev_attr.attr, &sensor_dev_attr_in14_input.dev_attr.attr, @@ -160,21 +158,21 @@ static struct attribute *mc13783_attr_ts[] = { NULL }; -static const struct attribute_group mc13783_group_ts = { - .attrs = mc13783_attr_ts, +static const struct attribute_group mc13xxx_group_ts = { + .attrs = mc13xxx_attr_ts, }; -static int mc13783_adc_use_touchscreen(struct platform_device *pdev) +static int mc13xxx_adc_use_touchscreen(struct platform_device *pdev) { - struct mc13783_adc_priv *priv = platform_get_drvdata(pdev); + struct mc13xxx_adc_priv *priv = platform_get_drvdata(pdev); unsigned flags = mc13xxx_get_flags(priv->mc13xxx); return flags & MC13XXX_USE_TOUCHSCREEN; } -static int __init mc13783_adc_probe(struct platform_device *pdev) +static int __init mc13xxx_adc_probe(struct platform_device *pdev) { - struct mc13783_adc_priv *priv; + struct mc13xxx_adc_priv *priv; int ret; const struct platform_device_id *id = platform_get_device_id(pdev); char *dash; @@ -192,19 +190,19 @@ static int __init mc13783_adc_probe(struct platform_device *pdev) platform_set_drvdata(pdev, priv); /* Register sysfs hooks */ - ret = sysfs_create_group(&pdev->dev.kobj, &mc13783_group_base); + ret = sysfs_create_group(&pdev->dev.kobj, &mc13xxx_group_base); if (ret) return ret; if (id->driver_data & MC13783_ADC_16CHANS) { ret = sysfs_create_group(&pdev->dev.kobj, - &mc13783_group_16chans); + &mc13xxx_group_16chans); if (ret) goto out_err_create_16chans; } - if (!mc13783_adc_use_touchscreen(pdev)) { - ret = sysfs_create_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) { + ret = sysfs_create_group(&pdev->dev.kobj, &mc13xxx_group_ts); if (ret) goto out_err_create_ts; } @@ -221,60 +219,53 @@ static int __init mc13783_adc_probe(struct platform_device *pdev) out_err_register: - if (!mc13783_adc_use_touchscreen(pdev)) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_ts); out_err_create_ts: if (id->driver_data & MC13783_ADC_16CHANS) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_16chans); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_16chans); out_err_create_16chans: - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_base); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_base); return ret; } -static int mc13783_adc_remove(struct platform_device *pdev) +static int mc13xxx_adc_remove(struct platform_device *pdev) { - struct mc13783_adc_priv *priv = platform_get_drvdata(pdev); + struct mc13xxx_adc_priv *priv = platform_get_drvdata(pdev); kernel_ulong_t driver_data = platform_get_device_id(pdev)->driver_data; hwmon_device_unregister(priv->hwmon_dev); - if (!mc13783_adc_use_touchscreen(pdev)) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_ts); + if (!mc13xxx_adc_use_touchscreen(pdev)) + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_ts); if (driver_data & MC13783_ADC_16CHANS) - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_16chans); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_16chans); - sysfs_remove_group(&pdev->dev.kobj, &mc13783_group_base); + sysfs_remove_group(&pdev->dev.kobj, &mc13xxx_group_base); return 0; } -static const struct platform_device_id mc13783_adc_idtable[] = { - { - .name = "mc13783-adc", - .driver_data = MC13783_ADC_16CHANS, - }, { - .name = "mc13892-adc", - .driver_data = MC13783_ADC_BPDIV2, - }, { - /* sentinel */ - } +static const struct platform_device_id mc13xxx_adc_idtable[] = { + { "mc13783-adc", MC13783_ADC_16CHANS, }, + { "mc13892-adc", MC13892_ADC_BPDIV2, }, + { } }; -MODULE_DEVICE_TABLE(platform, mc13783_adc_idtable); +MODULE_DEVICE_TABLE(platform, mc13xxx_adc_idtable); -static struct platform_driver mc13783_adc_driver = { - .remove = mc13783_adc_remove, +static struct platform_driver mc13xxx_adc_driver = { .driver = { .owner = THIS_MODULE, - .name = DRIVER_NAME, + .name = "mc13xxx-adc", }, - .id_table = mc13783_adc_idtable, + .remove = mc13xxx_adc_remove, + .id_table = mc13xxx_adc_idtable, }; +module_platform_driver_probe(mc13xxx_adc_driver, mc13xxx_adc_probe); -module_platform_driver_probe(mc13783_adc_driver, mc13783_adc_probe); - -MODULE_DESCRIPTION("MC13783 ADC driver"); +MODULE_DESCRIPTION("MC13XXX ADC driver"); MODULE_AUTHOR("Luotao Fu <l.fu@pengutronix.de>"); MODULE_LICENSE("GPL"); -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [lm-sensors] [PATCH 2/2] hwmon: mc13783-adc: Rename unit to indicate various MC13xxx chips support 2013-06-05 8:57 ` Alexander Shiyan @ 2013-06-05 8:57 ` Alexander Shiyan -1 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 8:57 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Alexander Shiyan <shc_work@mail.ru> --- arch/arm/configs/imx_v4_v5_defconfig | 2 +- drivers/hwmon/Kconfig | 10 +++++----- drivers/hwmon/Makefile | 2 +- drivers/hwmon/{mc13783-adc.c => mc13xxx-adc.c} | 0 4 files changed, 7 insertions(+), 7 deletions(-) rename drivers/hwmon/{mc13783-adc.c => mc13xxx-adc.c} (100%) diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig index 7fd9f9b..ba5b640 100644 --- a/arch/arm/configs/imx_v4_v5_defconfig +++ b/arch/arm/configs/imx_v4_v5_defconfig @@ -114,7 +114,7 @@ CONFIG_W1=y CONFIG_W1_MASTER_MXC=y CONFIG_W1_SLAVE_THERM=y CONFIG_HWMON=m -CONFIG_SENSORS_MC13783_ADC=m +CONFIG_SENSORS_MC13XXX_ADC=m CONFIG_WATCHDOG=y CONFIG_IMX2_WDT=y CONFIG_MFD_MC13XXX_SPI=y diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 4f71370..c28a362 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1526,11 +1526,11 @@ config SENSORS_APPLESMC Say Y here if you have an applicable laptop and want to experience the awesome power of applesmc. -config SENSORS_MC13783_ADC - tristate "Freescale MC13783/MC13892 ADC" - depends on MFD_MC13XXX - help - Support for the A/D converter on MC13783 and MC13892 PMIC. +config SENSORS_MC13XXX_ADC + tristate "Freescale MC13783/MC13892 ADC" + depends on MFD_MC13XXX + help + Support for the A/D converter on MC13783 and MC13892 PMIC. if ACPI diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index d17d3e6..b0cbc36f 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -106,7 +106,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MAX6697) += max6697.o -obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_MC13XXX_ADC)+= mc13xxx-adc.o obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o diff --git a/drivers/hwmon/mc13783-adc.c b/drivers/hwmon/mc13xxx-adc.c similarity index 100% rename from drivers/hwmon/mc13783-adc.c rename to drivers/hwmon/mc13xxx-adc.c -- 1.8.1.5 _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply related [flat|nested] 20+ messages in thread
* [PATCH 2/2] hwmon: mc13783-adc: Rename unit to indicate various MC13xxx chips support @ 2013-06-05 8:57 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 8:57 UTC (permalink / raw) To: linux-arm-kernel Signed-off-by: Alexander Shiyan <shc_work@mail.ru> --- arch/arm/configs/imx_v4_v5_defconfig | 2 +- drivers/hwmon/Kconfig | 10 +++++----- drivers/hwmon/Makefile | 2 +- drivers/hwmon/{mc13783-adc.c => mc13xxx-adc.c} | 0 4 files changed, 7 insertions(+), 7 deletions(-) rename drivers/hwmon/{mc13783-adc.c => mc13xxx-adc.c} (100%) diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig index 7fd9f9b..ba5b640 100644 --- a/arch/arm/configs/imx_v4_v5_defconfig +++ b/arch/arm/configs/imx_v4_v5_defconfig @@ -114,7 +114,7 @@ CONFIG_W1=y CONFIG_W1_MASTER_MXC=y CONFIG_W1_SLAVE_THERM=y CONFIG_HWMON=m -CONFIG_SENSORS_MC13783_ADC=m +CONFIG_SENSORS_MC13XXX_ADC=m CONFIG_WATCHDOG=y CONFIG_IMX2_WDT=y CONFIG_MFD_MC13XXX_SPI=y diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 4f71370..c28a362 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -1526,11 +1526,11 @@ config SENSORS_APPLESMC Say Y here if you have an applicable laptop and want to experience the awesome power of applesmc. -config SENSORS_MC13783_ADC - tristate "Freescale MC13783/MC13892 ADC" - depends on MFD_MC13XXX - help - Support for the A/D converter on MC13783 and MC13892 PMIC. +config SENSORS_MC13XXX_ADC + tristate "Freescale MC13783/MC13892 ADC" + depends on MFD_MC13XXX + help + Support for the A/D converter on MC13783 and MC13892 PMIC. if ACPI diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index d17d3e6..b0cbc36f 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -106,7 +106,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o obj-$(CONFIG_SENSORS_MAX6642) += max6642.o obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MAX6697) += max6697.o -obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o +obj-$(CONFIG_SENSORS_MC13XXX_ADC)+= mc13xxx-adc.o obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o diff --git a/drivers/hwmon/mc13783-adc.c b/drivers/hwmon/mc13xxx-adc.c similarity index 100% rename from drivers/hwmon/mc13783-adc.c rename to drivers/hwmon/mc13xxx-adc.c -- 1.8.1.5 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips 2013-06-05 8:57 ` Alexander Shiyan @ 2013-06-05 9:02 ` Jean Delvare -1 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 9:02 UTC (permalink / raw) To: linux-arm-kernel On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > This patch renames structures, variables and functions to indicate support > for various MC13xxx chips. > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > --- > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > 1 file changed, 63 insertions(+), 72 deletions(-) Nack. This change serves absolutely no purpose, all it's doing it make everyone's life harder. Just don't do that, thanks. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 9:02 ` Jean Delvare 0 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 9:02 UTC (permalink / raw) To: linux-arm-kernel On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > This patch renames structures, variables and functions to indicate support > for various MC13xxx chips. > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > --- > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > 1 file changed, 63 insertions(+), 72 deletions(-) Nack. This change serves absolutely no purpose, all it's doing it make everyone's life harder. Just don't do that, thanks. -- Jean Delvare ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re 2013-06-05 9:02 ` Jean Delvare @ 2013-06-05 9:19 ` Alexander Shiyan -1 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 9:19 UTC (permalink / raw) To: linux-arm-kernel > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > This patch renames structures, variables and functions to indicate support > > for various MC13xxx chips. > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > --- > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > 1 file changed, 63 insertions(+), 72 deletions(-) > > Nack. This change serves absolutely no purpose, all it's doing it make > everyone's life harder. Just don't do that, thanks. I do not understand stubbornness here. The driver works for different chips, it should be reflected in the code. --- _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 9:19 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 9:19 UTC (permalink / raw) To: linux-arm-kernel > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > This patch renames structures, variables and functions to indicate support > > for various MC13xxx chips. > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > --- > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > 1 file changed, 63 insertions(+), 72 deletions(-) > > Nack. This change serves absolutely no purpose, all it's doing it make > everyone's life harder. Just don't do that, thanks. I do not understand stubbornness here. The driver works for different chips, it should be reflected in the code. --- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips 2013-06-05 9:19 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan @ 2013-06-05 10:53 ` Jean Delvare -1 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 10:53 UTC (permalink / raw) To: linux-arm-kernel On Wed, 05 Jun 2013 13:19:12 +0400, Alexander Shiyan wrote: > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > > This patch renames structures, variables and functions to indicate support > > > for various MC13xxx chips. > > > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > > --- > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > > 1 file changed, 63 insertions(+), 72 deletions(-) > > > > Nack. This change serves absolutely no purpose, all it's doing it make > > everyone's life harder. Just don't do that, thanks. > > I do not understand stubbornness here. > The driver works for different chips, it should be reflected in the code. Let's look at it from another angle. What problem are you trying to solve? I see absolutely no problem with the current function and file names. Almost all Linux kernel drivers support more chips than their name says. On the other hand, changing all function names makes backporting fixes harder, and changing Kconfig symbol names makes upgrading to the new kernel version harder for everyone. So the cost of your proposal far outweighs the benefits. -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 10:53 ` Jean Delvare 0 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 10:53 UTC (permalink / raw) To: linux-arm-kernel On Wed, 05 Jun 2013 13:19:12 +0400, Alexander Shiyan wrote: > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > > This patch renames structures, variables and functions to indicate support > > > for various MC13xxx chips. > > > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > > --- > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > > 1 file changed, 63 insertions(+), 72 deletions(-) > > > > Nack. This change serves absolutely no purpose, all it's doing it make > > everyone's life harder. Just don't do that, thanks. > > I do not understand stubbornness here. > The driver works for different chips, it should be reflected in the code. Let's look at it from another angle. What problem are you trying to solve? I see absolutely no problem with the current function and file names. Almost all Linux kernel drivers support more chips than their name says. On the other hand, changing all function names makes backporting fixes harder, and changing Kconfig symbol names makes upgrading to the new kernel version harder for everyone. So the cost of your proposal far outweighs the benefits. -- Jean Delvare ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re 2013-06-05 10:53 ` Jean Delvare @ 2013-06-05 11:14 ` Alexander Shiyan -1 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 11:14 UTC (permalink / raw) To: linux-arm-kernel > > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > > > This patch renames structures, variables and functions to indicate support > > > > for various MC13xxx chips. > > > > > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > > > --- > > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > > > 1 file changed, 63 insertions(+), 72 deletions(-) > > > > > > Nack. This change serves absolutely no purpose, all it's doing it make > > > everyone's life harder. Just don't do that, thanks. > > > > I do not understand stubbornness here. > > The driver works for different chips, it should be reflected in the code. > > Let's look at it from another angle. What problem are you trying to > solve? I see absolutely no problem with the current function and file > names. Almost all Linux kernel drivers support more chips than their > name says. > > On the other hand, changing all function names makes backporting fixes > harder, and changing Kconfig symbol names makes upgrading to the new > kernel version harder for everyone. > > So the cost of your proposal far outweighs the benefits. Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* symbols in the log (debug) will say a developer who does not know about mc13892 compatibility with mc13783? I still believe that this should be reflected. Thanks. --- _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 11:14 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 11:14 UTC (permalink / raw) To: linux-arm-kernel > > > On Wed, 5 Jun 2013 12:57:07 +0400, Alexander Shiyan wrote: > > > > This patch renames structures, variables and functions to indicate support > > > > for various MC13xxx chips. > > > > > > > > Signed-off-by: Alexander Shiyan <shc_work@mail.ru> > > > > --- > > > > drivers/hwmon/mc13783-adc.c | 135 +++++++++++++++++++++----------------------- > > > > 1 file changed, 63 insertions(+), 72 deletions(-) > > > > > > Nack. This change serves absolutely no purpose, all it's doing it make > > > everyone's life harder. Just don't do that, thanks. > > > > I do not understand stubbornness here. > > The driver works for different chips, it should be reflected in the code. > > Let's look at it from another angle. What problem are you trying to > solve? I see absolutely no problem with the current function and file > names. Almost all Linux kernel drivers support more chips than their > name says. > > On the other hand, changing all function names makes backporting fixes > harder, and changing Kconfig symbol names makes upgrading to the new > kernel version harder for everyone. > > So the cost of your proposal far outweighs the benefits. Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* symbols in the log (debug) will say a developer who does not know about mc13892 compatibility with mc13783? I still believe that this should be reflected. Thanks. --- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips 2013-06-05 11:14 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan @ 2013-06-05 11:36 ` Arnd Bergmann -1 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2013-06-05 11:36 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 05 June 2013, Alexander Shiyan wrote: > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > symbols in the log (debug) will say a developer who does not know about > mc13892 compatibility with mc13783? I still believe that this should be reflected. If the log messages use dev_printk, they will use the correct device name already, if not, that can be fixed. I agree with Jean: we don't just rename things unless there is a significant benefit, which I don't see here. There is also the risk that we need to support a different chip named mc13xxx in the future that is different enough to require a new driver and then the naming is even more screwed up. Arnd _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 11:36 ` Arnd Bergmann 0 siblings, 0 replies; 20+ messages in thread From: Arnd Bergmann @ 2013-06-05 11:36 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 05 June 2013, Alexander Shiyan wrote: > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > symbols in the log (debug) will say a developer who does not know about > mc13892 compatibility with mc13783? I still believe that this should be reflected. If the log messages use dev_printk, they will use the correct device name already, if not, that can be fixed. I agree with Jean: we don't just rename things unless there is a significant benefit, which I don't see here. There is also the risk that we need to support a different chip named mc13xxx in the future that is different enough to require a new driver and then the naming is even more screwed up. Arnd ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re 2013-06-05 11:36 ` Arnd Bergmann @ 2013-06-05 11:43 ` Alexander Shiyan -1 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 11:43 UTC (permalink / raw) To: linux-arm-kernel > On Wednesday 05 June 2013, Alexander Shiyan wrote: > > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > > symbols in the log (debug) will say a developer who does not know about > > mc13892 compatibility with mc13783? I still believe that this should be reflected. > > If the log messages use dev_printk, they will use the correct device name already, > if not, that can be fixed. > > I agree with Jean: we don't just rename things unless there is a significant > benefit, which I don't see here. There is also the risk that we need to support > a different chip named mc13xxx in the future that is different enough to require > a new driver and then the naming is even more screwed up. It is a pity that the revision and updating of the code of this driver died. Well, lets drop thesepatches. Thanks. --- _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re[4]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 11:43 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 11:43 UTC (permalink / raw) To: linux-arm-kernel > On Wednesday 05 June 2013, Alexander Shiyan wrote: > > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > > symbols in the log (debug) will say a developer who does not know about > > mc13892 compatibility with mc13783? I still believe that this should be reflected. > > If the log messages use dev_printk, they will use the correct device name already, > if not, that can be fixed. > > I agree with Jean: we don't just rename things unless there is a significant > benefit, which I don't see here. There is also the risk that we need to support > a different chip named mc13xxx in the future that is different enough to require > a new driver and then the naming is even more screwed up. It is a pity that the revision and updating of the code of this driver died. Well, lets drop thesepatches. Thanks. --- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips 2013-06-05 11:14 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan @ 2013-06-05 11:45 ` Jean Delvare -1 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 11:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote: > > Let's look at it from another angle. What problem are you trying to > > solve? I see absolutely no problem with the current function and file > > names. Almost all Linux kernel drivers support more chips than their > > name says. > > > > On the other hand, changing all function names makes backporting fixes > > harder, and changing Kconfig symbol names makes upgrading to the new > > kernel version harder for everyone. > > > > So the cost of your proposal far outweighs the benefits. > > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > symbols in the log (debug) will say a developer who does not know about > mc13892 compatibility with mc13783? I still believe that this should be reflected. You're splitting hairs here. mc13783_* symbols in the log mean this comes from a driver named mc13783, period. A developer drawing conclusions beyond that needs to be educated. Which device the driver is driving can be retried from the log itself, or from sysfs. Or the hardware board datasheet. "mc13xxx" would tell no more, BTW. Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to name all these drivers and functions mcxxxxx* to cover all the supported chip. Which makes no sense at all, because so many x's are confusing, and because the mask then matches many devices the drivers do _not_ handle. So please forget about this and move on to something else. There are many many code cleanups and improvements, and bug fixes, all way more important than this. So I'm sure you can find better ways to spend your time, and mine. Thanks, -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 11:45 ` Jean Delvare 0 siblings, 0 replies; 20+ messages in thread From: Jean Delvare @ 2013-06-05 11:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote: > > Let's look at it from another angle. What problem are you trying to > > solve? I see absolutely no problem with the current function and file > > names. Almost all Linux kernel drivers support more chips than their > > name says. > > > > On the other hand, changing all function names makes backporting fixes > > harder, and changing Kconfig symbol names makes upgrading to the new > > kernel version harder for everyone. > > > > So the cost of your proposal far outweighs the benefits. > > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > symbols in the log (debug) will say a developer who does not know about > mc13892 compatibility with mc13783? I still believe that this should be reflected. You're splitting hairs here. mc13783_* symbols in the log mean this comes from a driver named mc13783, period. A developer drawing conclusions beyond that needs to be educated. Which device the driver is driving can be retried from the log itself, or from sysfs. Or the hardware board datasheet. "mc13xxx" would tell no more, BTW. Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to name all these drivers and functions mcxxxxx* to cover all the supported chip. Which makes no sense at all, because so many x's are confusing, and because the mask then matches many devices the drivers do _not_ handle. So please forget about this and move on to something else. There are many many code cleanups and improvements, and bug fixes, all way more important than this. So I'm sure you can find better ways to spend your time, and mine. Thanks, -- Jean Delvare ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re 2013-06-05 11:45 ` Jean Delvare @ 2013-06-05 12:01 ` Alexander Shiyan -1 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 12:01 UTC (permalink / raw) To: linux-arm-kernel CgoK0KHRgNC10LTQsCwgIDUg0LjRjtC90Y8gMjAxMywgMTM6NDUgKzAyOjAwINC+0YIgSmVhbiBE ZWx2YXJlIDxraGFsaUBsaW51eC1mci5vcmc+Ogo+IE9uIFdlZCwgMDUgSnVuIDIwMTMgMTU6MTQ6 MzkgKzA0MDAsIEFsZXhhbmRlciBTaGl5YW4gd3JvdGU6Cj4gPiA+IExldCdzIGxvb2sgYXQgaXQg ZnJvbSBhbm90aGVyIGFuZ2xlLiBXaGF0IHByb2JsZW0gYXJlIHlvdSB0cnlpbmcgdG8KPiA+ID4g c29sdmU/IEkgc2VlIGFic29sdXRlbHkgbm8gcHJvYmxlbSB3aXRoIHRoZSBjdXJyZW50IGZ1bmN0 aW9uIGFuZCBmaWxlCj4gPiA+IG5hbWVzLiBBbG1vc3QgYWxsIExpbnV4IGtlcm5lbCBkcml2ZXJz IHN1cHBvcnQgbW9yZSBjaGlwcyB0aGFuIHRoZWlyCj4gPiA+IG5hbWUgc2F5cy4KPiA+ID4gCj4g PiA+IE9uIHRoZSBvdGhlciBoYW5kLCBjaGFuZ2luZyBhbGwgZnVuY3Rpb24gbmFtZXMgbWFrZXMg YmFja3BvcnRpbmcgZml4ZXMKPiA+ID4gaGFyZGVyLCBhbmQgY2hhbmdpbmcgS2NvbmZpZyBzeW1i b2wgbmFtZXMgbWFrZXMgdXBncmFkaW5nIHRvIHRoZSBuZXcKPiA+ID4ga2VybmVsIHZlcnNpb24g aGFyZGVyIGZvciBldmVyeW9uZS4KPiA+ID4gCj4gPiA+IFNvIHRoZSBjb3N0IG9mIHlvdXIgcHJv cG9zYWwgZmFyIG91dHdlaWdocyB0aGUgYmVuZWZpdHMuCj4gPiAKPiA+IFdlbGwsIGxldCdzIGxl YXZlIHRoZSBrY29uZmlnIHN5bWJvbCBhcyBpcy4gQnV0IGFib3V0IHRoZSByZXN0LCB0aGF0IG1j MTM3ODNfKgo+ID4gc3ltYm9scyBpbiB0aGUgbG9nIChkZWJ1Zykgd2lsbCBzYXkgYSBkZXZlbG9w ZXIgd2hvIGRvZXMgbm90IGtub3cgYWJvdXQKPiA+IG1jMTM4OTIgY29tcGF0aWJpbGl0eSB3aXRo IG1jMTM3ODM/IEkgc3RpbGwgYmVsaWV2ZSB0aGF0IHRoaXMgc2hvdWxkIGJlIHJlZmxlY3RlZC4K PiAKPiBZb3UncmUgc3BsaXR0aW5nIGhhaXJzIGhlcmUuIG1jMTM3ODNfKiBzeW1ib2xzIGluIHRo ZSBsb2cgbWVhbiB0aGlzCj4gY29tZXMgZnJvbSBhIGRyaXZlciBuYW1lZCBtYzEzNzgzLCBwZXJp b2QuIEEgZGV2ZWxvcGVyIGRyYXdpbmcKPiBjb25jbHVzaW9ucyBiZXlvbmQgdGhhdCBuZWVkcyB0 byBiZSBlZHVjYXRlZC4gV2hpY2ggZGV2aWNlIHRoZSBkcml2ZXIKPiBpcyBkcml2aW5nIGNhbiBi ZSByZXRyaWVkIGZyb20gdGhlIGxvZyBpdHNlbGYsIG9yIGZyb20gc3lzZnMuIE9yIHRoZQo+IGhh cmR3YXJlIGJvYXJkIGRhdGFzaGVldC4gIm1jMTN4eHgiIHdvdWxkIHRlbGwgbm8gbW9yZSwgQlRX Lgo+IAo+IEFsc28gbm90ZSB0aGF0IHRoZSBuYW1lIG1jMTN4eHggaXMgd3JvbmcgYXMgd2VsbCwg YXMgdGhlIG1jMTN4eHgtaTJjCj4gYW5kIG1jMTN4eHgtc3BpIGRyaXZlcnMgaGFuZGxlIHRoZSBN QzM0NzA4IGNoaXAgdG9vLiBTbyB5b3UnZCBoYXZlIHRvCj4gbmFtZSBhbGwgdGhlc2UgZHJpdmVy cyBhbmQgZnVuY3Rpb25zIG1jeHh4eHgqIHRvIGNvdmVyIGFsbCB0aGUKPiBzdXBwb3J0ZWQgY2hp cC4gV2hpY2ggbWFrZXMgbm8gc2Vuc2UgYXQgYWxsLCBiZWNhdXNlIHNvIG1hbnkgeCdzIGFyZQo+ IGNvbmZ1c2luZywgYW5kIGJlY2F1c2UgdGhlIG1hc2sgdGhlbiBtYXRjaGVzIG1hbnkgZGV2aWNl cyB0aGUgZHJpdmVycwo+IGRvIF9ub3RfIGhhbmRsZS4KPiAKPiBTbyBwbGVhc2UgZm9yZ2V0IGFi b3V0IHRoaXMgYW5kIG1vdmUgb24gdG8gc29tZXRoaW5nIGVsc2UuIFRoZXJlIGFyZQo+IG1hbnkg bWFueSBjb2RlIGNsZWFudXBzIGFuZCBpbXByb3ZlbWVudHMsIGFuZCBidWcgZml4ZXMsIGFsbCB3 YXkgbW9yZQo+IGltcG9ydGFudCB0aGFuIHRoaXMuIFNvIEknbSBzdXJlIHlvdSBjYW4gZmluZCBi ZXR0ZXIgd2F5cyB0byBzcGVuZCB5b3VyCj4gdGltZSwgYW5kIG1pbmUuCgpBZ3JlZSwgd2UgaGF2 ZSBhIGxvdCBvZiBwbGFjZXMgaW4gdGhlIGtlcm5lbCB0byBiZSBjbGVhcmVkLgpGb3IgdGhlIHNh bWUgZHJpdmVyIE1DMTNYWFgsIGF0IGxlYXN0IHdlIG5lZWQgdG8gcmVtb3ZlIGEgdXNlbGVzcyBz eW1ib2wKTUZEX00xMzc4MyB3aGljaCBpcyBzZWxlY3RlZCBhdXRvbWF0aWNhbGx5IGlmIHdlIHNl bGVjdCBNRkRfTUMxM1hYWCwgCm1jMTN4eHhfbG9jay91bmxvY2sgZnVuY3Rpb25zIGluIHRoZSBk cml2ZXIgaGFzIGxvbmcgYmVlbiBub3QgbmVlZGVkIGJlY2F1c2UKd2UgdXNlIHJlZ21hcCBldGMu CkJ1dCB0byBzdGFydCBpbiBteSBvcGluaW9uIHlvdSBuZWVkIHdpdGgganVzdCBzdWNoIHRyaWZs ZXMgYXMgcmVuYW1lIGV0Yy4uLgpCdXQgZXZlbiBhdCB0aGlzIHN0YWdlIG9mIG9ic3RhY2xlcyBo YXZlIGNvbWUgdXAgYWdhaW5zdCAuLi4KV2VsbCwgYnkgYW5kIGxhcmdlIGl0IGRvZXMgbm90IGNo YW5nZSBjb2RlIGJ1dCByYXRoZXIgYSBncm9vbWluZyBjb2RlLCAKc28gSSBjYW4gZWFzaWx5IGdp dmUgaXQgdXAuIEJ1dCwgaW4gbXkgb3BpbmlvbiwgdGhlIHB1cml0eSBhbmQgY2xhcml0eSBvZiB0 aGUgY29kZQpoYXMgbmV2ZXIgaGFybWVkLgpPSywgbGV0cyBkcm9wIHRoZXNlIHBhdGNoZXMuClRo YW5rcy4KCi0tLQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpsbS1zZW5zb3JzIG1haWxpbmcgbGlzdApsbS1zZW5zb3JzQGxtLXNlbnNvcnMub3JnCmh0dHA6 Ly9saXN0cy5sbS1zZW5zb3JzLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xtLXNlbnNvcnM ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips @ 2013-06-05 12:01 ` Alexander Shiyan 0 siblings, 0 replies; 20+ messages in thread From: Alexander Shiyan @ 2013-06-05 12:01 UTC (permalink / raw) To: linux-arm-kernel ?????, 5 ???? 2013, 13:45 +02:00 ?? Jean Delvare <khali@linux-fr.org>: > On Wed, 05 Jun 2013 15:14:39 +0400, Alexander Shiyan wrote: > > > Let's look at it from another angle. What problem are you trying to > > > solve? I see absolutely no problem with the current function and file > > > names. Almost all Linux kernel drivers support more chips than their > > > name says. > > > > > > On the other hand, changing all function names makes backporting fixes > > > harder, and changing Kconfig symbol names makes upgrading to the new > > > kernel version harder for everyone. > > > > > > So the cost of your proposal far outweighs the benefits. > > > > Well, let's leave the kconfig symbol as is. But about the rest, that mc13783_* > > symbols in the log (debug) will say a developer who does not know about > > mc13892 compatibility with mc13783? I still believe that this should be reflected. > > You're splitting hairs here. mc13783_* symbols in the log mean this > comes from a driver named mc13783, period. A developer drawing > conclusions beyond that needs to be educated. Which device the driver > is driving can be retried from the log itself, or from sysfs. Or the > hardware board datasheet. "mc13xxx" would tell no more, BTW. > > Also note that the name mc13xxx is wrong as well, as the mc13xxx-i2c > and mc13xxx-spi drivers handle the MC34708 chip too. So you'd have to > name all these drivers and functions mcxxxxx* to cover all the > supported chip. Which makes no sense at all, because so many x's are > confusing, and because the mask then matches many devices the drivers > do _not_ handle. > > So please forget about this and move on to something else. There are > many many code cleanups and improvements, and bug fixes, all way more > important than this. So I'm sure you can find better ways to spend your > time, and mine. Agree, we have a lot of places in the kernel to be cleared. For the same driver MC13XXX, at least we need to remove a useless symbol MFD_M13783 which is selected automatically if we select MFD_MC13XXX, mc13xxx_lock/unlock functions in the driver has long been not needed because we use regmap etc. But to start in my opinion you need with just such trifles as rename etc... But even at this stage of obstacles have come up against ... Well, by and large it does not change code but rather a grooming code, so I can easily give it up. But, in my opinion, the purity and clarity of the code has never harmed. OK, lets drop these patches. Thanks. --- ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-06-05 12:01 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-06-05 8:57 [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan 2013-06-05 8:57 ` Alexander Shiyan 2013-06-05 8:57 ` [lm-sensors] [PATCH 2/2] hwmon: mc13783-adc: Rename unit to indicate various MC13xxx chips support Alexander Shiyan 2013-06-05 8:57 ` Alexander Shiyan 2013-06-05 9:02 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Jean Delvare 2013-06-05 9:02 ` Jean Delvare 2013-06-05 9:19 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan 2013-06-05 9:19 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan 2013-06-05 10:53 ` [lm-sensors] " Jean Delvare 2013-06-05 10:53 ` Jean Delvare 2013-06-05 11:14 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan 2013-06-05 11:14 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan 2013-06-05 11:36 ` [lm-sensors] " Arnd Bergmann 2013-06-05 11:36 ` Arnd Bergmann 2013-06-05 11:43 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan 2013-06-05 11:43 ` Re[4]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan 2013-06-05 11:45 ` [lm-sensors] " Jean Delvare 2013-06-05 11:45 ` Jean Delvare 2013-06-05 12:01 ` [lm-sensors] [PATCH 1/2] hwmon: mc13783-adc: Re Alexander Shiyan 2013-06-05 12:01 ` Re[2]: [PATCH 1/2] hwmon: mc13783-adc: Refactor source to indicate various mc13xxx chips Alexander Shiyan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.