Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754834AbcDNJhw (ORCPT ); Thu, 14 Apr 2016 05:37:52 -0400 Received: from mail-io0-f195.google.com ([209.85.223.195]:32793 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbcDNJhq (ORCPT ); Thu, 14 Apr 2016 05:37:46 -0400 MIME-Version: 1.0 Reply-To: andrea.merello@gmail.com In-Reply-To: References: <1460536591-12573-1-git-send-email-andrea.merello@gmail.com> From: Andrea Merello Date: Thu, 14 Apr 2016 11:37:25 +0200 Message-ID: Subject: Re: [PATCH RFC] I2C: i2c-smbus: add device tree support To: Andy Shevchenko Cc: jdelvare@suse.de, Wolfram Sang , linux-i2c@vger.kernel.org, devicetree , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2428 Lines: 60 On Wed, Apr 13, 2016 at 7:58 PM, Andy Shevchenko wrote: > On Wed, Apr 13, 2016 at 11:36 AM, Andrea Merello > wrote: >> According to Documentation/i2c/smbus-protocol, a smbus controller driver >> that wants to hook-in smbus extensions support, can call >> i2c_setup_smbus_alert(). There are very few drivers that are currently >> doing this. >> >> However the i2c-smbus module can also work with any >> smbus-extensions-unaware I2C controller, as long as we provide an extra >> IRQ line connected to the I2C bus ALARM signal. >> >> This patch makes it possible to go this way via DT. Note that the DT node >> will indeed describe a (little) piece of HW, that is the routing of the >> ALARM signal to an IRQ line (so it seems a fair DT use to me, but RFC). >> >> Note that AFAICT, by design, i2c-smbus module pretends to be an I2C slave >> with address 0x0C (that is the alarm response address), and IMHO this is >> quite consistent with usage in the DT as a I2C child node. > >> --- a/drivers/i2c/i2c-smbus.c >> +++ b/drivers/i2c/i2c-smbus.c > >> @@ -137,20 +138,29 @@ static int smbalert_probe(struct i2c_client *ara, >> struct i2c_smbus_alert_setup *setup = dev_get_platdata(&ara->dev); >> struct i2c_smbus_alert *alert; >> struct i2c_adapter *adapter = ara->adapter; >> + struct device_node *of_node = ara->dev.of_node; > > Perhaps fwnode_handle ? Browsing the kernel tree it looks like using of_node is how almost all drivers do. Any specific reason to go for fwnode_handle here? Wouldn't this end up to just an extra is_of_node() and to_of_node() ? > >> int res; >> + int irq_type; >> >> alert = devm_kzalloc(&ara->dev, sizeof(struct i2c_smbus_alert), >> GFP_KERNEL); >> if (!alert) >> return -ENOMEM; >> >> - alert->alert_edge_triggered = setup->alert_edge_triggered; >> - alert->irq = setup->irq; >> + if (setup) { >> + alert->alert_edge_triggered = setup->alert_edge_triggered; >> + alert->irq = setup->irq; >> + } else if (of_node) { >> + alert->irq = irq_of_parse_and_map(of_node, 0); >> + irq_type = irq_get_trigger_type(alert->irq); >> + alert->alert_edge_triggered = (irq_type & IRQ_TYPE_EDGE_BOTH); >> + } > > -- > With Best Regards, > Andy Shevchenko