* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-01-17 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zjmvau23.fsf@nemi.mork.no>
On Fri, Jan 17, 2014 at 09:31:16AM +0100, Bj?rn Mork wrote:
> arno at natisbad.org (Arnaud Ebalard) writes:
> > Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> >
> >>> ... AFAICT, this is exactly what commit 35773dac5f86 does and reverting
> >>> it does not help. If I am mistaken, can you point which part you want me
> >>> to remove in the code to test?
> >>>
> >>> I am slowly starting to see a bisect session coming ;-)
> >>
> >> Try reverting commit 60e102ac73cd40069d077014c93c86dc7205cb68.
> >
> > AFAICT, this commit does not exist in master (Linus tree), i.e. it is
> > not in 3.13.0-rc8.
>
> That commit is a stable backport of 9df89d85b407690afa46ddfbccc80bec6869971d
> which is in v3.13-rc8:
>
> bjorn at nemi:/usr/local/src/git/linux$ git tag --contains 9df89d85b407690afa46ddfbccc80bec6869971d
> usb-3.13-rc1
> usb-3.13-rc3
> usb-3.13-rc5
> v3.13-rc1
> v3.13-rc2
> v3.13-rc3
> v3.13-rc4
> v3.13-rc5
> v3.13-rc6
> v3.13-rc7
> v3.13-rc8
Sorry for using the stable commit ID. Arnaud, please try reverting
commit 9df89d85b407690afa46ddfbccc80bec6869971d "usbcore: set
lpm_capable field for LPM capable root hubs" and see if it fixes your
issues.
Sarah Sharp
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Russell King - ARM Linux @ 2014-01-17 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D995C4.80104@wwwdotorg.org>
On Fri, Jan 17, 2014 at 01:42:44PM -0700, Stephen Warren wrote:
> On 01/17/2014 01:24 PM, Russell King - ARM Linux wrote:
> > On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
> >> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
> >>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> >>> hides stuff. It's really wonderful, because you don't have to care
> >>> about how the GPIOs are actually accessed in drivers anymore.
> >> ...
> >>> 1. What should gpio_get_value() return for an output?
> >>
> >> Some HW can't ever read back the value of an output pin, so isn't
> >> calling gpio_get_value() undefined for output pins?
> >
> > As has been pointed out, that's not how gpio_get_valie() is documented.
> > It's documented to return the value of the pin where possible. In my
> > case, it _is_ possible to read back the value of the pin - it just
> > needs the appropriate chip configuration to make it happen.
> >
> > Now to the crunch point of my email: where subsystems differ completely
> > _unnecessarily_ from what is expected from them - such as returning the
> > current state of the output where it's possible to do so - then this
> > kind of difference *reduces* the portability of that subsystem, and
> > makes being able to move from one SoC to another _unnecessarily_ more
> > difficult.
>
> If the gpio_get_value() was guaranteed never to be valid for an output
> pin, that would actually be *more* portable, not less; it would work the
> same way everywhere.
>
> I believe you want gpio_get_value() to return either the driven or
> actual pin value where it can on the current HW, but just e.g. hard-code
> 0 on other HW. That would introduce a core feature that works some
> places but not others, and hence make drivers that relied on the feature
> less portable between HW with different actual features.
I can buy that argument, but there's an issue which stands squarely in
its way, and that is open-drain GPIOs.
These are modelled just as any other GPIO, mainly so that both
gpio_set_value(gpio, 1) and gpio_direction_input(gpio) both result in
the signal being high. The only combination which results in the
signal being driven low is outputting zero - and the state of the signal
can aways be read back.
The problem here is that such gpios are implemented in things like the
I2C driver such that they're _always_ outputs, and gpio_set_value() is
used to pull the signal down. gpio_get_value() is used to read its
current state.
So, if we say that gpio_get_value() is undefined, we force such
subsystems to always jump through the non-open-drain paths (using
gpio_direction_input() to set the line high and
gpio_direction_output(gpio, 0) to drive it low.)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Russell King - ARM Linux @ 2014-01-17 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117202015.GE25911@pengutronix.de>
On Fri, Jan 17, 2014 at 09:20:15PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
> > On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
> > > So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> > > hides stuff. It's really wonderful, because you don't have to care
> > > about how the GPIOs are actually accessed in drivers anymore.
> > ...
> > > 1. What should gpio_get_value() return for an output?
> >
> > Some HW can't ever read back the value of an output pin, so isn't
> > calling gpio_get_value() undefined for output pins?
> I remember something like: "If possible it should return what is seen on
> the pad, if not, return 0." being the requirement.
Yes, these have already been quoted. :)
> Documentation/gpio/gpio-legacy.txt still says that:
> When reading the value of an output pin, the value returned should be
> what's seen on the pin ... that won't always match the specified output
> value, because of issues including open-drain signaling and output
> latencies.
>
> [...] However, note that not all platforms can read the value of output
> pins; those that can't should always return zero.
>
> Something similar can be found in Documentation/gpio/consumer about
> gpiod_get_value.
Right - and I've no problem with this wording. If it's _impossible_ to
read back the output because the hardware has no support for doing so,
then that's absolutely fine - we can't ask the impossible from the
hardware.
My issue here is that it _is_ possible to read back the state of an
output pin on i.MX6 hardware provided stuff is configured correctly.
> Other than that I see five possibilities:
>
> a) keep everything as is. Seems to imply surprises which is bad. Maybe
> at least improve the docs to have the information that the return
> value of gpio_get_value might not be usefull in the same paragraph
> as what should be reported.
This I'm not in favour of as it makes the board porter's job
unnecessarily harder.
> b) check if for the requested gpio pad the SION bit is set and read the
> pad value if it is, return 0 otherwise. (But note, after thinking
> again I don't believe this to be possible, because there is usually >1
> pad that can output a given gpio. Moreover AFAIK the information to
> which pads a given gpio can be routed is missing in the kernel. That
> could be fixed, that would result in a big table though. (And the
> first problem is still unfixed.))
There's no input muxing on the GPIOs as you have for the non-GPIO
functions in iMX6, so I'd be surprised if you could assign a particular
GPIO to more than one pin. As I understand it as well, the function of
the SION bit is to force the input path to be enabled, and direct the
state of that pin to the GPIO corresponding with that pin.
Note that the hardware returns zero from the pad value if the input path
is not enabled, so this already happens. Hence why, when I was checking
the state of the GPIOs enabling the regulators, they were showing that
the GPIOs were low, hence regulators disabled, and hence why I've been
looking at the regulator and gpio code all afternoon.
> c) When gpio_get_value is requested for a gpio, set SION temporarily.
> This has the same implementation problems as b) tough.
> d) Read out the pad value unconditionally and return that.
> I didn't check if it always returns 0 if SION is unset though. That
> should be asserted first (or otherwise check if there are
> possibilities to find out if the pad value is valid).
This is what currently happens.
> e) add a flag to all gpio-chips signalling which case gpio_get_value
> implements (i.e: return
> - the actual value on the pad; or
> - zero.
> ). This is not orthogonal to b) - d)
>
> > > 2. What should be reported in /sys/kernel/debug/gpio for an output?
> It should report the same thing as gpio_get_value in 1.
There's another solution here. /sys/kernel/debug/gpio is there to allow
us to see the state of the GPIOs, right? Well, if the asked-for output
value can be different from the read-back output value, how about fixing
this so that the _debug_ can report back what the desired output state
as well as the current input state.
This would mean that this file becomes something like:
gpio-86 (usb_otg_vbus ) dir:out out:hi in:lo
which makes it clear that either the pad is being asked to output a high
level, but for some reason reading the input side is returning low state.
It also lets you see what was asked of the output, and what was (in
theory) written to the output. We already have gpio-generic.c tracking
the output state so it doesn't have to read-modify-write the output
register.
It may _also_ be a good idea to do (e) - have a per-gpiochip flag which
indicates the behaviour here, and omit the "out:" or "in:" as appropriate.
Finally, consider that some drivers should be provided this information.
For example, the bitbanging I2C driver needs this for:
scllo(adap);
sda = getsda(adap);
scl = (adap->getscl == NULL) ? 0 : getscl(adap);
if (scl) {
printk(KERN_WARNING "%s: SCL stuck high!\n", name);
goto bailout;
}
if (!sda) {
printk(KERN_WARNING "%s: SDA unexpected low "
"while pulling SCL low!\n", name);
goto bailout;
}
sclhi(adap);
sda = getsda(adap);
scl = (adap->getscl == NULL) ? 1 : getscl(adap);
if (!scl) {
printk(KERN_WARNING "%s: SCL stuck low!\n", name);
goto bailout;
}
if (!sda) {
printk(KERN_WARNING "%s: SDA unexpected low "
"while pulling SCL high!\n", name);
goto bailout;
}
Now, if getscl() always returns zero when scllo() is called (because the
pin is set as an output) the test is pretty useless - it turns into a
verification that yes, the hardware does return zero from the pad register
when the pin is set as an output.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Stephen Warren @ 2014-01-17 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117202405.GF15937@n2100.arm.linux.org.uk>
On 01/17/2014 01:24 PM, Russell King - ARM Linux wrote:
> On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
>> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
>>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
>>> hides stuff. It's really wonderful, because you don't have to care
>>> about how the GPIOs are actually accessed in drivers anymore.
>> ...
>>> 1. What should gpio_get_value() return for an output?
>>
>> Some HW can't ever read back the value of an output pin, so isn't
>> calling gpio_get_value() undefined for output pins?
>
> As has been pointed out, that's not how gpio_get_valie() is documented.
> It's documented to return the value of the pin where possible. In my
> case, it _is_ possible to read back the value of the pin - it just
> needs the appropriate chip configuration to make it happen.
>
> Now to the crunch point of my email: where subsystems differ completely
> _unnecessarily_ from what is expected from them - such as returning the
> current state of the output where it's possible to do so - then this
> kind of difference *reduces* the portability of that subsystem, and
> makes being able to move from one SoC to another _unnecessarily_ more
> difficult.
If the gpio_get_value() was guaranteed never to be valid for an output
pin, that would actually be *more* portable, not less; it would work the
same way everywhere.
I believe you want gpio_get_value() to return either the driven or
actual pin value where it can on the current HW, but just e.g. hard-code
0 on other HW. That would introduce a core feature that works some
places but not others, and hence make drivers that relied on the feature
less portable between HW with different actual features.
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Arnaud Patard (Rtp) @ 2014-01-17 20:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D98E94.6000609@boundarydevices.com>
Eric Nelson <eric.nelson@boundarydevices.com> writes:
> On 01/17/2014 12:57 PM, Arnaud Patard (Rtp) wrote:
>> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>>
>>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
>>> hides stuff. It's really wonderful, because you don't have to care
>>> about how the GPIOs are actually accessed in drivers anymore.
>>>
>>> However, what about the behaviour of GPIOs?
>>>
>>> What about... for example... this sequence:
>>>
>>> gpio_direction_output(gpio, 1);
>>> val = gpio_get_value(gpio);
>>>
>>> What value is "val"? More importantly, what value is reflected in
>>> /sys/kernel/debug/gpio ? Would it indicate that it's high or low?
>>>
>>> Now, while you can make reasonable assumptions, such as "it'll return
>>> that the output is being driven to the requested state" or "it'll
>>> return the actual state of the pin", what about this instead, which
>>> happens on iMX hardware - "it'll _always_ return zero".
>>>
>>
>> this is "expected". gpio layer docs are saying that in output case, the
>> value may be wrong. Not intuitive but documented.
>>
>>> Yes, iMX6 at least has this behaviour. For any output, val as above
>>> will always be zero, and /proc/sys/kernel/debug/gpio will always
>>> report that an output is zero... unless the SION bit has been set for
>>> that GPIO signal.
>>
>> afaik at least imx51/53 have some behaviour.
>>
>>>
>>> The reason is that on hardware such as iMX6, reading the GPIO is done
>>> by reading the pad state register, and this register is _only_ supplied
>>> the state of the pad when the input path is enabled. The input path
>>> is only enabled when the output is disabled, or the SION bit is set
>>> to force the GPIO input path.
>>
>> I sent mails about this same issue for imx51 in Dec 2010 and answer were
>> that the SION bit should not be set for all gpios:
>> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/100875
>>
>
> Thanks Arnaud,
>
> This bit from the 2010 chain really needs some explanation:
>
>>> Arnaud Patard (Rtp) writes:
>>>
>>> <snip>
>>>
>>> I had done the same, but had some trouble with this.
>>> E.g. on our board GPIO1_7 is used as a generic GPIO to enable an
>>> external clock oscillator for the USBH1 ULPI PHY. When the SION bit
>>> for this pad was set, I got strange errors on the USBH1 port
>>> (disconnecting low speed devices behind a hub would stall the
>>> bus). When I removed the SION bit for that pin everything worked
>>> well.
>>>
>
> Did you ever chase down the symptom here? Was the GPIO output not
> holding a constant value such that the oscillator wasn't functioning?
>
It was not me who got this issue. The issue I had was not being able to
read GPIO value if set as output. This link may be clearer:
http://archive.arm.linux.org.uk/lurker/message/20101215.151016.ea731aa7.en.html
Arnaud
^ permalink raw reply
* [PATCH RFC 0/6] net: rfkill: gpio: Add device tree support
From: Johannes Berg @ 2014-01-17 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389941251-32692-1-git-send-email-wens@csie.org>
On Fri, 2014-01-17 at 14:47 +0800, Chen-Yu Tsai wrote:
> This patch series adds device tree support to rfkill-gpio, and
> fixes some issues I ran into. This is so we can define and control
> RF devices through the device tree, such as the Broadcom BCM20710
> UART-based Bluetooth device found on the CubieTruck,
> Comments, please?
Does anyone else want to maintain rfkill-gpio? :)
I'm not up to par on all the DT, ACPI and even GPIO stuff it does, and
the rfkill bits in it are really small ...
I'll happily apply the patches if everyone else is happy with them, but
please don't expect me to actually be able to say anything about them.
johannes
^ permalink raw reply
* [PATCH v7 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: Sergei Shtylyov @ 2014-01-17 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389918150-19058-2-git-send-email-horms+renesas@verge.net.au>
Hello.
On 01/17/2014 03:22 AM, Simon Horman wrote:
> Return a boolean from sh_eth_is_gether() and refactor it as a one-liner.
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
WBR, Sergei
^ permalink raw reply
* [PATCH 3/3] clk: ti: OMAP build fixes
From: Tero Kristo @ 2014-01-17 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389990340-23358-1-git-send-email-t-kristo@ti.com>
Improper merge of TI clock driver resulted in build breakage for OMAP1 build,
and various other TI single SoC builds. This patch fixes those by adding the
missed Makefile tweaks.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/clk/Makefile | 2 +-
drivers/clk/ti/Makefile | 17 +++++++++--------
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 1f3143f..13c1e91 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/
obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/
-obj-$(CONFIG_ARCH_OMAP) += ti/
+obj-$(CONFIG_ARCH_OMAP2PLUS) += ti/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 007c3c2..4319d40 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,10 +1,11 @@
ifneq ($(CONFIG_OF),)
-obj-y += clk.o dpll.o autoidle.o divider.o \
- fixed-factor.o gate.o clockdomain.o \
- composite.o mux.o apll.o clk-43xx.o
-obj-$(CONFIG_SOC_AM33XX) += clk-33xx.o
-obj-$(CONFIG_ARCH_OMAP3) += interface.o clk-3xxx.o
-obj-$(CONFIG_ARCH_OMAP4) += clk-44xx.o
-obj-$(CONFIG_SOC_OMAP5) += clk-54xx.o
-obj-$(CONFIG_SOC_DRA7XX) += clk-7xx.o
+obj-y += clk.o autoidle.o clockdomain.o
+clk-common = dpll.o composite.o divider.o gate.o \
+ fixed-factor.o mux.o apll.o
+obj-$(CONFIG_SOC_AM33XX) += $(clk-common) clk-33xx.o
+obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o
+obj-$(CONFIG_ARCH_OMAP4) += $(clk-common) clk-44xx.o
+obj-$(CONFIG_SOC_OMAP5) += $(clk-common) clk-54xx.o
+obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o
+obj-$(CONFIG_SOC_AM43XX) += $(clk-common) clk-43xx.o
endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] ARM: DRA7XX: Add support for DRA7XX only build
From: Tero Kristo @ 2014-01-17 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389990340-23358-1-git-send-email-t-kristo@ti.com>
SOC_DRA7XX was under wrong menu within Kconfig file, which prevented
DRA7XX only build. Fixed the kconfig options for this SoC as we are
there. voltage.c needs to be added to the DRA7XX build also, otherwise
DRA7XX only build will fail.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/Kconfig | 18 ++++++++++--------
arch/arm/mach-omap2/Makefile | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dc21df1..e65948a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -76,6 +76,16 @@ config SOC_AM43XX
select ARM_GIC
select MACH_OMAP_GENERIC
+config SOC_DRA7XX
+ bool "TI DRA7XX"
+ depends on ARCH_MULTI_V7
+ select ARCH_OMAP2PLUS
+ select ARM_CPU_SUSPEND if PM
+ select ARM_GIC
+ select CPU_V7
+ select HAVE_SMP
+ select HAVE_ARM_ARCH_TIMER
+
config ARCH_OMAP2PLUS
bool
select ARCH_HAS_BANDGAP
@@ -128,14 +138,6 @@ config SOC_HAS_REALTIME_COUNTER
depends on SOC_OMAP5 || SOC_DRA7XX
default y
-config SOC_DRA7XX
- bool "TI DRA7XX"
- select ARM_ARCH_TIMER
- select CPU_V7
- select ARM_GIC
- select HAVE_SMP
- select COMMON_CLK
-
comment "OMAP Core Type"
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 96a990f..8ebe9f3 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -132,6 +132,7 @@ obj-$(CONFIG_SOC_AM33XX) += $(voltagedomain-common)
obj-$(CONFIG_SOC_AM43XX) += $(voltagedomain-common)
obj-$(CONFIG_SOC_OMAP5) += $(voltagedomain-common)
obj-$(CONFIG_SOC_OMAP5) += voltagedomains54xx_data.o
+obj-$(CONFIG_SOC_DRA7XX) += $(voltagedomain-common)
# OMAP powerdomain framework
powerdomain-common += powerdomain.o powerdomain-common.o
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] ARM: DRA7XX/AM43XX: randconfig fixes
From: Tero Kristo @ 2014-01-17 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389990340-23358-1-git-send-email-t-kristo@ti.com>
DRA7XX and AM43XX were missing common clock code from the Makefile, which
causes build breakage in DRA7XX / AM43XX only builds once clock support
for these SoCs is added. Add the missing entries to the Makefile as
preparation of this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 088305f..96a990f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -191,6 +191,9 @@ obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o
obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o
obj-$(CONFIG_SOC_OMAP5) += $(clock-common)
obj-$(CONFIG_SOC_OMAP5) += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_DRA7XX) += $(clock-common)
+obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o
+obj-$(CONFIG_SOC_AM43XX) += $(clock-common) dpll3xxx.o
# OMAP2 clock rate set data (old "OPP" data)
obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
From: Tero Kristo @ 2014-01-17 20:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Quick emergency band-aid for the build breakages introduced in clk-next
by Mike. I didn't have time to test this out (Nishanth will provide some
logs) and I will leave the decision whether/how to use these patches or not
to Tony + Mike.
I also pushed a test branch based on top of clk-next here:
tree: https://github.com/t-kristo/linux-pm.git
branch: clk-next-omap-fixes
-Tero
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Russell King - ARM Linux @ 2014-01-17 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D98712.3070103@wwwdotorg.org>
On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
> > So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> > hides stuff. It's really wonderful, because you don't have to care
> > about how the GPIOs are actually accessed in drivers anymore.
> ...
> > 1. What should gpio_get_value() return for an output?
>
> Some HW can't ever read back the value of an output pin, so isn't
> calling gpio_get_value() undefined for output pins?
As has been pointed out, that's not how gpio_get_valie() is documented.
It's documented to return the value of the pin where possible. In my
case, it _is_ possible to read back the value of the pin - it just
needs the appropriate chip configuration to make it happen.
Now to the crunch point of my email: where subsystems differ completely
_unnecessarily_ from what is expected from them - such as returning the
current state of the output where it's possible to do so - then this
kind of difference *reduces* the portability of that subsystem, and
makes being able to move from one SoC to another _unnecessarily_ more
difficult.
This is the issue: if everyone has to re-learn how subsystem X behaves
on hardware Y because it has unnecessarily different hardware, then
we're just making stuff much harder for no reason what so ever, and I'd
say there's no point to having that subsystem in the first place. It's
nothing more than a waste of space.
Let's put it a different way - what if every hard disk you bought had
a completely different connector on it just because the manufacturer
could put a different connector on it, and you had to also buy their
special cable... oh, and the motherboard end also had a motherboard
specific connector, so you had to get the right connector at both ends
of the cable. Electrically, the thing is the same, it's just that the
manufacturer is being perverse and changing the connector for the shere
hell of it. Would that annoy you?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Uwe Kleine-König @ 2014-01-17 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D98712.3070103@wwwdotorg.org>
On Fri, Jan 17, 2014 at 12:40:02PM -0700, Stephen Warren wrote:
> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
> > So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> > hides stuff. It's really wonderful, because you don't have to care
> > about how the GPIOs are actually accessed in drivers anymore.
> ...
> > 1. What should gpio_get_value() return for an output?
>
> Some HW can't ever read back the value of an output pin, so isn't
> calling gpio_get_value() undefined for output pins?
I remember something like: "If possible it should return what is seen on
the pad, if not, return 0." being the requirement.
Documentation/gpio/gpio-legacy.txt still says that:
When reading the value of an output pin, the value returned should be
what's seen on the pin ... that won't always match the specified output
value, because of issues including open-drain signaling and output
latencies.
[...] However, note that not all platforms can read the value of output
pins; those that can't should always return zero.
Something similar can be found in Documentation/gpio/consumer about
gpiod_get_value.
So you might consider i.MX6 (and also the earlier i.MX SoCs) to violate
a "should" in the requirements. If (not necessarily iff) adding the SION
bit doesn't have other side effects than being able to read out the gpio
value (like increased latencies or power consumption) I'm all for
setting it in every case assuming it is available for all pins.
Other than that I see five possibilities:
a) keep everything as is. Seems to imply surprises which is bad. Maybe
at least improve the docs to have the information that the return
value of gpio_get_value might not be usefull in the same paragraph
as what should be reported.
b) check if for the requested gpio pad the SION bit is set and read the
pad value if it is, return 0 otherwise. (But note, after thinking
again I don't believe this to be possible, because there is usually >1
pad that can output a given gpio. Moreover AFAIK the information to
which pads a given gpio can be routed is missing in the kernel. That
could be fixed, that would result in a big table though. (And the
first problem is still unfixed.))
c) When gpio_get_value is requested for a gpio, set SION temporarily.
This has the same implementation problems as b) tough.
d) Read out the pad value unconditionally and return that.
I didn't check if it always returns 0 if SION is unset though. That
should be asserted first (or otherwise check if there are
possibilities to find out if the pad value is valid).
e) add a flag to all gpio-chips signalling which case gpio_get_value
implements (i.e: return
- the actual value on the pad; or
- zero.
). This is not orthogonal to b) - d)
> > 2. What should be reported in /sys/kernel/debug/gpio for an output?
It should report the same thing as gpio_get_value in 1.
> Shouldn't it indicate that the pin is an output, and say nothing about
> the input value?
It's usefull at times to be able to read an output pin. So I'm against
discarding the value on all platforms because some platforms are unable
to provide it.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
From: Arnd Bergmann @ 2014-01-17 20:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67UKiyfJbKZ_Frk3OwZupMPoA2Ck3Hj2zsRFXBQPztavg@mail.gmail.com>
On Friday 17 January 2014, Chen-Yu Tsai wrote:
> 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.
The Linux implementation should not enforce an inferior DT binding.
I think it would be better to change the code instead and make this
work with a more sensible representation.
> 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.
(adding the gpio people here). I don't understand enough of the
current API to make a good call here, but I agree that we should try
to make it more uniform and do it in a way that allows simpler DT
bindings for devices using it.
> About the property string, is the plural form required, even though we
> only want one?
I would keep the plural form for consistency.
Arnd
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Eric Nelson @ 2014-01-17 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ioti2xfu.fsf@lebrac.rtp-net.org>
On 01/17/2014 12:57 PM, Arnaud Patard (Rtp) wrote:
> Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
>
>> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
>> hides stuff. It's really wonderful, because you don't have to care
>> about how the GPIOs are actually accessed in drivers anymore.
>>
>> However, what about the behaviour of GPIOs?
>>
>> What about... for example... this sequence:
>>
>> gpio_direction_output(gpio, 1);
>> val = gpio_get_value(gpio);
>>
>> What value is "val"? More importantly, what value is reflected in
>> /sys/kernel/debug/gpio ? Would it indicate that it's high or low?
>>
>> Now, while you can make reasonable assumptions, such as "it'll return
>> that the output is being driven to the requested state" or "it'll
>> return the actual state of the pin", what about this instead, which
>> happens on iMX hardware - "it'll _always_ return zero".
>>
>
> this is "expected". gpio layer docs are saying that in output case, the
> value may be wrong. Not intuitive but documented.
>
>> Yes, iMX6 at least has this behaviour. For any output, val as above
>> will always be zero, and /proc/sys/kernel/debug/gpio will always
>> report that an output is zero... unless the SION bit has been set for
>> that GPIO signal.
>
> afaik at least imx51/53 have some behaviour.
>
>>
>> The reason is that on hardware such as iMX6, reading the GPIO is done
>> by reading the pad state register, and this register is _only_ supplied
>> the state of the pad when the input path is enabled. The input path
>> is only enabled when the output is disabled, or the SION bit is set
>> to force the GPIO input path.
>
> I sent mails about this same issue for imx51 in Dec 2010 and answer were
> that the SION bit should not be set for all gpios:
> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/100875
>
Thanks Arnaud,
This bit from the 2010 chain really needs some explanation:
>> Arnaud Patard (Rtp) writes:
>>
>> <snip>
>>
>> I had done the same, but had some trouble with this.
>> E.g. on our board GPIO1_7 is used as a generic GPIO to enable an
>> external clock oscillator for the USBH1 ULPI PHY. When the SION bit
>> for this pad was set, I got strange errors on the USBH1 port
>> (disconnecting low speed devices behind a hub would stall the
>> bus). When I removed the SION bit for that pin everything worked
>> well.
>>
Did you ever chase down the symptom here? Was the GPIO output not
holding a constant value such that the oscillator wasn't functioning?
Please advise,
Eric
^ permalink raw reply
* [PATCH] clk: qcom: Fix modular build
From: Stephen Boyd @ 2014-01-17 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52d8dde8.Mqtb7njO7G6foYTt%fengguang.wu@intel.com>
According to Documentation/kbuild/makefiles.txt these symbols
should be clk-qcom-y. Otherwise the build will fail if
CONFIG_COMMON_CLK_QCOM=m. Fix it.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/clk/qcom/Makefile | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 190d38433202..f60db2ef1aee 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -1,11 +1,11 @@
obj-$(CONFIG_COMMON_CLK_QCOM) += clk-qcom.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-regmap.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-pll.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-rcg.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-rcg2.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += clk-branch.o
-clk-qcom-$(CONFIG_COMMON_CLK_QCOM) += reset.o
+clk-qcom-y += clk-regmap.o
+clk-qcom-y += clk-pll.o
+clk-qcom-y += clk-rcg.o
+clk-qcom-y += clk-rcg2.o
+clk-qcom-y += clk-branch.o
+clk-qcom-y += reset.o
obj-$(CONFIG_MSM_GCC_8660) += gcc-msm8660.o
obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v4 8/8] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Arnd Bergmann @ 2014-01-17 20:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389986367-4010-9-git-send-email-marc.ceeeee@gmail.com>
On Friday 17 January 2014, Marc Carino wrote:
> + serial at f0406b00 {
> + compatible = "ns16550a";
> + reg = <0x00 0xf0406b00 0x00 0x20>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <0 75 0x4>;
> + clock-frequency = <0x4d3f640>;
> + };
> +
> + rdb {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "simple-bus";
> + ranges = <0 0x00 0xf0000000 0x1000000>;
> +
> + sun_top_ctrl: syscon at 404000 {
> + compatible = "brcm,bcm7445-sun-top-ctrl",
> + "syscon";
> + reg = <0x404000 0x51c>;
> + };
> +
Yes, this looks better, but as a minor comment, the serial device above
should really be part of the rdb bus now, since that encompasses the
0xf0000000 device range.
Arnd
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-17 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r486mrh5.fsf@linaro.org>
On 01/17/2014 11:46 AM, Kevin Hilman wrote:
> 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.
Here are my logs for the similar configuration(with few patches for
legacy boot):
next-db23a6c + next-20140117 (omap2plus_defconfig)
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20pGXG1jF
2: am335x-sk: Boot PASS: http://slexy.org/raw/s2ViUqyxYc
3: am3517-evm: Boot PASS: http://slexy.org/raw/s29qMTk2mS
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20aZ0oDHS
5: beag: Boot PASS: http://slexy.org/raw/s2DAKDwqRm
6: bone: Boot PASS: http://slexy.org/raw/s215UVEmq2
7: crane: No Image built - Missing platform support?: (pending
merge from Benoit)
8: dra7: Boot PASS: http://slexy.org/raw/s2CbtBGGxE
9: ldp: Boot FAIL: http://slexy.org/raw/s20MOKNvPG
(been seeing this behavior on and off for some days now.. not really a
regression due to this series - need to debug this - could be setup
issues).
10: panda: Boot PASS: http://slexy.org/raw/s20RHdfXjS
11: sdp2430: Boot PASS: http://slexy.org/raw/s21fR9cQap
12: sdp3430: Boot PASS: http://slexy.org/raw/s209eZfYlQ
13: sdp4430: Boot PASS: http://slexy.org/raw/s21jemvEcd
14: uevm: Boot PASS: http://slexy.org/raw/s20OumuRI8
TOTAL = 14 boards, Booted Boards = 12, No Boot boards = 2
clk-next-db23a6c + next-20140117 (multi_v7_defconfig)
1: am335x-evm: Boot PASS: http://slexy.org/raw/s21kek3KDX
2: am335x-sk: Boot PASS: http://slexy.org/raw/s20b6Ypnpr
3: am3517-evm: Boot PASS: http://slexy.org/raw/s200aHOMA1
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2QwHWtLbB
5: beag: Boot PASS: http://slexy.org/raw/s2120qe2nJ
6: bone: Boot PASS: http://slexy.org/raw/s21SnQH1AY
7: crane: No Image built - Missing platform support?:
8: dra7: Boot FAIL: http://slexy.org/raw/s20HxBFzIr
missing DRA7 in multi_v7
9: ldp: Boot PASS: http://slexy.org/raw/s21vjb9GeV
10: panda: Boot FAIL: http://slexy.org/raw/s2WahEfqVw
kevin already reported this for CPU_IDLE enable
11: sdp2430: Boot FAIL: http://slexy.org/raw/s2ADmtqRhq
* multi_v7 does not boot v6 based boards
12: sdp3430: Boot PASS: http://slexy.org/raw/s2qM9hxrfi
13: sdp4430: Boot PASS: http://slexy.org/raw/s2ubbIBRA7
14: uevm: Boot PASS: http://slexy.org/raw/s2Y9xESvfH
TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4
clk-next-db23a6c + next-20140117 (multi_v7_defconfig + CONFIG_LPAE=y)
1: am335x-evm: Boot PASS: http://slexy.org/raw/s26sCQ0zqh
2: am335x-sk: Boot PASS: http://slexy.org/raw/s20BDyQWdB
3: am3517-evm: Boot PASS: http://slexy.org/raw/s21OPwGNo1
4: am37x-evm: Boot PASS: http://slexy.org/raw/s20tpjF0ri
5: beag: Boot PASS: http://slexy.org/raw/s2jzkyRVaS
6: bone: Boot PASS: http://slexy.org/raw/s20XodcZtZ
7: crane: No Image built - Missing platform support?:
8: dra7: Boot FAIL: http://slexy.org/raw/s21cv8ni1H
missing DRA7 in multi_v7
9: ldp: Boot PASS: http://slexy.org/raw/s22x4lqV3F
10: panda: Boot FAIL: http://slexy.org/raw/s200ETyoTB
kevin already reported this for CPU_IDLE enable
11: sdp2430: Boot FAIL: http://slexy.org/raw/s2lw3baFwx
* multi_v7 does not boot v6 based boards
12: sdp3430: Boot PASS: http://slexy.org/raw/s21i0TdsYs
13: sdp4430: Boot PASS: http://slexy.org/raw/s2DaYv6GVp
14: uevm: Boot PASS: http://slexy.org/raw/s2Q5IdWfMQ
TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH v4 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
From: Sherman Yin @ 2014-01-17 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaPZrR=kEknr3YKDWLd_E+o22Yn19ei7iT6cdbYdbeZ2w@mail.gmail.com>
On 14-01-16 05:19 AM, Linus Walleij wrote:
> On Sat, Dec 21, 2013 at 3:13 AM, Sherman Yin <syin@broadcom.com> wrote:
>
> '> Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs.
>>
>> Signed-off-by: Sherman Yin <syin@broadcom.com>
>> Reviewed-by: Christian Daudt <bcm@fixthebug.org>
>> Reviewed-by: Matt Porter <matt.porter@linaro.org>
>> ---
>> v4: - PINCTRL selected in Kconfig, PINCTRL_CAPRI selected in bcm_defconfig
>> - make use of regmap
>> - change CAPRI_PIN_UPDATE from macro to inline function.
>> - Handle pull-up strength arg in Ohm instead of enum
>
> Patch applied. It is really good now! It's late before the merge
> window, but you've done a tremendous work on this driver and
> I don't want to delay its deployment further.
Great, thanks for the support and reviews!
> But note:
>
>> arch/arm/configs/bcm_defconfig | 1 +
>> arch/arm/mach-bcm/Kconfig | 1 +
>
> I've optimistically applied these two hunks of the patch as well,
> but if there is any conflict with the ARM SoC tree I will just rebase
> the patch and pull these *out*.
>
> ARM SoC maintainers: be warned if something collides.
Ok, will keep an eye on this and fix accordingly. Should be simple fixes.
Regards,
Sherman
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Arnaud Patard (Rtp) @ 2014-01-17 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117184731.GE15937@n2100.arm.linux.org.uk>
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> hides stuff. It's really wonderful, because you don't have to care
> about how the GPIOs are actually accessed in drivers anymore.
>
> However, what about the behaviour of GPIOs?
>
> What about... for example... this sequence:
>
> gpio_direction_output(gpio, 1);
> val = gpio_get_value(gpio);
>
> What value is "val"? More importantly, what value is reflected in
> /sys/kernel/debug/gpio ? Would it indicate that it's high or low?
>
> Now, while you can make reasonable assumptions, such as "it'll return
> that the output is being driven to the requested state" or "it'll
> return the actual state of the pin", what about this instead, which
> happens on iMX hardware - "it'll _always_ return zero".
>
this is "expected". gpio layer docs are saying that in output case, the
value may be wrong. Not intuitive but documented.
> Yes, iMX6 at least has this behaviour. For any output, val as above
> will always be zero, and /proc/sys/kernel/debug/gpio will always
> report that an output is zero... unless the SION bit has been set for
> that GPIO signal.
afaik at least imx51/53 have some behaviour.
>
> The reason is that on hardware such as iMX6, reading the GPIO is done
> by reading the pad state register, and this register is _only_ supplied
> the state of the pad when the input path is enabled. The input path
> is only enabled when the output is disabled, or the SION bit is set
> to force the GPIO input path.
I sent mails about this same issue for imx51 in Dec 2010 and answer were
that the SION bit should not be set for all gpios:
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/100875
Arnaud
^ permalink raw reply
* [PATCH] pinctrl: capri: add dependency on OF
From: Sherman Yin @ 2014-01-17 19:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389912312-16285-1-git-send-email-linus.walleij@linaro.org>
On 14-01-16 02:45 PM, Linus Walleij wrote:
> As this driver is using pinconf_generic_dt_node_to_map_pin() it
> needs to depend on OF so as not to cause build problems on
> archs that do not support OF.
>
> Cc: Sherman Yin <syin@broadcom.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/pinctrl/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index f1dda4d9de13..be361b7cd30f 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -106,6 +106,7 @@ config PINCTRL_BCM2835
>
> config PINCTRL_CAPRI
> bool "Broadcom Capri pinctrl driver"
> + depends on OF
> select PINMUX
> select PINCONF
> select GENERIC_PINCONF
>
Thanks for the fix, Linus. While we're visiting this config, should we
add "depends on MACH_BCM_MOBILE" as well?
Thanks,
Sherman
^ permalink raw reply
* [PATCH v2 0/6] arm64: Add audit support
From: Richard Guy Briggs @ 2014-01-17 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389946399-4525-1-git-send-email-takahiro.akashi@linaro.org>
On 14/01/17, AKASHI Takahiro wrote:
> This patchset adds system call audit support on arm64.
> Both 32-bit (AUIDT_ARCH_ARM[EB]) and 64-bit tasks (AUDIT_ARCH_AARCH64[EB])
> are supported, but presuming 32-LE on 64-LE or 32-BE on 64-BE.
>
> There are some prerequisites for this patch to work correctly:
> * "generic compat system call audit support" patch
> * "correct a type mismatch in audit_syscall_exit()" patch
> (already accepted and queued in 3.14)
> * "Modify a set of system calls in audit class" patch
> * userspace audit tool (v2.3.2 + my patch for arm64)
>
> All those were already or will be soon posted separately.
> Please review them as well for better understandings.
>
> This code was tested on both 32-bit and 64-bit LE userland
> in the following two ways:
> 1) basic operations with auditctl/autrace
> # auditctl -a exit,always -S openat -F path=/etc/inittab
> # auditctl -a exit,always -F dir=/tmp -F perm=rw
> # auditctl -a task,always
> # autrace /bin/ls
> by comparing output from autrace with one from strace
>
> 2) audit-test-code (+ my workarounds for arm/arm64)
> by running "audit-tool", "filter" and "syscalls" test categories.
>
> Changes v1 -> v2:
> * Modified to utilize "generic compat system call audit" [3/6, 4/6, 5/6]
> Please note that a required header, unistd_32.h, is automatically
> generated from unistd32.h.
> * Refer to regs->orig_x0 instead of regs->x0 as the first argument of
> system call in audit_syscall_entry() [6/6]
> * Include "Add regs_return_value() in syscall.h" patch [2/6],
> which was not intentionally included in v1 because it could be added
> by "kprobes support".
>
>
> AKASHI Takahiro (6):
> audit: Enable arm64 support
> arm64: Add regs_return_value() in syscall.h
> arm64: Add audit support
> arm64: audit: Add 32-bit (compat) syscall support
> arm64: audit: Add makefile rule to create unistd_32.h for compat
> syscalls
> arm64: audit: Add audit hook in ptrace/syscall_trace
>
> arch/arm64/Makefile | 4 ++++
> arch/arm64/include/asm/audit.h | 20 ++++++++++++++++++++
> arch/arm64/include/asm/ptrace.h | 5 +++++
> arch/arm64/include/asm/syscall.h | 22 ++++++++++++++++++++++
> arch/arm64/include/asm/thread_info.h | 1 +
> arch/arm64/kernel/entry.S | 3 +++
> arch/arm64/kernel/ptrace.c | 12 ++++++++++++
> arch/arm64/kernel/syscalls/Makefile | 20 ++++++++++++++++++++
> include/uapi/linux/audit.h | 2 ++
> init/Kconfig | 2 +-
> 10 files changed, 90 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/include/asm/audit.h
> create mode 100644 arch/arm64/kernel/syscalls/Makefile
>
> --
> 1.7.9.5
Set:
Acked-by: Richard Guy Briggs <rgb@redhat.com>
>
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* [PATCH] audit: Modify a set of system calls in audit class definitions
From: Richard Guy Briggs @ 2014-01-17 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389945903-4326-1-git-send-email-takahiro.akashi@linaro.org>
On 14/01/17, AKASHI Takahiro wrote:
> Each asm-generic/audit_xx.h defines a set of system calls for respective
> audit permssion class (read, write, change attribute or exec).
> This patch changes two entries:
>
> 1) fchown in audit_change_attr.h
> Make fchown included by its own because in asm-generic/unistd.h, for example,
> fchown always exists while chown is optional. This change is necessary at
> least for arm64.
>
> 2) truncate64 in audit_write.h
> Add missing truncate64/ftruncate64 as well as truncate/ftruncate
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> include/asm-generic/audit_change_attr.h | 4 +++-
> include/asm-generic/audit_write.h | 6 ++++++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/include/asm-generic/audit_change_attr.h b/include/asm-generic/audit_change_attr.h
> index 89b73e5..a186553 100644
> --- a/include/asm-generic/audit_change_attr.h
> +++ b/include/asm-generic/audit_change_attr.h
> @@ -4,9 +4,11 @@ __NR_chmod,
> __NR_fchmod,
> #ifdef __NR_chown
> __NR_chown,
> -__NR_fchown,
> __NR_lchown,
> #endif
> +#ifdef __NR_fchown
> +__NR_fchown,
> +#endif
> __NR_setxattr,
> __NR_lsetxattr,
> __NR_fsetxattr,
> diff --git a/include/asm-generic/audit_write.h b/include/asm-generic/audit_write.h
> index e7020c5..274575d 100644
> --- a/include/asm-generic/audit_write.h
> +++ b/include/asm-generic/audit_write.h
> @@ -10,6 +10,12 @@ __NR_truncate,
> #ifdef __NR_truncate64
> __NR_truncate64,
> #endif
> +#ifdef __NR_ftruncate
> +__NR_ftruncate,
> +#endif
> +#ifdef __NR_ftruncate64
> +__NR_ftruncate64,
> +#endif
> #ifdef __NR_bind
> __NR_bind, /* bind can affect fs object only in one way... */
> #endif
> --
> 1.7.9.5
>
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Stephen Warren @ 2014-01-17 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117184731.GE15937@n2100.arm.linux.org.uk>
On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
> So, we have this wonderful GPIO layer which abstracts GPIO stuff and
> hides stuff. It's really wonderful, because you don't have to care
> about how the GPIOs are actually accessed in drivers anymore.
...
> 1. What should gpio_get_value() return for an output?
Some HW can't ever read back the value of an output pin, so isn't
calling gpio_get_value() undefined for output pins?
> 2. What should be reported in /sys/kernel/debug/gpio for an output?
Shouldn't it indicate that the pin is an output, and say nothing about
the input value?
^ permalink raw reply
* More GPIO madness on iMX6 - and the crappy ARM port of Linux
From: Eric Nelson @ 2014-01-17 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D980C8.9020809@boundarydevices.com>
Hi Russell,
On 01/17/2014 12:13 PM, Eric Nelson wrote:
> Hi Russell,
>
> On 01/17/2014 11:47 AM, Russell King - ARM Linux wrote:
>>
>> <snip>
>>
>> So, this brings up three obvious questions:
>>
>> 1. What should gpio_get_value() return for an output?
>
> It seems that this is pretty well specified.
>
> To quote Documentation/gpio/gpio-legacy.txt:
> >> When reading the value of an output pin, the value
> >> returned should be what's seen on the pin ... that
> >> won't always match the specified output value, because
> >> of issues including open-drain signaling and output
> >> latencies.
>
> Documentation/gpio/gpio.txt is a little less clear, but implies
> the same:
> >> If you are "driving" the signal high but
> >> gpiod_get_value(gpio) reports a low value (after
> >> the appropriate rise time passes), you know some other
> >> component is driving the shared signal low
>
>> 2. What should be reported in /sys/kernel/debug/gpio for an output?
>> 3. Should iMX6 (and similar) GPIOs always have the SION bit set in
>> their DT descriptions?
>>
>> Discuss.
>>
>
> Each signal accessed using the GPIO subsystem **must** have
> the SION bit set and the values returned should be the value
> from the PSR registers.
>
Because the MUX registers are very consistent, it appears
that a fix for this that sets the SION bit is simple (almost
mechanical) in the imx*pinfunc.h files.
It seems that each of the declarations matching
#define MX*GPIO_something
should have bit four set in the mux_mode column.
I'd be happy to work up a patch if there's agreement here
(and I can't think of any rationale for not setting these).
Regards,
Eric
^ 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