Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård <m...@mansr.com> wrote:
>> Andy Shevchenko <andy.shevche...@gmail.com> writes:
>>
>>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <li...@roeck-us.
Andy Shevchenko writes:
> On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck wrote:
>>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>>
>>
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <li...@roeck-us.net> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <m...@mansr.com&g
Andy Shevchenko writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård wrote:
>>>
>>>> Not very surprising either. The number
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <li...@roeck-us.net> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <m...@mansr.com&g
Andy Shevchenko writes:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård wrote:
>>>
>>>> Not very surprising either. The number
object is typically not warned
about since the purpose of the call might be to initialise it in the
first place. Now the second argument of sigaction() is a pointer to
const, so the compiler should be able to see that this isn't the case.
Maybe it's not warning because some fields in the struct are initialised
and the function, as far as the compiler knows, might only be accessing
those. (There's certainly code out there using that pattern.) If this
is the case here, a flag to warn unless the object is fully initialised
would be useful to catch bugs like this.
--
Måns Rullgård
e of the call might be to initialise it in the
first place. Now the second argument of sigaction() is a pointer to
const, so the compiler should be able to see that this isn't the case.
Maybe it's not warning because some fields in the struct are initialised
and the function, as far as the compiler knows, might only be accessing
those. (There's certainly code out there using that pattern.) If this
is the case here, a flag to warn unless the object is fully initialised
would be useful to catch bugs like this.
--
Måns Rullgård
were addressed.
Gerrit has some merits, but for seasoned developers it's largely a
nuisance. It's probably good at keeping junior/undisciplined developers
from doing too much damage by strictly enforcing a cumbersome process.
--
Måns Rullgård
Sebastian Frias writes:
> On 02/08/2016 03:11 PM, Mason wrote:
>> On 08/02/2016 14:37, Måns Rullgård wrote:
>>
>>> Sebastian Frias wrote:
>>>
>>>> By the way, I know some people like the command line, email, etc. but
>>>> the
Sebastian Frias writes:
> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>> Sebastian Frias writes:
>>>>
>>>>> On 02/05/2016 03:34 PM, Måns Rullgård w
iv->phy_node = of_node_get(pdev->dev.of_node);
> + }
> +
> + if (!priv->phy_node)
> + priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> + "phy-handle", 0);
> +
> if (!priv->phy_node) {
> dev_err(>dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
>
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/08/2016 03:11 PM, Mason wrote:
>> On 08/02/2016 14:37, Måns Rullgård wrote:
>>
>>> Sebastian Frias wrote:
>>>
>>>> By the way, I know some people like the command line, email, etc. but
>>
}
> + priv->phy_node = of_node_get(pdev->dev.of_node);
> + }
> +
> + if (!priv->phy_node)
> + priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> + "phy-handle", 0);
> +
> if (!priv->phy_node) {
> dev_err(>dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
>
--
Måns Rullgård
he inlined comments were addressed.
Gerrit has some merits, but for seasoned developers it's largely a
nuisance. It's probably good at keeping junior/undisciplined developers
from doing too much damage by strictly enforcing a cumbersome process.
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 04:26 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <s...@laposte.net> writes:
Guenter Roeck writes:
> On 02/06/2016 06:01 AM, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt writes:
>>
>>>>> Example for avr32:defconfig:
>>>>>
>>>>> fs/built-in.o: In function `anon_inode_getfile':
>>>>> (.t
estion is if the avr32 kernel still supported, or if I should
>>>just stop trying to build test it. Any thoughts ?
>>
>> I have already stopped building it.
>
> I build the kernel and try to fix small issues here and there.
Even when it builds, it often doesn't work since non-DT support has
bitrotted in many drivers.
--
Måns Rullgård
Guenter Roeck <li...@roeck-us.net> writes:
> On 02/06/2016 06:01 AM, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt <egtv...@samfundet.no> writes:
>>
>>>>> Example for avr32:defconfig:
>>>>>
>>>>> fs/built-in.o: In fu
>>>Another question is if the avr32 kernel still supported, or if I should
>>>just stop trying to build test it. Any thoughts ?
>>
>> I have already stopped building it.
>
> I build the kernel and try to fix small issues here and there.
Even when it builds, it often doesn't work since non-DT support has
bitrotted in many drivers.
--
Måns Rullgård
Andy Shevchenko writes:
> On Fri, Feb 5, 2016 at 3:39 PM, Måns Rullgård wrote:
>>> + if (ret < 0) {
>>> + dev_err(>dev, "broken fixed-link
>>> specification\n");
>>
>> Line is longe
Sebastian Frias writes:
> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>> Sebastian Frias writes:
>>>>
>>>>> Signed-off-by: Sebastian Frias
>&
Sebastian Frias writes:
> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> Signed-off-by: Sebastian Frias
>>
>> Please change the subject to something like "net: ethernet: nb8800:
>> support fixed-link DT node&quo
of_node);
> + }
> +
> + if (!priv->phy_node)
> + priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> + "phy-handle", 0);
> +
> if (!priv->phy_node) {
> dev_err(>dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
--
Måns Rullgård
Sebastian Frias writes:
> On 02/05/2016 02:58 PM, Måns Rullgård wrote:
>> Sebastian Frias writes:
>>
>>> Signed-off-by: Sebastian Frias
>>> ---
>>> drivers/net/ethernet/aurora/nb8800.c | 15 ---
>>> 1 file changed, 12 inserti
goto err_free_bus;
}
priv->phy_node = of_node_get(pdev->dev.of_node);
}
if (!priv->phy_node)
priv->phy_node = of_parse_phandle(pdev->dev.of_node,
"phy-handle", 0);
if (!priv->phy_node) {
dev_err(>dev, "no PHY specified\n");
ret = -ENODEV;
goto err_free_bus;
}
--
Måns Rullgård
Mark Brown writes:
> On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote:
>> Mark Brown writes:
>
>> > Please remember to CC the maintainers for the driver when sending
>> > patches.
>
>> I CCd everybody scripts/get_maintainers.pl sugge
ecified\n");
> + ret = -ENODEV;
> + goto err_free_bus;
> + }
> }
>
> priv->mii_bus = bus;
> --
> 2.1.4
>
--
Måns Rullgård
How am I supposed
to know who the maintainers are if they're not listed in MAINTAINERS?
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 04:08 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>>>> Sebastian Frias <s...@laposte.net> writes:
>&
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 03:34 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> Signed-off-by: Sebastian Frias <s...@laposte.net>
>>
>> Please change the subject to something like
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Fri, Feb 5, 2016 at 3:39 PM, Måns Rullgård <m...@mansr.com> wrote:
>>> + if (ret < 0) {
>>> + dev_err(>dev, "broken fixed-link
>>>
"phy-handle", 0);
if (!priv->phy_node) {
dev_err(>dev, "no PHY specified\n");
ret = -ENODEV;
goto err_free_bus;
}
--
Måns Rullgård
Sebastian Frias <s...@laposte.net> writes:
> On 02/05/2016 02:58 PM, Måns Rullgård wrote:
>> Sebastian Frias <s...@laposte.net> writes:
>>
>>> Signed-off-by: Sebastian Frias <s...@laposte.net>
>>> ---
>>> drivers/net/ethernet/a
ainers.pl suggested. How am I supposed
to know who the maintainers are if they're not listed in MAINTAINERS?
--
Måns Rullgård
dev_err(>dev, "no PHY specified\n");
> + ret = -ENODEV;
> + goto err_free_bus;
> + }
> }
>
> priv->mii_bus = bus;
> --
> 2.1.4
>
--
Måns Rullgård
Mark Brown <broo...@kernel.org> writes:
> On Fri, Feb 05, 2016 at 01:23:20PM +0000, Måns Rullgård wrote:
>> Mark Brown <broo...@kernel.org> writes:
>
>> > Please remember to CC the maintainers for the driver when sending
>> > patches.
>
>> I
de = of_node_get(pdev->dev.of_node);
> + }
> +
> + if (!priv->phy_node)
> + priv->phy_node = of_parse_phandle(pdev->dev.of_node,
> + "phy-handle", 0);
> +
> if (!priv->phy_node) {
> dev_err(>dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
--
Måns Rullgård
Ralf Baechle writes:
> On Tue, Feb 02, 2016 at 02:54:06PM +0000, Måns Rullgård wrote:
>
>> We don't really have much choice given the reality of existing hardware.
>
> No, of course not - but I want us discourage new weakly ordered
> platforms as much as possible.
Where
an be very hard to debug.
>
> One of the problems I've experienced is that Linux does support liberal
> memory ordering, even as extreme as the Alpha.
We don't really have much choice given the reality of existing hardware.
--
Måns Rullgård
ing and the resulting bugs can be very hard to debug.
>
> One of the problems I've experienced is that Linux does support liberal
> memory ordering, even as extreme as the Alpha.
We don't really have much choice given the reality of existing hardware.
--
Måns Rullgård
Ralf Baechle <r...@linux-mips.org> writes:
> On Tue, Feb 02, 2016 at 02:54:06PM +0000, Måns Rullgård wrote:
>
>> We don't really have much choice given the reality of existing hardware.
>
> No, of course not - but I want us discourage new weakly ordered
> platforms as
; @@ -1571,6 +1571,7 @@ static int atmel_spi_probe(struct platform_device *pdev)
>
> as->use_cs_gpios = true;
> if (atmel_spi_is_v2(as) &&
> + pdev->dev.of_node &&
> !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
> as->use_cs_gpios = false;
> master->num_chipselect = 4;
> --
> 2.1.3
>
--
Måns Rullgård
os = true;
> if (atmel_spi_is_v2(as) &&
> + pdev->dev.of_node &&
> !of_get_property(pdev->dev.of_node, "cs-gpios", NULL)) {
> as->use_cs_gpios = false;
> master->num_chipselect = 4;
> --
> 2.1.3
>
--
Måns Rullgård
Nicolas Ferre writes:
> Le 27/01/2016 16:53, Måns Rullgård a écrit :
>> Nicolas Ferre writes:
>>
>>> Le 05/01/2016 22:50, Måns Rullgård a écrit :
>>>> Cyrille Pitchen writes:
>>>>
>>>>> This patch relies on the CSAAT (Chip Select
Nicolas Ferre writes:
> Le 05/01/2016 22:50, Måns Rullgård a écrit :
>> Cyrille Pitchen writes:
>>
>>> This patch relies on the CSAAT (Chip Select Active After Transfer) feature
>>> introduced by the version 2 of the spi controller. This new mode allows to
&
work++;
> - }
> + } while (work < budget);
>
> if (work) {
> priv->rx_descs[last].desc.config |= DESC_EOC;
> --
> 2.7.0
>
--
Måns Rullgård
Nicolas Ferre <nicolas.fe...@atmel.com> writes:
> Le 05/01/2016 22:50, Måns Rullgård a écrit :
>> Cyrille Pitchen <cyrille.pitc...@atmel.com> writes:
>>
>>> This patch relies on the CSAAT (Chip Select Active After Transfer) feature
>>> introduced by
Nicolas Ferre <nicolas.fe...@atmel.com> writes:
> Le 27/01/2016 16:53, Måns Rullgård a écrit :
>> Nicolas Ferre <nicolas.fe...@atmel.com> writes:
>>
>>> Le 05/01/2016 22:50, Måns Rullgård a écrit :
>>>> Cyrille Pitchen <cyrille.pitc...@atmel.com
rxd->report = 0;
> last = next;
> work++;
> - }
> + } while (work < budget);
>
> if (work) {
> priv->rx_descs[last].desc.config |= DESC_EOC;
> --
> 2.7.0
>
--
Måns Rullgård
..., 5 - 256bits)
>> > +- data-width: Maximum data width supported by hardware (in bytes)
>>
>> To the reader this suggests a value truely byte granular, but code
>> uses ffs
>> implying that it is still power of 2.
>> Can you mention this here (in bytes, always power of 2).
>
> While this comment is good, I have still note that using non-power of 2
> values will not break anything. Least power of two number will be used
> in that case. So, means I would suggest to replace 'always' by 'better
> to be' or something like that.
Although the code rounds down, the hardware actually works in powers of
two, and it's better to document this.
--
Måns Rullgård
controller
>> > -- data_width: Maximum data width supported by hardware per AHB
>> > master
>> > - (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
>> > +- data-width: Maximum data width supported by hardware (in bytes)
>>
>> To the reader this suggests a va
Seriously, this is impossible. If I don't include everybody
in the slightest way related to any patch in the series, I get
complaints that patches are missing. If I do, the lists reject it all
due to too many recipients. What the hell am I supposed to do?
--
Måns Rullgård
Hans-Christian Noren Egtvedt writes:
> Around Sun 24 Jan 2016 20:19:46 + or thereabout, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt writes:
>>> Around Sun 24 Jan 2016 19:21:50 + or thereabout, Mans Rullgard wrote:
>>>> From: Andy She
| 12 ++--
>> drivers/dma/dw/regs.h | 4 ++--
>> drivers/spi/spi-pxa2xx-pci.c | 8
>> drivers/tty/serial/8250/8250_pci.c | 8
>> include/linux/platform_data/dma-dw.h | 8
>> 9 files changed, 39 insertions(+), 40 deletions(-)
>
>
>
> --
> Best regards, Hans-Christian Egtvedt
--
Måns Rullgård
e series - what are the
> dependencies and so on?
I give up. Seriously, this is impossible. If I don't include everybody
in the slightest way related to any patch in the series, I get
complaints that patches are missing. If I do, the lists reject it all
due to too many recipients. What the hell am I supposed to do?
--
Måns Rullgård
8
>> drivers/tty/serial/8250/8250_pci.c | 8
>> include/linux/platform_data/dma-dw.h | 8
>> 9 files changed, 39 insertions(+), 40 deletions(-)
>
>
>
> --
> Best regards, Hans-Christian Egtvedt
--
Måns Rullgård
Hans-Christian Noren Egtvedt <egtv...@samfundet.no> writes:
> Around Sun 24 Jan 2016 20:19:46 + or thereabout, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt <egtv...@samfundet.no> writes:
>>> Around Sun 24 Jan 2016 19:21:50 + or thereabout, Mans R
Marc Gonzalez writes:
> On 22/01/2016 17:39, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 22/01/2016 17:35, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez writes:
>>>>
>>>>> With your latest patch, can I dr
Marc Gonzalez writes:
> On 22/01/2016 17:35, Måns Rullgård wrote:
>> Marc Gonzalez writes:
>>
>>> On 20/01/2016 19:09, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez writes:
>>>>
>>>>> On 20/01/2016 17:38, Måns Rullgård wr
t; 100, 300).
I could've sworn I'd made that change. Too many versions of this patch
floating about...
> Otherwise,
>
> Acked-by: Rob Herring
>
>> +reg = <0x000 0x100>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>
Marc Gonzalez writes:
> On 20/01/2016 19:09, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 20/01/2016 17:38, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez writes:
>>>>
>>>>> On 20/01/2016 17:25, Måns Rullgård
Andy Shevchenko writes:
> On Fri, 2016-01-22 at 11:13 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>> > On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> > > Andy Shevchenko writes:
>
>> > In DWC_DEFAULT_CTLLO() can we do tab i
Andy Shevchenko writes:
> On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > > > > > One comment still regarding to lli types. We can avoid
>> > > > > > warnings by
>> > > > >
Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
> On Wed, 2016-01-20 at 20:07 +0000, Måns Rullgård wrote:
>> Andy Shevchenko <andy.shevche...@gmail.com> writes:
>>
>> > > > > > One comment still regarding to lli types. We can avoid
>
Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
> On Fri, 2016-01-22 at 11:13 +0000, Måns Rullgård wrote:
>> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>> > On Wed, 2016-01-20 at 20:07 +, Måns Rullgård wrote:
>> > >
terrupt-controller;
>> +#interrupt-cells = <2>;
>> +interrupts = ;
>> +};
>> +
>> +irq1: irq1 {
>> +reg = <0x100 0x100>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +interrupts = ;
>> +};
>> +
>> +irq2: irq2 {
>> +reg = <0x300 0x100>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>> +interrupts = ;
>> +};
>> +};
>> --
>> 2.7.0
>>
--
Måns Rullgård
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 22/01/2016 17:35, Måns Rullgård wrote:
>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
>>
>>> On 20/01/2016 19:09, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez <marc
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 22/01/2016 17:39, Måns Rullgård wrote:
>
>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
>>
>>> On 22/01/2016 17:35, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez &
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 20/01/2016 19:09, Måns Rullgård wrote:
>
>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
>>
>>> On 20/01/2016 17:38, Måns Rullgård wrote:
>>>
>>>> Marc Gonzalez <m
)
In my particular case, I can put whatever pinmux I want in the DT and
bring out the SPI signals, but I simply don't know what device will be
connected.
--
Måns Rullgård
writes:
> From: Alan Tull
>
> Add documentation for new FPGA bridge class's sysfs interface.
>
> Signed-off-by: Alan Tull
I don't see a patch in this email.
--
Måns Rullgård
<at...@opensource.altera.com> writes:
> From: Alan Tull <at...@opensource.altera.com>
>
> Add documentation for new FPGA bridge class's sysfs interface.
>
> Signed-off-by: Alan Tull <at...@opensource.altera.com>
I don't see a patch in this email.
--
Måns Rullgård
> modules.
>
> And with pinmux, FWIW ;-)
In my particular case, I can put whatever pinmux I want in the DT and
bring out the SPI signals, but I simply don't know what device will be
connected.
--
Måns Rullgård
Andy Shevchenko writes:
> On Wed, Jan 20, 2016 at 9:46 PM, Måns Rullgård wrote:
>
>>>>> One comment still regarding to lli types. We can avoid warnings by
>>>>> using (__force u32) in macros.
>>>>
>>>> But that won't give the benefit
Andy Shevchenko writes:
> On Wed, Jan 20, 2016 at 9:24 PM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>> On Wed, 2016-01-20 at 18:50 +, Måns Rullgård wrote:
>>>> Andy Shevchenko writes:
>>>>
>>>> >
Andy Shevchenko writes:
> On Wed, 2016-01-20 at 18:50 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
>> > >
>> > > Code here:
>> > > https://
Andy Shevchenko writes:
>> Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
>>
>> Code here:
>> https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata
>
> Thanks for testing!
Have you had time to look any more at these patches?
--
Måns Rullgård
Marc Gonzalez writes:
> On 20/01/2016 17:38, Måns Rullgård wrote:
>
>> Marc Gonzalez writes:
>>
>>> On 20/01/2016 17:25, Måns Rullgård wrote:
>>>
>>>> Marc Zyngier writes:
>>>>
>>>>>
driver would
> still function correctly?
Not the one you posted.
--
Måns Rullgård
Mark Rutland writes:
> On Wed, Jan 20, 2016 at 05:24:14PM +0100, Marc Gonzalez wrote:
>> On 20/01/2016 17:10, Måns Rullgård wrote:
>>
>> > Marc Zyngier wrote:
>> >
>> >>> +if (of_property_read_u32(node, "reg", ))
>> >
Marc Gonzalez writes:
> On 20/01/2016 17:25, Måns Rullgård wrote:
>
>> Marc Zyngier writes:
>>
>>> On 20/01/16 16:10, Måns Rullgård wrote:
>>>
>>>> Marc Zyngier writes:
>>>>
>>>>>> +if (of_property_read
Marc Gonzalez writes:
> On 20/01/2016 17:10, Måns Rullgård wrote:
>
>> Marc Zyngier wrote:
>>
>>>> + if (of_property_read_u32(node, "reg", ))
>>>> + panic("%s: failed to get reg base", node->name);
>>>>
Marc Zyngier writes:
> On 20/01/16 16:10, Måns Rullgård wrote:
>> Marc Zyngier writes:
>>
>>>> + if (of_property_read_u32(node, "reg", ))
>>>> + panic("%s: failed to get reg base", node->name);
>>>> +
gt;base = base;
As I said before, this assumes the outer DT node uses a ranges
property. Normally reg properties work the same whether they specify an
offset within an outer "ranges" or have a full address directly. It
would be easy enough to make this work with either, so I don't see any
reason not to.
--
Måns Rullgård
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 20/01/2016 17:38, Måns Rullgård wrote:
>
>> Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
>>
>>> On 20/01/2016 17:25, Måns Rullgård wrote:
>>>
>>>> Marc Zyngier <m
Marc Zyngier <marc.zyng...@arm.com> writes:
> On 20/01/16 16:10, Måns Rullgård wrote:
>> Marc Zyngier <marc.zyng...@arm.com> writes:
>>
>>>> + if (of_property_read_u32(node, "reg", ))
>>>> + panic("%s: failed to get
e the node without a ranges property, and the driver would
> still function correctly?
Not the one you posted.
--
Måns Rullgård
Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>> Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
>>
>> Code here:
>> https://bitbucket.org/mansr/linux-dwc/branch/dwc-sata
>
> Thanks for testing!
Have you had time to look any more at these patches?
--
Måns Rullgård
tl;
>> +chip->base = base;
As I said before, this assumes the outer DT node uses a ranges
property. Normally reg properties work the same whether they specify an
offset within an outer "ranges" or have a full address directly. It
would be easy enough to make this work with either, so I don't see any
reason not to.
--
Måns Rullgård
Mark Rutland <mark.rutl...@arm.com> writes:
> On Wed, Jan 20, 2016 at 05:24:14PM +0100, Marc Gonzalez wrote:
>> On 20/01/2016 17:10, Måns Rullgård wrote:
>>
>> > Marc Zyngier wrote:
>> >
>> >>> +if (of_property_read_u32(node, &quo
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 20/01/2016 17:10, Måns Rullgård wrote:
>
>> Marc Zyngier wrote:
>>
>>>> + if (of_property_read_u32(node, "reg", ))
>>>> + panic("%s: failed to get reg base",
Marc Gonzalez <marc_gonza...@sigmadesigns.com> writes:
> On 20/01/2016 17:25, Måns Rullgård wrote:
>
>> Marc Zyngier <marc.zyng...@arm.com> writes:
>>
>>> On 20/01/16 16:10, Måns Rullgård wrote:
>>>
>>>> Marc Zyngier <marc.zyng...
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Wed, Jan 20, 2016 at 9:24 PM, Måns Rullgård <m...@mansr.com> wrote:
>> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>>
>>> On Wed, 2016-01-20 at 18:50 +, Måns Rullgård w
Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
> On Wed, 2016-01-20 at 18:50 +0000, Måns Rullgård wrote:
>> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>>
>> > > Tested on AVR32 (DMA driver) and Sigma SMP8642 (SATA driver).
Andy Shevchenko <andy.shevche...@gmail.com> writes:
> On Wed, Jan 20, 2016 at 9:46 PM, Måns Rullgård <m...@mansr.com> wrote:
>
>>>>> One comment still regarding to lli types. We can avoid warnings by
>>>>> using (__force u32) in macros.
>
Andy Shevchenko writes:
> On Tue, 2015-12-22 at 00:08 +0000, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>> > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote:
>> > > Andy Shevchenko writes:
>> > >
>> > > >
Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
> On Tue, 2015-12-22 at 00:08 +0000, Måns Rullgård wrote:
>> Andy Shevchenko <andriy.shevche...@linux.intel.com> writes:
>>
>> > On Mon, 2015-12-21 at 19:27 +, Måns Rullgård wrote:
&g
, "cs-gpios", NULL)) {
> + as->use_cs_gpios = false;
> + master->num_chipselect = 4;
> + }
This part breaks the AVR32 boards and probably anything else that
doesn't use devicetree but does use GPIOs for chip select.
--
Måns Rullgård
--
0x19e/0x27c
[<9418>] repair_env_string+0x0/0x58
[<9374>] kernel_init_freeable+0x88/0x12c
[<9382>] kernel_init_freeable+0x96/0x12c
[<9418>] repair_env_string+0x0/0x58
[<901d2588>] kernel_init+0x8/0xa4
[<90013130>] syscall_return+0x0/0x12
[<
201 - 300 of 818 matches
Mail list logo
