* [PATCH v2] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
From: Josh Cartwright @ 2014-01-17 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lhyemr3y.fsf@linaro.org>
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
---
v1->v2: Change conditional to simply CONFIG_PM (thanks ccov and khilman!)
drivers/usb/phy/phy-msm-usb.c | 57 ++++++++++++++++++++-----------------------
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8546c8d..5b169a7 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,32 +159,6 @@ put_3p3:
return rc;
}
-#ifdef CONFIG_PM_SLEEP
-#define USB_PHY_SUSP_DIG_VOL 500000
-static int msm_hsusb_config_vddcx(int high)
-{
- int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
- int min_vol;
- int ret;
-
- if (high)
- min_vol = USB_PHY_VDD_DIG_VOL_MIN;
- else
- min_vol = USB_PHY_SUSP_DIG_VOL;
-
- ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
- if (ret) {
- pr_err("%s: unable to set the voltage for regulator "
- "HSUSB_VDDCX\n", __func__);
- return ret;
- }
-
- pr_debug("%s: min_vol:%d max_vol:%d\n", __func__, min_vol, max_vol);
-
- return ret;
-}
-#endif
-
static int msm_hsusb_ldo_set_mode(int on)
{
int ret = 0;
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC (100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#if CONFIG_PM
+
+#define USB_PHY_SUSP_DIG_VOL 500000
+static int msm_hsusb_config_vddcx(int high)
+{
+ int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
+ int min_vol;
+ int ret;
+
+ if (high)
+ min_vol = USB_PHY_VDD_DIG_VOL_MIN;
+ else
+ min_vol = USB_PHY_SUSP_DIG_VOL;
+
+ ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
+ if (ret) {
+ pr_err("%s: unable to set the voltage for regulator "
+ "HSUSB_VDDCX\n", __func__);
+ return ret;
+ }
+
+ pr_debug("%s: min_vol:%d max_vol:%d\n", __func__, min_vol, max_vol);
+
+ return ret;
+}
+
static int msm_otg_suspend(struct msm_otg *motg)
{
struct usb_phy *phy = &motg->phy;
@@ -1733,22 +1732,18 @@ static int msm_otg_pm_resume(struct device *dev)
}
#endif
-#ifdef CONFIG_PM
static const struct dev_pm_ops msm_otg_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(msm_otg_pm_suspend, msm_otg_pm_resume)
SET_RUNTIME_PM_OPS(msm_otg_runtime_suspend, msm_otg_runtime_resume,
msm_otg_runtime_idle)
};
-#endif
static struct platform_driver msm_otg_driver = {
.remove = msm_otg_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = &msm_otg_dev_pm_ops,
-#endif
},
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] clocksource: timer-sun5i: Switch to sched_clock_register()
From: Stephen Boyd @ 2014-01-17 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D90060.5020104@linaro.org>
On 01/17/14 02:05, Daniel Lezcano wrote:
> On 01/17/2014 02:38 AM, Stephen Boyd wrote:
>> The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
>> Upgrade to the 64 bit function to allow us to remove the 32 bit
>> registration interface.
>>
>> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>> ---
>>
>> Cc'in Ingo because this is simple enough to probably just apply to
>> timers/core
>
> Hi Stephen,
>
> I applied your patch in my tree for 3.15.
>
I was hoping we could remove setup_sched_clock() in 3.14-rc1 timeline,
but if we delay this until 3.15 we'll have to wait another 3 months. Is
there any chance we can get this in for 3.14?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 1/7] ARM: perf_event: Support percpu irqs for the CPU PMU
From: Stephen Boyd @ 2014-01-17 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117150411.GI16003@mudshark.cambridge.arm.com>
On 01/17/14 07:04, Will Deacon wrote:
> Hi Stephen,
>
> On Wed, Jan 15, 2014 at 08:54:27PM +0000, Stephen Boyd wrote:
>> On 01/15, Stephen Boyd wrote:
>>> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
>>> index 789d846a9184..e76750980b38 100644
>>> --- a/arch/arm/kernel/perf_event.c
>>> +++ b/arch/arm/kernel/perf_event.c
>>> @@ -295,9 +297,15 @@ validate_group(struct perf_event *event)
>>>
>>> static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
>>> {
>>> - struct arm_pmu *armpmu = (struct arm_pmu *) dev;
>>> - struct platform_device *plat_device = armpmu->plat_device;
>>> - struct arm_pmu_platdata *plat = dev_get_platdata(&plat_device->dev);
>>> + struct arm_pmu *armpmu;
>>> + struct platform_device *plat_device;
>>> + struct arm_pmu_platdata *plat;
>>> +
>>> + if (irq_is_percpu(irq))
>>> + dev = *(struct arm_pmu_cpu **)dev;
>> Oh. I just realized that struct arm_pmu_cpu doesn't even exist. This
>> still compiles though because we're dealing with a void pointer.
>>
>> Perhaps its better to just do
>>
>> dev = *(void **)dev;
>>
>> here. Can you fix that up when applying? Otherwise I'll do it on
>> the next send if there are more comments.
> Shouldn't that actually be some per_cpu accessor like this_cpu_ptr?
>
Nope. The genirq layer unwraps the per_cpu pointer and passes it to the
handler.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
From: Kevin Hilman @ 2014-01-17 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389979580-14812-1-git-send-email-joshc@codeaurora.org>
Josh Cartwright <joshc@codeaurora.org> writes:
> Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
> msm_otg_{suspend,resume} routines, however these routines are only being
> built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
> depends on msm_hsusb_config_vddcx(), which is only built when
> CONFIG_PM_SLEEP.
>
> Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
> preprocessor conditional, and moving msm_hsusb_config_vddcx().
>
> While we're here, eliminate the CONFIG_PM conditional for setting
> up the dev_pm_ops.
>
> This address the following errors Russell King has hit doing randconfig
> builds:
>
> drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
> drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
> drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
> drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
>
> Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
> Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
[...]
> @@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
> #define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
> #define PHY_RESUME_TIMEOUT_USEC (100 * 1000)
>
> -#ifdef CONFIG_PM_SLEEP
> +#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
nit: you should just use CONFIG_PM here since that is what it's for.
c.f. kernel/power/Kconfig:
config PM
def_bool y
depends on PM_SLEEP || PM_RUNTIME
Kevin
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Tony Lindgren @ 2014-01-17 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r486mrh5.fsf@linaro.org>
* Kevin Hilman <khilman@linaro.org> [140117 09:48]:
> Mike Turquette <mturquette@linaro.org> writes:
>
> [...]
>
> > I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
> > Tero's series. This includes the AM3517 bits now. I've pushed this
> > branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
> > final sanity test before I merge this into clk-next?
>
> I merged clk-next-omap into next-20140117 and build/boot tested
> omap2plus_defconfig, multi_v7_defconfig and
> multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for
> omap5uevm.
>
> I'll add OMAP5 to the automated boot testing starting with the next
> linux-next.
OK that's good news. Looks like omap1_defconfig build has now started
failing though:
vers/built-in.o: In function `omap5xxx_dt_clk_init':
:(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all'
drivers/built-in.o: In function `am43xx_dt_clk_init':
:(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all'
drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc'
drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate'
drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate'
drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate'
drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate'
drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate'
drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable'
drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable'
drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc'
drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate'
drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc'
drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate'
drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent'
drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate'
drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable'
drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable'
drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled'
drivers/built-in.o:(.rodata+0xc728): undefined reference to `omap2_clkops_enable_clkdm'
drivers/built-in.o:(.rodata+0xc72c): undefined reference to `omap2_clkops_disable_clkdm'
drivers/built-in.o:(.rodata+0xc754): undefined reference to `omap2_init_clk_clkdm'
drivers/built-in.o:(.rodata+0xc784): undefined reference to `omap2_dflt_clk_disable'
drivers/built-in.o:(.rodata+0xc788): undefined reference to `omap2_dflt_clk_is_enabled'
drivers/built-in.o:(.rodata+0xc7ac): undefined reference to `omap2_init_clk_clkdm'
drivers/built-in.o:(.rodata+0xc7c0): undefined reference to `omap2_dflt_clk_enable'
drivers/built-in.o:(.rodata+0xc7c4): undefined reference to `omap2_dflt_clk_disable'
drivers/built-in.o:(.rodata+0xc7c8): undefined reference to `omap2_dflt_clk_is_enabled'
drivers/built-in.o:(.rodata+0xc7ec): undefined reference to `omap2_init_clk_clkdm'
drivers/built-in.o:(.rodata+0xc838): undefined reference to `__clk_mux_determine_rate'
drivers/built-in.o:(.rodata+0xc904): undefined reference to `omap2_dflt_clk_enable'
drivers/built-in.o:(.rodata+0xc908): undefined reference to `omap2_dflt_clk_disable'
drivers/built-in.o:(.rodata+0xc90c): undefined reference to `omap2_dflt_clk_is_enabled'
drivers/built-in.o:(.rodata+0xc930): undefined reference to `omap2_init_clk_clkdm'
Regards,
Tony
^ permalink raw reply
* [PATCH] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
From: Christopher Covington @ 2014-01-17 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389979580-14812-1-git-send-email-joshc@codeaurora.org>
Hi Josh,
On 01/17/2014 12:26 PM, Josh Cartwright wrote:
[...]
> @@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
> #define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
> #define PHY_RESUME_TIMEOUT_USEC (100 * 1000)
>
> -#ifdef CONFIG_PM_SLEEP
> +#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
Why not #ifdef CONFIG_PM here?
Regards,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Kevin Hilman @ 2014-01-17 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116213954.4167.37071@quantum>
Mike Turquette <mturquette@linaro.org> writes:
[...]
> I took Tony's advice and fast-forwarded clk-next to -rc7 and applied
> Tero's series. This includes the AM3517 bits now. I've pushed this
> branch to clk-next-omap (force update) on my Linaro mirror. Can you do a
> final sanity test before I merge this into clk-next?
I merged clk-next-omap into next-20140117 and build/boot tested
omap2plus_defconfig, multi_v7_defconfig and
multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for
omap5uevm.
I'll add OMAP5 to the automated boot testing starting with the next
linux-next.
Kevin
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Chen-Yu Tsai @ 2014-01-17 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401171747.46332.arnd@arndb.de>
On Sat, Jan 18, 2014 at 12:47 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 17 January 2014, Chen-Yu Tsai wrote:
>> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
>> new file mode 100644
>> index 0000000..8a07ea4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
>> @@ -0,0 +1,26 @@
>> +GPIO controlled RFKILL devices
>> +
>> +Required properties:
>> +- compatible : Must be "rfkill-gpio".
>> +- rfkill-name : Name of RFKILL device
>> +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth
>> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
>> + (phandle must be the second)
>> +- NAME_reset-gpios : GPIO phandle to reset control
>> +
>> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
>> +NAME_reset-gpios, or both, must be defined.
>> +
>
> I don't understand this part. Why do you include the name in the
> gpios property, rather than just hardcoding the property strings
> to "shutdown-gpios" and "reset-gpios"?
This quirk is a result of how gpiod_get_index implements device tree
lookup. You'll also notice that the shutdown GPIO must be the second
phandle, as the driver uses indexed lookup to support ACPI cases.
If con_id is given, it is prepended to "gpios" as the property string.
con_id is also used as the label passed to gpiod_request, which is
then shown in /sys/kernel/debug/gpio.
I can do a seperate lookup for the device tree case, with or without
fallback to platform lookup tables. Then the names can be "reset-gpio"
and "shutdown-gpio". Need to promote gpiod_request to non-static so
we can register usage of the gpio, to match non-dt code path.
Personally I prefer adding a "label" parameter to gpiod_get_index, so
we can use a different name than con_id. con_id isn't used in the ACPI
case, and is optional in platform lookup case. However device tree
lookup is dependent on this. What I see is non-uniform behavior
between the three. In my opinion this is undesirable, but I haven't
come up with a good solution yet.
About the property string, is the plural form required, even though we
only want one?
Thanks!
ChenYu
> The description of hte "rfkill-name" property seems to suggest
> that you can only have one logical RFKILL device per device node,
> so he names would not be ambiguous.
>
> Arnd
^ permalink raw reply
* [PATCH v2] of: add functions to count number of elements in a property
From: Rob Herring @ 2014-01-17 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434798.oSb68sYmYT@phil>
On Fri, Jan 17, 2014 at 9:44 AM, Heiko St?bner <heiko@sntech.de> wrote:
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper static function that also centralises strict sanity
> checking and DTB format details, as well as a set of wrapper functions
> for u8, u16, u32 and u64.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> changes since v1:
> address comments from Rob Herring and Mark Rutland:
> - provide a helper and a set of wrappers for u8-u64
> - get rid of extra len variable, prop->length is enough
> - include node name in error message
>
> drivers/of/base.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 32 +++++++++++++++++
> 2 files changed, 130 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..b6e6d4a 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -862,6 +862,104 @@ struct device_node *of_find_node_by_phandle(phandle handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_count_property_elems_of_size - Count the number of elements in a property
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @elem_size: size of the individual element
> + */
> +static int of_count_property_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size)
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> +
> + if (prop->length % elem_size != 0) {
> + pr_err("size of %s in node %s is not a multiple of %d\n",
> + propname, np->name, elem_size);
> + return -EINVAL;
> + }
> +
> + return prop->length / elem_size;
> +}
Export this one.
> +
> +/**
> + * of_property_count_u8_elems - Count the number of u8 elements in a property
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + *
> + * Search for a property in a device node and count the number of u8 elements
> + * in it. Returns number of elements on sucess, -EINVAL if the property does
> + * not exist or its length does not match a multiple of u8 and -ENODATA if the
> + * property does not have a value.
> + */
> +int of_property_count_u8_elems(const struct device_node *np,
> + const char *propname)
> +{
> + return of_count_property_elems_of_size(np, propname, sizeof(u8));
> +}
> +EXPORT_SYMBOL_GPL(of_property_count_u8_elems);
And make all these static inline.
Then you only need a single empty function for !OF.
Rob
^ permalink raw reply
* [PATCH v4 0/7] mtd: spi-nor: add a new framework for SPI NOR
From: Gupta, Pekon @ 2014-01-17 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RT1m+7BWZyYqU7Pb2+bhki-Wqs6f96=GhMyF1nHyy2wuw@mail.gmail.com>
Hi Shijie,
>From: Jagan Teki [mailto:jagannadh.teki at gmail.com]
[...]
>
>I feel these are good points to discuss all.
>1. With new framework seems like we need two separate controller drivers
> one for non spi-nor and one for spi-nor with single controller hw
>2. With spi-nor implementation though the hw is spi complaint but the sw is
> completely ignoring the Linux SPI core interaction.
>
>I feel above two points are technically wrong - Please correct me if am wrong
>but need all developers will join..thanks!
>
I have been following this patch-set from sometime, And I think point (2)
has been discussed back and forth in multiple times in earlier discussions.
So, Is it possible for you to summarize point (2) with all pros-n-cons ?
- A README will helpful to clear all doubts and will ease your implementation
as well.
- It will also help in reducing turn-around time to get this framework in
acceptable state and still keep it generic enough.
You can submit the README as Documentation/mtd/spi-nor.txt
with regards, pekon
^ permalink raw reply
* [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id
From: Sudeep Holla @ 2014-01-17 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-11-git-send-email-hanjun.guo@linaro.org>
On 17/01/14 12:25, Hanjun Guo wrote:
> When boot the kernel with MADT, the cpu possible and present sets should
> be enumerated for later smp initialization.
>
> The logic cpu id maps to APIC id (GIC id) is also implemented, it is
> needed for acpi processor drivers.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/include/asm/acpi.h | 7 ++--
> drivers/acpi/plat/arm-core.c | 83 +++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index c335c6d..7edd39e 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -76,9 +76,6 @@ static inline void acpi_disable_pci(void)
> /* FIXME: this function should be moved to topology.h when it's ready */
> void arch_fix_phys_package_id(int num, u32 slot);
>
> -/* temperally define -1 to make acpi core compilerable */
> -#define cpu_physical_id(cpu) -1
> -
> /* Low-level suspend routine. */
> extern int (*acpi_suspend_lowlevel)(void);
> #define acpi_wakeup_address (0)
> @@ -86,6 +83,10 @@ extern int (*acpi_suspend_lowlevel)(void);
> #define MAX_GIC_CPU_INTERFACE 256
> #define MAX_GIC_DISTRIBUTOR 1 /* should be the same as MAX_GIC_NR */
>
> +/* map logic cpu id to physical GIC id */
> +extern int arm_cpu_to_apicid[NR_CPUS];
> +#define cpu_physical_id(cpu) arm_cpu_to_apicid[cpu]
> +
You refer arm_cpu_to_apicid as a mapping from logical cpu id to GIC id,
then why is it assigned to cpu_physical_id. cpu_physical_id must be same as
cpu_logical_map which is from logical cpu id to MPIDRs.
[...]
> @@ -321,6 +401,9 @@ int __init early_acpi_boot_init(void)
> if (acpi_disabled)
> return -ENODEV;
>
> + /* Get the boot CPU's GIC cpu interface id before MADT parsing */
> + boot_cpu_apic_id = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
Code contradicts your comment. You need GIC cpu interface ID(referred as GIC ID
in the MADT), but you are assigning the MPIDR(physical CPU ID on ARM) to
boot_cpu_apic_id. I think you are assuming GIC ID and MPIDR to be same which is
wrong.
With ACPI5.0, IIUC the only possible way to manage mapping from GIC CPU
interface to MPIDR is to assume(in a way enforce on ARM) ACPI Processor UID in
MADT and CPU Device definition match MPIDR.
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3] of: add functions to count number of elements in a property
From: Heiko Stübner @ 2014-01-17 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117165333.GH19578@e106331-lin.cambridge.arm.com>
The need to know the number of array elements in a property is
a common pattern. To prevent duplication of open-coded implementations
add a helper static function that also centralises strict sanity
checking and DTB format details, as well as a set of wrapper functions
for u8, u16, u32 and u64.
Suggested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
---
changes since v2:
address more comments from Mark Rutland
- switch to of_property_count_elems_of_size
- use full_name instead of name in error message
changes since v1:
address comments from Rob Herring and Mark Rutland:
- provide a helper and a set of wrappers for u8-u64
- get rid of extra len variable, prop->length is enough
- include node name in error message
Posted for completenes sake. If nobody complains,
I'll simply make it part of my Rockchip-SMP series.
drivers/of/base.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 32 +++++++++++++++++
2 files changed, 131 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index f807d0e..1cd6dc9 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -862,6 +862,105 @@ struct device_node *of_find_node_by_phandle(phandle handle)
EXPORT_SYMBOL(of_find_node_by_phandle);
/**
+ * of_property_count_elems_of_size - Count the number of elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ * @elem_size: size of the individual element
+ */
+static int of_property_count_elems_of_size(const struct device_node *np,
+ const char *propname, int elem_size)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop->value)
+ return -ENODATA;
+
+pr_err("size of %s in node %s is not a multiple of %d\n", propname, np->full_name, elem_size);
+ if (prop->length % elem_size != 0) {
+ pr_err("size of %s in node %s is not a multiple of %d\n",
+ propname, np->full_name, elem_size);
+ return -EINVAL;
+ }
+
+ return prop->length / elem_size;
+}
+
+/**
+ * of_property_count_u8_elems - Count the number of u8 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u8 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u8 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_property_count_elems_of_size(np, propname, sizeof(u8));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u8_elems);
+
+/**
+ * of_property_count_u16_elems - Count the number of u16 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u16 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u16 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_property_count_elems_of_size(np, propname, sizeof(u16));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u16_elems);
+
+/**
+ * of_property_count_u32_elems - Count the number of u32 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u32 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u32 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_property_count_elems_of_size(np, propname, sizeof(u32));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u32_elems);
+
+/**
+ * of_property_count_u64_elems - Count the number of u64 elements in a property
+ *
+ * @np: device node from which the property value is to be read.
+ * @propname: name of the property to be searched.
+ *
+ * Search for a property in a device node and count the number of u64 elements
+ * in it. Returns number of elements on sucess, -EINVAL if the property does
+ * not exist or its length does not match a multiple of u64 and -ENODATA if the
+ * property does not have a value.
+ */
+int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname)
+{
+ return of_property_count_elems_of_size(np, propname, sizeof(u64));
+}
+EXPORT_SYMBOL_GPL(of_property_count_u64_elems);
+
+/**
* of_find_property_value_of_size
*
* @np: device node from which the property value is to be read.
diff --git a/include/linux/of.h b/include/linux/of.h
index 276c546..06fe898 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -250,6 +250,14 @@ extern struct device_node *of_find_node_with_property(
extern struct property *of_find_property(const struct device_node *np,
const char *name,
int *lenp);
+extern int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname);
+extern int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname);
extern int of_property_read_u32_index(const struct device_node *np,
const char *propname,
u32 index, u32 *out_value);
@@ -426,6 +434,30 @@ static inline struct device_node *of_find_compatible_node(
return NULL;
}
+static inline int of_property_count_u8_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u16_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u32_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
+static inline int of_property_count_u64_elems(const struct device_node *np,
+ const char *propname)
+{
+ return -ENOSYS;
+}
+
static inline int of_property_read_u32_index(const struct device_node *np,
const char *propname, u32 index, u32 *out_value)
{
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 13/28] drm/i2c: tda998x: use irq for connection status and EDID read
From: Jean-Francois Moine @ 2014-01-17 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D2EC5D.2010800@gmail.com>
On Sun, 12 Jan 2014 20:26:21 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> On 01/12/2014 07:51 PM, Jean-Francois Moine wrote:
> > On Sat, 11 Jan 2014 19:35:21 +0100
> > Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote:
> >
> >> At least for the DT part, I'd suggest to not ask for interrupt directly
> >> but use a proper gpios property. The can of course be converted to
> >> priv->int_irq in some tda998x_dt_probe.
> >
> > May you give me more information?
>
> Sure, see [1].
>
> [1] http://lists.freedesktop.org/archives/dri-devel/2013-May/038822.html
Thanks for the link, but I still don't see the advantage of the gpio
(which value?) over the irq number.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP
From: Josh Cartwright @ 2014-01-17 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117132232.GC15937@n2100.arm.linux.org.uk>
Both the PM_RUNTIME and PM_SLEEP callbacks call into the common
msm_otg_{suspend,resume} routines, however these routines are only being
built when CONFIG_PM_SLEEP. In addition, msm_otg_{suspend,resume} also
depends on msm_hsusb_config_vddcx(), which is only built when
CONFIG_PM_SLEEP.
Fix the CONFIG_PM_RUNTIME, !CONFIG_PM_SLEEP case by changing the
preprocessor conditional, and moving msm_hsusb_config_vddcx().
While we're here, eliminate the CONFIG_PM conditional for setting
up the dev_pm_ops.
This address the following errors Russell King has hit doing randconfig
builds:
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function 'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declaration of function 'msm_otg_resume'
Cc: Ivan T. Ivanov <iivanov@mm-sol.com>
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
---
drivers/usb/phy/phy-msm-usb.c | 57 ++++++++++++++++++++-----------------------
1 file changed, 26 insertions(+), 31 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 8546c8d..7c7384f 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -159,32 +159,6 @@ put_3p3:
return rc;
}
-#ifdef CONFIG_PM_SLEEP
-#define USB_PHY_SUSP_DIG_VOL 500000
-static int msm_hsusb_config_vddcx(int high)
-{
- int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
- int min_vol;
- int ret;
-
- if (high)
- min_vol = USB_PHY_VDD_DIG_VOL_MIN;
- else
- min_vol = USB_PHY_SUSP_DIG_VOL;
-
- ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
- if (ret) {
- pr_err("%s: unable to set the voltage for regulator "
- "HSUSB_VDDCX\n", __func__);
- return ret;
- }
-
- pr_debug("%s: min_vol:%d max_vol:%d\n", __func__, min_vol, max_vol);
-
- return ret;
-}
-#endif
-
static int msm_hsusb_ldo_set_mode(int on)
{
int ret = 0;
@@ -440,7 +414,32 @@ static int msm_otg_reset(struct usb_phy *phy)
#define PHY_SUSPEND_TIMEOUT_USEC (500 * 1000)
#define PHY_RESUME_TIMEOUT_USEC (100 * 1000)
-#ifdef CONFIG_PM_SLEEP
+#if defined(CONFIG_PM_SLEEP) || defined(CONFIG_PM_RUNTIME)
+
+#define USB_PHY_SUSP_DIG_VOL 500000
+static int msm_hsusb_config_vddcx(int high)
+{
+ int max_vol = USB_PHY_VDD_DIG_VOL_MAX;
+ int min_vol;
+ int ret;
+
+ if (high)
+ min_vol = USB_PHY_VDD_DIG_VOL_MIN;
+ else
+ min_vol = USB_PHY_SUSP_DIG_VOL;
+
+ ret = regulator_set_voltage(hsusb_vddcx, min_vol, max_vol);
+ if (ret) {
+ pr_err("%s: unable to set the voltage for regulator "
+ "HSUSB_VDDCX\n", __func__);
+ return ret;
+ }
+
+ pr_debug("%s: min_vol:%d max_vol:%d\n", __func__, min_vol, max_vol);
+
+ return ret;
+}
+
static int msm_otg_suspend(struct msm_otg *motg)
{
struct usb_phy *phy = &motg->phy;
@@ -1733,22 +1732,18 @@ static int msm_otg_pm_resume(struct device *dev)
}
#endif
-#ifdef CONFIG_PM
static const struct dev_pm_ops msm_otg_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(msm_otg_pm_suspend, msm_otg_pm_resume)
SET_RUNTIME_PM_OPS(msm_otg_runtime_suspend, msm_otg_runtime_resume,
msm_otg_runtime_idle)
};
-#endif
static struct platform_driver msm_otg_driver = {
.remove = msm_otg_remove,
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
-#ifdef CONFIG_PM
.pm = &msm_otg_dev_pm_ops,
-#endif
},
};
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v7 0/2] ohci and ehci-platform clks, phy and dt support
From: Alan Stern @ 2014-01-17 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2909743.WgOIUglCS0@lenovo>
On Thu, 16 Jan 2014, Florian Fainelli wrote:
> Le mercredi 15 janvier 2014, 15:26:21 Alan Stern a ?crit :
> > On Wed, 15 Jan 2014, Hans de Goede wrote:
> > > Hi All,
> > >
> > > This version of my ohci and ehci-platform clks, phy and dt support
> > > patch-set, really fixes the 2 small bugs Alan found.
> >
> > All okay -- this time I can't find anything to complain about. :-)
>
> There is one minor issue; which is that the ehci binding claims the driver
> supports the following optional boolean properties:
>
> - big-endian-regs : boolean, set this for hcds with big-endian registers
> - big-endian-desc : boolean, set this for hcds with big-endian descriptors
> - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
>
> while it does not (yet) so this is misleading. Can we at get that fixed before
> merging? Copy pasting the PPC ehci driver should do the job.
I agree it needs to be fixed. This can be done in a follow-up patch,
though. It doesn't have to be in this one because nobody is using
ehci-platform with DT yet.
A simple copy from the PPC driver isn't quite enough, because the
platform data settings would override the DT values.
ehci_platform_reset has to be changed so that it sets
ehci->big_endian_desc and _mmio if the pdata flags are set, but
otherwise leaves them alone.
Hans, would you like to write another patch to take care of this?
Alan Stern
^ permalink raw reply
* [PATCH v4 0/7] mtd: spi-nor: add a new framework for SPI NOR
From: Jagan Teki @ 2014-01-17 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD6G_RSF_TPk8g9CNmSc+xs+9psLmJoakZw3Eqf-a8KD5P4AVg@mail.gmail.com>
On Fri, Jan 17, 2014 at 2:09 PM, Jagan Teki <jagannadh.teki@gmail.com> wrote:
> On Fri, Jan 17, 2014 at 12:24 PM, Huang Shijie <b32955@freescale.com> wrote:
>> On Fri, Jan 17, 2014 at 12:36:08PM +0530, Jagan Teki wrote:
>>> >> My basic question is like I have a qspi spi controller in my SOC and I
>>> >> designed two boards B1 and B2
>>> >
>>> > okay.
>>> >
>>> >> B1 with quad spi controller connected with non-flash as a slave and B2
>>> >> with quad spi controller connected
>>> >> with quad flash as a slave.
>>> > You can use the framework for B2. But for B1, you should not use the framework,
>>> > since this framework is just for the SPI-NOR. If you do not connected with
>>> > a NOR, i think it's better to code another driver for your controller.
>>>
>>> Means we have two separate controller drivers for same controller one
>>> with spi-nor and
>>> another with spi is it?
>> Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you only
>> need to add a NOR device node in the device tree. In the probe, it will call
>> the m25p80.c to probe the NOR device.
>>
>> But if we connect other device to it. you should set another device node for it.
>>
>> I am not sure if your controller driver can works as the spi-imx.c
>
> My question here was - this new framework suggest to write a two
> different controller
> drivers one is for non spi-nor and spi-nor models? do you agree that?
>
> And also one important note from your design was spi-nor mode is
> completely bypassing
> Linux spi core is that the good idea?
I feel these are good points to discuss all.
1. With new framework seems like we need two separate controller drivers
one for non spi-nor and one for spi-nor with single controller hw
2. With spi-nor implementation though the hw is spi complaint but the sw is
completely ignoring the Linux SPI core interaction.
I feel above two points are technically wrong - Please correct me if am wrong
but need all developers will join..thanks!
--
Jagan.
^ permalink raw reply
* [PATCH v3 7/7] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Arnd Bergmann @ 2014-01-17 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140116134732.GB17314@sirena.org.uk>
On Thursday 16 January 2014, Mark Brown wrote:
> On Thu, Jan 16, 2014 at 12:19:00PM +0100, Arnd Bergmann wrote:
>
> > 1. Other platforms also require the syscon driver to be active before
> > the regular device driver probing starts. Michal Simek has the same
> > issue in the zynq clock driver that you have for SMP initialization.
> > We have talked about this with Mark Brown already, and I think we will
> > find a solution for this in the end, but it's not as straightforward
> > as I first hoped. We can probably use help in this area.
>
> I thought the solution with deferring registration of the resource for
> dev_get_regmap() until a proper device materialised seemed simple and
> enough, did you folks run into any problems with that? I had assumed a
> patch was likely to materialise so wasn't worrying about it myself.
I'm still hoping that Michal will do that patch.
Arnd
^ permalink raw reply
* Re: [PATCH V3 3/3] power: reset: use syscon driver to parse reboot register from scu
From: Alexander Shiyan @ 2014-01-17 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401171752.47393.arnd@arndb.de>
???????, 17 ?????? 2014, 17:52 +01:00 ?? Arnd Bergmann <arnd@arndb.de>:
> On Wednesday 15 January 2014, Feng Kan wrote:
> > +static int __init xgene_reboot_init(void)
> > {
> > arm_pm_restart = xgene_restart;
> > return 0;
> > }
> > device_initcall(xgene_reboot_init);
>
> This won't work on a generic kernel, since you unconditionally set the
> pm_restart function to your own, which is broken for everything else.
>
> Please keep the platform_driver to attach to the reboot device
> as you had before. It might be good to turn this into a generic
> "syscon-reset" driver that gets both the register number and
> the contents to write from the device node.
I am not sure but think the new driver for SYSCON GPIOs can be
reused for such purpose:
http://www.spinics.net/lists/devicetree/msg18221.html
---
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Nicolas Pitre @ 2014-01-17 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKX2RT2E6uk3d35m+TWW7iuPFFiuZzOwd0xA9zMgqAZRw@mail.gmail.com>
On Fri, 17 Jan 2014, Rob Herring wrote:
> On Thu, Jan 16, 2014 at 9:08 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Thu, 16 Jan 2014, Olof Johansson wrote:
> >
> >> "for SDIO slots" is somewhat misleading; nearly all controllers only
> >> do one slot/device per controller. The designware controller can do
> >> multiple slots, and that adds a bit of driver and binding complexity
> >> for something that seemingly not a single vendor has actually
> >> implemented.
> >
> > The Marvell 8688, just to name one, does both WIFI and BlueTooth over
> > the same SDIO controller using separate functions/slots.
>
> But that is logical functions within a chip, not multiple discrete
> chips (i.e. slots) with their own reset, regulators, etc.
OK. If that's the definition of a slot in this context then I agree.
Nicolas
^ permalink raw reply
* [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file
From: Sudeep Holla @ 2014-01-17 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389961514-13562-5-git-send-email-hanjun.guo@linaro.org>
On 17/01/14 12:24, Hanjun Guo wrote:
> Introduce arm_core.c and its related head file, after this patch,
> we can get ACPI tables from firmware on ARM64 now.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/include/asm/acpi.h | 57 +++++++++++
> arch/arm64/kernel/setup.c | 6 ++
> drivers/acpi/Makefile | 2 +
> drivers/acpi/plat/Makefile | 1 +
> drivers/acpi/plat/arm-core.c | 209 +++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 275 insertions(+)
> create mode 100644 drivers/acpi/plat/Makefile
> create mode 100644 drivers/acpi/plat/arm-core.c
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index cf19dc6..908d71b 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -19,6 +19,43 @@
> #ifndef _ASM_ARM64_ACPI_H
> #define _ASM_ARM64_ACPI_H
>
> +#include <asm/cacheflush.h>
> +
> +#include <linux/init.h>
> +
> +#define COMPILER_DEPENDENT_INT64 s64
> +#define COMPILER_DEPENDENT_UINT64 u64
> +
> +/*
> + * Calling conventions:
> + *
> + * ACPI_SYSTEM_XFACE - Interfaces to host OS (handlers, threads)
> + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
> + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
> + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
> + */
> +#define ACPI_SYSTEM_XFACE
> +#define ACPI_EXTERNAL_XFACE
> +#define ACPI_INTERNAL_XFACE
> +#define ACPI_INTERNAL_VAR_XFACE
> +
> +/* Asm macros */
> +#define ACPI_FLUSH_CPU_CACHE() flush_cache_all()
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;
> +
> +static inline void disable_acpi(void)
> +{
> + acpi_disabled = 1;
> + acpi_pci_disabled = 1;
> + acpi_noirq = 1;
> +}
> +
> static inline bool arch_has_acpi_pdc(void)
> {
> return false; /* always false for now */
> @@ -29,4 +66,24 @@ static inline void arch_acpi_set_pdc_bits(u32 *buf)
> return;
> }
>
> +static inline void acpi_noirq_set(void) { acpi_noirq = 1; }
> +static inline void acpi_disable_pci(void)
> +{
> + acpi_pci_disabled = 1;
> + acpi_noirq_set();
> +}
> +
> +/* FIXME: this function should be moved to topology.h when it's ready */
> +void arch_fix_phys_package_id(int num, u32 slot);
> +
> +/* temperally define -1 to make acpi core compilerable */
> +#define cpu_physical_id(cpu) -1
> +
I assume `cpu` here is logical cpu id in which case you can define it to be same
as cpu_logical_map ?
Regards,
Sudeep
^ permalink raw reply
* [PATCH v2] of: add functions to count number of elements in a property
From: Mark Rutland @ 2014-01-17 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1434798.oSb68sYmYT@phil>
On Fri, Jan 17, 2014 at 03:44:14PM +0000, Heiko St?bner wrote:
> The need to know the number of array elements in a property is
> a common pattern. To prevent duplication of open-coded implementations
> add a helper static function that also centralises strict sanity
> checking and DTB format details, as well as a set of wrapper functions
> for u8, u16, u32 and u64.
>
> Suggested-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
> changes since v1:
> address comments from Rob Herring and Mark Rutland:
> - provide a helper and a set of wrappers for u8-u64
> - get rid of extra len variable, prop->length is enough
> - include node name in error message
>
> drivers/of/base.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of.h | 32 +++++++++++++++++
> 2 files changed, 130 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index f807d0e..b6e6d4a 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -862,6 +862,104 @@ struct device_node *of_find_node_by_phandle(phandle handle)
> EXPORT_SYMBOL(of_find_node_by_phandle);
>
> /**
> + * of_count_property_elems_of_size - Count the number of elements in a property
> + *
> + * @np: device node from which the property value is to be read.
> + * @propname: name of the property to be searched.
> + * @elem_size: size of the individual element
> + */
> +static int of_count_property_elems_of_size(const struct device_node *np,
> + const char *propname, int elem_size)
As a minor nit, it would be nicer to have 'count' and 'property' switch
places in the name (i.e. call this of_property_count_elems_of_size).
That way it's concistent with the naming of the wrappers.
> +{
> + struct property *prop = of_find_property(np, propname, NULL);
> +
> + if (!prop)
> + return -EINVAL;
> + if (!prop->value)
> + return -ENODATA;
> +
> + if (prop->length % elem_size != 0) {
> + pr_err("size of %s in node %s is not a multiple of %d\n",
> + propname, np->name, elem_size);
It would be nice to use np->full_name so you get the absolute path of
the node -- it makes finding them easier later.
Otherwise, the patch looks good to me, thanks for implementing it!
With those changes:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cheers,
Mark.
^ permalink raw reply
* [PATCH V3 3/3] power: reset: use syscon driver to parse reboot register from scu
From: Arnd Bergmann @ 2014-01-17 16:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389748055-23534-4-git-send-email-fkan@apm.com>
On Wednesday 15 January 2014, Feng Kan wrote:
> +static int __init xgene_reboot_init(void)
> {
> arm_pm_restart = xgene_restart;
> return 0;
> }
> device_initcall(xgene_reboot_init);
This won't work on a generic kernel, since you unconditionally set the
pm_restart function to your own, which is broken for everything else.
Please keep the platform_driver to attach to the reboot device
as you had before. It might be good to turn this into a generic
"syscon-reset" driver that gets both the register number and
the contents to write from the device node.
Arnd
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Arnd Bergmann @ 2014-01-17 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389941251-32692-5-git-send-email-wens@csie.org>
On Friday 17 January 2014, Chen-Yu Tsai wrote:
> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> new file mode 100644
> index 0000000..8a07ea4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
> @@ -0,0 +1,26 @@
> +GPIO controlled RFKILL devices
> +
> +Required properties:
> +- compatible : Must be "rfkill-gpio".
> +- rfkill-name : Name of RFKILL device
> +- rfkill-type : Type of RFKILL device: 1 for WiFi, 2 for BlueTooth
> +- NAME_shutdown-gpios : GPIO phandle to shutdown control
> + (phandle must be the second)
> +- NAME_reset-gpios : GPIO phandle to reset control
> +
> +NAME must match the rfkill-name property. NAME_shutdown-gpios or
> +NAME_reset-gpios, or both, must be defined.
> +
I don't understand this part. Why do you include the name in the
gpios property, rather than just hardcoding the property strings
to "shutdown-gpios" and "reset-gpios"?
The description of hte "rfkill-name" property seems to suggest
that you can only have one logical RFKILL device per device node,
so he names would not be ambiguous.
Arnd
^ permalink raw reply
* [PATCH v2 4/6] arm64: audit: Add 32-bit (compat) syscall support
From: Will Deacon @ 2014-01-17 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389946399-4525-5-git-send-email-takahiro.akashi@linaro.org>
Hi Akashi,
On Fri, Jan 17, 2014 at 08:13:17AM +0000, AKASHI Takahiro wrote:
> Generic audit code also support compat system calls now.
> This patch adds a small piece of architecture dependent code.
[...]
> static inline int syscall_get_nr(struct task_struct *task,
> @@ -109,6 +110,15 @@ static inline void syscall_set_arguments(struct task_struct *task,
> static inline int syscall_get_arch(struct task_struct *task,
> struct pt_regs *regs)
> {
> +#ifdef CONFIG_COMPAT
> + if (is_compat_thread(task_thread_info(task)))
You can call is_compat_thread even when !CONFIG_COMPAT, so you don't need
that #ifdef.
> +#ifdef __AARCH64EB__
> + return AUDIT_ARCH_ARMEB; /* only BE on BE */
Well, actually, we only support userspace to be the same endianness as the
kernel, so you that comment is slightly misleading. You could probably avoid
these repeated ifdefs by defining things like ARM64_AUDIT_ARCH and
ARM64_COMPAT_AUDIT_ARCH once depending on endianness.
Will
^ permalink raw reply
* [PATCH] arm64: fix strnlen_user when count <= strlen
From: Kyle McMartin @ 2014-01-17 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117105107.GC16003@mudshark.cambridge.arm.com>
On Fri, Jan 17, 2014 at 10:51:07AM +0000, Will Deacon wrote:
> Actually, I have removed strnlen_user for 3.14. Could you try your test case
> with our for-next branch please?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
>
This will work fine, I believe (I can't easily test on HW since we're
dependent on $vendor drivers that aren't upstream yet) but in my testing
yesterday I parroted the x86 word-at-a-time.h and lib/strnlen_user.c and
that seemed to work.
> As for the issue you spotted, we probably need a fix for that to go into
> stable kernels. Does the following (smaller patch) work for you?
>
This gets the count == 0 case wrong still, I believe.
=== count = 0 ===
strnlen_user = 0
__strnlen_user = 1
(Where strnlen_user is the lib/strnlen_user.c implementation.)
Testing if (n <= 0) return 0; before __strnlen_user fixes it though.
Given this is called in, I think, only two places in the kernel, maybe
we should just backport the switch to generic for stable? I can't
imagine it conflicting with anything.
regards, Kyle
> Will
>
> --->8
>
> diff --git a/arch/arm64/lib/strnlen_user.S b/arch/arm64/lib/strnlen_user.S
> index 7f7b176a5646..73f3335a2a45 100644
> --- a/arch/arm64/lib/strnlen_user.S
> +++ b/arch/arm64/lib/strnlen_user.S
> @@ -37,6 +37,7 @@ ENTRY(__strnlen_user)
> USER(9f, ldrb w3, [x0], #1 )
> cbnz w3, 1b
> 2: sub x0, x0, x2
> + cinc x0, x0, mi
> ret
> ENDPROC(__strnlen_user)
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox