* Re: [PATCH] pinctrl: core: Fix regression caused by delayed work for hogs
From: Tony Lindgren @ 2017-01-12 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-omap@vger.kernel.org, Gary Bisson, Linux-Renesas
In-Reply-To: <CAMuHMdXGaDoBbNGkS8oYRiNUNbtUNand6qkNY-s4QNSt5Fj0ZQ@mail.gmail.com>
* Geert Uytterhoeven <geert@linux-m68k.org> [170112 00:44]:
> Hi Tony,
>
> On Wed, Jan 11, 2017 at 11:13 PM, Tony Lindgren <tony@atomide.com> wrote:
> > Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
> > regression at least with sh-pfc that is also a GPIO controller as
> > noted by Geert Uytterhoeven <geert@linux-m68k.org>.
> >
> > As the original pinctrl_register() has issues calling pin controller
> > driver functions early before the controller has finished registering,
> > we can't just revert commit df61b366af26. That would break the drivers
> > using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.
> >
> > So let's fix the issue with the following steps as a single patch:
> >
> > 1. Revert the late_init parts of commit df61b366af26.
> >
> > The late_init clearly won't work and we have to just give up
> > on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
> > GENERIC_PINMUX_FUNCTIONS.
> >
> > 2. Split pinctrl_register() into two parts
> >
> > By splitting pinctrl_register() into pinctrl_init_controller()
> > and pinctrl_create_and_start() we have better control over when
> > it's safe to call pinctrl_create().
> >
> > 3. Introduce a new pinctrl_register_and_init() function
> >
> > As suggested by Linus Walleij <linus.walleij@linaro.org>, we
> > can just introduce a new function for the controllers that need
> > pinctrl_create() called later.
> >
> > 4. Convert the four known problem cases to use new function
> >
> > Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
> > to use the new function to fix the issues. The rest of the drivers
> > can be converted later. Let's also update Documentation/pinctrl.txt
> > accordingly because of the known issues with pinctrl_register().
> >
> > Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Gary Bisson <gary.bisson@boundarydevices.com>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> Thanks, this fixes r8a7740/armadillo.
>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
OK thanks for testing, good to hear it works for you.
Thanks,
Tony
^ permalink raw reply
* [PATCH] ARM: dts: NSP: Fix DT ranges error
From: Jon Mason @ 2017-01-12 15:50 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, linux-arm-kernel, bcm-kernel-feedback-list,
linux-kernel
The range size for axi is 0x2 bytes too small, as the QSPI needs
0x11c408 + 0x004 (which is 0x0011c40c, not 0x0011c40a). No errors have
been observed with this shortcoming, but fixing it for correctness.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm/boot/dts/bcm-nsp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 6c58c78..832795b 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -160,7 +160,7 @@
axi {
compatible = "simple-bus";
- ranges = <0x00000000 0x18000000 0x0011c40a>;
+ ranges = <0x00000000 0x18000000 0x0011c40c>;
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 4/4] mmc: pwrseq-simple: add disable-post-power-on option
From: Ulf Hansson @ 2017-01-12 15:57 UTC (permalink / raw)
To: Matt Ranostay
Cc: Linus Walleij, Rob Herring, devicetree@vger.kernel.org,
linux-mmc@vger.kernel.org, Tony Lindgren, Liam Breck
In-Reply-To: <CAJ_EiSQaE4FcLdf_8t8=6cNCZ+nAWhqqANKbfEp7VW02=Kj-RA@mail.gmail.com>
On 12 January 2017 at 05:43, Matt Ranostay <matt@ranostay.consulting> wrote:
> On Wed, Jan 11, 2017 at 2:55 PM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>> On 9 January 2017 at 05:53, Matt Ranostay <matt@ranostay.consulting> wrote:
>>> On Fri, Dec 30, 2016 at 12:05 AM, Linus Walleij
>>> <linus.walleij@linaro.org> wrote:
>>>> On Mon, Dec 19, 2016 at 1:01 AM, Matt Ranostay <matt@ranostay.consulting> wrote:
>>>>
>>>>> * SD8787 has a "powerdown" line, and CW1200 has a "powerup" line.. I
>>>>> know this is a simple logic inversion.
>>>>
>>>> If this is a GPIO line, the GPIO subsystem can flag a line for
>>>> inverted logic. GPIO_ACTIVE_LOW from device tree for example.
>>>
>>> Slight ping on Ulf on this thread :).
>>
>> Thanks, sorry for the delay!
>>
>>>
>>> I do understand the inverted logic flag but that doesn't help if there
>>> are different logic states between various chipsets.
>>
>> For cw1200 (I looked at code from an old ST-Ericsson vendor tree), the
>> sequence is as follows:
>>
>> 1) Enable clock/power to the card/chip.
>> 2) Assert GPIO pin. I assume this also can be done before the
>> clock/power is enabled.
>> 3) Wait some time (~50ms).
>> 4) De-assert GPIO pin.
>> 5) Wait some time (~20ms)
>> 6) Assert GPIO pin.
>> 7) Wait some time (~32ms).
>>
>> At power off, the GPIO pin is de-asserted and of course also the
>> clock/power is disabled. Just to make sure we have all the relevant
>> logic.
>>
>> Looking at mmc pwrseq simple, perhaps we can extend this to deal with
>> GPIOs that needs to be *toggled*, as this is not just reset GPIOs.
>> Then we also need to deal with the delays in-between the toggling.
>
> Wouldn't we need to have a per chip function for each device
> supported? As well document gpios? I suspect we'd need an array of
I was hoping to avoid this, but the more I look at it, it seems inevitable.
> gpios defined in device tree since different devices will likely have
> various numbers of pins to toggle
Maybe we can think of a clever way to combine cw1200 with your case?
Perhaps a "mmc pwrseq toggle". :-) If not, please go ahead an repost a
device specific mmc pwrseq for your case.
I realize this would be a good opportunity for me to work on enabling
support for cw1200 on ux500, but as the implementation of the
clock/power control also needs to be up-streamed, I am quite far from
being done.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 16:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1484234867.2492.39.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, Jan 12, 2017 at 09:27:47AM -0600, Benjamin Herrenschmidt wrote:
> On Thu, 2017-01-12 at 11:30 +0100, Greg KH wrote:
> > > > And don't call access_ok(), it's racy and no driver should ever do that.
> > > >
> > >
> > > Oh, duly noted. I'll be sure to check out how and why. Perhaps it
> > > would be wise that no driver actually do that, I'm quite sure I used
> > > other drivers as examples of best practice.
> >
> > You did? Please point me at that code so we can fix them up properly.
> > Cargo-cult coding is not a good thing, but it happens, so if we can at
> > least provide clean code to fixate on, it's good overall for everyone.
>
> How so ? I mean, access_ok followed by __get/__put_user is still a
> classic, what's wrong with it ?
No "normal" driver should do that, just call copy_to/from_user and be
done with it. That way all of the proper locking and validation checks
like this are done correctly for you. Why would a driver ever call the
"raw" __get/__put_user functions?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Benjamin Herrenschmidt @ 2017-01-12 16:07 UTC (permalink / raw)
To: Greg KH
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112160051.GB8095-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, 2017-01-12 at 17:00 +0100, Greg KH wrote:
> > How so ? I mean, access_ok followed by __get/__put_user is still a
> > classic, what's wrong with it ?
>
> No "normal" driver should do that, just call copy_to/from_user and be
> done with it. That way all of the proper locking and validation checks
> like this are done correctly for you. Why would a driver ever call the
> "raw" __get/__put_user functions?
I supposed historically it was considered faster for some things :-)
Not a huge deal, and yes it's probably cleaner, I was just wondering
what was "racy" about access_ok() that I might have missed...
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2017-01-12 16:17 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Wolfram Sang, Rob Herring, Maxime Coquelin, Alexandre Torgue,
Linus Walleij, Patrice Chotard, Russell King, linux-i2c,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <CAOAejn2pW20VPP_yGtvJ_ufvj6Xj1poBiiA2WqkALiaLyyONug@mail.gmail.com>
>>> > I don't understand scl_period = 1 µs for Fast Mode. For a bus freqency
>>> > of 400 kHz we need low + high = 2.5 µs. Is there a factor 10 missing
>>> > somewhere?
>>>
>>> As CCR = SCL_period * I2C parent clk frequency with minimal freq =
>>> 2Mhz and SCL_period = 1 we have:
>>> CCR = 1 * 2Mhz = 2.
>>> But to compute, scl_low and scl_high in Fast mode, we have to do the
>>> following thing as Duty=1:
>>> scl_high = 9 * CCR * I2C parent clk period
>>> scl_low = 16 * CCR * I2C parent clk period
>>> In our example:
>>> scl_high = 9 * 2 * 0,0000005 = 0,000009 sec = 9 µs
>>> scl_low = 16 * 2 * 0.0000005 = 0,000016 sec = 16 µs
>>> So low + high = 27 µs > 2,5 µs
>>
>> For me 9 µs + 16 µs is 25 µs, resulting in 40 kHz. That's why I wondered
>> if there is a factor 10 missing somewhere.
>
> Hum ok. I am going to double-check what is wrong because when I check
> with the scope I always reach 400Khz for SCL.
> I will let you know.
There is one point I miss here that is described in the reference manual:
To reach the 400 kHz maximum I²C fast mode clock, the I2C parent rate
must be a multiple of 10 MHz.
So, contrary to what we said in a previous thread, 400 kHz could not
be reached with low frequencies.
In that way, we could compute CCR with duty = 0 by default.
So, I find another formula very close to the first one I pushed in the
first version:
In fast mode, we compute CCR with duty = 0:
t_scl_high = CCR * I2C parent clk period
t_scl_low = 2 *CCR * I2C parent clk period
So, CCR = I2C parent rate / 400 kHz / 3
For example with parent rate = 40 MHz:
CCR = 40000000 / 400000 / 3 = 33.333333333 = 33
t_scl_high = 33 * (1 / 2000000) = 825 ns > 600 ns
t_scl_low = 2 * 16 * (1 / 2000000) = 1650 ns > 1300 ns
It seems ok now.
Best regards,
Cedric
^ permalink raw reply
* Re: [PATCH] pinctrl: qcom: Add msm8998 pinctrl driver
From: Bjorn Andersson @ 2017-01-12 16:20 UTC (permalink / raw)
To: Imran Khan
Cc: andy.gross, Linus Walleij, Rob Herring, Mark Rutland, David Brown,
open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:ARM/QUALCOMM SUPPORT,
open list:ARM/QUALCOMM SUPPORT
In-Reply-To: <1483974019-8235-1-git-send-email-kimran@codeaurora.org>
On Mon 09 Jan 07:00 PST 2017, Imran Khan wrote:
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm8998.c b/drivers/pinctrl/qcom/pinctrl-msm8998.c
[..]
> +
> +#define NORTH 0x500000
> +#define WEST 0x100000
> +#define EAST 0x900000
So the control registers are now laid out in 3 non-contiguous ranges?
Please move them to the top of the file.
> +#define REG_SIZE 0x1000
Just inline 0x1000 in the macro below.
> +#define PINGROUP(id, base, f1, f2, f3, f4, f5, f6, f7, f8, f9) \
> + { \
> + .name = "gpio" #id, \
> + .pins = gpio##id##_pins, \
> + .npins = (unsigned int)ARRAY_SIZE(gpio##id##_pins), \
> + .funcs = (int[]){ \
> + msm_mux_gpio, /* gpio mode */ \
> + msm_mux_##f1, \
> + msm_mux_##f2, \
> + msm_mux_##f3, \
> + msm_mux_##f4, \
> + msm_mux_##f5, \
> + msm_mux_##f6, \
> + msm_mux_##f7, \
> + msm_mux_##f8, \
> + msm_mux_##f9 \
> + }, \
> + .nfuncs = 10, \
> + .ctl_reg = base + REG_SIZE * id, \
> + .io_reg = base + 0x4 + REG_SIZE * id, \
> + .intr_cfg_reg = base + 0x8 + REG_SIZE * id, \
> + .intr_status_reg = base + 0xc + REG_SIZE * id, \
> + .intr_target_reg = base + 0x8 + REG_SIZE * id, \
> + .mux_bit = 2, \
> + .pull_bit = 0, \
> + .drv_bit = 6, \
> + .oe_bit = 9, \
> + .in_bit = 0, \
> + .out_bit = 1, \
> + .intr_enable_bit = 0, \
> + .intr_status_bit = 0, \
> + .intr_target_bit = 5, \
> + .intr_target_kpss_val = 3, \
> + .intr_raw_status_bit = 4, \
> + .intr_polarity_bit = 1, \
> + .intr_detection_bit = 2, \
> + .intr_detection_width = 2, \
> + }
> +
> +#define SDC_QDSD_PINGROUP(pg_name, ctl, pull, drv) \
> + { \
> + .name = #pg_name, \
> + .pins = pg_name##_pins, \
> + .npins = (unsigned int)ARRAY_SIZE(pg_name##_pins), \
> + .ctl_reg = ctl, \
> + .io_reg = 0, \
> + .intr_cfg_reg = 0, \
> + .intr_status_reg = 0, \
> + .intr_target_reg = 0, \
> + .mux_bit = -1, \
> + .pull_bit = pull, \
> + .drv_bit = drv, \
> + .oe_bit = -1, \
> + .in_bit = -1, \
> + .out_bit = -1, \
> + .intr_enable_bit = -1, \
> + .intr_status_bit = -1, \
> + .intr_target_bit = -1, \
> + .intr_raw_status_bit = -1, \
> + .intr_polarity_bit = -1, \
> + .intr_detection_bit = -1, \
> + .intr_detection_width = -1, \
> + }
> +
> +#define UFS_RESET(pg_name, offset) \
> + { \
> + .name = #pg_name, \
> + .pins = pg_name##_pins, \
> + .npins = (unsigned int)ARRAY_SIZE(pg_name##_pins), \
> + .ctl_reg = offset, \
> + .io_reg = offset + 0x4, \
> + .intr_cfg_reg = 0, \
> + .intr_status_reg = 0, \
> + .intr_target_reg = 0, \
> + .mux_bit = -1, \
> + .pull_bit = 3, \
> + .drv_bit = 0, \
> + .oe_bit = -1, \
> + .in_bit = -1, \
> + .out_bit = 0, \
> + .intr_enable_bit = -1, \
> + .intr_status_bit = -1, \
> + .intr_target_bit = -1, \
> + .intr_raw_status_bit = -1, \
> + .intr_polarity_bit = -1, \
> + .intr_detection_bit = -1, \
> + .intr_detection_width = -1, \
> + }
Please add an empty line here.
> +static const struct pinctrl_pin_desc msm8998_pins[] = {
[..]
> +enum msm8998_functions {
[..]
> + msm_mux_phase_flag6,
> + msm_mux_phase_flag29,
> + msm_mux_phase_flag30,
> + msm_mux_phase_flag31,
With the Qualcomm pinctrl driver it's possible to specify configuration
in DT for a subset of pins of a group. So I think you should squash the
"phase_flag"s and "atest_char" into one group each.
> + msm_mux_pa_indicator,
> + msm_mux_ssbi1,
> + msm_mux_isense_dbg,
> + msm_mux_mss_lte,
> + msm_mux_gpio,
> + msm_mux_NA,
> +};
[..]
> +static const struct msm_pingroup msm8998_groups[] = {
> + PINGROUP(0, EAST, blsp_spi1, blsp_uart1_a, blsp_uim1_a, NA, NA, NA, NA,
> + NA, NA),
Please do ignore the 80-char "rule" and skip the line break on
these - it makes the table easier to read.
[..]
> +};
> +
> +static const struct msm_pinctrl_soc_data msm8998_pinctrl = {
> + .pins = msm8998_pins,
> + .npins = ARRAY_SIZE(msm8998_pins),
> + .functions = msm8998_functions,
> + .nfunctions = ARRAY_SIZE(msm8998_functions),
> + .groups = msm8998_groups,
> + .ngroups = ARRAY_SIZE(msm8998_groups),
> + .ngpios = 153,
ngpios is 150
> +};
> +
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 16:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1484237253.2492.43.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, Jan 12, 2017 at 10:07:33AM -0600, Benjamin Herrenschmidt wrote:
> On Thu, 2017-01-12 at 17:00 +0100, Greg KH wrote:
> > > How so ? I mean, access_ok followed by __get/__put_user is still a
> > > classic, what's wrong with it ?
> >
> > No "normal" driver should do that, just call copy_to/from_user and be
> > done with it. That way all of the proper locking and validation checks
> > like this are done correctly for you. Why would a driver ever call the
> > "raw" __get/__put_user functions?
>
> I supposed historically it was considered faster for some things :-)
>
> Not a huge deal, and yes it's probably cleaner, I was just wondering
> what was "racy" about access_ok() that I might have missed...
I think, you can change things after access_ok() happens, there used to
be bugs in that area a few years ago. I think we fixed them by moving
the offending drivers to use copy_*() instead.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 16:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1484235315.2492.41.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, Jan 12, 2017 at 09:35:15AM -0600, Benjamin Herrenschmidt wrote:
> On Thu, 2017-01-12 at 21:16 +1100, Cyril Bur wrote:
> > My aim here was to only have one process playing with the LPC mapping
> > registers at a time.
> >
> > > Again, use UIO, it will save you from yourself...
> > >
> >
> > Thank-you! This is the first I've heard of UIO and I'll investigate
> > furthur!
>
> Greg, I don't think UIO is the answer here either. Note, this isn't an
> exploit so much as root shooting itself in the foot as this driver
> should never be accessed by anybody but root, but see below.
>
> This is a BMC, ie, the system controller of a x86 or POWER based
> system.
>
> The LPC controller controls the LPC bus which is mastered by the "host"
> (ie. the x86 or PPC) and acts as a slave on the BMC side.
>
> It has a bunch of registers that need to be configured in more/less
> system specific ways by the BMC, but more so, it has a pair of
> registers that allow "mapping" of a region of the BMC physical address
> space into the host address space.
>
> This is by definition dangerous to configure since it gives you a
> window to any part of the BMC, kernel space, any IOs, etc... however it
> needs to be configured by a userspace daemon which communicates with
> the host via a mailbox in order to map either different portions of the
> system flash controller address space or reserved memory.
>
> So in fact it should be done by the kernel, not userspace.
>
> What Cyril needs to do to make it more secure is:
>
> - For random register accesses, white list what registers
> specifically are allowed (and if necessary filter values). These
> registers aren't dangerous from the BMC perspective and need to be set
> appropriately for the host to operate correctly.
>
> - For the mapping of the LPC FW space <-> BMC space, use ioctl's to
> explicit establish the mapping to a portion of the flash (and nowhere
> else) or one of the known reserved memory areas. IE, dont have
> userspace just pass raw physical addresses through, but tell the kernel
> driver what portion (offset/size) of what area (flash space or reserved
> memory region) to configure the HW window for.
Yes, something more needs to be documented here, as what was proposed
isn't acceptable at all.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Benjamin Herrenschmidt @ 2017-01-12 16:29 UTC (permalink / raw)
To: Cyril Bur, Greg KH
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1484235315.2492.41.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, 2017-01-12 at 09:35 -0600, Benjamin Herrenschmidt wrote:
> Greg, I don't think UIO is the answer here either. Note, this isn't an
> exploit so much as root shooting itself in the foot as this driver
> should never be accessed by anybody but root, but see below.
Reading back my previous email I realize that the lack of coffee
made my prose a lot less clear than I intended it to be :-)
I think some background is in order here, it will help whoever
reviews this and Cyril, skip to the bottom to how I think you should
articulate the driver.
So on a bunch of server systems, you have a system controller typically
known as a BMC controller all sort of things such as power to various
elements, sometimes fans, often the system flash, etc...
The Aspeed BMC family which is what is used on OpenPOWER machines and a
number of x86 as well is typically connected to the host via an LPC
bus. (among others).
This is an ISA bus on steroids, it has IO and MEM/FW cycles (different
address spaces, the subtle differences between MEM and FW can be
ignored for the sake of this discussion). It's generally used by the
BMC chip to provide the host with access to the system flash that
contains the BIOS or other host firmware (via MEM/FW space) along with
a number of SuperIO-style IOs (via IO space) such as UARTs, IPMI
controllers, etc....
On the BMC chip side, this is all configured via a bunch of registers
whose content is related to a given policy of what devices are exposed
how and where on a given system, which is system/vendor specific, so we
don't want to bolt that into the BMC kernel. So this started with a
need to provide something nicer than /dev/mem for user space to
configure these things. At that point, something like UIO could have
still made sense. However...
One important aspect of the configuration is how the MEM/FW space is
exposed to the host (ie, the x86 or POWER). Some registers in that
bridge can define a window remapping all or portion of the LPC MEM/FW
space to a portion of the BMC internal bus, with no specific limits
imposed in HW.
As you can see, this can be pretty nasty. So for this, I think it makes
sense to ensure that this window is configured by a kernel driver that
can apply some serious sanity checks on what it is configured to map.
In practice, user space wants to control this by flipping the mapping
between essentially two types of portions of the BMC address space:
- The flash space. This is a region of the BMC MMIO space that
more/less directly maps the system flash (at least for reads, writes
are somewhat more complicated).
- One (or more) reserved area(s) of the BMC physical memory.
The latter is needed for a number of things, such as avoiding letting
the host manipulate the innards of the BMC flash controller via some
evil backdoor, we want to do flash updates by routing the window to a
portion of memory (under control of a mailbox protocol via some
separate set of registers) which the host can use to write new data in
bulk and then request the BMC to flash it. There are other uses, such
as allowing the host to boot from an in-memory flash image rather than
the one in flash (very handy for continuous integration and test, the
BMC can just download new images), etc...
So I think the best approach here is:
- A pair of ioctls to read and write random registers in the
LPC bridge for all the "generally configuration gunk". These have a
filter to ensure that the registers controlling the above mapping
cannot be accessed that way.
- An ioctl to control the above mapping window. It takes as
arguments the location in LPC space, the window type (flash vs.
memory), for memory, maybe an ID (several windows to chose from), and
the offset& size in the latter. The driver can enforce that the windows
are one of the specially reserved areas of memory etc...
- An mmap function to map those reserved windows into userspace
so the daemon can communicate appropriately (only needed for the memory
windows, the flash space is accessed via the normal /dev/mtd drivers)
Greg, does that make sense ?
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Benjamin Herrenschmidt @ 2017-01-12 16:31 UTC (permalink / raw)
To: Greg KH
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <20170112162619.GB10283-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Thu, 2017-01-12 at 17:26 +0100, Greg KH wrote:
> I think, you can change things after access_ok() happens, there used to
> be bugs in that area a few years ago. I think we fixed them by moving
> the offending drivers to use copy_*() instead.
Ok, I'm surprised though, we still have a metric ton of code,
especially in filesystems, who do access_ok. Generally the idea here is
that the enforcement is done by the MMU normally via the permission in
the page tables. access_ok() is simply needed to make sure we access
the portion of the page tables representing user space, not kernel
space, and that is a pretty fixed dichotomy.
Anyway, this is academic, I agree that copy_to/from_... is nicer.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Re: [PATCH 4/5] ARM: dts: sunxi: add dtsi file for V3s SoC
From: Maxime Ripard @ 2017-01-12 16:52 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA, linux-kernel,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170111065638.uW1SQ7Kq-jDEamKawf7I0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
On Wed, Jan 11, 2017 at 11:56:32AM +0800, Icenowy Zheng wrote:
>
> 2017年1月11日 02:21于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Tue, Jan 03, 2017 at 11:16:28PM +0800, Icenowy Zheng wrote:
> > > + uart0_pins_a: uart0@0 {
> > > + pins = "PB8", "PB9";
> > > + function = "uart0";
> > > + bias-pull-up;
> >
> > Why do you need a pullup here?
>
> I think TX needs one, but RX do not need.
That's (at best) board specific. So it belongs in the DTS if it's
truely needed.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: core: helper function to detect slave mode
From: Andy Shevchenko @ 2017-01-12 17:01 UTC (permalink / raw)
To: Vladimir Zapolskiy, Andy Shevchenko
Cc: Luis Oliveira, Wolfram Sang, Rob Herring, Mark Rutland,
Jarkko Nikula, Mika Westerberg, linux-i2c, devicetree,
linux-kernel@vger.kernel.org, Ramiro.Oliveira, Joao Pinto,
CARLOS.PALMINHA
In-Reply-To: <3748130b-5321-12eb-ec75-e2637dd9fc54@mleia.com>
On Sat, 2017-01-07 at 03:24 +0200, Vladimir Zapolskiy wrote:
> On 01/07/2017 02:19 AM, Andy Shevchenko wrote:
> > On Sat, Jan 7, 2017 at 1:43 AM, Vladimir Zapolskiy <vz@mleia.com>
> > wrote:
> > > On 01/07/2017 12:45 AM, Andy Shevchenko wrote:
> > > > + }
> > > > > > + } else if (IS_BUILTIN(CONFIG_ACPI) &&
> > > > > > ACPI_HANDLE(dev)) {
> > > > > > + dev_dbg(dev, "ACPI slave is not supported
> > > > > > yet\n");
> > > > > > + }
> > > > >
> > > > > If so, then it might be better to drop else-if stub for now.
> > > >
> > > > Please, don't.
> > > >
> > >
> > > Why do you ask for this stub to be added?
> >
> > 1. Exactly the reason you asked above. Here is the code which has
> > built differently on different platforms. x86 usually is not using
> > CONFIG_OF, ARM doesn't ACPI (versus ARM64). Check GPIO library for
> > existing examples.
>
> From the context by the stub I mean dev_dbg() in
> i2c_slave_mode_detect()
> function, I don't see a connection to GPIO library, please clarify.
I agree that is not good proof for using IS_ENABLED/IS_BUILTIN macro.
> > 2. We might add that support later, but here is again, just no-op.
> >
> > So, what is your strong argument here against that?
>
> When the support is ready for ACPI case, you'll remove the added
> dev_dbg(), and I don't see a good point by adding it temporarily.
It would remind me to look at it at some point.
> What is wrong with the approach of adding the ACPI case handling
> branch when it is ready and remove any kind of stubs right now?
I will not object. Here is maintainer, let him speak.
> On ACPI platforms the function returns 'false' always, will the
> function work correctly (= corresponding to its description) as is?
Yes.
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH] ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB
From: codekipper-Re5JQEeQqe8AvxtiuMwx3w @ 2017-01-12 17:11 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Marcus Cooper
From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, HDMI, an IR
receiver, 1 LEDs and an optical S/PDIF connector.
Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 187 ++++++++++++++++++++++++++++++
2 files changed, 188 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 78a94b747059..75960b1468a4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -857,6 +857,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a83t-cubietruck-plus.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+ sun8i-h3-beelink-x2.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
new file mode 100644
index 000000000000..bc5aed52cb1d
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
@@ -0,0 +1,187 @@
+/*
+ * Copyright (C) 2017 Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Beelink X2";
+ compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
+
+ aliases {
+ serial0 = &uart0;
+ /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
+ ethernet1 = &rtl8189ftv;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_led_x2>;
+
+ pwr_led {
+ label = "beelink-x2:red:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
+ default-state = "on";
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sw_r_x2>;
+
+ sw4 {
+ label = "power";
+ linux,code = <BTN_0>;
+ gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_en_x2>;
+ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+
+ /*
+ * Explicitly define the sdio device, so that we can add an ethernet
+ * alias for it (which e.g. makes u-boot set a mac-address).
+ */
+ rtl8189ftv: sdio_wifi@1 {
+ reg = <1>;
+ };
+};
+
+&mmc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc2_8bit_pins>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <8>;
+ non-removable;
+ cap-mmc-hw-reset;
+ status = "okay";
+};
+
+&mmc2_8bit_pins {
+ /* Increase drive strength for DDR modes */
+ drive-strength = <40>;
+ /* eMMC is missing pull-ups */
+ bias-pull-up;
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&r_pio {
+ pwr_led_x2: led_pins@0 {
+ pins = "PL10";
+ function = "gpio_out";
+ };
+
+ sw_r_x2: key_pins@0 {
+ pins = "PL3";
+ function = "gpio_in";
+ };
+
+ wifi_en_x2: wifi_en_pin {
+ pins = "PL7";
+ function = "gpio_out";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>, <&uart1_rts_cts_pins>;
+ status = "okay";
+};
+
+&usbphy {
+ /* USB VBUS is on as long as VCC-IO is on */
+ status = "okay";
+};
--
2.11.0
^ permalink raw reply related
* Re: Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-12 17:13 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA, linux-kernel,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai
In-Reply-To: <20170111065524.tILSH8cS-V6dNpkQgAPs0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
Hi,
On Wed, Jan 11, 2017 at 11:55:16AM +0800, Icenowy Zheng wrote:
>
> 2017年1月11日 02:10于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> > > V3s has a similar but cut-down CCU to H3.
> > >
> > > Add support for it.
> > >
> > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >
> > It looks like there's nothing different but the clocks that you
> > register with the H3, please just use the H3 driver.
>
> USB gate part is different, and many things have gone.
As far as I can see, you're only adding a few clocks, and removing a
bunch. This is definitely something that can be dealt with by simply
registering a slightly different set of clocks, like we're doing on
sun5i.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] arm: sunxi: add support for V3s SoC
From: Maxime Ripard @ 2017-01-12 17:17 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, Stephen Boyd, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <2706391484163632-/w1NKm4lK9luio3avFS2gg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]
1;4601;0c
On Thu, Jan 12, 2017 at 03:40:32AM +0800, Icenowy Zheng wrote:
>
>
> 11.01.2017, 02:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > On Tue, Jan 03, 2017 at 11:16:25PM +0800, Icenowy Zheng wrote:
> >> Allwinner V3s is a low-end single-core Cortex-A7 SoC, with 64MB
> >> integrated DRAM, and several peripherals.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >> ---
> >> Documentation/arm/sunxi/README | 4 ++++
> >> arch/arm/mach-sunxi/sunxi.c | 1 +
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> >> index cd0243302bc1..91ec8f2055be 100644
> >> --- a/Documentation/arm/sunxi/README
> >> +++ b/Documentation/arm/sunxi/README
> >> @@ -67,6 +67,10 @@ SunXi family
> >> + Datasheet
> >> http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
> >>
> >> + - Allwinner V3s (sun8i)
> >> + + Datasheet
> >> + https://www.goprawn.com/forum/allwinner-cams/783-allwinner-v3s-soc-datasheet
> >> +
> >
> > Please don't put random links in there, but at least something that we
> > know will be there in a couple of weeks/monthes/years
>
> Is http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf acceptable?
It's much better, yes.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 4/5] powernv: Pass PSSCR value and mask to power9_idle_stop
From: Balbir Singh @ 2017-01-12 17:18 UTC (permalink / raw)
To: Gautham R. Shenoy
Cc: Stewart Smith, devicetree, Michael Neuling, linux-pm,
Shreyas B. Prabhu, Daniel Lezcano, Rafael J. Wysocki,
linux-kernel, Rob Herring, Paul Mackerras, Shilpasri G Bhat,
Oliver O'Halloran, mark.rutland, linuxppc-dev
In-Reply-To: <1484039224-5630-5-git-send-email-ego@linux.vnet.ibm.com>
On Tue, Jan 10, 2017 at 02:37:03PM +0530, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> The arch300_idle_stop method currently takes only the requested stop
power9_idle_stop (see subject :) and second paragraph)
> level as a parameter and picks up the rest of the PSSCR bits from a
> hand-coded macro. This is not a very flexible design, especially when
> the firmware has the capability to communicate the psscr value and the
> mask associated with a particular stop state via device tree.
>
> This patch modifies the power9_idle_stop API to take as parameters the
> PSSCR value and the PSSCR mask corresponding to the stop state that
> needs to be set. These PSSCR value and mask are respectively obtained
> by parsing the "ibm,cpu-idle-state-psscr" and
> "ibm,cpu-idle-state-psscr-mask" fields from the device tree.
>
> In addition to this, the patch adds support for handling stop states
> for which ESL and EC bits in the PSSCR are zero. As per the
> architecture, a wakeup from these stop states resumes execution from
> the subsequent instruction as opposed to waking up at the System
> Vector.
>
> The older firmware sets only the Requested Level (RL) field in the
> psscr and psscr-mask exposed in the device tree. For older firmware
> where psscr-mask=0xf, this patch will set the default sane values that
> the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
> TR). For the new firmware, the patch will validate that the invariants
> required by the ISA for the psscr values are maintained by the
> firmware.
>
> This skiboot patch that exports fully populated PSSCR values and the
> mask for all the stop states can be found here:
> https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html
>
> [Optimize the number of instructions before entering STOP with
> ESL=EC=0, validate the PSSCR values provided by the firimware
> maintains the invariants required as per the ISA suggested by Balbir
> Singh]
>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> ---
Acked-by: Balbir Singh <bsingharora@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-12 17:19 UTC (permalink / raw)
To: Icenowy Zheng
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linus Walleij,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, Stephen Boyd,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <2714901484163893-/w1NKm4lK9luio3avFS2gg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]
On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
>
>
> 12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
> > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> >> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> >>> V3s has a similar but cut-down CCU to H3.
> >>>
> >>> Add support for it.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >>
> >> It looks like there's nothing different but the clocks that you
> >> register with the H3, please just use the H3 driver.
> >
> > Nope.
> >
> > It has a different PLL (PLL_ISP) at different address, and some
> > different muxes.
>
> Forgot to mention the missing of PLL_DE and related misses.
Those are not conflicting, it's just a slightly different set of
clocks.
So there's really nothing undoable.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] drivers/misc: Add ASpeed LPC control driver
From: Greg KH @ 2017-01-12 17:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Cyril Bur, devicetree-u79uwXL29TY76Z2rM5mHXA,
jassisinghbrar-Re5JQEeQqe8AvxtiuMwx3w, arnd-r2nGTMty4D4,
joel-U3u1mxZcP9KHXe+LvDLADg, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, openbmc-uLR06cmDAlY/bJ5BZ2RsiQ,
andrew-zrmu5oMJ5Fs, xow-hpIqsD4AKlfQT0dZR+AlfA,
jk-mnsaURCQ41sdnm+yROfE0A
In-Reply-To: <1484238577.2492.45.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On Thu, Jan 12, 2017 at 10:29:37AM -0600, Benjamin Herrenschmidt wrote:
> So I think the best approach here is:
>
> - A pair of ioctls to read and write random registers in the
> LPC bridge for all the "generally configuration gunk". These have a
> filter to ensure that the registers controlling the above mapping
> cannot be accessed that way.
>
> - An ioctl to control the above mapping window. It takes as
> arguments the location in LPC space, the window type (flash vs.
> memory), for memory, maybe an ID (several windows to chose from), and
> the offset& size in the latter. The driver can enforce that the windows
> are one of the specially reserved areas of memory etc...
>
> - An mmap function to map those reserved windows into userspace
> so the daemon can communicate appropriately (only needed for the memory
> windows, the flash space is accessed via the normal /dev/mtd drivers)
>
> Greg, does that make sense ?
Yes, that makes a lot more sense to me. Thanks for writing it up,
hopefully it survives into the next driver submission, otherwise I'll
ask the same questions again due to not having a short-term memory at
all :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB
From: Maxime Ripard @ 2017-01-12 17:28 UTC (permalink / raw)
To: codekipper-Re5JQEeQqe8AvxtiuMwx3w
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170112171135.7822-1-codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 6403 bytes --]
Hi,
On Thu, Jan 12, 2017 at 06:11:35PM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
> SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, HDMI, an IR
> receiver, 1 LEDs and an optical S/PDIF connector.
>
> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 187 ++++++++++++++++++++++++++++++
> 2 files changed, 188 insertions(+)
> create mode 100644 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 78a94b747059..75960b1468a4 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -857,6 +857,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-a83t-cubietruck-plus.dtb \
> sun8i-h2-plus-orangepi-zero.dtb \
> sun8i-h3-bananapi-m2-plus.dtb \
> + sun8i-h3-beelink-x2.dtb \
> sun8i-h3-nanopi-m1.dtb \
> sun8i-h3-nanopi-neo.dtb \
> sun8i-h3-orangepi-2.dtb \
> diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> new file mode 100644
> index 000000000000..bc5aed52cb1d
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
> @@ -0,0 +1,187 @@
> +/*
> + * Copyright (C) 2017 Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun8i-h3.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + model = "Beelink X2";
> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
> +
> + aliases {
> + serial0 = &uart0;
> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> + ethernet1 = &rtl8189ftv;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_led_x2>;
Please drop all the pinctrl nodes for the GPIOs. They're useless, and
will be harmful when we'll switch to a stricter pinctrl driver.
> +
> + pwr_led {
> + label = "beelink-x2:red:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
> + default-state = "on";
> + };
> + };
> +
> + gpio_keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sw_r_x2>;
> +
> + sw4 {
> + label = "power";
> + linux,code = <BTN_0>;
Should that be BTN_0 then if the label is that one?
> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + wifi_pwrseq: wifi_pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_en_x2>;
> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ir {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_pins_a>;
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> + cd-inverted;
> + status = "okay";
> +};
> +
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins_a>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +
> + /*
> + * Explicitly define the sdio device, so that we can add an ethernet
> + * alias for it (which e.g. makes u-boot set a mac-address).
> + */
> + rtl8189ftv: sdio_wifi@1 {
> + reg = <1>;
> + };
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_8bit_pins>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <8>;
> + non-removable;
> + cap-mmc-hw-reset;
> + status = "okay";
> +};
> +
> +&mmc2_8bit_pins {
> + /* Increase drive strength for DDR modes */
> + drive-strength = <40>;
Have you actually tested that it was needed?
> + /* eMMC is missing pull-ups */
> + bias-pull-up;
This is already enabled in the DTSI.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Icenowy Zheng @ 2017-01-12 17:31 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-kernel, linux-sunxi,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai
2017年1月13日 01:19于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>
> On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
> >
> >
> > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
> > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
> > >> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> > >>> V3s has a similar but cut-down CCU to H3.
> > >>>
> > >>> Add support for it.
> > >>>
> > >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > >>
> > >> It looks like there's nothing different but the clocks that you
> > >> register with the H3, please just use the H3 driver.
> > >
> > > Nope.
> > >
> > > It has a different PLL (PLL_ISP) at different address, and some
> > > different muxes.
> >
> > Forgot to mention the missing of PLL_DE and related misses.
>
> Those are not conflicting, it's just a slightly different set of
> clocks.
If saying so, we can have only one ccu driver, and make every ccu register different set ;-)
V3s itself is a totally different SoC with H3.
The relationship of V3s and H3 can be farther than the relationship of A33 and H3😃
>
> So there's really nothing undoable.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] ARM: dts: sun8i-h3: Add dts for the Beelink X2 STB
From: Code Kipper @ 2017-01-12 17:39 UTC (permalink / raw)
To: Maxime Ripard; +Cc: linux-arm-kernel, devicetree, linux-sunxi
In-Reply-To: <20170112172813.cbwqfpjlprkxdzcp@lukather>
On 12 January 2017 at 18:28, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Thu, Jan 12, 2017 at 06:11:35PM +0100, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>> From: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>
>> The Beelink X2 is an STB based on the Allwinner H3 SoC with a uSD slot,
>> 2 USB ports( 1 * USB-2 Host, 1 USB OTG), a 10/100M ethernet port using the
>> SoC's integrated PHY, Wifi via a RTL8189ETV sdio wifi chip, HDMI, an IR
>> receiver, 1 LEDs and an optical S/PDIF connector.
>>
>> Signed-off-by: Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun8i-h3-beelink-x2.dts | 187 ++++++++++++++++++++++++++++++
>> 2 files changed, 188 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 78a94b747059..75960b1468a4 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -857,6 +857,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>> sun8i-a83t-cubietruck-plus.dtb \
>> sun8i-h2-plus-orangepi-zero.dtb \
>> sun8i-h3-bananapi-m2-plus.dtb \
>> + sun8i-h3-beelink-x2.dtb \
>> sun8i-h3-nanopi-m1.dtb \
>> sun8i-h3-nanopi-neo.dtb \
>> sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>> new file mode 100644
>> index 000000000000..bc5aed52cb1d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h3-beelink-x2.dts
>> @@ -0,0 +1,187 @@
>> +/*
>> + * Copyright (C) 2017 Marcus Cooper <codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "Beelink X2";
>> + compatible = "roofull,beelink-x2", "allwinner,sun8i-h3";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
>> + ethernet1 = &rtl8189ftv;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pwr_led_x2>;
>
> Please drop all the pinctrl nodes for the GPIOs. They're useless, and
> will be harmful when we'll switch to a stricter pinctrl driver.
>
ACK
>> +
>> + pwr_led {
>> + label = "beelink-x2:red:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */
>> + default-state = "on";
>> + };
>> + };
>> +
>> + gpio_keys {
>> + compatible = "gpio-keys";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&sw_r_x2>;
>> +
>> + sw4 {
>> + label = "power";
>> + linux,code = <BTN_0>;
>
> Should that be BTN_0 then if the label is that one?
>
ACK
>> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
>> + };
>> + };
>> +
>> + wifi_pwrseq: wifi_pwrseq {
>> + compatible = "mmc-pwrseq-simple";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wifi_en_x2>;
>> + reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>; /* PL7 */
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&ir {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&ir_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&mmc1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc1_pins_a>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + non-removable;
>> + status = "okay";
>> +
>> + /*
>> + * Explicitly define the sdio device, so that we can add an ethernet
>> + * alias for it (which e.g. makes u-boot set a mac-address).
>> + */
>> + rtl8189ftv: sdio_wifi@1 {
>> + reg = <1>;
>> + };
>> +};
>> +
>> +&mmc2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc2_8bit_pins>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <8>;
>> + non-removable;
>> + cap-mmc-hw-reset;
>> + status = "okay";
>> +};
>> +
>> +&mmc2_8bit_pins {
>> + /* Increase drive strength for DDR modes */
>> + drive-strength = <40>;
>
> Have you actually tested that it was needed?
>
I'll confess that I've rushed this one as I just wanted to verify my
spdif changes. I'll respin this,
BR,
CK
>> + /* eMMC is missing pull-ups */
>> + bias-pull-up;
>
> This is already enabled in the DTSI.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: sun8i: add OTG function to Lichee Pi Zero
From: Maxime Ripard @ 2017-01-12 17:39 UTC (permalink / raw)
To: Bin Liu, Icenowy Zheng, Chen-Yu Tsai, Kishon Vijay Abraham I,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20170112145014.GC16865@uda0271908>
[-- Attachment #1.1: Type: text/plain, Size: 3329 bytes --]
Hi Bin,
On Thu, Jan 12, 2017 at 08:50:14AM -0600, Bin Liu wrote:
> On Wed, Jan 11, 2017 at 10:06:38PM +0100, Maxime Ripard wrote:
> > On Wed, Jan 11, 2017 at 02:08:11PM -0600, Bin Liu wrote:
> > > On Thu, Jan 12, 2017 at 03:55:33AM +0800, Icenowy Zheng wrote:
> > > >
> > > >
> > > > 11.01.2017, 04:24, "Bin Liu" <b-liu@ti.com>:
> > > > > On Tue, Jan 03, 2017 at 11:25:34PM +0800, Icenowy Zheng wrote:
> > > > >> Lichee Pi Zero features a USB OTG port.
> > > > >>
> > > > >> Add support for it.
> > > > >>
> > > > >> Note: in order to use the Host mode, the board must be powered via the
> > > > >> +5V and GND pins.
> > > > >>
> > > > >> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> > > > >> ---
> > > > >> arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 10 ++++++++++
> > > > >> 1 file changed, 10 insertions(+)
> > > > >>
> > > > >> diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> index 0099affc6ce3..3d9168cbaeca 100644
> > > > >> --- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> +++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
> > > > >> @@ -71,3 +71,13 @@
> > > > >> pinctrl-names = "default";
> > > > >> status = "okay";
> > > > >> };
> > > > >> +
> > > > >> +&usb_otg {
> > > > >> + dr_mode = "otg";
> > > > >
> > > > > Why not set this default mode in dtsi instead?
> > > > >
> > > > > Regards,
> > > > > -Bin.
> > > >
> > > > There's possibly boards which do not have OTG functions.
> > >
> > > That is board specific.
> >
> > Exactly, and this is why it should be done in the board DT.
>
> I am just suggesting based on the common practice. If a .dtsi exists for
> a family, the .dtsi describes the device and common properties for all
> possible boards, and each board .dts adds or overrides its specific
> implementation. Kernel has many devices/boards done in this way - define
> the default dr_mode in .dtsi.
>
> In this case, I suggest to set the common dr_mode in .dtsi, then each
> board .dts only overrides it if the implementation is different.
>
> >
> > The controller in the Allwinner SoCs do not handle directly the ID pin
> > and VBUS, but rather rely on a GPIO to do so.
> >
> > So boards with OTG will need setup anyway, at least to tell which
> > GPIOs are used. There's no point in enforcing a default if it doesn't
> > work by default.
>
> Then define a default which supposes to work for most boards.
>
> Why I suggest this, is because defining a default dr_mode which works
> for most cases in dtsi could prevent a little surprise in MUSB function.
> If someone designs a new board but forgets to define dr_mode in the new
> board DT, the MUSB driver will default to org mode, which might not be
> intended.
The point is that there is no sensible default. Some boards don't have
an ID pin and no VBUS (peripheral), some don't have an ID pin but VBUS
(host), and some have an ID pin but no controllable VBUS, some have an
ID pin and a controllable VBUS, but we have no idea which GPIOs are
used.
There's no way we can have something that works on most cases.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Martin Blumenstingl @ 2017-01-12 17:40 UTC (permalink / raw)
To: Neil Armstrong, brian.kim
Cc: khilman, carlo, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, moon.linux
In-Reply-To: <1483689872-30389-1-git-send-email-narmstrong@baylibre.com>
Hi Neil,
(adding Brian Kim, one of the Hardkernel developers to this conversation)
On Fri, Jan 6, 2017 at 9:04 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> The current hardware is not able to run with all cores enabled at a
> cluster frequency superior at 1536MHz.
> But the currently shipped u-boot for the platform still reports an OPP
> table with possible DVFS frequency up to 2GHz, and will not change since
> the off-tree linux tree supports limiting the OPPs with a kernel parameter.
> A recent u-boot change reports the boot-time DVFS around 100MHz and
> the default performance cpufreq governor sets the maximum frequency.
> Previous version of u-boot reported to be already at the max OPP and
> left the OPP as is.
> Nevertheless, other governors like ondemand could setup the max frequency
> and make the system crash.
>
> This patch disables the DVFS clock and disables cpufreq.
I don't have any Odroid-C2 board, but having to live without cpufreq
sounds bad for the Odroid-C2 users.
What would we expect from a kernel perspective (maybe the Hardkernel
guys would adjust their u-boot instead of us adjusting to the behavior
of one specific device? one solution that I could think of involves
the "maxcpus" kernel parameter (see [0]), if this is not set u-boot
should report a max CPU frequency of 1536MHz (= max frequency for 4
active cores). Based on the "maxcpus" value additional frequencies can
be unlocked (this could be step-by-step if there are different
frequencies for one core/two cores/etc.). However, I'd like to hear
other opinions as well.
Regards,
Martin
[0] http://lxr.free-electrons.com/source/Documentation/kernel-parameters.txt?v=4.8#L2163
^ permalink raw reply
* Re: [PATCH 2/5] clk: sunxi-ng: add support for V3s CCU
From: Maxime Ripard @ 2017-01-12 17:41 UTC (permalink / raw)
To: Icenowy Zheng
Cc: linux-kernel, linux-sunxi,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA, Linus Walleij,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Chen-Yu Tsai
In-Reply-To: <20170112203149.VhtuR9dM-fU7thrOZ3Cs0PDqKvflMoHmW9unr2Ajn@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]
On Fri, Jan 13, 2017 at 01:31:41AM +0800, Icenowy Zheng wrote:
>
> 2017年1月13日 01:19于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> >
> > On Thu, Jan 12, 2017 at 03:44:53AM +0800, Icenowy Zheng wrote:
> > >
> > >
> > > 12.01.2017, 03:40, "Icenowy Zheng" <icenowy-ymACFijhrKM@public.gmane.org>:
> > > > 11.01.2017, 02:10, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTGGXanvQGlWp@public.gmane.orgm>:
> > > >> On Tue, Jan 03, 2017 at 11:16:26PM +0800, Icenowy Zheng wrote:
> > > >>> V3s has a similar but cut-down CCU to H3.
> > > >>>
> > > >>> Add support for it.
> > > >>>
> > > >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > > >>
> > > >> It looks like there's nothing different but the clocks that you
> > > >> register with the H3, please just use the H3 driver.
> > > >
> > > > Nope.
> > > >
> > > > It has a different PLL (PLL_ISP) at different address, and some
> > > > different muxes.
> > >
> > > Forgot to mention the missing of PLL_DE and related misses.
> >
> > Those are not conflicting, it's just a slightly different set of
> > clocks.
>
> If saying so, we can have only one ccu driver, and make every ccu
> register different set ;-)
>
> V3s itself is a totally different SoC with H3.
>
> The relationship of V3s and H3 can be farther than the relationship
> of A33 and H3😃
A33 and H3 are an entirely different story. The H3 and A33 have
conflicting clocks (ie same clocks with different parameters). This is
not your case.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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