linux-kernel - Re: [PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings for the Type-C port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e1be9239-daff-1f67-dc15-a504acc433a4@redhat.com>
Date:   Mon, 4 Sep 2017 16:20:35 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Peter Rosin <peda@...ntia.se>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        devel@...verdev.osuosl.org,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Sathyanarayanan Kuppuswamy Natarajan <sathyaosid@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB <linux-usb@...r.kernel.org>
Subject: Re: [PATCH 11/11] platform/x86: intel_cht_int33fe: Add mux mappings
 for the Type-C port

Hi,

On 02-09-17 12:42, Andy Shevchenko wrote:
> On Sat, Sep 2, 2017 at 12:48 AM, Hans de Goede <hdegoede@...hat.com> wrote:
>> We need to add mappings for the mux subsys to be able to find the
>> muxes for the fusb302 driver to be able to control the PI3USB30532
>> Type-C mux and the device/host mux integrated in the CHT SoC.
>>
> 
> I suppose it will go via not PDx86 tree,

Hmm, as I just mentioned in the "[PATCH v4 0/3] i2c: Hookup typec power-negotation to the PMIC and charger"
thread I've multiple patches for the intel_cht_int33fe.c driver pending,
so I think it would be best if these were merged through platform/x86,
but that is going to require a merge-tag for the mux stuff so that
that can be merged into platform/x86 as we need some mux/consumer.h
changes.

Anyways lets figure this out as we go along, it is also going to depend
on the timing, if the mux changes land for 4.15 but some of the other
bits don't then this patch (which ties everything together) becomes
4.16 material and we don't need to worry about a merge-tag,

Regards,

Hans



  so
> 
> Acked-by: Andy Shevchenko <andy.shevchenko@...il.com>



> 
>> Signed-off-by: Hans de Goede <hdegoede@...hat.com>
>> ---
>>   drivers/platform/x86/Kconfig             |  1 +
>>   drivers/platform/x86/intel_cht_int33fe.c | 23 +++++++++++++++++++++++
>>   2 files changed, 24 insertions(+)
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index c5554577681a..4256e05ee584 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -794,6 +794,7 @@ config ACPI_CMPC
>>   config INTEL_CHT_INT33FE
>>          tristate "Intel Cherry Trail ACPI INT33FE Driver"
>>          depends on X86 && ACPI && I2C && REGULATOR
>> +       select MULTIPLEXER
>>          ---help---
>>            This driver add support for the INT33FE ACPI device found on
>>            some Intel Cherry Trail devices.
>> diff --git a/drivers/platform/x86/intel_cht_int33fe.c b/drivers/platform/x86/intel_cht_int33fe.c
>> index 24a1662be81d..611b8af9cefd 100644
>> --- a/drivers/platform/x86/intel_cht_int33fe.c
>> +++ b/drivers/platform/x86/intel_cht_int33fe.c
>> @@ -24,6 +24,7 @@
>>   #include <linux/i2c.h>
>>   #include <linux/interrupt.h>
>>   #include <linux/module.h>
>> +#include <linux/mux/consumer.h>
>>   #include <linux/regulator/consumer.h>
>>   #include <linux/slab.h>
>>
>> @@ -35,6 +36,19 @@ struct cht_int33fe_data {
>>          struct i2c_client *pi3usb30532;
>>   };
>>
>> +static struct mux_lookup cht_int33fe_mux_lookup[] = {
>> +       {
>> +               .provider = "i2c-pi3usb30532",
>> +               .dev_id   = "i2c-fusb302",
>> +               .mux_name = "type-c-mode-mux",
>> +       },
>> +       {
>> +               .provider = "intel_cht_usb_mux",
>> +               .dev_id   = "i2c-fusb302",
>> +               .mux_name = "usb-role-mux",
>> +       },
>> +};
>> +
>>   /*
>>    * Grrr I severly dislike buggy BIOS-es. At least one BIOS enumerates
>>    * the max17047 both through the INT33FE ACPI device (it is right there
>> @@ -170,6 +184,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
>>          board_info.properties = fusb302_props;
>>          board_info.irq = fusb302_irq;
>>
>> +       mux_add_table(cht_int33fe_mux_lookup,
>> +                     ARRAY_SIZE(cht_int33fe_mux_lookup));
>> +
>>          data->fusb302 = i2c_acpi_new_device(dev, 2, &board_info);
>>          if (!data->fusb302)
>>                  goto out_unregister_max17047;
>> @@ -193,6 +210,9 @@ static int cht_int33fe_probe(struct i2c_client *client)
>>          if (data->max17047)
>>                  i2c_unregister_device(data->max17047);
>>
>> +       mux_remove_table(cht_int33fe_mux_lookup,
>> +                     ARRAY_SIZE(cht_int33fe_mux_lookup));
>> +
>>          return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
>>   }
>>
>> @@ -205,6 +225,9 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
>>          if (data->max17047)
>>                  i2c_unregister_device(data->max17047);
>>
>> +       mux_remove_table(cht_int33fe_mux_lookup,
>> +                     ARRAY_SIZE(cht_int33fe_mux_lookup));
>> +
>>          return 0;
>>   }
>>
>> --
>> 2.13.5
>>
> 
> 
>