[PATCH v2 0/2] mfd: intel_quark_i2c_gpio: Refactor and support for IOT2000

[PATCH v2 0/2] mfd: intel_quark_i2c_gpio: Refactor and support for IOT2000

[Jan Kiszka]

Changes in v2:
 - refactor DMI matching first

Jan

Jan Kiszka (2):
  mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving
    frequency
  mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform

 drivers/mfd/intel_quark_i2c_gpio.c | 49 ++++++++++++++++++++++----------------
 1 file changed, 29 insertions(+), 20 deletions(-)

-- 
2.12.0

[PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

Avoids reimplementation of DMI matching in intel_quark_i2c_setup.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/mfd/intel_quark_i2c_gpio.c | 33 +++++++++++++--------------------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
index 7946d6e38b87..050061320377 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -58,19 +58,18 @@ struct intel_quark_mfd {
 	struct clk_lookup	*i2c_clk_lookup;
 };
 
-struct i2c_mode_info {
-	const char *name;
-	unsigned int i2c_scl_freq;
-};
-
-static const struct i2c_mode_info platform_i2c_mode_info[] = {
+static const struct dmi_system_id dmi_platform_info[] = {
 	{
-		.name = "Galileo",
-		.i2c_scl_freq = 100000,
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "Galileo"),
+		},
+		.driver_data = (void *)100000,
 	},
 	{
-		.name = "GalileoGen2",
-		.i2c_scl_freq = 400000,
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "GalileoGen2"),
+		},
+		.driver_data = (void *)400000,
 	},
 	{}
 };
@@ -160,8 +159,7 @@ static void intel_quark_unregister_i2c_clk(struct device *dev)
 
 static int intel_quark_i2c_setup(struct pci_dev *pdev, struct mfd_cell *cell)
 {
-	const char *board_name = dmi_get_system_info(DMI_BOARD_NAME);
-	const struct i2c_mode_info *info;
+	const struct dmi_system_id *dmi_id;
 	struct dw_i2c_platform_data *pdata;
 	struct resource *res = (struct resource *)cell->resources;
 	struct device *dev = &pdev->dev;
@@ -181,14 +179,9 @@ static int intel_quark_i2c_setup(struct pci_dev *pdev, struct mfd_cell *cell)
 	/* Normal mode by default */
 	pdata->i2c_scl_freq = 100000;
 
-	if (board_name) {
-		for (info = platform_i2c_mode_info; info->name; info++) {
-			if (!strcmp(board_name, info->name)) {
-				pdata->i2c_scl_freq = info->i2c_scl_freq;
-				break;
-			}
-		}
-	}
+	dmi_id = dmi_first_match(dmi_platform_info);
+	if (dmi_id)
+		pdata->i2c_scl_freq = (uintptr_t)dmi_id->driver_data;
 
 	cell->platform_data = pdata;
 	cell->pdata_size = sizeof(*pdata);
-- 
2.12.0

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.

What's wrong with current approach? I suppose this will make sense
when we will have an issue / impediment. Right now it looks like
over-engineering.

(Yes, I know what I said to you about this earlier, OTOH see above)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:12, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
> 
> What's wrong with current approach? I suppose this will make sense
> when we will have an issue / impediment. Right now it looks like
> over-engineering.
> 
> (Yes, I know what I said to you about this earlier, OTOH see above)
> 

It allows matching on additional DMI tags without additional code -
patch 2 depends on it.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-22 19:12, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
>>
>> What's wrong with current approach? I suppose this will make sense
>> when we will have an issue / impediment. Right now it looks like
>> over-engineering.
>>
>> (Yes, I know what I said to you about this earlier, OTOH see above)
>>
>
> It allows matching on additional DMI tags without additional code -
> patch 2 depends on it.

And since there is no difference to the frequency the name is enough.
So, I wouldn't go with this series as is. See above.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:20, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
>>>
>>> What's wrong with current approach? I suppose this will make sense
>>> when we will have an issue / impediment. Right now it looks like
>>> over-engineering.
>>>
>>> (Yes, I know what I said to you about this earlier, OTOH see above)
>>>
>>
>> It allows matching on additional DMI tags without additional code -
>> patch 2 depends on it.
> 
> And since there is no difference to the frequency the name is enough.
> So, I wouldn't go with this series as is. See above.

Nope: Just like for the stmmac, we need to include the asset tags to
avoid matching variations of the devices which may carry the same board
name. While I will try to avoid that this happens, we are better safe
than sorry here.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-22 19:20, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
>>>>
>>>> What's wrong with current approach? I suppose this will make sense
>>>> when we will have an issue / impediment. Right now it looks like
>>>> over-engineering.
>>>>
>>>> (Yes, I know what I said to you about this earlier, OTOH see above)
>>>>
>>>
>>> It allows matching on additional DMI tags without additional code -
>>> patch 2 depends on it.
>>
>> And since there is no difference to the frequency the name is enough.
>> So, I wouldn't go with this series as is. See above.
>
> Nope: Just like for the stmmac, we need to include the asset tags to
> avoid matching variations of the devices which may carry the same board
> name. While I will try to avoid that this happens, we are better safe
> than sorry here.

Do we have an issue right now?
Yes / No


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:26, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-05-22 19:20, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>> Avoids reimplementation of DMI matching in intel_quark_i2c_setup.
>>>>>
>>>>> What's wrong with current approach? I suppose this will make sense
>>>>> when we will have an issue / impediment. Right now it looks like
>>>>> over-engineering.
>>>>>
>>>>> (Yes, I know what I said to you about this earlier, OTOH see above)
>>>>>
>>>>
>>>> It allows matching on additional DMI tags without additional code -
>>>> patch 2 depends on it.
>>>
>>> And since there is no difference to the frequency the name is enough.
>>> So, I wouldn't go with this series as is. See above.
>>
>> Nope: Just like for the stmmac, we need to include the asset tags to
>> avoid matching variations of the devices which may carry the same board
>> name. While I will try to avoid that this happens, we are better safe
>> than sorry here.
> 
> Do we have an issue right now?
> Yes / No

Andy, we are trying to design a robust upstream driver here, no ad-hoc
BSP that will not survive the hardware anyway.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-22 19:26, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-05-22 19:20, Andy Shevchenko wrote:
>>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

>>>> And since there is no difference to the frequency the name is enough.
>>>> So, I wouldn't go with this series as is. See above.
>>>
>>> Nope: Just like for the stmmac, we need to include the asset tags to
>>> avoid matching variations of the devices which may carry the same board
>>> name. While I will try to avoid that this happens, we are better safe
>>> than sorry here.
>>
>> Do we have an issue right now?
>> Yes / No
>
> Andy, we are trying to design a robust upstream driver here, no ad-hoc
> BSP that will not survive the hardware anyway.

You didn't answer my question...

I do not see a good point to solve the issue that might happen in the future.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 19:36, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> On 2017-05-22 19:26, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-05-22 19:20, Andy Shevchenko wrote:
>>>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
>>>>> And since there is no difference to the frequency the name is enough.
>>>>> So, I wouldn't go with this series as is. See above.
>>>>
>>>> Nope: Just like for the stmmac, we need to include the asset tags to
>>>> avoid matching variations of the devices which may carry the same board
>>>> name. While I will try to avoid that this happens, we are better safe
>>>> than sorry here.
>>>
>>> Do we have an issue right now?
>>> Yes / No
>>
>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
>> BSP that will not survive the hardware anyway.
> 
> You didn't answer my question...
> 
> I do not see a good point to solve the issue that might happen in the future.
> 

While I do - that's why your question is misleading.

Then let's leave the decision up to the maintainer.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-22 19:36, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>> On 2017-05-22 19:26, Andy Shevchenko wrote:
>>>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>> On 2017-05-22 19:20, Andy Shevchenko wrote:
>>>>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
>>>>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

>>>>>> And since there is no difference to the frequency the name is enough.
>>>>>> So, I wouldn't go with this series as is. See above.
>>>>>
>>>>> Nope: Just like for the stmmac, we need to include the asset tags to
>>>>> avoid matching variations of the devices which may carry the same board
>>>>> name. While I will try to avoid that this happens, we are better safe
>>>>> than sorry here.
>>>>
>>>> Do we have an issue right now?
>>>> Yes / No
>>>
>>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
>>> BSP that will not survive the hardware anyway.
>>
>> You didn't answer my question...
>>
>> I do not see a good point to solve the issue that might happen in the future.
>>
>
> While I do - that's why your question is misleading.
>
> Then let's leave the decision up to the maintainer.

Lee, just for your convenience I'm repeating myself here:

I do not like this series at all since it tries to solve non-existing
issue in over-engineering way.

If you on opposite side I will be happy to help reviewing it.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Lee Jones]

On Mon, 22 May 2017, Andy Shevchenko wrote:

> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > On 2017-05-22 19:36, Andy Shevchenko wrote:
> >> On Mon, May 22, 2017 at 8:34 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>> On 2017-05-22 19:26, Andy Shevchenko wrote:
> >>>> On Mon, May 22, 2017 at 8:25 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>> On 2017-05-22 19:20, Andy Shevchenko wrote:
> >>>>>> On Mon, May 22, 2017 at 8:18 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>> On 2017-05-22 19:12, Andy Shevchenko wrote:
> >>>>>>>> On Mon, May 22, 2017 at 1:53 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> 
> >>>>>> And since there is no difference to the frequency the name is enough.
> >>>>>> So, I wouldn't go with this series as is. See above.
> >>>>>
> >>>>> Nope: Just like for the stmmac, we need to include the asset tags to
> >>>>> avoid matching variations of the devices which may carry the same board
> >>>>> name. While I will try to avoid that this happens, we are better safe
> >>>>> than sorry here.
> >>>>
> >>>> Do we have an issue right now?
> >>>> Yes / No
> >>>
> >>> Andy, we are trying to design a robust upstream driver here, no ad-hoc
> >>> BSP that will not survive the hardware anyway.
> >>
> >> You didn't answer my question...
> >>
> >> I do not see a good point to solve the issue that might happen in the future.
> >>
> >
> > While I do - that's why your question is misleading.
> >
> > Then let's leave the decision up to the maintainer.
> 
> Lee, just for your convenience I'm repeating myself here:
> 
> I do not like this series at all since it tries to solve non-existing
> issue in over-engineering way.
> 
> If you on opposite side I will be happy to help reviewing it.

New code looks cleaner and appears to use an already defined API.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 9:23 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 22 May 2017, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>> > On 2017-05-22 19:36, Andy Shevchenko wrote:

>> > Then let's leave the decision up to the maintainer.
>>
>> Lee, just for your convenience I'm repeating myself here:
>>
>> I do not like this series at all since it tries to solve non-existing
>> issue in over-engineering way.
>>
>> If you on opposite side I will be happy to help reviewing it.
>
> New code looks cleaner and appears to use an already defined API.

Got your point.
Jan, care to resend  (an updated?) version?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Jan Kiszka]

On 2017-05-22 20:37, Andy Shevchenko wrote:
> On Mon, May 22, 2017 at 9:23 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> On Mon, 22 May 2017, Andy Shevchenko wrote:
>>> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>> On 2017-05-22 19:36, Andy Shevchenko wrote:
> 
>>>> Then let's leave the decision up to the maintainer.
>>>
>>> Lee, just for your convenience I'm repeating myself here:
>>>
>>> I do not like this series at all since it tries to solve non-existing
>>> issue in over-engineering way.
>>>
>>> If you on opposite side I will be happy to help reviewing it.
>>
>> New code looks cleaner and appears to use an already defined API.
> 
> Got your point.
> Jan, care to resend  (an updated?) version?
> 

Updated in which regard? The one for stmmac is broken, this one should
be fine.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v2 1/2] mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving frequency

[Andy Shevchenko]

On Mon, May 22, 2017 at 9:47 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> On 2017-05-22 20:37, Andy Shevchenko wrote:
>> On Mon, May 22, 2017 at 9:23 PM, Lee Jones <lee.jones@linaro.org> wrote:
>>> On Mon, 22 May 2017, Andy Shevchenko wrote:
>>>> On Mon, May 22, 2017 at 8:38 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote:

>> Got your point.
>> Jan, care to resend  (an updated?) version?

> Updated in which regard? The one for stmmac is broken, this one should
> be fine.

Can you just resend then, please? I have been out a while and now I
have a pile of mails, it would be slightly easy for me to go through a
fresh series.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 2/2] mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform

[Jan Kiszka]

The SIMATIC IOT2020 and IOT2040 are derived from the Galileo Gen2 board
and share its I2C frequency.

Signed-off-by: Sascha Weisenberger <sascha.weisenberger@siemens.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 drivers/mfd/intel_quark_i2c_gpio.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/intel_quark_i2c_gpio.c b/drivers/mfd/intel_quark_i2c_gpio.c
index 050061320377..90e35dec8648 100644
--- a/drivers/mfd/intel_quark_i2c_gpio.c
+++ b/drivers/mfd/intel_quark_i2c_gpio.c
@@ -71,6 +71,22 @@ static const struct dmi_system_id dmi_platform_info[] = {
 		},
 		.driver_data = (void *)400000,
 	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+			DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+					"6ES7647-0AA00-0YA2"),
+		},
+		.driver_data = (void *)400000,
+	},
+	{
+		.matches = {
+			DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+			DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+					"6ES7647-0AA00-1YA2"),
+		},
+		.driver_data = (void *)400000,
+	},
 	{}
 };
 
-- 
2.12.0

Re: [PATCH v2 0/2] mfd: intel_quark_i2c_gpio: Refactor and support for IOT2000

[Andy Shevchenko]

On Mon, 2017-05-22 at 12:53 +0200, Jan Kiszka wrote:
> Changes in v2:
>  - refactor DMI matching first

Okay, we would do amendments later if something new comes up.
For now, FWIW:
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

P.S. After all it looks not bad.

> 
> Jan
> 
> Jan Kiszka (2):
>   mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving
>     frequency
>   mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform
> 
>  drivers/mfd/intel_quark_i2c_gpio.c | 49 ++++++++++++++++++++++-------
> ---------
>  1 file changed, 29 insertions(+), 20 deletions(-)
> 

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

Re: [PATCH v2 0/2] mfd: intel_quark_i2c_gpio: Refactor and support for IOT2000

[Lee Jones]

On Mon, 22 May 2017, Jan Kiszka wrote:

> Changes in v2:
>  - refactor DMI matching first
> 
> Jan
> 
> Jan Kiszka (2):
>   mfd: intel_quark_i2c_gpio: Use dmi_system_id table for retrieving
>     frequency
>   mfd: intel_quark_i2c_gpio: Add support for SIMATIC IOT2000 platform
> 
>  drivers/mfd/intel_quark_i2c_gpio.c | 49 ++++++++++++++++++++++----------------
>  1 file changed, 29 insertions(+), 20 deletions(-)

Jan, to make this easy, will you resend with Andy's Acks please?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog