Hi,
This patch series add support for Intel Input Output Manager (IOM)
driver, which is leveraged by the Intel PMC USB mux control driver.
This patch series has a dependency on the following 4 patches, that
are in Greg's usb-next branch.
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/tree/?h=usb-next
ffe82945d8eb usb: typec: intel_pmc_mux: Add support for USB4
cab9219d2af4 usb: typec: intel_pmc_mux: Definitions for response status bits
1a1be50b5ebd usb: typec: Add data structure for Enter_USB message
6701911bb1c1 usb: typec: Combine the definitions for Accessory and USB modes
Heikki Krogerus (1):
usb: typec: intel_pmc_mux: Check the port status before connect
Rajmohan Mani (1):
platform/x86: Add Intel Input Output Manager (IOM) driver
drivers/platform/x86/Kconfig | 16 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/intel_iom.c | 133 ++++++++++++++++++++
drivers/usb/typec/mux/Kconfig | 1 +
drivers/usb/typec/mux/intel_pmc_mux.c | 73 +++++++++--
include/linux/platform_data/x86/intel_iom.h | 62 +++++++++
6 files changed, 276 insertions(+), 10 deletions(-)
create mode 100644 drivers/platform/x86/intel_iom.c
create mode 100644 include/linux/platform_data/x86/intel_iom.h
--
2.20.1
From: Heikki Krogerus <[email protected]>
The PMC microcontroller that we use for configuration, does
not supply any status information back. For port status we
need to talk to another controller on the board called IOM
(I/O manager).
By checking the port status before configuring the muxes, we
can make sure that we do not reconfigure the port after
bootup when the system firmware (for example BIOS) has
already configured it.
Using the status information also to check if DisplayPort
HPD is still asserted when the cable plug is disconnected,
and clearing it if it is.
Signed-off-by: Heikki Krogerus <[email protected]>
---
drivers/usb/typec/mux/Kconfig | 1 +
drivers/usb/typec/mux/intel_pmc_mux.c | 73 +++++++++++++++++++++++----
2 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
index a4dbd11f8ee2..46f5512de63d 100644
--- a/drivers/usb/typec/mux/Kconfig
+++ b/drivers/usb/typec/mux/Kconfig
@@ -12,6 +12,7 @@ config TYPEC_MUX_PI3USB30532
config TYPEC_MUX_INTEL_PMC
tristate "Intel PMC mux control"
depends on INTEL_SCU_IPC
+ depends on INTEL_IOM
select USB_ROLE_SWITCH
help
Driver for USB muxes controlled by Intel PMC FW. Intel PMC FW can
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
index 2aba07c7b221..84101fb99934 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -9,6 +9,7 @@
#include <linux/acpi.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/platform_data/x86/intel_iom.h>
#include <linux/property.h>
#include <linux/usb/pd.h>
#include <linux/usb/role.h>
@@ -83,10 +84,17 @@ enum {
#define PMC_USB_DP_HPD_LVL BIT(4)
#define PMC_USB_DP_HPD_IRQ BIT(5)
+/* IOM Port Status */
+#define IOM_PORT_ACTIVITY_IS(_status_, _type_) \
+ ((((_status_) & IOM_PORT_STATUS_ACTIVITY_TYPE_MASK) >> \
+ IOM_PORT_STATUS_ACTIVITY_TYPE_SHIFT) == \
+ (IOM_PORT_STATUS_ACTIVITY_TYPE_##_type_))
+
struct pmc_usb;
struct pmc_usb_port {
int num;
+ u32 iom_status;
struct pmc_usb *pmc;
struct typec_mux *typec_mux;
struct typec_switch *typec_sw;
@@ -105,6 +113,7 @@ struct pmc_usb_port {
struct pmc_usb {
u8 num_ports;
struct device *dev;
+ struct intel_iom *iom;
struct intel_scu_ipc_dev *ipc;
struct pmc_usb_port *port;
};
@@ -145,18 +154,17 @@ static int pmc_usb_command(struct pmc_usb_port *port, u8 *msg, u32 len)
}
static int
-pmc_usb_mux_dp_hpd(struct pmc_usb_port *port, struct typec_mux_state *state)
+pmc_usb_mux_dp_hpd(struct pmc_usb_port *port, struct typec_displayport_data *dp)
{
- struct typec_displayport_data *data = state->data;
u8 msg[2] = { };
msg[0] = PMC_USB_DP_HPD;
msg[0] |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
- if (data->status & DP_STATUS_IRQ_HPD)
+ if (dp->status & DP_STATUS_IRQ_HPD)
msg[1] = PMC_USB_DP_HPD_IRQ;
- if (data->status & DP_STATUS_HPD_STATE)
+ if (dp->status & DP_STATUS_HPD_STATE)
msg[1] |= PMC_USB_DP_HPD_LVL;
return pmc_usb_command(port, msg, sizeof(msg));
@@ -169,8 +177,12 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct typec_mux_state *state)
struct altmode_req req = { };
int ret;
+ if (IOM_PORT_ACTIVITY_IS(port->iom_status, DP) ||
+ IOM_PORT_ACTIVITY_IS(port->iom_status, DP_MFD))
+ return 0;
+
if (data->status & DP_STATUS_IRQ_HPD)
- return pmc_usb_mux_dp_hpd(port, state);
+ return pmc_usb_mux_dp_hpd(port, state->data);
req.usage = PMC_USB_ALT_MODE;
req.usage |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
@@ -193,7 +205,7 @@ pmc_usb_mux_dp(struct pmc_usb_port *port, struct typec_mux_state *state)
return ret;
if (data->status & DP_STATUS_HPD_STATE)
- return pmc_usb_mux_dp_hpd(port, state);
+ return pmc_usb_mux_dp_hpd(port, state->data);
return 0;
}
@@ -205,6 +217,10 @@ pmc_usb_mux_tbt(struct pmc_usb_port *port, struct typec_mux_state *state)
u8 cable_speed = TBT_CABLE_SPEED(data->cable_mode);
struct altmode_req req = { };
+ if (IOM_PORT_ACTIVITY_IS(port->iom_status, TBT) ||
+ IOM_PORT_ACTIVITY_IS(port->iom_status, ALT_MODE_TBT_USB))
+ return 0;
+
req.usage = PMC_USB_ALT_MODE;
req.usage |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
req.mode_type = PMC_USB_MODE_TYPE_TBT << PMC_USB_MODE_TYPE_SHIFT;
@@ -239,6 +255,10 @@ pmc_usb_mux_usb4(struct pmc_usb_port *port, struct typec_mux_state *state)
struct altmode_req req = { };
u8 cable_speed;
+ if (IOM_PORT_ACTIVITY_IS(port->iom_status, TBT) ||
+ IOM_PORT_ACTIVITY_IS(port->iom_status, ALT_MODE_TBT_USB))
+ return 0;
+
req.usage = PMC_USB_ALT_MODE;
req.usage |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
req.mode_type = PMC_USB_MODE_TYPE_TBT << PMC_USB_MODE_TYPE_SHIFT;
@@ -273,6 +293,9 @@ static int pmc_usb_mux_safe_state(struct pmc_usb_port *port)
{
u8 msg;
+ if (IOM_PORT_ACTIVITY_IS(port->iom_status, SAFE_MODE))
+ return 0;
+
msg = PMC_USB_SAFE_MODE;
msg |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
@@ -283,6 +306,9 @@ static int pmc_usb_connect(struct pmc_usb_port *port)
{
u8 msg[2];
+ if (port->iom_status & IOM_PORT_STATUS_CONNECTED)
+ return 0;
+
msg[0] = PMC_USB_CONNECT;
msg[0] |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
@@ -295,8 +321,18 @@ static int pmc_usb_connect(struct pmc_usb_port *port)
static int pmc_usb_disconnect(struct pmc_usb_port *port)
{
+ struct typec_displayport_data data = { };
u8 msg[2];
+ if (!(port->iom_status & IOM_PORT_STATUS_CONNECTED))
+ return 0;
+
+ /* Clear DisplayPort HPD if it's still asserted. */
+ if (((port->iom_status & IOM_PORT_STATUS_DHPD_HPD_STATUS_MASK) >>
+ IOM_PORT_STATUS_DHPD_HPD_STATUS_SHIFT) &
+ IOM_PORT_STATUS_DHPD_HPD_STATUS_ASSERT)
+ pmc_usb_mux_dp_hpd(port, &data);
+
msg[0] = PMC_USB_DISCONNECT;
msg[0] |= port->usb3_port << PMC_USB_MSG_USB3_PORT_SHIFT;
@@ -309,6 +345,11 @@ static int
pmc_usb_mux_set(struct typec_mux *mux, struct typec_mux_state *state)
{
struct pmc_usb_port *port = typec_mux_get_drvdata(mux);
+ int ret;
+
+ ret = intel_iom_port_status(port->pmc->iom, port->num, &port->iom_status);
+ if (ret)
+ return ret;
if (state->mode == TYPEC_STATE_SAFE)
return pmc_usb_mux_safe_state(port);
@@ -341,9 +382,11 @@ static int pmc_usb_set_orientation(struct typec_switch *sw,
enum typec_orientation orientation)
{
struct pmc_usb_port *port = typec_switch_get_drvdata(sw);
+ int ret;
- if (port->orientation == orientation)
- return 0;
+ ret = intel_iom_port_status(port->pmc->iom, port->num, &port->iom_status);
+ if (ret)
+ return ret;
port->orientation = orientation;
@@ -360,9 +403,11 @@ static int pmc_usb_set_orientation(struct typec_switch *sw,
static int pmc_usb_set_role(struct usb_role_switch *sw, enum usb_role role)
{
struct pmc_usb_port *port = usb_role_switch_get_drvdata(sw);
+ int ret;
- if (port->role == role)
- return 0;
+ ret = intel_iom_port_status(port->pmc->iom, port->num, &port->iom_status);
+ if (ret)
+ return ret;
port->role = role;
@@ -472,6 +517,10 @@ static int pmc_usb_probe(struct platform_device *pdev)
pmc->dev = &pdev->dev;
+ pmc->iom = intel_iom_get();
+ if (IS_ERR(pmc->iom))
+ return PTR_ERR(pmc->iom);
+
/*
* For every physical USB connector (USB2 and USB3 combo) there is a
* child ACPI device node under the PMC mux ACPI device object.
@@ -496,6 +545,8 @@ static int pmc_usb_probe(struct platform_device *pdev)
typec_mux_unregister(pmc->port[i].typec_mux);
}
+ intel_iom_put(pmc->iom);
+
return ret;
}
@@ -509,6 +560,8 @@ static int pmc_usb_remove(struct platform_device *pdev)
typec_mux_unregister(pmc->port[i].typec_mux);
}
+ intel_iom_put(pmc->iom);
+
return 0;
}
--
2.20.1
Input Output Manager (IOM) is part of the Tiger Lake SoC that
configures the Type-C Sub System (TCSS). IOM is a micro controller
that handles Type-C topology, configuration and PM functions of
various Type-C devices connected on the platform.
This driver helps read relevant information such as Type-C port
status (whether a device is connected to a Type-C port or not) and
the activity type on the Type-C ports (such as USB, Display Port,
Thunderbolt), for consumption by other drivers.
Currently intel_iom_port_status() API is exported by this driver,
that has information about the Type-C port status and port activity
type.
Signed-off-by: Rajmohan Mani <[email protected]>
---
drivers/platform/x86/Kconfig | 16 +++
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/intel_iom.c | 133 ++++++++++++++++++++
include/linux/platform_data/x86/intel_iom.h | 62 +++++++++
4 files changed, 212 insertions(+)
create mode 100644 drivers/platform/x86/intel_iom.c
create mode 100644 include/linux/platform_data/x86/intel_iom.h
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 0581a54cf562..271feddb20ef 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -816,6 +816,22 @@ config INTEL_INT0002_VGPIO
To compile this driver as a module, choose M here: the module will
be called intel_int0002_vgpio.
+config INTEL_IOM
+ tristate "Intel Input Output Manager (IOM) driver"
+ depends on ACPI && PCI
+ help
+ This driver helps read relevant information such as Type-C port
+ status (whether a device is connected to a Type-C port or not)
+ and the activity type on the Type-C ports (such as USB, Display
+ Port, Thunderbolt), for consumption by other drivers.
+
+ Currently intel_iom_port_status() API is exported by this driver,
+ that has information about the Type-C port status and port activity
+ type.
+
+ To compile this driver as a module, choose M here: the module will
+ be called intel_iom.
+
config INTEL_MENLOW
tristate "Thermal Management driver for Intel menlow platform"
depends on ACPI_THERMAL
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 2b85852a1a87..d71e4620a7c6 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -76,6 +76,7 @@ intel_cht_int33fe-objs := intel_cht_int33fe_common.o \
intel_cht_int33fe_microb.o
obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
+obj-$(CONFIG_INTEL_IOM) += intel_iom.o
obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o
obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o
obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
diff --git a/drivers/platform/x86/intel_iom.c b/drivers/platform/x86/intel_iom.c
new file mode 100644
index 000000000000..ece0fe720b2d
--- /dev/null
+++ b/drivers/platform/x86/intel_iom.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel Core SoC Input Output Manager (IOM) driver.
+ *
+ * This driver provides access to the Input Output Manager (IOM) (that
+ * is part of Tiger Lake SoC) registers that can be used to know about
+ * Type-C Sub System related information (such as Type-C port status,
+ * activity type on Type-C ports).
+ *
+ * Copyright (C) 2020, Intel Corporation
+ * Author: Rajmohan Mani <[email protected]>
+ */
+
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_data/x86/intel_iom.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+#define IOM_PORT_STATUS_OFFSET 0x560
+
+struct intel_iom {
+ struct device *dev;
+ void __iomem *regbar;
+};
+
+static struct intel_iom iom_dev;
+
+/**
+ * intel_iom_get() - Get IOM device instance
+ *
+ * This function returns the IOM device instance. This also ensures that
+ * this driver cannot be unloaded while the caller has the instance.
+ *
+ * Call intel_iom_put() to release the instance.
+ *
+ * Returns IOM device instance on success or error pointer otherwise.
+ */
+struct intel_iom *intel_iom_get(void)
+{
+ struct device *dev = get_device(iom_dev.dev);
+
+ /* Prevent this driver from being unloaded while in use */
+ if (!try_module_get(dev->driver->owner)) {
+ put_device(iom_dev.dev);
+ return ERR_PTR(-EBUSY);
+ }
+
+ return &iom_dev;
+}
+EXPORT_SYMBOL_GPL(intel_iom_get);
+
+/**
+ * intel_iom_put() - Put IOM device instance
+ * @iom: IOM device instance
+ *
+ * This function releases the IOM device instance created using
+ * intel_iom_get() and allows the driver to be unloaded.
+ *
+ * Call intel_iom_put() to release the instance.
+ */
+void intel_iom_put(struct intel_iom *iom)
+{
+ if (!iom)
+ return;
+
+ module_put(iom->dev->driver->owner);
+ put_device(iom->dev);
+}
+EXPORT_SYMBOL_GPL(intel_iom_put);
+
+/**
+ * intel_iom_port_status() - Get status bits for the Type-C port
+ * @iom: IOM device instance
+ * @port: Type-C port number
+ * @status: pointer to receive the status bits
+ *
+ * Returns 0 on success, error otherwise.
+ */
+int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status)
+{
+ void __iomem *reg;
+
+ if (!iom)
+ return -ENODEV;
+
+ if (!status || (port > IOM_MAX_PORTS - 1))
+ return -EINVAL;
+
+ reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * port;
+
+ *status = ioread32(reg);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(intel_iom_port_status);
+
+static int intel_iom_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ void __iomem *addr;
+
+ addr = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(addr))
+ return PTR_ERR(addr);
+
+ iom_dev.regbar = addr;
+
+ iom_dev.dev = dev;
+ dev_set_drvdata(dev, &iom_dev);
+ return 0;
+}
+
+static const struct acpi_device_id intel_iom_acpi_ids[] = {
+ { "INTC1072" },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, intel_iom_acpi_ids);
+
+static struct platform_driver intel_iom_driver = {
+ .probe = intel_iom_probe,
+ .driver = {
+ .name = "intel_iom",
+ .acpi_match_table = intel_iom_acpi_ids,
+ },
+};
+
+module_platform_driver_probe(intel_iom_driver, intel_iom_probe);
+
+MODULE_AUTHOR("Rajmohan Mani <[email protected]>");
+MODULE_DESCRIPTION("Intel IOM driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/platform_data/x86/intel_iom.h b/include/linux/platform_data/x86/intel_iom.h
new file mode 100644
index 000000000000..d86c60b25a44
--- /dev/null
+++ b/include/linux/platform_data/x86/intel_iom.h
@@ -0,0 +1,62 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _PLATFORM_DATA_X86_INTEL_IOM_H_
+#define _PLATFORM_DATA_X86_INTEL_IOM_H_
+
+#include <linux/bits.h>
+#include <linux/types.h>
+
+/* Input Output Manager (IOM) PORT STATUS */
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_MASK GENMASK(9, 6)
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_SHIFT 0x06
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_USB 0x03
+/* activity type: Safe Mode */
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_SAFE_MODE 0x04
+/* activity type: Display Port */
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_DP 0x05
+/* activity type: Display Port Multi Function Device */
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_DP_MFD 0x06
+/* activity type: Thunderbolt */
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_TBT 0x07
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_ALT_MODE_USB 0x0c
+#define IOM_PORT_STATUS_ACTIVITY_TYPE_ALT_MODE_TBT_USB 0x0d
+/* Upstream Facing Port Information */
+#define IOM_PORT_STATUS_UFP BIT(10)
+/* Display Port Hot Plug Detect status */
+#define IOM_PORT_STATUS_DHPD_HPD_STATUS_MASK GENMASK(13, 12)
+#define IOM_PORT_STATUS_DHPD_HPD_STATUS_SHIFT 0x0c
+#define IOM_PORT_STATUS_DHPD_HPD_STATUS_ASSERT 0x01
+#define IOM_PORT_STATUS_DHPD_HPD_SOURCE_TBT BIT(14)
+#define IOM_PORT_STATUS_CONNECTED BIT(31)
+
+#define IOM_MAX_PORTS 4
+/* Register length in bytes */
+#define IOM_REG_LEN 4
+
+struct intel_iom;
+
+#ifdef CONFIG_ACPI
+
+struct intel_iom *intel_iom_get(void);
+void intel_iom_put(struct intel_iom *iom);
+int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status);
+
+#else
+
+struct intel_iom *intel_iom_get(void)
+{
+ return NULL;
+}
+
+void intel_iom_put(struct intel_iom *iom)
+{
+}
+
+int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* _PLATFORM_DATA_X86_INTEL_IOM_H_ */
--
2.20.1
On Wed, Jul 15, 2020 at 05:33:10PM -0700, Rajmohan Mani wrote:
> From: Heikki Krogerus <[email protected]>
>
> The PMC microcontroller that we use for configuration, does
> not supply any status information back. For port status we
> need to talk to another controller on the board called IOM
> (I/O manager).
>
> By checking the port status before configuring the muxes, we
> can make sure that we do not reconfigure the port after
> bootup when the system firmware (for example BIOS) has
> already configured it.
>
> Using the status information also to check if DisplayPort
> HPD is still asserted when the cable plug is disconnected,
> and clearing it if it is.
>
> Signed-off-by: Heikki Krogerus <[email protected]>
You can't just forward on patches from others without also adding your
signed-off-by to them, right?
Please fix up this series and try again.
thanks,
greg k-h
On Wed, Jul 15, 2020 at 05:33:09PM -0700, Rajmohan Mani wrote:
> Input Output Manager (IOM) is part of the Tiger Lake SoC that
> configures the Type-C Sub System (TCSS). IOM is a micro controller
> that handles Type-C topology, configuration and PM functions of
> various Type-C devices connected on the platform.
>
> This driver helps read relevant information such as Type-C port
> status (whether a device is connected to a Type-C port or not) and
> the activity type on the Type-C ports (such as USB, Display Port,
> Thunderbolt), for consumption by other drivers.
>
> Currently intel_iom_port_status() API is exported by this driver,
> that has information about the Type-C port status and port activity
> type.
>
> Signed-off-by: Rajmohan Mani <[email protected]>
> ---
> drivers/platform/x86/Kconfig | 16 +++
> drivers/platform/x86/Makefile | 1 +
> drivers/platform/x86/intel_iom.c | 133 ++++++++++++++++++++
> include/linux/platform_data/x86/intel_iom.h | 62 +++++++++
Why do you need a .h file for a single .c file that no one else shares
this data? Just put it all in the .c file please.
> 4 files changed, 212 insertions(+)
> create mode 100644 drivers/platform/x86/intel_iom.c
> create mode 100644 include/linux/platform_data/x86/intel_iom.h
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 0581a54cf562..271feddb20ef 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -816,6 +816,22 @@ config INTEL_INT0002_VGPIO
> To compile this driver as a module, choose M here: the module will
> be called intel_int0002_vgpio.
>
> +config INTEL_IOM
> + tristate "Intel Input Output Manager (IOM) driver"
> + depends on ACPI && PCI
> + help
> + This driver helps read relevant information such as Type-C port
> + status (whether a device is connected to a Type-C port or not)
> + and the activity type on the Type-C ports (such as USB, Display
> + Port, Thunderbolt), for consumption by other drivers.
> +
> + Currently intel_iom_port_status() API is exported by this driver,
> + that has information about the Type-C port status and port activity
> + type.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called intel_iom.
> +
> config INTEL_MENLOW
> tristate "Thermal Management driver for Intel menlow platform"
> depends on ACPI_THERMAL
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 2b85852a1a87..d71e4620a7c6 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -76,6 +76,7 @@ intel_cht_int33fe-objs := intel_cht_int33fe_common.o \
> intel_cht_int33fe_microb.o
> obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
> obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
> +obj-$(CONFIG_INTEL_IOM) += intel_iom.o
> obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o
> obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o
> obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
> diff --git a/drivers/platform/x86/intel_iom.c b/drivers/platform/x86/intel_iom.c
> new file mode 100644
> index 000000000000..ece0fe720b2d
> --- /dev/null
> +++ b/drivers/platform/x86/intel_iom.c
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Intel Core SoC Input Output Manager (IOM) driver.
> + *
> + * This driver provides access to the Input Output Manager (IOM) (that
> + * is part of Tiger Lake SoC) registers that can be used to know about
> + * Type-C Sub System related information (such as Type-C port status,
> + * activity type on Type-C ports).
> + *
> + * Copyright (C) 2020, Intel Corporation
> + * Author: Rajmohan Mani <[email protected]>
> + */
> +
> +#include <linux/io.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_data/x86/intel_iom.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +
> +#define IOM_PORT_STATUS_OFFSET 0x560
> +
> +struct intel_iom {
> + struct device *dev;
> + void __iomem *regbar;
> +};
> +
> +static struct intel_iom iom_dev;
Why just one? Why is this static?
> +
> +/**
> + * intel_iom_get() - Get IOM device instance
> + *
> + * This function returns the IOM device instance. This also ensures that
> + * this driver cannot be unloaded while the caller has the instance.
> + *
> + * Call intel_iom_put() to release the instance.
> + *
> + * Returns IOM device instance on success or error pointer otherwise.
> + */
> +struct intel_iom *intel_iom_get(void)
> +{
> + struct device *dev = get_device(iom_dev.dev);
Wht if dev is NULL?
> +
> + /* Prevent this driver from being unloaded while in use */
> + if (!try_module_get(dev->driver->owner)) {
Why are you poking around in a random device's driver's owner?
That's not ok. And probably totally racy.
Handle module reference counts properly, not like this.
And why does it even matter that you incremented the module reference
count? What is that "protecting" you from?
> + put_device(iom_dev.dev);
> + return ERR_PTR(-EBUSY);
> + }
> +
> + return &iom_dev;
> +}
> +EXPORT_SYMBOL_GPL(intel_iom_get);
Who calls this function?
> +
> +/**
> + * intel_iom_put() - Put IOM device instance
> + * @iom: IOM device instance
> + *
> + * This function releases the IOM device instance created using
> + * intel_iom_get() and allows the driver to be unloaded.
> + *
> + * Call intel_iom_put() to release the instance.
> + */
> +void intel_iom_put(struct intel_iom *iom)
> +{
> + if (!iom)
> + return;
> +
> + module_put(iom->dev->driver->owner);
And if the device doesn't have a driver? boom :(
Don't do this.
> + put_device(iom->dev);
> +}
> +EXPORT_SYMBOL_GPL(intel_iom_put);
> +
> +/**
> + * intel_iom_port_status() - Get status bits for the Type-C port
> + * @iom: IOM device instance
> + * @port: Type-C port number
> + * @status: pointer to receive the status bits
> + *
> + * Returns 0 on success, error otherwise.
> + */
> +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32 *status)
> +{
> + void __iomem *reg;
> +
> + if (!iom)
> + return -ENODEV;
> +
> + if (!status || (port > IOM_MAX_PORTS - 1))
> + return -EINVAL;
> +
> + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN * port;
> +
> + *status = ioread32(reg);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(intel_iom_port_status);
So the whole driver is here just to read, directly from memory, a single
32 bit value? Doesn't that seem like a lot of overkill? Why can't the
caller just do this themselves?
greg k-h
Hi Greg,
Thanks for the reviews.
> -----Original Message-----
> From: Greg Kroah-Hartman <[email protected]>
> Sent: Thursday, July 16, 2020 12:10 AM
> To: Mani, Rajmohan <[email protected]>
> Cc: Darren Hart <[email protected]>; Andy Shevchenko
> <[email protected]>; Mika Westerberg
> <[email protected]>; Dmitry Torokhov
> <[email protected]>; Lee Jones <[email protected]>; Ayman
> Bagabas <[email protected]>; Masahiro Yamada
> <[email protected]>; Joseph, Jithu <[email protected]>; Bla?
> Hrastnik <[email protected]>; Srinivas Pandruvada
> <[email protected]>; [email protected];
> [email protected]; Heikki Krogerus
> <[email protected]>; [email protected];
> [email protected]; [email protected]
> Subject: Re: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM)
> driver
>
> On Wed, Jul 15, 2020 at 05:33:09PM -0700, Rajmohan Mani wrote:
> > Input Output Manager (IOM) is part of the Tiger Lake SoC that
> > configures the Type-C Sub System (TCSS). IOM is a micro controller
> > that handles Type-C topology, configuration and PM functions of
> > various Type-C devices connected on the platform.
> >
> > This driver helps read relevant information such as Type-C port status
> > (whether a device is connected to a Type-C port or not) and the
> > activity type on the Type-C ports (such as USB, Display Port,
> > Thunderbolt), for consumption by other drivers.
> >
> > Currently intel_iom_port_status() API is exported by this driver, that
> > has information about the Type-C port status and port activity type.
> >
> > Signed-off-by: Rajmohan Mani <[email protected]>
> > ---
> > drivers/platform/x86/Kconfig | 16 +++
> > drivers/platform/x86/Makefile | 1 +
> > drivers/platform/x86/intel_iom.c | 133 ++++++++++++++++++++
> > include/linux/platform_data/x86/intel_iom.h | 62 +++++++++
>
> Why do you need a .h file for a single .c file that no one else shares this data?
> Just put it all in the .c file please.
>
The APIs exported by this driver, are used by the caller (Intel PMC USB mux
control driver), hence the need for header file.
> > 4 files changed, 212 insertions(+)
> > create mode 100644 drivers/platform/x86/intel_iom.c create mode
> > 100644 include/linux/platform_data/x86/intel_iom.h
> >
> > diff --git a/drivers/platform/x86/Kconfig
> > b/drivers/platform/x86/Kconfig index 0581a54cf562..271feddb20ef 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -816,6 +816,22 @@ config INTEL_INT0002_VGPIO
> > To compile this driver as a module, choose M here: the module will
> > be called intel_int0002_vgpio.
> >
> > +config INTEL_IOM
> > + tristate "Intel Input Output Manager (IOM) driver"
> > + depends on ACPI && PCI
> > + help
> > + This driver helps read relevant information such as Type-C port
> > + status (whether a device is connected to a Type-C port or not)
> > + and the activity type on the Type-C ports (such as USB, Display
> > + Port, Thunderbolt), for consumption by other drivers.
> > +
> > + Currently intel_iom_port_status() API is exported by this driver,
> > + that has information about the Type-C port status and port activity
> > + type.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called intel_iom.
> > +
> > config INTEL_MENLOW
> > tristate "Thermal Management driver for Intel menlow platform"
> > depends on ACPI_THERMAL
> > diff --git a/drivers/platform/x86/Makefile
> > b/drivers/platform/x86/Makefile index 2b85852a1a87..d71e4620a7c6
> > 100644
> > --- a/drivers/platform/x86/Makefile
> > +++ b/drivers/platform/x86/Makefile
> > @@ -76,6 +76,7 @@ intel_cht_int33fe-objs :=
> intel_cht_int33fe_common.o \
> > intel_cht_int33fe_microb.o
> > obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
> > obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
> > +obj-$(CONFIG_INTEL_IOM) += intel_iom.o
> > obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o
> > obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o
> > obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
> > diff --git a/drivers/platform/x86/intel_iom.c
> > b/drivers/platform/x86/intel_iom.c
> > new file mode 100644
> > index 000000000000..ece0fe720b2d
> > --- /dev/null
> > +++ b/drivers/platform/x86/intel_iom.c
> > @@ -0,0 +1,133 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Intel Core SoC Input Output Manager (IOM) driver.
> > + *
> > + * This driver provides access to the Input Output Manager (IOM)
> > +(that
> > + * is part of Tiger Lake SoC) registers that can be used to know
> > +about
> > + * Type-C Sub System related information (such as Type-C port status,
> > + * activity type on Type-C ports).
> > + *
> > + * Copyright (C) 2020, Intel Corporation
> > + * Author: Rajmohan Mani <[email protected]> */
> > +
> > +#include <linux/io.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_data/x86/intel_iom.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +
> > +#define IOM_PORT_STATUS_OFFSET 0x560
> > +
> > +struct intel_iom {
> > + struct device *dev;
> > + void __iomem *regbar;
> > +};
> > +
> > +static struct intel_iom iom_dev;
>
> Why just one? Why is this static?
>
There is just one IOM device in the system.
> > +
> > +/**
> > + * intel_iom_get() - Get IOM device instance
> > + *
> > + * This function returns the IOM device instance. This also ensures
> > +that
> > + * this driver cannot be unloaded while the caller has the instance.
> > + *
> > + * Call intel_iom_put() to release the instance.
> > + *
> > + * Returns IOM device instance on success or error pointer otherwise.
> > + */
> > +struct intel_iom *intel_iom_get(void) {
> > + struct device *dev = get_device(iom_dev.dev);
>
> Wht if dev is NULL?
>
Ack. Will add a check for NULL.
> > +
> > + /* Prevent this driver from being unloaded while in use */
> > + if (!try_module_get(dev->driver->owner)) {
>
> Why are you poking around in a random device's driver's owner?
>
> That's not ok. And probably totally racy.
>
> Handle module reference counts properly, not like this.
>
Ack. Will use THIS_MODULE here.
> And why does it even matter that you incremented the module reference
> count? What is that "protecting" you from?
>
To prevent this driver from being unloaded, while it is being used.
> > + put_device(iom_dev.dev);
> > + return ERR_PTR(-EBUSY);
> > + }
> > +
> > + return &iom_dev;
> > +}
> > +EXPORT_SYMBOL_GPL(intel_iom_get);
>
> Who calls this function?
>
Intel PMC USB mux control driver, in this case.
The callers are expected to call intel_iom_get() before using the
intel_iom_port_status(), after which intel_iom_put() can be called
to release the IOM device instance.
> > +
> > +/**
> > + * intel_iom_put() - Put IOM device instance
> > + * @iom: IOM device instance
> > + *
> > + * This function releases the IOM device instance created using
> > + * intel_iom_get() and allows the driver to be unloaded.
> > + *
> > + * Call intel_iom_put() to release the instance.
> > + */
> > +void intel_iom_put(struct intel_iom *iom) {
> > + if (!iom)
> > + return;
> > +
> > + module_put(iom->dev->driver->owner);
>
> And if the device doesn't have a driver? boom :(
>
> Don't do this.
>
Ack. Will use THIS_MODULE here.
> > + put_device(iom->dev);
> > +}
> > +EXPORT_SYMBOL_GPL(intel_iom_put);
> > +
> > +/**
> > + * intel_iom_port_status() - Get status bits for the Type-C port
> > + * @iom: IOM device instance
> > + * @port: Type-C port number
> > + * @status: pointer to receive the status bits
> > + *
> > + * Returns 0 on success, error otherwise.
> > + */
> > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32
> > +*status) {
> > + void __iomem *reg;
> > +
> > + if (!iom)
> > + return -ENODEV;
> > +
> > + if (!status || (port > IOM_MAX_PORTS - 1))
> > + return -EINVAL;
> > +
> > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN *
> port;
> > +
> > + *status = ioread32(reg);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(intel_iom_port_status);
>
> So the whole driver is here just to read, directly from memory, a single
> 32 bit value?
Yes.
> Doesn't that seem like a lot of overkill? Why can't the caller just
> do this themselves?
>
Ack.
Intel PMC USB mux device is part of the PCH, while IOM is part of the SoC.
So I thought it made sense to keep these 2 devices / drivers apart, despite
the overkill. Heikki also agreed with this approach, given the above.
> greg k-h
Hi Greg,
> -----Original Message-----
> From: Greg Kroah-Hartman <[email protected]>
> Sent: Thursday, July 16, 2020 12:05 AM
> To: Mani, Rajmohan <[email protected]>
> Cc: Darren Hart <[email protected]>; Andy Shevchenko
> <[email protected]>; Mika Westerberg
> <[email protected]>; Dmitry Torokhov
> <[email protected]>; Lee Jones <[email protected]>; Ayman
> Bagabas <[email protected]>; Masahiro Yamada
> <[email protected]>; Joseph, Jithu <[email protected]>; Bla?
> Hrastnik <[email protected]>; Srinivas Pandruvada
> <[email protected]>; [email protected];
> [email protected]; Heikki Krogerus
> <[email protected]>; [email protected];
> [email protected]; [email protected]
> Subject: Re: [PATCH 2/2] usb: typec: intel_pmc_mux: Check the port status
> before connect
>
> On Wed, Jul 15, 2020 at 05:33:10PM -0700, Rajmohan Mani wrote:
> > From: Heikki Krogerus <[email protected]>
> >
> > The PMC microcontroller that we use for configuration, does not supply
> > any status information back. For port status we need to talk to
> > another controller on the board called IOM (I/O manager).
> >
> > By checking the port status before configuring the muxes, we can make
> > sure that we do not reconfigure the port after bootup when the system
> > firmware (for example BIOS) has already configured it.
> >
> > Using the status information also to check if DisplayPort HPD is still
> > asserted when the cable plug is disconnected, and clearing it if it
> > is.
> >
> > Signed-off-by: Heikki Krogerus <[email protected]>
>
> You can't just forward on patches from others without also adding your
> signed-off-by to them, right?
>
Sorry I missed this.
> Please fix up this series and try again.
>
Ack. Will fix this with v2.
> thanks,
>
> greg k-h
On Fri, Jul 17, 2020 at 06:04:51AM +0000, Mani, Rajmohan wrote:
> Hi Greg,
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Thursday, July 16, 2020 12:05 AM
> > To: Mani, Rajmohan <[email protected]>
> > Cc: Darren Hart <[email protected]>; Andy Shevchenko
> > <[email protected]>; Mika Westerberg
> > <[email protected]>; Dmitry Torokhov
> > <[email protected]>; Lee Jones <[email protected]>; Ayman
> > Bagabas <[email protected]>; Masahiro Yamada
> > <[email protected]>; Joseph, Jithu <[email protected]>; Blaž
> > Hrastnik <[email protected]>; Srinivas Pandruvada
> > <[email protected]>; [email protected];
> > [email protected]; Heikki Krogerus
> > <[email protected]>; [email protected];
> > [email protected]; [email protected]
> > Subject: Re: [PATCH 2/2] usb: typec: intel_pmc_mux: Check the port status
> > before connect
> >
> > On Wed, Jul 15, 2020 at 05:33:10PM -0700, Rajmohan Mani wrote:
> > > From: Heikki Krogerus <[email protected]>
> > >
> > > The PMC microcontroller that we use for configuration, does not supply
> > > any status information back. For port status we need to talk to
> > > another controller on the board called IOM (I/O manager).
> > >
> > > By checking the port status before configuring the muxes, we can make
> > > sure that we do not reconfigure the port after bootup when the system
> > > firmware (for example BIOS) has already configured it.
> > >
> > > Using the status information also to check if DisplayPort HPD is still
> > > asserted when the cable plug is disconnected, and clearing it if it
> > > is.
> > >
> > > Signed-off-by: Heikki Krogerus <[email protected]>
> >
> > You can't just forward on patches from others without also adding your
> > signed-off-by to them, right?
> >
>
> Sorry I missed this.
>
> > Please fix up this series and try again.
> >
>
> Ack. Will fix this with v2.
Stop and go talk to the proper people in Intel for how to submit patches
to the kernel as you are not following the rules they have documented
for you.
thanks,
greg k-h
On Fri, Jul 17, 2020 at 06:03:55AM +0000, Mani, Rajmohan wrote:
> Hi Greg,
>
> Thanks for the reviews.
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Thursday, July 16, 2020 12:10 AM
> > To: Mani, Rajmohan <[email protected]>
> > Cc: Darren Hart <[email protected]>; Andy Shevchenko
> > <[email protected]>; Mika Westerberg
> > <[email protected]>; Dmitry Torokhov
> > <[email protected]>; Lee Jones <[email protected]>; Ayman
> > Bagabas <[email protected]>; Masahiro Yamada
> > <[email protected]>; Joseph, Jithu <[email protected]>; Blaž
> > Hrastnik <[email protected]>; Srinivas Pandruvada
> > <[email protected]>; [email protected];
> > [email protected]; Heikki Krogerus
> > <[email protected]>; [email protected];
> > [email protected]; [email protected]
> > Subject: Re: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM)
> > driver
> >
> > On Wed, Jul 15, 2020 at 05:33:09PM -0700, Rajmohan Mani wrote:
> > > Input Output Manager (IOM) is part of the Tiger Lake SoC that
> > > configures the Type-C Sub System (TCSS). IOM is a micro controller
> > > that handles Type-C topology, configuration and PM functions of
> > > various Type-C devices connected on the platform.
> > >
> > > This driver helps read relevant information such as Type-C port status
> > > (whether a device is connected to a Type-C port or not) and the
> > > activity type on the Type-C ports (such as USB, Display Port,
> > > Thunderbolt), for consumption by other drivers.
> > >
> > > Currently intel_iom_port_status() API is exported by this driver, that
> > > has information about the Type-C port status and port activity type.
> > >
> > > Signed-off-by: Rajmohan Mani <[email protected]>
> > > ---
> > > drivers/platform/x86/Kconfig | 16 +++
> > > drivers/platform/x86/Makefile | 1 +
> > > drivers/platform/x86/intel_iom.c | 133 ++++++++++++++++++++
> > > include/linux/platform_data/x86/intel_iom.h | 62 +++++++++
> >
> > Why do you need a .h file for a single .c file that no one else shares this data?
> > Just put it all in the .c file please.
> >
>
> The APIs exported by this driver, are used by the caller (Intel PMC USB mux
> control driver), hence the need for header file.
>
> > > 4 files changed, 212 insertions(+)
> > > create mode 100644 drivers/platform/x86/intel_iom.c create mode
> > > 100644 include/linux/platform_data/x86/intel_iom.h
> > >
> > > diff --git a/drivers/platform/x86/Kconfig
> > > b/drivers/platform/x86/Kconfig index 0581a54cf562..271feddb20ef 100644
> > > --- a/drivers/platform/x86/Kconfig
> > > +++ b/drivers/platform/x86/Kconfig
> > > @@ -816,6 +816,22 @@ config INTEL_INT0002_VGPIO
> > > To compile this driver as a module, choose M here: the module will
> > > be called intel_int0002_vgpio.
> > >
> > > +config INTEL_IOM
> > > + tristate "Intel Input Output Manager (IOM) driver"
> > > + depends on ACPI && PCI
> > > + help
> > > + This driver helps read relevant information such as Type-C port
> > > + status (whether a device is connected to a Type-C port or not)
> > > + and the activity type on the Type-C ports (such as USB, Display
> > > + Port, Thunderbolt), for consumption by other drivers.
> > > +
> > > + Currently intel_iom_port_status() API is exported by this driver,
> > > + that has information about the Type-C port status and port activity
> > > + type.
> > > +
> > > + To compile this driver as a module, choose M here: the module will
> > > + be called intel_iom.
> > > +
> > > config INTEL_MENLOW
> > > tristate "Thermal Management driver for Intel menlow platform"
> > > depends on ACPI_THERMAL
> > > diff --git a/drivers/platform/x86/Makefile
> > > b/drivers/platform/x86/Makefile index 2b85852a1a87..d71e4620a7c6
> > > 100644
> > > --- a/drivers/platform/x86/Makefile
> > > +++ b/drivers/platform/x86/Makefile
> > > @@ -76,6 +76,7 @@ intel_cht_int33fe-objs :=
> > intel_cht_int33fe_common.o \
> > > intel_cht_int33fe_microb.o
> > > obj-$(CONFIG_INTEL_HID_EVENT) += intel-hid.o
> > > obj-$(CONFIG_INTEL_INT0002_VGPIO) += intel_int0002_vgpio.o
> > > +obj-$(CONFIG_INTEL_IOM) += intel_iom.o
> > > obj-$(CONFIG_INTEL_MENLOW) += intel_menlow.o
> > > obj-$(CONFIG_INTEL_OAKTRAIL) += intel_oaktrail.o
> > > obj-$(CONFIG_INTEL_VBTN) += intel-vbtn.o
> > > diff --git a/drivers/platform/x86/intel_iom.c
> > > b/drivers/platform/x86/intel_iom.c
> > > new file mode 100644
> > > index 000000000000..ece0fe720b2d
> > > --- /dev/null
> > > +++ b/drivers/platform/x86/intel_iom.c
> > > @@ -0,0 +1,133 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Intel Core SoC Input Output Manager (IOM) driver.
> > > + *
> > > + * This driver provides access to the Input Output Manager (IOM)
> > > +(that
> > > + * is part of Tiger Lake SoC) registers that can be used to know
> > > +about
> > > + * Type-C Sub System related information (such as Type-C port status,
> > > + * activity type on Type-C ports).
> > > + *
> > > + * Copyright (C) 2020, Intel Corporation
> > > + * Author: Rajmohan Mani <[email protected]> */
> > > +
> > > +#include <linux/io.h>
> > > +#include <linux/mod_devicetable.h>
> > > +#include <linux/module.h>
> > > +#include <linux/platform_data/x86/intel_iom.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/slab.h>
> > > +
> > > +#define IOM_PORT_STATUS_OFFSET 0x560
> > > +
> > > +struct intel_iom {
> > > + struct device *dev;
> > > + void __iomem *regbar;
> > > +};
> > > +
> > > +static struct intel_iom iom_dev;
> >
> > Why just one? Why is this static?
> >
>
> There is just one IOM device in the system.
For today, yes, no need to force yourself to have to change this in the
future. Just use a normal per-instance variable instead please, if you
really need it.
> > > +
> > > + /* Prevent this driver from being unloaded while in use */
> > > + if (!try_module_get(dev->driver->owner)) {
> >
> > Why are you poking around in a random device's driver's owner?
> >
> > That's not ok. And probably totally racy.
> >
> > Handle module reference counts properly, not like this.
> >
>
> Ack. Will use THIS_MODULE here.
No, that is not the answer, and is always wrong to use :(
> > And why does it even matter that you incremented the module reference
> > count? What is that "protecting" you from?
> >
>
> To prevent this driver from being unloaded, while it is being used.
Why does that matter? Shouldn't normal reference counting and
dependancies be all that you need?
> > > + put_device(iom_dev.dev);
> > > + return ERR_PTR(-EBUSY);
> > > + }
> > > +
> > > + return &iom_dev;
> > > +}
> > > +EXPORT_SYMBOL_GPL(intel_iom_get);
> >
> > Who calls this function?
> >
>
> Intel PMC USB mux control driver, in this case.
> The callers are expected to call intel_iom_get() before using the
> intel_iom_port_status(), after which intel_iom_put() can be called
> to release the IOM device instance.
Why not just have a single call if all this driver does is support one
thing. The reference counting shouldn't be needed at all, right?
> > > +/**
> > > + * intel_iom_put() - Put IOM device instance
> > > + * @iom: IOM device instance
> > > + *
> > > + * This function releases the IOM device instance created using
> > > + * intel_iom_get() and allows the driver to be unloaded.
> > > + *
> > > + * Call intel_iom_put() to release the instance.
> > > + */
> > > +void intel_iom_put(struct intel_iom *iom) {
> > > + if (!iom)
> > > + return;
> > > +
> > > + module_put(iom->dev->driver->owner);
> >
> > And if the device doesn't have a driver? boom :(
> >
> > Don't do this.
> >
>
> Ack. Will use THIS_MODULE here.
Again, no, that will be even more incorrect.
> > > + put_device(iom->dev);
> > > +}
> > > +EXPORT_SYMBOL_GPL(intel_iom_put);
> > > +
> > > +/**
> > > + * intel_iom_port_status() - Get status bits for the Type-C port
> > > + * @iom: IOM device instance
> > > + * @port: Type-C port number
> > > + * @status: pointer to receive the status bits
> > > + *
> > > + * Returns 0 on success, error otherwise.
> > > + */
> > > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32
> > > +*status) {
> > > + void __iomem *reg;
> > > +
> > > + if (!iom)
> > > + return -ENODEV;
> > > +
> > > + if (!status || (port > IOM_MAX_PORTS - 1))
> > > + return -EINVAL;
> > > +
> > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN *
> > port;
> > > +
> > > + *status = ioread32(reg);
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(intel_iom_port_status);
> >
> > So the whole driver is here just to read, directly from memory, a single
> > 32 bit value?
>
> Yes.
Ok, then this whole driver could be about 90% smaller and more obvious.
Don't add the reference counting, the static variables and all the other
stuff just to get a 32bit number.
As it is, this feels like an excuse to get paid per lines of code :(
greg k-h
Hi Greg,
> Subject: Re: [PATCH 1/2] platform/x86: Add Intel Input Output Manager (IOM)
> driver
...
> > > > +struct intel_iom {
> > > > + struct device *dev;
> > > > + void __iomem *regbar;
> > > > +};
> > > > +
> > > > +static struct intel_iom iom_dev;
> > >
> > > Why just one? Why is this static?
> > >
> >
> > There is just one IOM device in the system.
>
> For today, yes, no need to force yourself to have to change this in the future.
> Just use a normal per-instance variable instead please, if you really need it.
>
Ack
> > > > +
> > > > + /* Prevent this driver from being unloaded while in use */
> > > > + if (!try_module_get(dev->driver->owner)) {
> > >
> > > Why are you poking around in a random device's driver's owner?
> > >
> > > That's not ok. And probably totally racy.
> > >
> > > Handle module reference counts properly, not like this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> No, that is not the answer, and is always wrong to use :(
>
This should not matter anymore, as I find reference counting may not be needed.
> > > And why does it even matter that you incremented the module
> > > reference count? What is that "protecting" you from?
> > >
> >
> > To prevent this driver from being unloaded, while it is being used.
>
> Why does that matter? Shouldn't normal reference counting and
> dependancies be all that you need?
>
I find just dependencies are enough to prevent the driver from being unloaded.
With Intel PMC USB mux control driver, not using intel_iom_get()/intel_iom_put(),
just invoking intel_iom_port_status() is enough for rmmod to report failure
(citing the use by intel_pmc_mux) in unloading the IOM driver.
> > > > + put_device(iom_dev.dev);
> > > > + return ERR_PTR(-EBUSY);
> > > > + }
> > > > +
> > > > + return &iom_dev;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_get);
> > >
> > > Who calls this function?
> > >
> >
> > Intel PMC USB mux control driver, in this case.
> > The callers are expected to call intel_iom_get() before using the
> > intel_iom_port_status(), after which intel_iom_put() can be called to
> > release the IOM device instance.
>
> Why not just have a single call if all this driver does is support one thing. The
> reference counting shouldn't be needed at all, right?
>
Ack. That looks to be the case, based on my findings.
> > > > +/**
> > > > + * intel_iom_put() - Put IOM device instance
> > > > + * @iom: IOM device instance
> > > > + *
> > > > + * This function releases the IOM device instance created using
> > > > + * intel_iom_get() and allows the driver to be unloaded.
> > > > + *
> > > > + * Call intel_iom_put() to release the instance.
> > > > + */
> > > > +void intel_iom_put(struct intel_iom *iom) {
> > > > + if (!iom)
> > > > + return;
> > > > +
> > > > + module_put(iom->dev->driver->owner);
> > >
> > > And if the device doesn't have a driver? boom :(
> > >
> > > Don't do this.
> > >
> >
> > Ack. Will use THIS_MODULE here.
>
> Again, no, that will be even more incorrect.
>
This shouldn't be relevant anymore.
> > > > + put_device(iom->dev);
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_put);
> > > > +
> > > > +/**
> > > > + * intel_iom_port_status() - Get status bits for the Type-C port
> > > > + * @iom: IOM device instance
> > > > + * @port: Type-C port number
> > > > + * @status: pointer to receive the status bits
> > > > + *
> > > > + * Returns 0 on success, error otherwise.
> > > > + */
> > > > +int intel_iom_port_status(struct intel_iom *iom, u8 port, u32
> > > > +*status) {
> > > > + void __iomem *reg;
> > > > +
> > > > + if (!iom)
> > > > + return -ENODEV;
> > > > +
> > > > + if (!status || (port > IOM_MAX_PORTS - 1))
> > > > + return -EINVAL;
> > > > +
> > > > + reg = iom->regbar + IOM_PORT_STATUS_OFFSET + IOM_REG_LEN *
> > > port;
> > > > +
> > > > + *status = ioread32(reg);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(intel_iom_port_status);
> > >
> > > So the whole driver is here just to read, directly from memory, a
> > > single
> > > 32 bit value?
> >
> > Yes.
>
> Ok, then this whole driver could be about 90% smaller and more obvious.
> Don't add the reference counting, the static variables and all the other stuff
> just to get a 32bit number.
>
Ack