Chris,
On Thu, Jun 27, 2013 at 9:44 AM, Chris Ball wrote:
> This hunk breaks the build for me, because err_setup_bus and ret are
> used in the error path of the call to mmc_add_host() in this function.
>
> I'll push a version that leaves those in. Let me know if you think
> something strange is
Jaehoon,
On Mon, Jun 17, 2013 at 9:51 PM, Jaehoon Chung wrote:
> Hi Doug,
>
> I have one question for using .
> I found the fixed-rate-clocks feature.
> If we want to set , then can we use the fixed-rate-clocks?
> i'm not sure how use the fixed-rate-clocks. but it seems to set fixed-rate
> value
Tomasz,
On Fri, Jun 7, 2013 at 10:42 AM, Tomasz Figa wrote:
> A question just out of curiousity: Is it really correct to have one vmmc
> regulator for the whole device, instead of one regulator per slot?
>
> This might be something obvious, but I don't know any details about
> dw_mmc, so sorry if
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson
Acked-by: Jaehoon Chung
---
Changes in v2:
- Added example as per Ja
.
We only specify one regulator for the whole device and other parts of
the code (like suspend/resume) assume that the regulator has only been
enabled once.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Avoid hackery to detect regulators that will never show up.
- Move regulator out of slot
Tomasz / Mark,
On Fri, Jun 7, 2013 at 3:30 AM, Tomasz Figa wrote:
> On Friday 07 of June 2013 11:24:04 Mark Brown wrote:
>> On Fri, Jun 07, 2013 at 12:19:58PM +0200, Tomasz Figa wrote:
>> > This interesting case makes me think that regulator core should
>> > differentiate between regulator lookup
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson
---
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt| 13 +
dr
er_ dw_mmc.
Fix this limitation by adding the ability to make vmmc required. If a
vmmc-supply is specified in the device tree we'll assume that vmmc is
required.
Signed-off-by: Doug Anderson
---
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt | 3 +++
drivers/mm
Padmavathi,
On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna wrote:
> This patch updates the samsung i2s documentation for pinmux and
> clock entries.
>
> Signed-off-by: Padmavathi Venna
> ---
> .../devicetree/bindings/sound/samsung-i2s.txt | 40 ++-
> 1 files changed, 13
Padmavathi,
On Tue, Jun 4, 2013 at 5:28 AM, Padmavathi Venna wrote:
> @@ -471,6 +477,8 @@
> dmas = <&pdma1 12
> &pdma1 11>;
> dma-names = "tx", "rx";
> + clocks = <&clock 307>;
> + clock-names = "iis";
...actuall
still like to see a separate patch documenting these clocks in
"Documentation/devicetree/bindings/sound/samsung-i2s.txt". ...but
what's here looks good, thanks!
Reviewed-by: Doug Anderson
___
devicetree-discuss mailing list
devicetr
Sylwester Nawrocki
> ---
> arch/arm/boot/dts/exynos5250.dtsi |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Responded on patch set 4 already, but this is the same. I'm happy with this.
Reviewed-by: Doug Anderson
___
exynos-audss.c | 133
>
> include/dt-bindings/clk/exynos-audss-clk.h | 25
> 4 files changed, 223 insertions(+), 0 deletions(-)
Thanks for fixing up my nits. This looks good to me.
Reviewed-by: Doug Anderson
_
Padma,
On Mon, Jun 3, 2013 at 9:25 PM, Padma Venkat wrote:
> Hi Doug,
>
> On Tue, Jun 4, 2013 at 1:43 AM, Doug Anderson wrote:
>> Padmavathi,
>>
>> On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna
>> wrote:
>>> Audio subsystem introduced in s5
Andrew,
On Mon, Jun 3, 2013 at 4:46 PM, Andrew Bresticker wrote:
>> I think this is supposed to be "xxti" which might or might not be
>> "fin_pll". In the exynos4 code these are two different clocks that
>> are chosen by OM[0]. I'd bet that 99% of the time they are the same,
>> but it seems bet
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna wrote:
> + clocks = <&clock_audss EXYNOS_I2S_BUS>,
> + <&clock_audss EXYNOS_I2S_BUS>,
> + <&clock_audss EXYNOS_SCLK_I2S>,
> + <&clock_audss EXYNOS_MOUT_AUD
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna wrote:
> Audio subsystem introduced in s5pv210 and exynos platforms
> which has a internal clock controller. This patch adds a node
> for the same on exynos5250.
>
> Signed-off-by: Padmavathi Venna
> Reviewed-by: Sylwester Nawrocki
>
Padmavathi,
On Sun, Jun 2, 2013 at 10:19 PM, Padmavathi Venna wrote:
> +static unsigned long reg_save[][2] = {
> + {ASS_CLK_SRC, 0},
> + {ASS_CLK_DIV, 0},
> + {ASS_CLK_GATE, 0},
> +};
> +
> +/* list of all parent clock list */
> +static const char *mout_audss_p[] = { "fin_pll
Guenter,
On Tue, Apr 16, 2013 at 9:45 AM, Guenter Roeck wrote:
> On Tue, Apr 16, 2013 at 09:29:00AM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
&
ed on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
<https://patchwork.kernel.org/patch/1877311/> for some history.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Wolfram / Guenter / Stephen,
Thanks for your reviews. New version on its way...
On Tue, Apr 16, 2013 at 2:36 AM, Wolfram Sang wrote:
> "uses GPIO lines and a challange & response mechanism" or something like
> that. There might be other GPIO based arbitrations in the future (though
> I hope the
From: Thomas Abraham
With device core now able to setup the default pin configuration,
the pin configuration code based on the deprecated Samsung specific
gpio bindings is removed.
Signed-off-by: Thomas Abraham
Signed-off-by: Doug Anderson
Acked-by: Linus Walleij
Reviewed-by: Doug Anderson
ed on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
<https://patchwork.kernel.org/patch/1877311/> for some history.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
ed on code that Simon Glass added to the i2c-s3c2410
driver in the Chrome OS kernel 3.4 tree. The current incarnation as a
mux driver is as suggested by Grant Likely. See
<https://patchwork.kernel.org/patch/1877311/> for some history.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Wolfram,
Thanks for your review!
On Mon, Apr 8, 2013 at 3:26 AM, Wolfram Sang wrote:
> I'd like to have the bindings more generic. They should allow for n
> possible masters IMO. It doesn't need to be implemented right now, but
> it should be possible to add that later.
Done. Left code as onl
Wolfram,
On Fri, Mar 29, 2013 at 4:58 AM, Wolfram Sang wrote:
> I can't recall the reason standard I2C bus arbitration is not working
> and why this is needed. I need the feeling this is a solution and not a
> workaround. I mean driver bugs can be fixed and I am unsure if it is a
> good idea to o
Hi,
On Wed, Mar 27, 2013 at 11:40 AM, Lars-Peter Clausen wrote:
> On 03/27/2013 07:35 PM, Naveen Krishna Ch wrote:
>> On 13 March 2013 13:39, Doug Anderson wrote:
>>> The exynos ADC won't work without a regulator called "vdd" and a clock
>>> called &qu
Naveen,
On Wed, Mar 27, 2013 at 11:37 AM, Naveen Krishna Ch
wrote:
> On 13 March 2013 13:40, Doug Anderson wrote:
>> Without this change the exynos adc controller needed to have its phy
>> enabled in some out-of-driver C code. Add support for specifying the
>> phy enable r
Wolfram,
On Wed, Mar 13, 2013 at 9:36 AM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering. This i2c-arbitrator-cros-ec driver could also
>
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Fixed embarrassing typo adc=>usb. Thanks Jingoo!
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
1 f
The exynox4210-ehci and exynos4210-ohci nodes need a clock specified
using the common clock framework. Document it.
Signed-off-by: Doug Anderson
---
Documentation/devicetree/bindings/usb/exynos-usb.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree
p1_input
/sys/class/hwmon/hwmon0/device/temp1_input:37890
/sys/class/hwmon/hwmon1/device/temp1_input:38393
/sys/class/hwmon/hwmon2/device/temp1_input:37148
/sys/class/hwmon/hwmon3/device/temp1_input:38059
Tested-by: Doug Anderson
___
devicetree-discuss m
The exynos ADC won't work without a regulator called "vdd" and a clock
called "adc". Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson
---
Changes in v2: None
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8
1 f
exynos adc driver under iio framwork
298489f iio:common: Use spi_sync_transfer() in STMicroelectronics ...
1d9a4cb IIO ADC support for AD7923
9a282b0 iio: Add OF support
3d277fc3 staging:iio: Remove adt7410 driver
Changes in v2:
- Match 'uV' -> 'uv' change in Naveen
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson
---
Changes in v2: None
.../devicetree/bindings/arm/samsung/exynos-adc.txt
Stephen,
On Wed, Mar 13, 2013 at 9:53 AM, Stephen Warren wrote:
>> Changes in v4: None
>
> Isn't this 'PATCH V3 REPOST' then?
In this case part 2 in the patch series changes but not parts 1 and 3.
I could have just reposted part 2 with a higher version, but that
makes it a little harder to piec
ry.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi
Reviewed-by: Stephen Warren
Tested-by: Naveen Krishna Chatradhi
---
Changes in v4: None
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
changing init order.
- Do
Hi,
On Tue, Mar 12, 2013 at 6:45 AM, Guenter Roeck wrote:
> On Tue, Mar 12, 2013 at 02:09:26PM +0530, Naveen Krishna Chatradhi wrote:
>> This patch adds DT support to NTC driver to parse the
>> platform data.
>>
>> Also adds the support to work as an iio device.
>>
>> During the probe ntc driver
The exynos ADC won't work without a regulator called "vdd" and a clock
called "adc". Document this fact in the device tree bindings.
Signed-off-by: Doug Anderson
---
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt | 8
1 file changed, 8 in
.plus Naveen's recent ADC cleanup and NTC thermistor patch.
Doug Anderson (4):
iio: adc: Document the regulator/clocks for exynos-adc
iio: adc: Add dt support for turning on the phy in exynos-adc
ARM: dts: Add adc to exynos5250 device tree file
ARM: dts: Add adc and thermistors for exyno
Without this change the exynos adc controller needed to have its phy
enabled in some out-of-driver C code. Add support for specifying the
phy enable register by listing it in the reg list.
Signed-off-by: Doug Anderson
---
.../devicetree/bindings/arm/samsung/exynos-adc.txt | 4
Naveen,
On Sun, Mar 10, 2013 at 7:09 PM, Naveen Krishna Chatradhi
wrote:
> @@ -317,7 +346,7 @@ static int ntc_thermistor_get_ohm(struct ntc_data *data)
> return data->pdata->read_ohm(data->pdev);
>
> if (data->pdata->read_uV) {
> - read_uV = data->pdata->read
ration
2224801 New ASoC: samsung: let device core setup the default
pin configuration
2224851 New mmc: dwmmc: let device core setup the default pin
configuration
2225141 New [1/2] ARM: dts: add pin state information in
client nodes for Exynos4 platforms
2225151 New
Wolfram,
On Fri, Feb 15, 2013 at 11:46 AM, Doug Anderson wrote:
> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
> that the Embedded Controller (EC) on the ARM Chromebook expects to use
> for bus multimastering. This i2c-arbitrator-cros-ec driver could also
>
Mark / Stephen,
On Fri, Feb 15, 2013 at 2:24 AM, Mark Brown
wrote:
> You shouldn't have dummy regulators enabled at all, that'll break a
> bunch of stuff including dependency resolution. They're a crutch to
> help get things booting not something you should be using in production.
> If they're n
ry.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi
---
Changes in v3:
- Handle of_find_i2c_adapter_by_node() failure more properly by
changing init order.
- Don't warn on -EPROBE_DEFER from calls that could return it.
- Move to module_platfo
On Fri, Feb 15, 2013 at 9:44 AM, Mark Brown
wrote:
> On Fri, Feb 15, 2013 at 10:38:29AM -0700, Stephen Warren wrote:
>
>> Either way though, I believe that upstream, no driver should be relying
>> on specific initcall levels in order to get dependencies/initialization
>> ordering correct.
>
> Righ
Stephen,
New version will come shortly with fixes below...
On Fri, Feb 15, 2013 at 8:39 AM, Stephen Warren wrote:
> On 02/14/2013 05:21 PM, Doug Anderson wrote:
>> The i2c-arbitrator-cros-ec driver implements the arbitration scheme
>> that the Embedded Controller (EC) on the
Stephen,
On Thu, Feb 14, 2013 at 4:16 PM, Stephen Warren wrote:
>> We can avoid that logic with has_full_constraints. That will be some
>> work to get done but also should be done at some point in time. Once
>> we use has_full_constraints we'll get ERR_PTR(-EPROBE_DEFER);
>
> That flag is norma
ry.
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Signed-off-by: Naveen Krishna Chatradhi
---
Changes in v2:
- Renamed to i2c-arbitrator-cros-ec.
- Documented "microsecond" properties as optional; removed
"bus-arbitration" prefix since it was just extra wordy.
-
Stephen,
On Thu, Feb 14, 2013 at 3:35 PM, Stephen Warren wrote:
>> [1.51] platform-lcd supply lcd_vdd not found, using dummy regulator
>
> What prints that? I assume that's some error-handling logic in the
> platform-lcd driver. It's probably not detecting an -EPROBE_DEFFERED
> return fro
On Wed, Feb 13, 2013 at 4:54 PM, Doug Anderson wrote:
>>>> You should be able to replace all that with:
>>>>
>>>> module_platform_driver(&i2c_arbitrator_driver);
>>>
>>> Sigh. Yeah, I had that. ...but it ends up getting initted
>>&
Linus,
On Thu, Feb 14, 2013 at 2:01 AM, Linus Walleij wrote:
> On Thu, Feb 14, 2013 at 1:41 AM, Stephen Warren wrote:
>> On 02/13/2013 05:34 PM, Doug Anderson wrote:
>
>>> A little torn here. It adds a bunch of complexity to the code to
>>> handle this
Stephen,
On Wed, Feb 13, 2013 at 4:41 PM, Stephen Warren wrote:
>> OK, going to go with i2c-arbitrator-cros-ec. Hopefully that sounds OK.
>
> That seems fine. The mechanism seems potentially a little more generic
> than just for cros-ec though, but I guess there's no harm naming it
> after the f
Stephen,
Thank you for the review. Comments below (including changes I have
done locally). I probably won't have time to test / repost until
tomorrow.
On Wed, Feb 13, 2013 at 1:02 PM, Stephen Warren wrote:
> On 02/13/2013 11:02 AM, Doug Anderson wrote:
>> The i2c-arbitrator dri
bitrator_remove,
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "i2c-arbitrator",
+ .of_match_table = of_match_ptr(i2c_arbitrator_of_match),
+ },
+};
+
+static int __init i2c_arbitrator_init(void)
+{
+ return platform_driver_register(
Vivek,
On Mon, Jan 14, 2013 at 12:06 AM, Vivek Gautam
wrote:
>> Is it fine if we don't use macro for SHIFT, earlier code also doesn't use it.
>> Can we just do like this ..
>> #define HOST_CTRL0_FSEL_MASK (0x7 << 16)
>> #define HOST_CTRL0_FSEL_CLKSEL_50M(0x7 <<
Vivek,
Sorry for being so absent from these reviews. I'll try to look over a
few patches today, but please don't hold up anything on account of my
reviews. I'm definitely a bit of an interested bystander in USB land.
;)
In general things look pretty good here. :) One last comment below...
O
Vivek,
On Fri, Jan 11, 2013 at 4:40 AM, Vivek Gautam wrote:
>>> +#define HOST_CTRL0_REFCLKSEL_MASK (0x3)
>>> +#define HOST_CTRL0_REFCLKSEL_XTAL (0x0 << 19)
>>> +#define HOST_CTRL0_REFCLKSEL_EXTL (0x1 << 19)
>>> +#define HOST_CTRL0_REFCLKSEL_CLKCORE
l in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson
Acked-by: Seungw
Hi,
A followup as I did more investigation here...
On Thu, Jan 10, 2013 at 3:23 PM, Doug Anderson wrote:
> Olof,
>
> Thanks for your comments.
>
> On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson wrote:
>>
>> The previous code used the controller-common quirk field
Olof,
Thanks for your comments.
On Thu, Jan 10, 2013 at 3:01 PM, Olof Johansson wrote:
>
> The previous code used the controller-common quirk field to set a
> per-controller DW_MCI_QUIRK_NO_WRITE_PROTECT. Is there really need to
> do this per-slot? And if so, please explain in the commit message
l in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson
Acked-by: Seu
Vivek,
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam
wrote:
> Hi all,
>
>
> On Wed, Dec 19, 2012 at 7:20 PM, Vivek Gautam
> wrote:
>> CC: Doug Anderson
>>
>>
>> On Sat, Dec 15, 2012 at 12:53 PM, Grant Likely
>> wrote:
>>> On Thu
mpatible strings for the device
>>>> usb: dwc3-exynos: Fix compatible strings for the device
>>>
>>> for both patches:
>>> Acked-by: Grant Likely
>>>
>
> Any more thought about this patch-set?
> Or does this change seems fine?
These two changes look good to me. For both of them:
Reviewed-by: Doug Anderson
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Vivek,
Nothing really serious below and things look good to me, but figured
I'd put a few nits in (sorry!).
On Fri, Dec 21, 2012 at 12:16 AM, Vivek Gautam wrote:
> diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
> b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
On Wed, Dec 19, 2012 at 10:37 PM, Vivek Gautam
wrote:
>
> On Thu, Dec 20, 2012 at 5:00 AM, Doug Anderson wrote:
>>
>> On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam
>> wrote:
>>> +static void s5p_ehci_phy_enable(struct s5p_ehci_hcd *s5p_ehci)
>>> +
Vivek,
On Wed, Dec 19, 2012 at 9:51 PM, Vivek Gautam wrote:
> Hi Doug,
>
>
> On Thu, Dec 20, 2012 at 3:18 AM, Doug Anderson wrote:
>> Vivek,
>>
>> Since you're changing the name, I would have expected to see a removal
>> of the old enum type in thi
Chris,
On Fri, Nov 30, 2012 at 3:57 AM, Seungwon Jeon wrote:
> Doug, Thanks to work.
> Looks good to me with other patches.
>
> Acked-by: Seungwon Jeon
Does this series look reasonable to you? I can check back later when
things are less hectic, but I wanted to make sure this wasn't
forgotten.
Vivek,
Again, not a high-level review, but...
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam wrote:
> Adding the phy driver to ehci-s5p. Keeping the platform data
> for continuing the smooth operation for boards which still uses it
>
> Signed-off-by: Vivek Gautam
> Acked-by: Jingoo Han
> ---
>
Vivek,
I don't really have a good 1 foot view about how all of the USB
bits fit together, but a few detail-oriented comments below.
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam wrote:
> This patch adds host phy support to samsung-usbphy.c and
> further adds support for samsung's exynos5250
Vivek,
On Tue, Dec 18, 2012 at 6:43 AM, Vivek Gautam wrote:
> Updating the names of usb-phy types to more generic names:
> USB_PHY_TYPE_DEIVCE & USB_PHY_TYPE_HOST; and further update
> its dependencies.
Since you're changing the name, I would have expected to see a removal
of the old enum type i
l in needing to specify "disable-wp"
because the lack of a "wp-gpios" property means to use the special
purpose write protect line. On some other mmc devices the lack of
"wp-gpios" means that write protect should be disabled.
Signed-off-by: Doug Anderson
---
Changes in v
ng
@data is left unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or "" if that's not defined)
Signed-off-by: Doug Anderson
CC: devicetree-discuss@lists.ozlabs.org
CC: Grant Likely
CC: Benjamin Herrenschmidt
CC: Rob Herring
ng
@data is left unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or "" if that's not defined)
Signed-off-by: Doug Anderson
CC: devicetree-discuss@lists.ozlabs.org
CC: Grant Likely
CC: Benjamin Herrenschmidt
CC: Rob Herring
--
Ben,
Thank you for the review! See below for a question...
On Tue, Jan 10, 2012 at 9:03 PM, Benjamin Herrenschmidt
wrote:
>> > The new logic is now documented in of_fdt.h and is copied here for
>> > reference:
>> >
>> > - CONFIG_CMDLINE_FORCE=true
>> > CONFIG_CMDLINE
>> > - CONFIG_CMDLINE_E
ng
@data is left unchanged
- CMDLINE_FROM_BOOTLOADER=true, dt bootargs=empty, @data is empty string
CONFIG_CMDLINE (or "" if that's not defined)
Signed-off-by: Doug Anderson
CC: devicetree-disc...@lists-ozlabs.org
CC: Grant Likely
CC: Benjamin Herr
I know this is a long-dead thread, but I was a little curious about
the motivation here.
I'm looking at trying to support CONFIG_CMDLINE_EXTEND (an ARM
Kconfig) in this function and don't know in which cases I should look
at the CONFIG_CMDLINE and in which cases I should use whatever
happened to b
78 matches
Mail list logo
