IOM status has a crucial role during debugging to check the
current state of the type-C port.
There are ways to fetch the status, but all those require the
IOM port status offset, which could change with platform.
Make a debugfs directory for intel_pmc_mux and expose the status
under it per port basis.
Signed-off-by: Rajat Khandelwal <[email protected]>
Reviewed-by: Heikki Krogerus <[email protected]>
---
drivers/usb/typec/mux/intel_pmc_mux.c | 44 +++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
index 34e4188a40ff..c99d20888f5d 100644
--- a/drivers/usb/typec/mux/intel_pmc_mux.c
+++ b/drivers/usb/typec/mux/intel_pmc_mux.c
@@ -15,6 +15,7 @@
#include <linux/usb/typec_mux.h>
#include <linux/usb/typec_dp.h>
#include <linux/usb/typec_tbt.h>
+#include <linux/debugfs.h>
#include <asm/intel_scu_ipc.h>
@@ -145,6 +146,8 @@ struct pmc_usb {
u32 iom_port_status_offset;
};
+static struct dentry *pmc_mux_debugfs_root;
+
static void update_port_status(struct pmc_usb_port *port)
{
u8 port_num;
@@ -639,6 +642,39 @@ static int pmc_usb_probe_iom(struct pmc_usb *pmc)
return 0;
}
+static int port_iom_status_show(struct seq_file *s, void *unused)
+{
+ struct pmc_usb_port *port = s->private;
+
+ update_port_status(port);
+ seq_printf(s, "0x%08x\n", port->iom_status);
+
+ return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(port_iom_status);
+
+static void pmc_mux_port_debugfs_init(struct pmc_usb_port *port)
+{
+ struct dentry *debugfs_dir;
+ char name[6];
+
+ snprintf(name, sizeof(name), "port%d", port->usb3_port - 1);
+
+ debugfs_dir = debugfs_create_dir(name, pmc_mux_debugfs_root);
+ debugfs_create_file("iom_status", 0400, debugfs_dir, port,
+ &port_iom_status_fops);
+}
+
+static void pmc_mux_debugfs_init(void)
+{
+ pmc_mux_debugfs_root = debugfs_create_dir("intel_pmc_mux", NULL);
+}
+
+static void pmc_mux_debugfs_exit(void)
+{
+ debugfs_remove_recursive(pmc_mux_debugfs_root);
+}
+
static int pmc_usb_probe(struct platform_device *pdev)
{
struct fwnode_handle *fwnode = NULL;
@@ -674,6 +710,8 @@ static int pmc_usb_probe(struct platform_device *pdev)
if (ret)
return ret;
+ pmc_mux_debugfs_init();
+
/*
* For every physical USB connector (USB2 and USB3 combo) there is a
* child ACPI device node under the PMC mux ACPI device object.
@@ -688,6 +726,8 @@ static int pmc_usb_probe(struct platform_device *pdev)
fwnode_handle_put(fwnode);
goto err_remove_ports;
}
+
+ pmc_mux_port_debugfs_init(&pmc->port[i]);
}
platform_set_drvdata(pdev, pmc);
@@ -703,6 +743,8 @@ static int pmc_usb_probe(struct platform_device *pdev)
acpi_dev_put(pmc->iom_adev);
+ pmc_mux_debugfs_exit();
+
return ret;
}
@@ -719,6 +761,8 @@ static int pmc_usb_remove(struct platform_device *pdev)
acpi_dev_put(pmc->iom_adev);
+ pmc_mux_debugfs_exit();
+
return 0;
}
--
2.34.1
On Thu, Mar 30, 2023 at 04:18:21PM +0530, Rajat Khandelwal wrote:
> IOM status has a crucial role during debugging to check the
> current state of the type-C port.
> There are ways to fetch the status, but all those require the
> IOM port status offset, which could change with platform.
>
> Make a debugfs directory for intel_pmc_mux and expose the status
> under it per port basis.
>
> Signed-off-by: Rajat Khandelwal <[email protected]>
> Reviewed-by: Heikki Krogerus <[email protected]>
> ---
> drivers/usb/typec/mux/intel_pmc_mux.c | 44 +++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
> index 34e4188a40ff..c99d20888f5d 100644
> --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> @@ -15,6 +15,7 @@
> #include <linux/usb/typec_mux.h>
> #include <linux/usb/typec_dp.h>
> #include <linux/usb/typec_tbt.h>
> +#include <linux/debugfs.h>
>
> #include <asm/intel_scu_ipc.h>
>
> @@ -145,6 +146,8 @@ struct pmc_usb {
> u32 iom_port_status_offset;
> };
>
> +static struct dentry *pmc_mux_debugfs_root;
Why not just look up the dentry and delete it when you want it with a
call to debugfs_lookup_and_remove() instead? That way you don't have to
keep it around (hint, pass it back from your call to
pmc_mux_debugfs_init() or better yet, don't even have a
pmc_mux_debugfs_init() function as it only contains one line and is
only called in one place.
This will save you the storage space of this variable if debugfs is not
enabled in your kernel. A small amount, yes, but it's nicer, right?
thanks,
greg k-h
Hi,
On 3/30/2023 4:31 PM, Greg KH wrote:
> On Thu, Mar 30, 2023 at 04:18:21PM +0530, Rajat Khandelwal wrote:
>> IOM status has a crucial role during debugging to check the
>> current state of the type-C port.
>> There are ways to fetch the status, but all those require the
>> IOM port status offset, which could change with platform.
>>
>> Make a debugfs directory for intel_pmc_mux and expose the status
>> under it per port basis.
>>
>> Signed-off-by: Rajat Khandelwal <[email protected]>
>> Reviewed-by: Heikki Krogerus <[email protected]>
>> ---
>> drivers/usb/typec/mux/intel_pmc_mux.c | 44 +++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
>> index 34e4188a40ff..c99d20888f5d 100644
>> --- a/drivers/usb/typec/mux/intel_pmc_mux.c
>> +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
>> @@ -15,6 +15,7 @@
>> #include <linux/usb/typec_mux.h>
>> #include <linux/usb/typec_dp.h>
>> #include <linux/usb/typec_tbt.h>
>> +#include <linux/debugfs.h>
>>
>> #include <asm/intel_scu_ipc.h>
>>
>> @@ -145,6 +146,8 @@ struct pmc_usb {
>> u32 iom_port_status_offset;
>> };
>>
>> +static struct dentry *pmc_mux_debugfs_root;
> Why not just look up the dentry and delete it when you want it with a
> call to debugfs_lookup_and_remove() instead? That way you don't have to
> keep it around (hint, pass it back from your call to
> pmc_mux_debugfs_init() or better yet, don't even have a
> pmc_mux_debugfs_init() function as it only contains one line and is
> only called in one place.
>
> This will save you the storage space of this variable if debugfs is not
> enabled in your kernel. A small amount, yes, but it's nicer, right?
I see. Yes, though a small amount, you're anyways right.
1. Though a single-line function, I explicitly defined it to make it more readable.
ATM, maintaining a small different framework within the file for another function
(debugfs) somehow presents a more 'organized' code to me, if that makes sense? :)
2. About the suggestion of not keeping the debugfs_root static throughout the
execution, I can change it as per your suggestion, but I'd like to keep it this
way, if that's ok? This way, it would fit nice in the future if more variables
are to be added.
Let me know your thoughts.
Thanks
Rajat
>
> thanks,
>
> greg k-h
On Tue, Apr 04, 2023 at 10:48:38PM +0530, Rajat Khandelwal wrote:
> Hi,
>
> On 3/30/2023 4:31 PM, Greg KH wrote:
> > On Thu, Mar 30, 2023 at 04:18:21PM +0530, Rajat Khandelwal wrote:
> > > IOM status has a crucial role during debugging to check the
> > > current state of the type-C port.
> > > There are ways to fetch the status, but all those require the
> > > IOM port status offset, which could change with platform.
> > >
> > > Make a debugfs directory for intel_pmc_mux and expose the status
> > > under it per port basis.
> > >
> > > Signed-off-by: Rajat Khandelwal <[email protected]>
> > > Reviewed-by: Heikki Krogerus <[email protected]>
> > > ---
> > > drivers/usb/typec/mux/intel_pmc_mux.c | 44 +++++++++++++++++++++++++++
> > > 1 file changed, 44 insertions(+)
> > >
> > > diff --git a/drivers/usb/typec/mux/intel_pmc_mux.c b/drivers/usb/typec/mux/intel_pmc_mux.c
> > > index 34e4188a40ff..c99d20888f5d 100644
> > > --- a/drivers/usb/typec/mux/intel_pmc_mux.c
> > > +++ b/drivers/usb/typec/mux/intel_pmc_mux.c
> > > @@ -15,6 +15,7 @@
> > > #include <linux/usb/typec_mux.h>
> > > #include <linux/usb/typec_dp.h>
> > > #include <linux/usb/typec_tbt.h>
> > > +#include <linux/debugfs.h>
> > > #include <asm/intel_scu_ipc.h>
> > > @@ -145,6 +146,8 @@ struct pmc_usb {
> > > u32 iom_port_status_offset;
> > > };
> > > +static struct dentry *pmc_mux_debugfs_root;
> > Why not just look up the dentry and delete it when you want it with a
> > call to debugfs_lookup_and_remove() instead? That way you don't have to
> > keep it around (hint, pass it back from your call to
> > pmc_mux_debugfs_init() or better yet, don't even have a
> > pmc_mux_debugfs_init() function as it only contains one line and is
> > only called in one place.
> >
> > This will save you the storage space of this variable if debugfs is not
> > enabled in your kernel. A small amount, yes, but it's nicer, right?
>
> I see. Yes, though a small amount, you're anyways right.
>
> 1. Though a single-line function, I explicitly defined it to make it more readable.
> ATM, maintaining a small different framework within the file for another function
> (debugfs) somehow presents a more 'organized' code to me, if that makes sense? :)
You are wrapping an abstraction in an abstraction, i.e. piling on layers
where they are not needed at all. That's not normal for kernel code.
If I am reading the code, and see that function call, I then have to go
and find it and then see that it is making a debugfs call. When
instead, if you just had the debugfs call, when reading the code, you
would instantly know what is happening and can keep on going in your
reading.
> 2. About the suggestion of not keeping the debugfs_root static throughout the
> execution, I can change it as per your suggestion, but I'd like to keep it this
> way, if that's ok? This way, it would fit nice in the future if more variables
> are to be added.
We write code for what we have today. If it needs to change in the
future, great, we will change it then. So no need to worry about that.
Anyway, your call, but I think you can make the code overall smaller
and simpler with my suggestions, but hey, try it out and prove me wrong!
thanks,
greg k-h