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
| ||
|
Date: Wed, 19 Aug 2015 15:00:13 +0530 From: Archit Taneja <architt@...eaurora.org> To: Andrzej Hajda <a.hajda@...sung.com>, dri-devel@...ts.freedesktop.org CC: linux-arm-msm@...r.kernel.org, treding@...dia.com, inki.dae@...sung.com, linux-kernel@...r.kernel.org, airlied@...ux.ie, daniel@...ll.ch, jani.nikula@...ux.intel.com Subject: Re: [RFC 1/2] drm/dsi: Create dummy DSI devices Hi, On 08/19/2015 01:40 PM, Andrzej Hajda wrote: > On 06/30/2015 07:24 AM, Archit Taneja wrote: >> We can have devices where the data bus is MIPI DSI, but the control bus >> is something else (i2c, spi etc). A typical example is i2c controlled >> encoder bridge chips. >> >> Such devices too require passing DSI specific parameters (number of data >> lanes, DSI mode flags, color format etc) to their DSI host. For a device >> that isn't 'mipi_dsi_device', there is no way of passing such parameters. >> >> Provide the option of creating a dummy DSI device. The main purpose of >> this would be to attach to a DSI host by calling mipi_dsi_attach, and >> pass DSI params. >> >> Create mipi_dsi_new_dummy for creating a dummy dsi device. The driver >> calling this needs to be aware of the mipi_dsi_host it wants to attach >> to, and also the DSI virtual channel the DSI device intends to use. >> >> Signed-off-by: Archit Taneja <architt@...eaurora.org> >> --- >> drivers/gpu/drm/drm_mipi_dsi.c | 78 ++++++++++++++++++++++++++++++++++++++++-- >> include/drm/drm_mipi_dsi.h | 2 ++ >> 2 files changed, 78 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c >> index 2d5ca8ee..9bfe215 100644 >> --- a/drivers/gpu/drm/drm_mipi_dsi.c >> +++ b/drivers/gpu/drm/drm_mipi_dsi.c >> @@ -47,7 +47,14 @@ >> >> static int mipi_dsi_device_match(struct device *dev, struct device_driver *drv) >> { >> - return of_driver_match_device(dev, drv); >> + if (of_driver_match_device(dev, drv)) >> + return 1; >> + >> + if (!strcmp(drv->name, "mipi_dsi_dummy") && >> + strstr(dev_name(dev), "dummy_dev")) >> + return 1; > > Is this kind of fuzzy matching used in other dummy devs? It looks little bit > scary. You > can at least replace > > strstr(dev_name(dev), "dummy_dev")) > > with > > strstr(dev_name(dev), ".dummy_dev.")) > > Anyway, currently it should not break anything, am I right? I took i2c's dummy dev creation as reference. The i2c_driver struct has an id_table param, that allows the match function (i2c_device_match) to not have a special case to check for a dummy device. We could a 'id_table' entry in mipi_dsi_driver, and a 'name' entry in mipi_dsi_device. But that would be a bit of an overkill just to support dummy devices. I could make the check more thorough by adding a func which does something similar to 'i2c_verify_client', but I think we would still need the above string. I will change "dummy_dev" to ".dummy_dev.". I grepped the kernel for devices named "dummy_dev", but didn't find anything as such, so it shouldn't really break anything. > >> + >> + return 0; >> } >> >> static const struct dev_pm_ops mipi_dsi_device_pm_ops = { >> @@ -171,6 +178,67 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node) >> return dsi; >> } >> >> +static int dummy_probe(struct mipi_dsi_device *dsi) >> +{ >> + return 0; >> +} >> + >> +static int dummy_remove(struct mipi_dsi_device *dsi) >> +{ >> + return 0; >> +} >> + >> +static void dummy_shutdown(struct mipi_dsi_device *dsi) >> +{ >> +} > > I suppose these callbacks are optional, so you can omit them. Right. I will remove these. Thanks for the review. Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists