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
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
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(&pdev->dev, "no PHY specified\n");
> ret = -ENODEV;
> --
> 2.1.4
>
--
Måns Rullgård
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
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
e 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
Christian Riesch writes:
> On Tue, Nov 11, 2014 at 2:04 PM, Måns Rullgård wrote:
>> Christian Riesch writes:
> [...]>> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
>>> index 2e900a9..b09f326 100644
>>> --- a/drivers/tty/n_tty.c
>>> +
ar c, struct n_tty_data *ldata)
> {
> - *read_buf_addr(ldata, ldata->read_head++) = c;
> + *read_buf_addr(ldata, ldata->read_head) = c;
> + /* increment read_head _after_ placing the character in the buffer */
> + ldata->read_head++;
> }
Is that
d to understand it. Not sure which is scarier.
Those are probably the Evil Vendor Tree developers who apparently think
"this is hard, best put volatile and barriers _everywhere_ and hope for
the best."
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line &
r sleeping, this approach keeps the data flowing
as fast as possible.
With the hardware you describe, there is unfortunately a trade-off
between throughput and CPU efficiency. You'll have to decide which is
more important to you.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send
on to remove working functionality.
>
> Unused.
What exactly are you proposing to remove? I see no unused code related
to early printk (in any variant) under arch/mips.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Joe Perches writes:
> On Fri, 2014-12-19 at 01:43 +0000, Måns Rullgård wrote:
>> What exactly are you proposing to remove?
>
> Optionally compile out
> kernel/printk/printk.c:early_printk()
> even if CONFIG_EARLY_PRINTK is enabled.
>
>> I see no unused code rela
t; For those that don't, perhaps we handle the conversion between perceived and
> pwm in the core, e.g. by adding a new flag to led_classdev.flags to indicate
> the need for conversion?
Some LED controllers do the right thing in hardware, so any adjustment
done in the core needs to
the leading `\' is
> merely how assembly syntax has been specified for references to macro
> arguments. And TBH I find banning any macro arguments starting with `u'
> rather silly.
Agreed.
> I'm leaning towards considering having -Wunicode disabled for all
> assembl
son this was dropped or if it just
> got forgotten about (I haven't found a V3 which should have addressed
> fixing all the get_parent return values yet).
I ran into this error myself just now, and it's quite annoying. It
would be great if it got fixed.
--
Måns Rullgård
m...@m
son this was dropped or if it just
> got forgotten about (I haven't found a V3 which should have addressed
> fixing all the get_parent return values yet).
The patch author is apparently no longer at TI (mail bounces). That
might explain a thing or two.
--
Måns Rullgård
m...@mansr.
ng multiple identical
definitions even though the C spec does not. Obviously all but one
should go away. No need to mention llvm, IMO.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
anks, queued for 3.20.
>
> This makes me wonder, though, if the sys and cfb versions could be
> somehow combined...
I would have done it by #including a common template with different
macro definitions for the memory access operations.
--
Måns Rullgård
m...@mansr.com
--
To unsub
have one with the interrupt line connected, so I can't really
help with that.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rly in the boot sequence and has very few dependencies, which makes
> it useful for board bringup.
EARLY_PRINTK on MIPS is enabled just after prom_init(), well before
OF_EARLYCON is usable. I'd prefer if it stayed that way.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list:
evice tree nodes ‘name' is usually
> not what you want to print to identify the node in question. ‘name’ is
> usually not unique.
Name and address without the full path is usually a good compromise
between uniqueness (it is usually unique for memory-mapped things) and
verbosity.
--
Måns
l_name);
>>>
>>> Which can be written now as:
>>> pr_info("Frobbing node %pO\n", node);
>>
>> Still disliking use of %p0.
>>
>
> Choices are limited. And it’s pO not p0.
O as in OF. Makes sense.
--
Måns Rullgård
m...@m
uffer: fix cfb_copyarea")
> - 5b789da8 ("framebuffer: fix screen corruption when copying")
>
> This patch incorporates the fixes into sys_copyarea() as well.
Scratch that, this patch is broken. Correct patch coming soon.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe f
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 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 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:
>>>>>
>>
One Thousand Gnomes writes:
> On Wed, 9 Mar 2016 21:30:55 +0200
> Andy Shevchenko wrote:
>
>> 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 P
k about how it should behave in
>> at803x_link_change_notify without control of the reset line, because
>> this code isn't reached then.
>
> If I understand correctly, it is possible to soft-reset the PHY
> by writing to a specific register. The GPIO pin is useful only to
Nicolas Pitre writes:
> On Fri, 30 Oct 2015, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > I'm going to do it anyway given that I already have it for ARM. It'll
>> > be opt-in, so if your arch doesn't provide it then the cur
; For the constant based optimization to work, you need to modify do_div()
>> in include/asm-generic/div64.h directly.
>
> OK... I was intrigued, so I adapted my ARM code to the generic case,
> including the overflow avoidance optimizations. Please have look and
> tell me how
Vineet Gupta writes:
> Claudiu, can some of this not be done in gcc itself !
All of it could be done by gcc. The trouble is that it isn't.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Nicolas Pitre writes:
> On Fri, 30 Oct 2015, Alexey Brodkin wrote:
>
>> Hi Nicolas,
>>
>> On Fri, 2015-10-30 at 11:17 -0400, Nicolas Pitre wrote:
>> > On Fri, 30 Oct 2015, Måns Rullgård wrote:
>> >
>> > > Nicolas Pitre writes:
>> &
ting new
> resources first, then receive data if alloc + map suceeded.
The hardware receives a frame and stores it in the provided DMA buffer,
then raises an interrupt and moves on to the next buffer. When a buffer
is handed over to the network stack, a new one has to take its place in
the DMA qu
t; + struct resource *res;
>> + struct net_device *dev;
>> + struct mii_bus *bus;
>> + const unsigned char *mac;
>> + void __iomem *base;
>> + int irq;
>> + int ret;
>> +
>> + match = of_match_device(nb8800_dt_i
Francois Romieu writes:
> Måns Rullgård :
>> Francois Romieu writes:
> [...]
>> > It looks like it receives, then tries to allocate new resources. If so
>> > it may deplete the ring and you should instead consider allocating new
>> > resources first, th
arithmetic on pointer values. They have to be
cast to an integer type first.
>>>> + nb8800_writeb(priv, NB8800_RANDOM_SEED, 0x08);
>>>> +
>>>> + /* TX single deferral params */
>>>> + nb8800_writeb(priv, NB8800_TX_SDP, 0xc);
>&g
; The register set looks like the one from i2c-xlr.c, only that they are
> 32 bit apart instead of 8. Can you check if you can reuse that driver?
It does look very similar indeed. I thought I'd checked for an existing
driver, but apparently I missed that one. I'll modify the xlr dri
too.
>
> Do you expect to have many different variations here? If not, I would
> get rid of all the child nodes and just hard code it in the driver.
Then how will other DT nodes reference the correct one?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unsigned long *inst = *p;
> + *inst = udiv_insn;
> + }
> + for (p = __start_idiv_loc; p < __stop_idiv_loc; p++) {
> + unsigned long *inst = *p;
> + *inst = sdiv_insn;
> + }
> + }
> +}
These fun
++--
> drivers/i2c/busses/i2c-xlr.c | 81
> +---
> 2 files changed, 80 insertions(+), 7 deletions(-)
Any comments on these patches?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
create the
>complete configuration matrix. IIRC, all CPUs that support
>virtualization also do lpae (they have to) and all CPUs that
>do lpae also do idiv, but the opposite is not true.
>
> Arnd
The ARM ARM says anything with virt has idiv, lpae doesn't matter. ARMv7-
Arnd Bergmann writes:
> On Saturday 21 November 2015 20:45:38 Måns Rullgård wrote:
>> On 21 November 2015 20:39:58 GMT+00:00, Arnd Bergmann wrote:
>> >On Friday 20 November 2015 17:23:14 Stephen Boyd wrote:
>> >> This is a respin of a patch series from about
rom
>https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
>just misinterpreted the flags
>
> b) the dartlag.org folks are correct, and it supports neither
>idivt nor idiva, and the /proc/cpuinfo flag is just wrong
>and requires a fixup
>
&g
;0: fbb0 f0f1 udivr0, r0, r1
>4: 4770bx lr
>6: bf00nop
>
> 0008 :
>8: fb90 f0f1 sdivr0, r0, r1
>c: 4770bx lr
>e: bf00nop
Your compiler seems to default to
Stephen Boyd writes:
> On 11/21, Måns Rullgård wrote:
>> Stephen Boyd writes:
>>
>> > +static int module_patch_aeabi_uidiv(unsigned long loc, const Elf32_Sym
>> > *sym)
>> > +{
>> > + extern char __aeabi_uidiv[], __aeabi_idiv[];
>> &g
we need to run a test
> build to check that -march=armv7ve or what-not really does work
> through both GCC and GAS.
If the compiler accepts the option but doesn't actually emit any div
instructions, is there any real harm?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this l
|MRC p6, 1, Rd , CRn , CRm, 4
> |
> |for PJ4B is the same as:
> |
> |SDIV Rd , Rn, Rm
> |
> | on ARM cores.
> |
> |And:
> |
> |MRC p6, 1, Rd , CRn , CRm, 0
> |
> |for PJ4B is the same as:
> |
> |UDIV Rd , Rn, Rm
> |
> |on ARM cores.
&
Russell King - ARM Linux writes:
> On Tue, Nov 24, 2015 at 12:10:02PM +0000, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote:
>> >> I suggested using -mcpu=cortex-a15 because t
mp(clk->name, orphan->parent_names[i]))
>> > __clk_reparent(orphan, clk);
>> > continue;
>> > }
>> >
>>
>> This works for me and is less invasive than the original patch series
at you keep rewriting, poorly, code you know I've already made
available suggests this might be the case. You even admit in private
that you couldn't have done this without looking at my tango3 tree.
Frankly, I find your behaviour shameful.
--
Måns Rullgård
m...@mansr.com
--
To unsubscrib
Marc Gonzalez writes:
> Måns Rullgård wrote:
>
>> Marc Gonzalez wrote:
>>
>>> Sigma Designs Tango platforms provide a 27 MHz crystal oscillator.
>>> Use it for clocksource, sched_clock, and delay_timer.
>>
>> Given the nature of this hardw
Måns Rullgård writes:
> Rob Herring writes:
>
>> On Wed, Oct 7, 2015 at 11:47 AM, Måns Rullgård wrote:
>>> What would be a proper way to select a sched_clock source? I realise
>>> it's a Linux-specific thing and DT is supposed to be generic, but the
>&
Stephen Boyd writes:
> On 10/09, Rob Herring wrote:
>> +Stephen who has worked on this code.
>>
>> On Fri, Oct 9, 2015 at 11:19 AM, Måns Rullgård wrote:
>> > Måns Rullgård writes:
>> >
>> >> Rob Herring writes:
>> >>
>> &g
Stephen Boyd writes:
> On 10/09, Rob Herring wrote:
>> +Stephen who has worked on this code.
>>
>> On Fri, Oct 9, 2015 at 11:19 AM, Måns Rullgård wrote:
>> > Måns Rullgård writes:
>> >
>> >> Rob Herring writes:
>> >>
>> &g
issed something that makes this a stupid idea, please tell.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Russell King - ARM Linux writes:
> On Sat, Oct 10, 2015 at 12:48:22AM +0100, Måns Rullgård wrote:
>> Russell King - ARM Linux writes:
>>
>> > On Fri, Oct 09, 2015 at 10:57:35PM +0100, Mans Rullgard wrote:
>> >> This passes a data pointer specified in the
tead of a "Linux index"? and where?
The simplest solution for you is probably to add a quick and dirty DT
binding to the old driver. If it doesn't use any driver-specific
platform data struct, you only need to set .of_match_table in the
struct platform_driver. If there is a platf
Mason writes:
> On 09/11/2015 16:40, Måns Rullgård wrote:
>
>> The simplest solution for you is probably to add a quick and dirty DT
>> binding to the old driver. If it doesn't use any driver-specific
>> platform data struct, you only need to set .of_match_table in
ot;plans" or "design documents" on lkml without
>> real code? Again, code will be posted when it's ready, like any other
>> kernel submission.
>
> I ask for feedback on ideas and designs on a fairly regular basis. I
> even frequently get valuable feedback :)
Mason writes:
> On 09/11/2015 17:12, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 09/11/2015 16:40, Måns Rullgård wrote:
>>>
>>>> The simplest solution for you is probably to add a quick and dirty DT
>>>> binding to the old drive
Greg KH writes:
> On Mon, Nov 09, 2015 at 05:02:45PM +0000, Måns Rullgård wrote:
>> Andy Lutomirski writes:
>>
>> > On Sun, Nov 8, 2015 at 3:30 PM, Greg KH wrote:
>> >> On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote:
>> &g
;nr_frags, page,
>> +offset + RX_COPYHDR, len - RX_COPYHDR,
>> +RX_BUF_SIZE);
>> +}
>> +
>> +skb->protocol = eth_type_trans(skb, dev);
>> +netif_receive_skb(skb);
>> +}
>> +
>
> An
O_DEVICE);
>> +
>> +if (dma_mapping_error(&dev->dev, dma_addr)) {
>> +netdev_err(dev, "tx dma mapping error\n");
>> +kfree_skb(skb);
>> +dev->stats.tx_dropped++;
>> + return NETDEV_TX_OK;
>> +
/aurora/nb8800.c | 1146
> ++
> drivers/net/ethernet/aurora/nb8800.h | 230 +++
Some of the increase is from new features, some from improvements, and
then there are a bunch of new comments.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David Miller writes:
> From: Måns Rullgård
> Date: Tue, 10 Nov 2015 18:05:15 +
>
>> Because I haven't been following the netdev list closely for the last
>> five years, and no documentation I read mentioned this function. I can
>> certainly change it.
>
David Miller writes:
> From: Måns Rullgård
> Date: Tue, 10 Nov 2015 20:53:19 +
>
>> David Miller writes:
>>
>>> From: Måns Rullgård
>>> Date: Tue, 10 Nov 2015 18:05:15 +
>>>
>>>> Because I haven't been follo
SC_ADDR, txb->dma_desc);
>> + wmb(); /* ensure desc addr is written before starting DMA */
>
> Hm… Have I missed corresponding rmb() ? If it's about MMIO, perhaps mmiowb() ?
Possibly.
>> + nb8800_writel(priv, NB8800_TXC_CR, txc_cr | TCR_EN);
>
Andy Shevchenko writes:
> On Wed, Nov 11, 2015 at 12:34 AM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>>
>>>> +static inline void nb8800_maskb(struct nb8800_priv *priv, int reg,
>>>> + u32 mask, u32 val)
>>>&g
+
>> +/* rx interrupt */
>> +val = nb8800_readl(priv, NB8800_RXC_SR);
>> +if (val) {
> [...]
>> +}
>> +
>> +return IRQ_HANDLED;
>
> Returning IRQ_HANDLED is fine if one of those hold:
> 1. you're sure that at least
Andy Shevchenko writes:
> On Wed, Nov 11, 2015 at 1:07 AM, Måns Rullgård wrote:
>> Andy Shevchenko writes:
>
>>>>>> + nb8800_writel(priv, NB8800_TX_DESC_ADDR, txb->dma_desc);
>>>>>> + wmb(); /* ensure desc addr is written
hich includes a proper subject line, changelog, plus
>> the necessary Makefile and Kconfig modifications.
>
> OK, I'll send a formal patch tomorrow.
> There are no Kconfig modifications, is that OK?
Why don't you use my driver? It's even simpler, and it works just fine
on th
Mason writes:
> Hello Mans,
>
> On 29/09/2015 22:18, Måns Rullgård wrote:
>
>> Mason writes:
>>
>>> On 29/09/2015 20:32, Thomas Gleixner wrote:
>>>
>>>> On Tue, 29 Sep 2015, Mason wrote:
>>>>
>>>>> I am trying to
et_device *dev, unsigned i, unsigned len)
> ...
>> +err = nb8800_alloc_rx(dev, i, true);
>
> It comes from an 'unsigned' value.
>
> Please pick one type and use it consistently.
Darn, missed one.
> Also, always fully spell out "unsigned int" r
David Miller writes:
> From: Måns Rullgård
> Date: Mon, 16 Nov 2015 20:59:18 +
>
>> Anything else?
>
> Sorry, when I find one problem I give you the feedback for that
> and move on to the 100s of other patches I have in my queue.
Some people prefer to comment on
)
> + platdata->phy_clkgate_delay_us = pval;
You don't need to use the pval temporary as of_property_read_u32 only
modifies the destination on success.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
&platdata->phy_clkgate_delay_us))
>
> platdata->itc_setting = 1;
Drop that if(). Since we're ignoring of_property_read_u32() failing,
there is no need to test its return value, and code above incorrectly
makes the next statement conditional.
--
Måns Rullgård
m...@mans
uch as yours,
> may see benefits in having all drivers use the same APIs; and there may
> be other savings for ARCH_MULTIPLATFORM builds with lots of platforms.
I think the patch is good. If there are issues with clocksource_mmio
those should addressed separately.
--
Måns Rullgård
m...@m
ing like
>
> arch/arm/include/debug/8250-palmchip.S:
>
> #include
>
> #undef UART_TX
> #undef UART_LSR
> #undef UART_MSR
>
> #define UART_TX 1
> #define UART_LSR 7
> #define UART_MSR 8
>
> #include "8250.S"
Good idea. I'll make a new patch.
-
> of 88 bytes only. And that is with my do_div optimization applied.
>
> With the do_div optimization turned off, the stack frame is still 88
> bytes.
>
> Turning on CONFIG_PROFILE_ALL_BRANCHES makes the frame size to grow to
> 96 bytes.
>
> Keeping CONFIG_PROFILE_ALL_BR
t boards
> with different SoC's. I have a couple of SD cards with various rootfs
> and use internal eMMC boot quite often as well. Remembering which board
> uses which numbering is a pain. Maintaining a patch is just easier...
> Furthermore, U-Boot allows reordering and all boards I deal with use mmc
> 0 for the internal eMMC. The aliases allow consistency.
Since pretty much every other device type supports renumbering with DT
aliases, it would make sense to do this for mmc as well.
--
Måns Rullgård
Miguel Ojeda writes:
> On Tue, Mar 12, 2019 at 4:48 PM Måns Rullgård wrote:
>>
>> The current code unconditionally flashes the light once. I though it
>> best to keep that behaviour as default, even if it's not seen as ideal.
>
> Sent into -next. If no one els
Maxime Ripard writes:
> On Thu, Mar 14, 2019 at 04:09:13PM +0000, Måns Rullgård wrote:
>> Maxime Ripard writes:
>>
>> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
>> >> Maxime Ripard writes:
>> >>
>> >> > Hi!
ruct platform_device *pdev)
> if (!priv)
> return -ENOMEM;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base = devm_ioremap_resource(&pdev->dev, res);
> + priv->base = devm_platform_ioremap_resource(pdev, 0);
>
_resource(dev, rc6_res);
> + ir->rc6_base = devm_platform_ioremap_resource(pdev, 1);
> if (IS_ERR(ir->rc6_base))
> return PTR_ERR(ir->rc6_base);
>
> --
> 2.23.0
>
--
Måns Rullgård
and_ it has and explicit status = "disabled" property.
The default is still to create devices for all interfaces.
That said, printing a message is probably a good idea anyway. Would
"info" level be appropriate for this?
--
Måns Rullgård
s
> line, so something like:
>
> /omit-if-no-ref/
> uart0_pf_pins: uart0-pf-pins {
> };
>
> And it does have the advantage of keeping the same line width, which
> could get pretty long on some nodes.
Thanks, I'd missed that directive. It always seems needlessly annoying
to make everybody working on a new board to add those nodes separately.
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård wrote:
>>
>> "Rafael J. Wysocki" writes:
>>
>> > On Sat, Feb 16, 2019 at 5:50 PM Mans Rullgard wrote:
>> >>
>> >> If the provided fwno
t;
>> So please add this to all the new nodes. It seems to work regardless whether
>> you add it before or after the label, though having it after the label seems
>> to make vim syntax highlighting happier.
Should we also add this to existing nodes?
BTW, I really do need all those uart pin options.
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Wed, Feb 20, 2019 at 11:41 AM Måns Rullgård wrote:
>>
>> "Rafael J. Wysocki" writes:
>>
>> > On Mon, Feb 18, 2019 at 12:10 PM Måns Rullgård wrote:
>> >>
>> >> "Rafael J. Wysoc
>
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> + pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
>
> if (pdevinfo->dma_mask) {
> /*
> --
Sorry, I forgot to add a v2 to this. Anyway, the only change is the
commit message.
--
Måns Rullgård
.c
>> +++ b/drivers/base/platform.c
>> @@ -512,6 +512,7 @@ struct platform_device *platform_device_register_full(
>>
>> pdev->dev.parent = pdevinfo->parent;
>> pdev->dev.fwnode = pdevinfo->fwnode;
>> +pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
>>
>> if (pdevinfo->dma_mask) {
>> /*
>
> Johan
--
Måns Rullgård
"Rafael J. Wysocki" writes:
> On Wed, Feb 20, 2019 at 1:12 PM Måns Rullgård wrote:
>>
>> Johan Hovold writes:
>>
>> > On Wed, Feb 20, 2019 at 11:35:06AM +, Mans Rullgard wrote:
>> >> If the provided fwnode is an OF node, set dev.of_node a
m still panic on errors during init. There's
really not much else that can sanely be done since nothing will work
without irq handling.
As for the error return added by this patch, nothing checks it, so a
failure would merely result in the irqchip being silently skipped and
nothing working.
Marek Szyprowski writes:
> Hi
>
> On 2019-05-08 13:46, Måns Rullgård wrote:
>> Marek Szyprowski writes:
>>> Commit 01fdf179f4b0 ("usb: core: skip interfaces disabled in devicetree")
>>> add support for disabling given USB device interface by adding
Marek Szyprowski writes:
> Hi Måns
>
> On 2019-05-21 15:30, Måns Rullgård wrote:
>> Marek Szyprowski writes:
>>> Dear All,
>>>
>>> Commit 69bec7259853 ("USB: core: let USB device know device node") added
>>> support for attaching dev
; conflict"), but it disabled support for USB device binding for Exynos
> EHCI/OHCI controllers.
>
> This patchset tries to resolve this binding conflict by changing Exynos
> EHCI/OHCI bindings: PHYs are moved from the sub-nodes to a standard array
> under the 'phys' pro
= "musb-hdrc";
> pinfo.id= PLATFORM_DEVID_AUTO;
> pinfo.parent= &pdev->dev;
> + pinfo.fwnode= of_fwnode_handle(pdev->dev.of_node);
> + pinfo.of_node_reused = true;
> pinfo.res = pdev->resource;
> pinfo.num_res = pdev->num_resources;
> pinfo.data = &pdata;
> --
> 2.20.1
>
--
Måns Rullgård
ls,
the system will not work anyway.
- Replace the panic() calls with error returns and check the return
value in tangox_of_irq_init(). The system will still end up unusable.
--
Måns Rullgård
ice_put(), should it ever be called. Moreover, these
devices are not removed if the module is unloaded or if there is an
error partway through the loop.
That said, it doesn't seem like setting of_node in
platform_device_register_full() should cause any (new) problems here.
--
Måns Rullgård
27;s kobject, so
> when is that reference dropped? Or if it doesn't need to be dropped
> at all, why is this the case?
platform_device_release() calls of_device_node_put().
--
Måns Rullgård
201 - 300 of 433 matches
Mail list logo
