linux-kernel - Re: [PATCH 0/3] drivers:staging:ti-st: patches

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]

Date:	Wed, 18 Aug 2010 14:04:40 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Pavan Savoy <pavan_savoy@...com>
Cc:	devel@...verdev.osuosl.org, gregkh@...e.de,
	linux-kernel@...r.kernel.org, alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH 0/3] drivers:staging:ti-st: patches

On Mon, 26 Jul 2010 10:37:02 +0530 Pavan Savoy wrote:

> On Fri, Jul 23, 2010 at 8:47 PM, Randy Dunlap <randy.dunlap@...cle.com> wrote:
> > On 07/22/10 21:56, Pavan Savoy wrote:
> >> Randy,
> >>
> >> On Fri, Jul 23, 2010 at 1:23 AM, Randy Dunlap <randy.dunlap@...cle.com> wrote:
> >>> On Thu, 22 Jul 2010 05:32:04 -0500 pavan_savoy@...com wrote:
> >>>
> >>>> From: Pavan Savoy <pavan_savoy@...com>
> >>>>
> >>>> The following patches cleanup bit of a mess and also adds functionality to protocol drivers.
> >>>> with the 3rd patch now providing context to even the protocol drivers, the single device limit
> >>>> or support for multiple devices would be easier to implement.
> >>>>
> >>>> These patches depend on the previously submitted
> >>>> 0001-drivers-staging-ti-st-make-use-of-linux-err-codes.patch
> >>>> commit d39d49b393d94f4137cee4f64526a4695352f183
> >>>>
> >>>> Pavan Savoy (3):
> >>>>   drivers:staging:ti-st: smarten, reduce logs
> >>>>   drivers:staging:ti-st: cleanup code comments
> >>>>   drivers:staging:ti-st: give proto drivers context
> >>>>
> >>>>  drivers/staging/ti-st/bt_drv.c  |   23 +++++---
> >>>>  drivers/staging/ti-st/st.h      |   52 +++++++++--------
> >>>>  drivers/staging/ti-st/st_core.c |  118 +++++++++++++++++++--------------------
> >>>>  drivers/staging/ti-st/st_core.h |   74 +++++++++++++++++--------
> >>>>  drivers/staging/ti-st/st_kim.c  |   73 ++++++++++++++----------
> >>>>  drivers/staging/ti-st/st_kim.h  |   77 ++++++++++++++++---------
> >>>>  drivers/staging/ti-st/st_ll.c   |    4 +-
> >>>>  drivers/staging/ti-st/st_ll.h   |    9 +++-
> >>>>  8 files changed, 255 insertions(+), 175 deletions(-)
> >>>
> >>> Hi,
> >>>
> >>> I have reported this error a few times.  Where is the patch for it??
> >>>
> >>> ERROR: "st_get_plat_device" [drivers/staging/ti-st/st_drv.ko] undefined!
> >>
> >>
> >> Yes, on one of the earlier patch sets, I had mentioned that the ST
> >> driver being a platform device, needs definition in any of the
> >> arch/XX/mach-XX/board-XX.c or devices.c or somewhere...
> >>
> >> and hence it is in that board-XX.c file that the symbol
> >> st_get_plat_device needs to be exported, the reason for that being,
> >>
> >> ST driver being both a TTY ldisc driver and platform driver, in TTY
> >> contexts it would need to refer to platform driver's data. So it does
> >> a st_get_plat_device which returns the platform device structure, and
> >> then does a dev_getdrvdata from it.
> >>
> >> here's a snippet of code ...
> >> /*
> >>  * ST related functions related functions
> >>  */
> >> #include <linux/platform_device.h>
> >>
> >> long gpios[] = { 55, -1, -1 };
> >> static struct platform_device ti_st_device = {
> >>         .name           = "kim",
> >>         .id             = -1,
> >>         .dev.platform_data      = &gpios,
> >> };
> >>
> >> struct platform_device *st_get_plat_device(void)
> >> {
> >>         return &ti_st_device;
> >> }
> >> EXPORT_SYMBOL(st_get_plat_device);
> >>
> >> static __init int add_ti_st_device(void)
> >> {
> >>         platform_device_register(&ti_st_device);
> >>         dev_info(&ti_st_device.dev,"registered platform TI ST device\n");
> >>
> >>         return 0;
> >> }
> >> device_initcall(add_ti_st_device);
> >>
> >>
> >> We have that in our local trees in arch/arm/mach-omap2/board-sdp4430.c
> >
> > Thanks for the explanation.
> >
> > Is the driver platform-specific?
> > E.g., should it not even be built on x86?
> 
> Yes. Requirement of the hardware is very much a must.
> However it is a separate peripheral (WiLink 7 - uart interfaced), may
> be there is a x86 platform with this - but certainly not desktops.
> 
> on linux-next, I generally put in that st_dev.c file for x86 - verify
> whether it builds as a module, inserts/rmmod, basic other
> functionalities (which doesn't involve response from chip..)
> But verify full functionality on board which constitutes that.

Hi,
Please make this driver build cleanly on X86 or prevent it from being built there.

thanks,
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
--
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/