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] [day] [month] [year] [list]
Message-ID: <CAK9oHmxmwM0TLZHcgXM5ryLecxD=Ouogoh0Zni4C+d7r0sPwqQ@mail.gmail.com>
Date:	Mon, 2 Dec 2013 15:07:39 +0200
From:	Ruslan Ruslichenko <ruslan.ruslichenko@...ballogic.com>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	Tony Lindgren <tony@...mide.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	Graeme Gregory <graeme.gregory@...aro.org>
Subject: Re: [PATCH] mfd: twl-core: Clean up module by removing twl603x pdata handling

Since add_children() never called in not-dt boot, this patch does not
change current
OMAP4 boot behavior and devices initialization.
Also as far as I see all these twl603x regulators (apart from CLK32KG)
and TWL usb
module now have dt-bindings support. Device tree support for CLK32KG
have been removed
since it should not be registered as regulator at all.
So this patch can merged safely.

On Mon, Dec 2, 2013 at 1:08 PM, Lee Jones <lee.jones@...aro.org> wrote:
>> > > > > Since currently nobody uses TWL603x platform data and all new
>> > > >
>> > > > Hmm... when you say nobody, how did you come to this conclusion?
>> > > >
>> > > > Without digging into it and probably not that relevant, it
>> > > > appears there is some references to it in platform data still:
>> > > >
>> > > > $ git grep twl603 -- arch/ | grep -v dts
>> > > > arch/arm/mach-omap2/common.h:extern int omap4_twl6030_hsmmc_init(struct
>> > > > omap2_hsmmc_info *controllers);
>> > > > arch/arm/mach-omap2/omap4-common.c:static int
>> > > > omap4_twl6030_hsmmc_late_init(struct device *dev)
>> > > > arch/arm/mach-omap2/omap4-common.c:             irq =
>> > > > twl6030_mmc_card_detect_config();
>> > > > arch/arm/mach-omap2/omap4-common.c:
>> > > > pdata->slots[0].card_detect = twl6030_mmc_card_detect;
>> > > > arch/arm/mach-omap2/omap4-common.c:static __init void
>> > > > omap4_twl6030_hsmmc_set_late_init(struct device *dev)
>> > > > arch/arm/mach-omap2/omap4-common.c:     pdata->init =
>> > > > omap4_twl6030_hsmmc_late_init;
>> > > > arch/arm/mach-omap2/omap4-common.c:int __init
>> > > > omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
>> > > > arch/arm/mach-omap2/omap4-common.c:
>> > > > omap4_twl6030_hsmmc_set_late_init(&c->pdev->dev);
>> > > > arch/arm/mach-omap2/omap4-common.c:int __init
>> > > > omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
>> > > > arch/arm/mach-omap2/omap_twl.c:static unsigned long
>> > > > twl6030_vsel_to_uv(const u8 vsel)
>> > > > arch/arm/mach-omap2/omap_twl.c:static u8 twl6030_uv_to_vsel(unsigned long
>> > > > uv)
>> > > > arch/arm/mach-omap2/omap_twl.c: if (uv > twl6030_vsel_to_uv(0x39)) {
>> > > > arch/arm/mach-omap2/omap_twl.c:                 __func__, uv,
>> > > > twl6030_vsel_to_uv(0x39));
>> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv             =
>> > > > twl6030_vsel_to_uv,
>> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel             =
>> > > > twl6030_uv_to_vsel,
>> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv             =
>> > > > twl6030_vsel_to_uv,
>> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel             =
>> > > > twl6030_uv_to_vsel,
>> > > > arch/arm/mach-omap2/omap_twl.c: .vsel_to_uv             =
>> > > > twl6030_vsel_to_uv,
>> > > > arch/arm/mach-omap2/omap_twl.c: .uv_to_vsel             =
>> > > > twl6030_uv_to_vsel,
>> > > >
>> > > Looks like some misunderstanding is here. This patch *only* removes
>> > > platform data for TWL603x
>> > > which were used to create TWL sub-devices like regulators, adc's,
>> > > watchdogs, etc.
>> > > Previously it was set up in twl_common.c by omap4_pmic_init(), which was
>> > > called from board files
>> > > with specific pmic config.
>> > > Since now in Linux kernel 3.13 OMAP4 non-DT boot is not supported and all
>> > > OMAP4 board files
>> > > have been removed omap4_pmic_init() is never called and all TWL603x
>> > > sub-devices are created
>> > > from device tree data.
>> >
>> > I'm not overly familiar with this driver (it looks like a big
>> > historical mess to me), or the current state of the OMAP4 platform, so
>> > I would like a second opinion on this.
>> >
>> > Tony would you be kind enough to oblige?
>>
>> We've moved omap4 to boot based on device tree only, so that legacy
>> platform data is no longer being used. It might be worth checking if
>> we do have bindings in place for all of that, or if some of it may
>> still be needed to be passed as auxdata while we wait for the bindings.
>
> Ruslan, do you know the answer to these concerns?
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog



-- 

Ruslan Ruslichenko | Software Engineer
GlobalLogic
www.globallogic.com

http://www.globallogic.com/email_disclaimer.txt
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ