Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

2017-04-13 Thread Guenter Roeck 

On 04/13/2017 03:53 PM, Moritz Fischer wrote:

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck  wrote:

On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:

From: Moritz Fischer 

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.



Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?


This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs


Hmm - weird. I thought I saw it implemented for those, but I must have been
struck by lightning or something. Let me check with Gwendal to see how
this (ie its use from iio) is supposed to work on non-LPC systems.

Guenter


emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

2017-04-13 Thread Guenter Roeck 
On Thu, Apr 13, 2017 at 03:01:40PM -0500, Rob Herring wrote:
> On Fri, Apr 07, 2017 at 03:00:09PM -0700, Moritz Fischer wrote:
> > From: Moritz Fischer 
> > 
> > Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
> > allows monitoring of temperature sensors and fans attached to the
> > EC.
> > 
> > Signed-off-by: Moritz Fischer 
> > ---
> >  .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 
> > ++
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
> > b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> > new file mode 100644
> > index 000..4c94869
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> > @@ -0,0 +1,25 @@
> > +Chromium Embedded Controller EC temperature and fan control
> > +---
> > +
> > +Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
> > Chromium EC
> > +firmware attached to the Embedded Controller (EC) and controlled via a 
> > host-command
> > +interface.
> > +
> > +An EC HWMON node should be only found as a sub-node of the EC node (see
> > +Documentation/devicetree/bindings/mfd/cros-ec.txt).
> > +
> > +Required properties:
> > +- compatible: Must contain "google,cros-ec-hwmon"
> > +
> > +Example:
> > +   embedded-controller@1e {
> > +   reg = <0x1e>;
> > +   compatible = "google,cros-ec-i2c";
> > +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> > +   interrupt-parent = <>;
> > +
> > +   hwmon {
> > +   compatible = "google,cros-ec-hwmon";
> 
> This is sufficient for all devices? I don't see that DT provides 
> anything here other than instantiating a device, but the parent device 
> can just as easily do that.
> 
The parent driver (drivers/mfd/cros_ec_i2c.c) calls cros_ec_register(),
which uses uses of_platform_populate() to populate all sub-devices.
There are various examples in the dts files (look for "google,cros-ec").
Does it really make sense to start a second method for instantiating
sub-devices ?

Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

2017-04-13 Thread Guenter Roeck 
On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
> From: Moritz Fischer 
> 
> The ChromeOS EC has mapped memory regions where things like temperature
> sensors and fan speed are stored. Provide access to those from the
> cros-ec mfd device.
> 

Turns out struct cros_ec_device already provides a cmd_readmem callback,
which is widely used by other drivers. Why don't you just use it ?

Thanks,
Guenter

> Signed-off-by: Moritz Fischer 
> ---
>  drivers/platform/chrome/cros_ec_proto.c | 55 
> +
>  include/linux/mfd/cros_ec.h | 39 +++
>  2 files changed, 94 insertions(+)
> 
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index ed5dee7..28063de 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
>   return get_keyboard_state_event(ec_dev);
>  }
>  EXPORT_SYMBOL(cros_ec_get_next_event);
> +
> +static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t 
> offset,
> +  void *buf, size_t size)
> +{
> + int ret;
> + struct ec_params_read_memmap *params;
> + struct cros_ec_command *msg;
> +
> + msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
> + if (!msg)
> + return -ENOMEM;
> +
> + msg->version = 0;
> + msg->command = EC_CMD_READ_MEMMAP;
> + msg->insize = size;
> + msg->outsize = sizeof(*params);
> +
> + params = (struct ec_params_read_memmap *)msg->data;
> + params->offset = offset;
> + params->size = size;
> +
> + ret = cros_ec_cmd_xfer(ec, msg);
> + if (ret < 0 || msg->result != EC_RES_SUCCESS) {
> + dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
> +  ret, msg->result);
> + goto out_free;
> + }
> +
> + memcpy(buf, msg->data, size);
> +
> +out_free:
> + kfree(msg);
> + return ret;
> +}
> +
> +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t 
> offset,
> +   uint32_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
> +
> +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t 
> offset,
> +   uint16_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
> +
> +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
> +  uint8_t *data)
> +{
> + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> +}
> +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index b3d04de..c2de878 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -190,6 +190,45 @@ struct cros_ec_dev {
>  };
>  
>  /**
> + * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
> +  uint8_t *data);
> +
> +/**
> + * cros_ec_read_mapped_mem16 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t 
> offset,
> +   uint16_t *data);
> +
> +/**
> + * cros_ec_read_mapped_mem32 - Read mapped memory in the ChromeOS EC
> + *
> + * This can be called by drivers to access the mapped memory in the EC
> + *
> + * @ec_dev: Device to read from
> + * @offset: Offset to read
> + * @data: Return data
> + * @return: 0 if Ok, -ve on error
> + */
> +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t 
> offset,
> +   uint32_t *data);
> +
> +/**
>   * cros_ec_suspend - Handle a suspend operation for the ChromeOS EC device
>   *
>   * This can be called by drivers to handle a suspend event.
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

2017-04-13 Thread Rob Herring 
On Fri, Apr 07, 2017 at 03:00:09PM -0700, Moritz Fischer wrote:
> From: Moritz Fischer 
> 
> Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
> allows monitoring of temperature sensors and fans attached to the
> EC.
> 
> Signed-off-by: Moritz Fischer 
> ---
>  .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
> b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> new file mode 100644
> index 000..4c94869
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
> @@ -0,0 +1,25 @@
> +Chromium Embedded Controller EC temperature and fan control
> +---
> +
> +Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
> Chromium EC
> +firmware attached to the Embedded Controller (EC) and controlled via a 
> host-command
> +interface.
> +
> +An EC HWMON node should be only found as a sub-node of the EC node (see
> +Documentation/devicetree/bindings/mfd/cros-ec.txt).
> +
> +Required properties:
> +- compatible: Must contain "google,cros-ec-hwmon"
> +
> +Example:
> + embedded-controller@1e {
> + reg = <0x1e>;
> + compatible = "google,cros-ec-i2c";
> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-parent = <>;
> +
> + hwmon {
> + compatible = "google,cros-ec-hwmon";

This is sufficient for all devices? I don't see that DT provides 
anything here other than instantiating a device, but the parent device 
can just as easily do that.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2,2/2] hwmon: (lm87) Add OF device ID table

2017-04-13 Thread Guenter Roeck 
On Wed, Apr 12, 2017 at 09:21:39PM -0300, Javier Martinez Canillas wrote:
> The driver doesn't have a struct of_device_id table but supported devices
> are registered via Device Trees. This is working on the assumption that a
> I2C device registered via OF will always match a legacy I2C device ID and
> that the MODALIAS reported will always be of the form i2c:.
> 
> But this could change in the future so the correct approach is to have an
> OF device ID table if the devices are registered via OF.
> 
> Signed-off-by: Javier Martinez Canillas 

Applied.

Thanks,
Guenter

> ---
> Hello,
> 
> I should had included this patch in series [0] but it seems that I didn't.
> 
> [0]: https://lkml.org/lkml/2017/2/24/360
> 
> Best regards,
> Javier
> 
> Changes in v2:
> - Use the correct driver in subject line.
> - Keep OF device ID table sorted in the same order than I2C device ID table.
> 
>  drivers/hwmon/lm87.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/hwmon/lm87.c b/drivers/hwmon/lm87.c
> index c0766e7392d3..b48d30760388 100644
> --- a/drivers/hwmon/lm87.c
> +++ b/drivers/hwmon/lm87.c
> @@ -985,10 +985,18 @@ static const struct i2c_device_id lm87_id[] = {
>  };
>  MODULE_DEVICE_TABLE(i2c, lm87_id);
>  
> +static const struct of_device_id lm87_of_match[] = {
> + { .compatible = "ti,lm87" },
> + { .compatible = "adi,adm1024" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, lm87_of_match);
> +
>  static struct i2c_driver lm87_driver = {
>   .class  = I2C_CLASS_HWMON,
>   .driver = {
>   .name   = "lm87",
> + .of_match_table = lm87_of_match,
>   },
>   .probe  = lm87_probe,
>   .id_table   = lm87_id,
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [v2,1/2] hwmon: (lm87) Remove unused I2C devices driver_data

2017-04-13 Thread Guenter Roeck 
On Wed, Apr 12, 2017 at 09:21:38PM -0300, Javier Martinez Canillas wrote:
> The I2C device ID entries set a .driver_data but this data is never
> looked up by the driver. So don't set it and also remove the enum.
> 
> Signed-off-by: Javier Martinez Canillas 

Applied.

Thanks,
Guenter

> ---
> 
> Changes in v2:
> - Use the correct driver in subject line.
> 
>  drivers/hwmon/lm87.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/lm87.c b/drivers/hwmon/lm87.c
> index 04a7a1ddb030..c0766e7392d3 100644
> --- a/drivers/hwmon/lm87.c
> +++ b/drivers/hwmon/lm87.c
> @@ -75,8 +75,6 @@
>  
>  static const unsigned short normal_i2c[] = { 0x2c, 0x2d, 0x2e, 
> I2C_CLIENT_END };
>  
> -enum chips { lm87, adm1024 };
> -
>  /*
>   * The LM87 registers
>   */
> @@ -981,8 +979,8 @@ static int lm87_probe(struct i2c_client *client, const 
> struct i2c_device_id *id)
>   */
>  
>  static const struct i2c_device_id lm87_id[] = {
> - { "lm87", lm87 },
> - { "adm1024", adm1024 },
> + { "lm87", 0 },
> + { "adm1024", 0 },
>   { }
>  };
>  MODULE_DEVICE_TABLE(i2c, lm87_id);
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

From: Mr. David Jones?

2017-04-13 Thread Mr. David Jones 
Hello

I'm Mr. David Jones, Personal Lawyer to Late Eng. Albert Buchanan,a
national of your country, An Estate Contractor here in England London.
My Client had an account valued(£ 11.700.000.00), am contacting you to
stand as a legal beneficiary for the deceased assets, so that the
proceeds of this fund can be paid to you, and money will be shared
even between both parties, Reply with your full name, and contact
information for more details to you.

Best Regards
Mr. David Jones
--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html