* Re: [PATCH v2] vsock.7: document VSOCK socket address family
From: Stefan Hajnoczi @ 2017-12-12 9:23 UTC (permalink / raw)
To: Michael Kerrisk (man-pages)
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Jorgen Hansen, G. Branden Robinson, Dexuan Cui
In-Reply-To: <cce43383-f42d-3c46-a34a-26e1c6a82af9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]
On Mon, Dec 11, 2017 at 08:32:20PM +0100, Michael Kerrisk (man-pages) wrote:
> On 12/05/2017 11:56 AM, Stefan Hajnoczi wrote:
> > +Data is transferred using the usual
> > +.BR send (2)
> > +and
> > +.BR recv (2)
>
> Or equally, write(2) and read(2), right? By failing to mention those, the
> text subtly implies that send(2) and recv(2) are preferred, but I don't
> suppose that is true.
>
> > +family of socket system calls.
Yes, this file descriptor is a socket so write(2) and read(2) work.
I said "family of socket system calls" to avoid listing all the
variations of send(2), sendmsg(2), sendfile(2), sendmmsg(2), etc but I
guess that doesn't include the read(2)/write(2) family of syscalls
(readv(2)/writev(2)).
Will send a follow-up patch to clarify this.
> > +.B EOPNOTSUPP
> > +Operation not supported. This includes:
> > +the
> > +.B MSG_OOB
> > +flag that is not implemented for
> > +.BR sendmsg (2)
> > +and
> > +.B MSG_PEEK
> > +for
> > +.BR recvmsg (2).
>
> So these errors might also occur for send() and recv(), right?
Yes, I'll change this to "the send(2) family of syscalls" and "recv(2)
family of syscalls", respectively.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Philippe Ombredanne @ 2017-12-12 9:14 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Russell King - ARM Linux, Kunihiko Hayashi, Mark Rutland,
Andrew Lunn, Florian Fainelli,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
netdev-u79uwXL29TY76Z2rM5mHXA, Linux kernel mailing list,
Masahiro Yamada, Rob Herring, Jassi Brar, David S. Miller,
linux-arm-kernel
In-Reply-To: <CAA93ih0C-aMpFAhU+5x6P=QjiOVRPZ0UL1wyKh1oeXzC8UjPXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dear Masami-san,
On Tue, Dec 12, 2017 at 3:29 AM, Masami Hiramatsu
<masami.hiramatsu-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
[...]
> Then what I'm considering is copyright notice lines. Those are usually
> treat as the header lines, not single line. So
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
>> +// Copyright 2014 Panasonic Corporation
>> +// Copyright 2015-2017 Socionext Inc.
>
> is acceptable? or should we keep C-style header lines for new drivers?
>
>> +// SDPX-License-Identifier: GPL-2.0
>> +/*
>> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
>> + * Copyright 2014 Panasonic Corporation
>> + * Copyright 2015-2017 Socionext Inc.
>> + */
>
> I just concern that those lines are not "single". that's all. :)
My voice carries the weight of a down feather in this discussion and
to me the benefit of the first form is that you have removed two
lines. Both forms work fine.
--
Cordially
Philippe Ombredanne
--
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
* [BUG] wl3501: a possible sleep-in-atomic bug in wl3501_reset
From: Jia-Ju Bai @ 2017-12-12 9:04 UTC (permalink / raw)
To: kvalo, mhchen, acme, niemeyer; +Cc: linux-wireless, netdev, linux-kernel
According to drivers/net/wireless/wl3501_cs.c, the driver may sleep
under a spinlock.
The function call path is:
wl3501_reset (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] bpf/tracing: allow user space to query prog array on the same tp
From: Peter Zijlstra @ 2017-12-12 9:03 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20171211193903.2428317-2-yhs@fb.com>
On Mon, Dec 11, 2017 at 11:39:02AM -0800, Yonghong Song wrote:
> The usage:
> struct perf_event_query_bpf *query = malloc(...);
> query.ids_len = ids_len;
> err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, &query);
You didn't spot the fixes to your changelog ;-) The above should read
something like:
struct perf_event_query_bpf *query =
malloc(sizeof(*query) + sizeof(u32) * ids_len);
query->ids_len = ids_len;
err = ioctl(pmu_efd, PERF_EVENT_IOC_QUERY_BPF, query);
^ permalink raw reply
* Re: linux-next: build failure after merge of the mac80211-next tree
From: Toke Høiland-Jørgensen @ 2017-12-12 8:59 UTC (permalink / raw)
To: Johannes Berg, Stephen Rothwell, Kalle Valo, Wireless
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Felix Fietkau,
Lorenzo Bianconi, David Miller, Networking
In-Reply-To: <1513068419.26976.86.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:
> Hi Stephen,
>
> Thanks!
>
> Felix made me aware of this yesterday evening and said he's going to
> work out the required changes to mt76.
>
> Kalle and I will make sure to submit the trees to Dave one by one so he
> doesn't have to deal with it :)
>
> Unfortunately, this might take a few days to resolve.
>
>> -void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
>> +void mt76_wake_tx_queue(struct ieee80211_hw *hw)
>> {
>> + struct ieee80211_txq *txq;
>> struct mt76_dev *dev = hw->priv;
>> - struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
>> - struct mt76_queue *hwq = mtxq->hwq;
>> + struct mt76_txq *mtxq;
>> + struct mt76_queue *hwq;
>>
>> + txq = ieee80211_next_txq(hw);
>> + mtxq = (struct mt76_txq *) txq->drv_priv;
>> + hwq = mtxq->hwq;
>
> Looks pretty much right to me - perhaps for safety there should be a
> NULL check on txq, but OTOH when you get here it should be non-NULL.
Note that while this will fix compilation it probably won't work right.
next_txq() is not guaranteed to return the same txq as was previously
passed in the wake_tx_queue() argument, so if this is the only place the
driver calls next_txq(), things are likely going to break.
Rather, the driver should call next_txq() whenever it schedules queues
instead of doing its own internal scheduling.
> Sorry for the inconvenience, I hadn't realized mt76 went in now.
Yeah, hadn't expected these streams to cross either. If Felix is looking
into this that is great; let me know if you need me to do anything else
on the mac80211 side. :)
-Toke
^ permalink raw reply
* [PATCH] drivers/staging/irda: fix max dup length for kstrndup
From: Ma Shimiao @ 2017-12-12 8:54 UTC (permalink / raw)
To: samuel; +Cc: netdev, linux-kernel, Ma Shimiao
If source string longer than max, kstrndup will alloc max+1 space.
So, we should make sure the result will not over limit.
Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
---
drivers/staging/irda/net/irias_object.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/irda/net/irias_object.c b/drivers/staging/irda/net/irias_object.c
index 53b86d0e1630..b626f796a3ff 100644
--- a/drivers/staging/irda/net/irias_object.c
+++ b/drivers/staging/irda/net/irias_object.c
@@ -56,7 +56,7 @@ struct ias_object *irias_new_object( char *name, int id)
}
obj->magic = IAS_OBJECT_MAGIC;
- obj->name = kstrndup(name, IAS_MAX_CLASSNAME, GFP_ATOMIC);
+ obj->name = kstrndup(name, IAS_MAX_CLASSNAME - 1, GFP_ATOMIC);
if (!obj->name) {
net_warn_ratelimited("%s(), Unable to allocate name!\n",
__func__);
@@ -326,7 +326,7 @@ void irias_add_integer_attrib(struct ias_object *obj, char *name, int value,
}
attrib->magic = IAS_ATTRIB_MAGIC;
- attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME, GFP_ATOMIC);
+ attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME - 1, GFP_ATOMIC);
/* Insert value */
attrib->value = irias_new_integer_value(value);
@@ -370,7 +370,7 @@ void irias_add_octseq_attrib(struct ias_object *obj, char *name, __u8 *octets,
}
attrib->magic = IAS_ATTRIB_MAGIC;
- attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME, GFP_ATOMIC);
+ attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME - 1, GFP_ATOMIC);
attrib->value = irias_new_octseq_value( octets, len);
if (!attrib->name || !attrib->value) {
@@ -412,7 +412,7 @@ void irias_add_string_attrib(struct ias_object *obj, char *name, char *value,
}
attrib->magic = IAS_ATTRIB_MAGIC;
- attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME, GFP_ATOMIC);
+ attrib->name = kstrndup(name, IAS_MAX_ATTRIBNAME - 1, GFP_ATOMIC);
attrib->value = irias_new_string_value(value);
if (!attrib->name || !attrib->value) {
@@ -468,7 +468,7 @@ struct ias_value *irias_new_string_value(char *string)
value->type = IAS_STRING;
value->charset = CS_ASCII;
- value->t.string = kstrndup(string, IAS_MAX_STRING, GFP_ATOMIC);
+ value->t.string = kstrndup(string, IAS_MAX_STRING - 1, GFP_ATOMIC);
if (!value->t.string) {
net_warn_ratelimited("%s: Unable to kmalloc!\n", __func__);
kfree(value);
--
2.13.6
^ permalink raw reply related
* [BUG] sbni: a possible sleep-in-atomic bug in sbni_close
From: Jia-Ju Bai @ 2017-12-12 8:53 UTC (permalink / raw)
To: davem, keescook, dhowells, timofeev; +Cc: netdev, Linux Kernel Mailing List
According to drivers/net/wan/sbni.c, the driver may sleep under a spinlock.
The function call path is:
sbni_close (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* [PATCH] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
From: Jia-Ju Bai @ 2017-12-12 8:49 UTC (permalink / raw)
To: jes, jes; +Cc: netdev, linux-kernel, Jia-Ju Bai
The driver may sleep under a spinlock.
The function call path is:
rr_close (acquire the spinlock)
free_irq --> may sleep
To fix it, free_irq is moved to the place without holding the spinlock.
This bug is found by my static analysis tool(DSAC) and checked by my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
---
drivers/net/hippi/rrunner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index 8483f03..1ab97d9 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1379,8 +1379,8 @@ static int rr_close(struct net_device *dev)
rrpriv->info_dma);
rrpriv->info = NULL;
- free_irq(pdev->irq, dev);
spin_unlock_irqrestore(&rrpriv->lock, flags);
+ free_irq(pdev->irq, dev);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* Re: linux-next: build failure after merge of the mac80211-next tree
From: Johannes Berg @ 2017-12-12 8:46 UTC (permalink / raw)
To: Stephen Rothwell, Kalle Valo, Wireless
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Felix Fietkau,
Lorenzo Bianconi, Toke Høiland-Jørgensen, David Miller,
Networking
In-Reply-To: <20171212125805.5f7813fd@canb.auug.org.au>
Hi Stephen,
Thanks!
Felix made me aware of this yesterday evening and said he's going to
work out the required changes to mt76.
Kalle and I will make sure to submit the trees to Dave one by one so he
doesn't have to deal with it :)
Unfortunately, this might take a few days to resolve.
> -void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
> +void mt76_wake_tx_queue(struct ieee80211_hw *hw)
> {
> + struct ieee80211_txq *txq;
> struct mt76_dev *dev = hw->priv;
> - struct mt76_txq *mtxq = (struct mt76_txq *) txq->drv_priv;
> - struct mt76_queue *hwq = mtxq->hwq;
> + struct mt76_txq *mtxq;
> + struct mt76_queue *hwq;
>
> + txq = ieee80211_next_txq(hw);
> + mtxq = (struct mt76_txq *) txq->drv_priv;
> + hwq = mtxq->hwq;
Looks pretty much right to me - perhaps for safety there should be a
NULL check on txq, but OTOH when you get here it should be non-NULL.
Sorry for the inconvenience, I hadn't realized mt76 went in now.
johannes
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Sean Wang @ 2017-12-12 8:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <20171212082837.GM28672@lunn.ch>
On Tue, 2017-12-12 at 09:28 +0100, Andrew Lunn wrote:
> On Tue, Dec 12, 2017 at 03:21:21PM +0800, Sean Wang wrote:
> > On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > > > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > > > {
> > > > struct dsa_port *dp = dsa_slave_to_port(dev);
> > > > u8 *mtk_tag;
> > > > + bool is_vlan_skb = true;
> > >
> > > ..
> > >
> > > > + /* Mark tag attribute on special tag insertion to notify hardware
> > > > + * whether that's a combined special tag with 802.1Q header.
> > > > + */
> > > > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > > > + MTK_HDR_XMIT_UNTAGGED;
> > > > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > > > - mtk_tag[2] = 0;
> > > > - mtk_tag[3] = 0;
> > > > +
> > > > + /* Tag control information is kept for 802.1Q */
> > > > + if (!is_vlan_skb) {
> > > > + mtk_tag[2] = 0;
> > > > + mtk_tag[3] = 0;
> > > > + }
> > > >
> > > > return skb;
> > > > }
> > >
> > > Hi Sean
> > >
> > > So you can mark a packet for egress. What about ingress? How do you
> > > know the VLAN/PORT combination for packets the CPU receives? I would
> > > of expected a similar change to mtk_tag_rcv().
> > >
> > > Andrew
> >
> > Hi, Andrew
> >
> > It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
> > present since it is able to put the VLAN tag after the special tag and
> > then follow the existing way to parse.
>
> Hi Sean
>
> O.K. Please mention this in the commit message. Since it was something
> i was expecting, it should be documented why it is not needed.
>
> Thanks
> Andrew
Sure. I will add this in the commit message.
Sean
>
^ permalink raw reply
* [BUG] skge: a possible sleep-in-atomic bug in skge_remove
From: Jia-Ju Bai @ 2017-12-12 8:38 UTC (permalink / raw)
To: mlindner, stephen, shemminger, shemminger
Cc: netdev, Linux Kernel Mailing List
According to drivers/net/ethernet/marvell/skge.c, the driver may sleep
under a spinlock.
The function call path is:
skge_remove (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Sean Wang @ 2017-12-12 8:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: davem, andrew, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <94df4a0c-3e9b-a51e-6f2d-5adc43e3b9e4@nbd.name>
On Tue, 2017-12-12 at 09:24 +0100, Felix Fietkau wrote:
> On 2017-12-07 07:06, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > MT7530 can treat each port as either VLAN-unware port or VLAN-ware port
> Shouldn't that be VLAN-unaware/VLAN-aware (in the code as well)?
>
> - Felix
>
Hi, Felix
Thank you. It is my misspelling problem. I will fix them all with this
including in the code.
Sean
^ permalink raw reply
* Re: [PATCH] net: dsa: allow XAUI phy interface mode
From: Andrew Lunn @ 2017-12-12 8:35 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: David Miller, vivien.didelot, f.fainelli, netdev
In-Reply-To: <20171211190220.GY10595@n2100.armlinux.org.uk>
> That's something like it - asked Andrew via IRC on Saturday:
>
> Do we want to do the XAUI thing as one patch to avoid any breakage, and
> if so via whom?
Hi Russell
Sorry for not replying. I was on a plane by then.
> and haven't had a response. Normally arm-soc folk want patches
> touching arch/arm/boot/dts to go via their tree.
>
> So, until I know what to do, I can't proceed with this... and I've
> soo many outstanding net patches now that I'm losing track of where
> each patch I've sent out is. Sorry, I'm failing.
I would put both patches via netdev, to avoid breakage. We have done
this before for the ZII devel board, with the imx maintainers ACK. I
don't expect any clashes in the DT file. The 10Gb port might be added
soon, but i think there is enough separation in the changes they won't
result in a conflict if they take a different path.
Do you want me to send a v2, with the additional DT patch?
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Andrew Lunn @ 2017-12-12 8:28 UTC (permalink / raw)
To: Sean Wang
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <1513063281.28444.25.camel@mtkswgap22>
On Tue, Dec 12, 2017 at 03:21:21PM +0800, Sean Wang wrote:
> On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > > {
> > > struct dsa_port *dp = dsa_slave_to_port(dev);
> > > u8 *mtk_tag;
> > > + bool is_vlan_skb = true;
> >
> > ..
> >
> > > + /* Mark tag attribute on special tag insertion to notify hardware
> > > + * whether that's a combined special tag with 802.1Q header.
> > > + */
> > > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > > + MTK_HDR_XMIT_UNTAGGED;
> > > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > > - mtk_tag[2] = 0;
> > > - mtk_tag[3] = 0;
> > > +
> > > + /* Tag control information is kept for 802.1Q */
> > > + if (!is_vlan_skb) {
> > > + mtk_tag[2] = 0;
> > > + mtk_tag[3] = 0;
> > > + }
> > >
> > > return skb;
> > > }
> >
> > Hi Sean
> >
> > So you can mark a packet for egress. What about ingress? How do you
> > know the VLAN/PORT combination for packets the CPU receives? I would
> > of expected a similar change to mtk_tag_rcv().
> >
> > Andrew
>
> Hi, Andrew
>
> It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
> present since it is able to put the VLAN tag after the special tag and
> then follow the existing way to parse.
Hi Sean
O.K. Please mention this in the commit message. Since it was something
i was expecting, it should be documented why it is not needed.
Thanks
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Felix Fietkau @ 2017-12-12 8:24 UTC (permalink / raw)
To: sean.wang, davem, andrew, f.fainelli, vivien.didelot
Cc: netdev, linux-kernel, linux-mediatek
In-Reply-To: <792c2d52b8da717b55ead9d480863ca390fe91b3.1512625814.git.sean.wang@mediatek.com>
On 2017-12-07 07:06, sean.wang@mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> MT7530 can treat each port as either VLAN-unware port or VLAN-ware port
Shouldn't that be VLAN-unaware/VLAN-aware (in the code as well)?
- Felix
^ permalink raw reply
* Re: [PATCH bpf 2/3] bpf: fix build issues on um due to mising bpf_perf_event.h
From: Richard Weinberger @ 2017-12-12 7:55 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev, Hendrik Brueckner
In-Reply-To: <20171212012532.30268-3-daniel@iogearbox.net>
Am Dienstag, 12. Dezember 2017, 02:25:31 CET schrieb Daniel Borkmann:
> Since c895f6f703ad ("bpf: correct broken uapi for
> BPF_PROG_TYPE_PERF_EVENT program type") um (uml) won't build
> on i386 or x86_64:
>
> [...]
> CC init/main.o
> In file included from ../include/linux/perf_event.h:18:0,
> from ../include/linux/trace_events.h:10,
> from ../include/trace/syscall.h:7,
> from ../include/linux/syscalls.h:82,
> from ../init/main.c:20:
> ../include/uapi/linux/bpf_perf_event.h:11:32: fatal error:
> asm/bpf_perf_event.h: No such file or directory #include
> <asm/bpf_perf_event.h>
> [...]
>
> Lets add missing bpf_perf_event.h also to um arch. This seems
> to be the only one still missing.
>
> Fixes: c895f6f703ad ("bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT
> program type") Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Suggested-by: Richard Weinberger <richard@sigma-star.at>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Tested-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
> Cc: Richard Weinberger <richard@sigma-star.at>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> ---
> arch/um/include/asm/Kbuild | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/um/include/asm/Kbuild b/arch/um/include/asm/Kbuild
> index 50a32c3..73c57f6 100644
> --- a/arch/um/include/asm/Kbuild
> +++ b/arch/um/include/asm/Kbuild
> @@ -1,4 +1,5 @@
> generic-y += barrier.h
> +generic-y += bpf_perf_event.h
> generic-y += bug.h
> generic-y += clkdev.h
> generic-y += current.h
Acked-by: Richard Weinberger <richard@nod.at>
Thanks,
//richard
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: mediatek: combine MediaTek tag with VLAN tag
From: Sean Wang @ 2017-12-12 7:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <20171207153016.GC24750@lunn.ch>
On Thu, 2017-12-07 at 16:30 +0100, Andrew Lunn wrote:
> > @@ -25,20 +28,37 @@ static struct sk_buff *mtk_tag_xmit(struct sk_buff *skb,
> > {
> > struct dsa_port *dp = dsa_slave_to_port(dev);
> > u8 *mtk_tag;
> > + bool is_vlan_skb = true;
>
> ..
>
> > + /* Mark tag attribute on special tag insertion to notify hardware
> > + * whether that's a combined special tag with 802.1Q header.
> > + */
> > + mtk_tag[0] = is_vlan_skb ? MTK_HDR_XMIT_TAGGED_TPID_8100 :
> > + MTK_HDR_XMIT_UNTAGGED;
> > mtk_tag[1] = (1 << dp->index) & MTK_HDR_XMIT_DP_BIT_MASK;
> > - mtk_tag[2] = 0;
> > - mtk_tag[3] = 0;
> > +
> > + /* Tag control information is kept for 802.1Q */
> > + if (!is_vlan_skb) {
> > + mtk_tag[2] = 0;
> > + mtk_tag[3] = 0;
> > + }
> >
> > return skb;
> > }
>
> Hi Sean
>
> So you can mark a packet for egress. What about ingress? How do you
> know the VLAN/PORT combination for packets the CPU receives? I would
> of expected a similar change to mtk_tag_rcv().
>
> Andrew
Hi, Andrew
It's unnecessary for extra handling in mtk_tag_rcv() when VLAN tag is
present since it is able to put the VLAN tag after the special tag and
then follow the existing way to parse.
Sean
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: Sean Wang @ 2017-12-12 6:52 UTC (permalink / raw)
To: Andrew Lunn
Cc: f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20171207152415.GB24750-g2DYL2Zd6BY@public.gmane.org>
Hi, Andrew
All sounds reasonable. All will be fixed in the next version.
Sean
On Thu, 2017-12-07 at 16:24 +0100, Andrew Lunn wrote:
> > static void
> > +mt7530_port_set_vlan_unware(struct dsa_switch *ds, int port)
> > +{
> > + struct mt7530_priv *priv = ds->priv;
> > + int i;
> > + bool all_user_ports_removed = true;
>
> Hi Sean
>
> Reverse Christmas tree please.
>
will be fixed
> > +static int
> > +mt7530_vlan_cmd(struct mt7530_priv *priv, enum mt7530_vlan_cmd cmd, u16 vid)
> > +{
> > + u32 val;
> > + int ret;
> > + struct mt7530_dummy_poll p;
>
> Here too.
>
will be fixed
> > +static int
> > +mt7530_port_vlan_prepare(struct dsa_switch *ds, int port,
> > + const struct switchdev_obj_port_vlan *vlan,
> > + struct switchdev_trans *trans)
> > +{
> > + struct mt7530_priv *priv = ds->priv;
> > +
> > + /* The port is being kept as VLAN-unware port when bridge is set up
> > + * with vlan_filtering not being set, Otherwise, the port and the
> > + * corresponding CPU port is required the setup for becoming a
> > + * VLAN-ware port.
> > + */
> > + if (!priv->ports[port].vlan_filtering)
> > + return 0;
> > +
> > + mt7530_port_set_vlan_ware(ds, port);
> > + mt7530_port_set_vlan_ware(ds, MT7530_CPU_PORT);
>
> A prepare function should just validate that it is possible to carry
> out the operation. It should not change any state. These two last
> lines probably don't belong here.
>
okay, it will be moved into the proper place such as
mt7530_port_vlan_filtering
> > +
> > + return 0;
> > +}
> > +
> > +static void
> > +mt7530_hw_vlan_add(struct mt7530_priv *priv,
> > + struct mt7530_hw_vlan_entry *entry)
> > +{
> > + u32 val;
> > + u8 new_members;
>
> Reverse Christmas tree. Please check the whole patch.
>
will be fixed
> > +static inline void INIT_MT7530_HW_ENTRY(struct mt7530_hw_vlan_entry *e,
> > + int port, bool untagged)
> > +{
> > + e->port = port;
> > + e->untagged = untagged;
> > +}
>
> All CAPITAL letters is for #defines. This is just a normal
> function. Please use lower case.
>
will be fixed
> Andrew
>
^ permalink raw reply
* [PATCH v2 2/3] r8169: switch to device-managed functions in probe
From: Heiner Kallweit @ 2017-12-12 6:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
Simplify probe error path and remove callback by using device-managed
functions.
rtl_disable_msi isn't needed any longer because the release callback
of pcim_enable_device does this implicitely.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 80 +++++++++---------------------------
1 file changed, 20 insertions(+), 60 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index fc0d5fa65..3c7d90d3a 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4643,16 +4643,6 @@ static void rtl8169_phy_timer(struct timer_list *t)
rtl_schedule_task(tp, RTL_FLAG_TASK_PHY_PENDING);
}
-static void rtl8169_release_board(struct pci_dev *pdev, struct net_device *dev,
- void __iomem *ioaddr)
-{
- iounmap(ioaddr);
- pci_release_regions(pdev);
- pci_clear_mwi(pdev);
- pci_disable_device(pdev);
- free_netdev(dev);
-}
-
DECLARE_RTL_COND(rtl_phy_reset_cond)
{
return tp->phy_reset_pending(tp);
@@ -4784,14 +4774,6 @@ static int rtl_tbi_ioctl(struct rtl8169_private *tp, struct mii_ioctl_data *data
return -EOPNOTSUPP;
}
-static void rtl_disable_msi(struct pci_dev *pdev, struct rtl8169_private *tp)
-{
- if (tp->features & RTL_FEATURE_MSI) {
- pci_disable_msi(pdev);
- tp->features &= ~RTL_FEATURE_MSI;
- }
-}
-
static void rtl_init_mdio_ops(struct rtl8169_private *tp)
{
struct mdio_ops *ops = &tp->mdio_ops;
@@ -8256,9 +8238,6 @@ static void rtl_remove_one(struct pci_dev *pdev)
unregister_netdev(dev);
- dma_free_coherent(&tp->pci_dev->dev, sizeof(*tp->counters),
- tp->counters, tp->counters_phys_addr);
-
rtl_release_firmware(tp);
if (pci_dev_run_wake(pdev))
@@ -8266,9 +8245,6 @@ static void rtl_remove_one(struct pci_dev *pdev)
/* restore original MAC address */
rtl_rar_set(tp, dev->perm_addr);
-
- rtl_disable_msi(pdev, tp);
- rtl8169_release_board(pdev, dev, tp->mmio_addr);
}
static const struct net_device_ops rtl_netdev_ops = {
@@ -8445,11 +8421,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
MODULENAME, RTL8169_VERSION);
}
- dev = alloc_etherdev(sizeof (*tp));
- if (!dev) {
- rc = -ENOMEM;
- goto out;
- }
+ dev = devm_alloc_etherdev(&pdev->dev, sizeof (*tp));
+ if (!dev)
+ return -ENOMEM;
SET_NETDEV_DEV(dev, &pdev->dev);
dev->netdev_ops = &rtl_netdev_ops;
@@ -8472,13 +8446,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
PCIE_LINK_STATE_CLKPM);
/* enable device (incl. PCI PM wakeup and hotplug setup) */
- rc = pci_enable_device(pdev);
+ rc = pcim_enable_device(pdev);
if (rc < 0) {
netif_err(tp, probe, dev, "enable failure\n");
- goto err_out_free_dev_1;
+ return rc;
}
- if (pci_set_mwi(pdev) < 0)
+ if (pcim_set_mwi(pdev) < 0)
netif_info(tp, probe, dev, "Mem-Wr-Inval unavailable\n");
/* make sure PCI base addr 1 is MMIO */
@@ -8486,30 +8460,28 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_err(tp, probe, dev,
"region #%d not an MMIO resource, aborting\n",
region);
- rc = -ENODEV;
- goto err_out_mwi_2;
+ return -ENODEV;
}
/* check for weird/broken PCI region reporting */
if (pci_resource_len(pdev, region) < R8169_REGS_SIZE) {
netif_err(tp, probe, dev,
"Invalid PCI region size(s), aborting\n");
- rc = -ENODEV;
- goto err_out_mwi_2;
+ return -ENODEV;
}
rc = pci_request_regions(pdev, MODULENAME);
if (rc < 0) {
netif_err(tp, probe, dev, "could not request regions\n");
- goto err_out_mwi_2;
+ return rc;
}
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, region), R8169_REGS_SIZE);
+ ioaddr = devm_ioremap(&pdev->dev, pci_resource_start(pdev, region),
+ R8169_REGS_SIZE);
if (!ioaddr) {
netif_err(tp, probe, dev, "cannot remap MMIO, aborting\n");
- rc = -EIO;
- goto err_out_free_res_3;
+ return -EIO;
}
tp->mmio_addr = ioaddr;
@@ -8535,7 +8507,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (rc < 0) {
netif_err(tp, probe, dev, "DMA configuration failed\n");
- goto err_out_unmap_4;
+ return rc;
}
}
@@ -8697,8 +8669,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->rtl_fw = RTL_FIRMWARE_UNKNOWN;
- tp->counters = dma_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
- &tp->counters_phys_addr, GFP_KERNEL);
+ tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
+ &tp->counters_phys_addr,
+ GFP_KERNEL);
if (!tp->counters) {
rc = -ENOMEM;
goto err_out_msi_5;
@@ -8706,7 +8679,7 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
rc = register_netdev(dev);
if (rc < 0)
- goto err_out_cnt_6;
+ goto err_out_msi_5;
pci_set_drvdata(pdev, dev);
@@ -8735,25 +8708,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_carrier_off(dev);
-out:
- return rc;
+ return 0;
-err_out_cnt_6:
- dma_free_coherent(&pdev->dev, sizeof(*tp->counters), tp->counters,
- tp->counters_phys_addr);
err_out_msi_5:
netif_napi_del(&tp->napi);
- rtl_disable_msi(pdev, tp);
-err_out_unmap_4:
- iounmap(ioaddr);
-err_out_free_res_3:
- pci_release_regions(pdev);
-err_out_mwi_2:
- pci_clear_mwi(pdev);
- pci_disable_device(pdev);
-err_out_free_dev_1:
- free_netdev(dev);
- goto out;
+
+ return rc;
}
static struct pci_driver rtl8169_pci_driver = {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 3/3] r8169: remove netif_napi_del in probe error path
From: Heiner Kallweit @ 2017-12-12 6:41 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
netif_napi_del is called implicitely by free_netdev, therefore we
don't have to do it explicitely.
When the probe error path is reached, the net_device isn't
registered yet. Therefore reordering the call to netif_napi_del
shouldn't cause any issues.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- no changes
---
drivers/net/ethernet/realtek/r8169.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3c7d90d3a..857f67beb 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -8672,14 +8672,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
&tp->counters_phys_addr,
GFP_KERNEL);
- if (!tp->counters) {
- rc = -ENOMEM;
- goto err_out_msi_5;
- }
+ if (!tp->counters)
+ return -ENOMEM;
rc = register_netdev(dev);
if (rc < 0)
- goto err_out_msi_5;
+ return rc;
pci_set_drvdata(pdev, dev);
@@ -8709,11 +8707,6 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
netif_carrier_off(dev);
return 0;
-
-err_out_msi_5:
- netif_napi_del(&tp->napi);
-
- return rc;
}
static struct pci_driver rtl8169_pci_driver = {
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/3] PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi()
From: Heiner Kallweit @ 2017-12-12 6:40 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
Add pcim_set_mwi(), a device-managed version of pci_set_mwi().
First user is the Realtek r8169 driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
v2:
- Reorder calls
- Adjust and commit message
---
drivers/pci/pci.c | 25 +++++++++++++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 4a7c6864f..764ca7b88 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1458,6 +1458,7 @@ struct pci_devres {
unsigned int pinned:1;
unsigned int orig_intx:1;
unsigned int restore_intx:1;
+ unsigned int mwi:1;
u32 region_mask;
};
@@ -1476,6 +1477,9 @@ static void pcim_release(struct device *gendev, void *res)
if (this->region_mask & (1 << i))
pci_release_region(dev, i);
+ if (this->mwi)
+ pci_clear_mwi(dev);
+
if (this->restore_intx)
pci_intx(dev, this->orig_intx);
@@ -3760,6 +3764,27 @@ int pci_set_mwi(struct pci_dev *dev)
}
EXPORT_SYMBOL(pci_set_mwi);
+/**
+ * pcim_set_mwi - a device-managed pci_set_mwi()
+ * @dev: the PCI device for which MWI is enabled
+ *
+ * Managed pci_set_mwi().
+ *
+ * RETURNS: An appropriate -ERRNO error value on error, or zero for success.
+ */
+int pcim_set_mwi(struct pci_dev *dev)
+{
+ struct pci_devres *dr;
+
+ dr = find_pci_dr(dev);
+ if (!dr)
+ return -ENOMEM;
+
+ dr->mwi = 1;
+ return pci_set_mwi(dev);
+}
+EXPORT_SYMBOL(pcim_set_mwi);
+
/**
* pci_try_set_mwi - enables memory-write-invalidate PCI transaction
* @dev: the PCI device for which MWI is enabled
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 978aad784..0a7ac863a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1064,6 +1064,7 @@ int pci_set_pcie_reset_state(struct pci_dev *dev, enum pcie_reset_state state);
int pci_set_cacheline_size(struct pci_dev *dev);
#define HAVE_PCI_SET_MWI
int __must_check pci_set_mwi(struct pci_dev *dev);
+int __must_check pcim_set_mwi(struct pci_dev *dev);
int pci_try_set_mwi(struct pci_dev *dev);
void pci_clear_mwi(struct pci_dev *dev);
void pci_intx(struct pci_dev *dev, int enable);
--
2.15.1
^ permalink raw reply related
* [PATCH v2 0/3] r8169: extend PCI core and switch to device-managed functions in probe
From: Heiner Kallweit @ 2017-12-12 6:34 UTC (permalink / raw)
To: Realtek linux nic maintainers, Bjorn Helgaas, David Miller
Cc: netdev@vger.kernel.org, linux-pci@vger.kernel.org
Probe error path and remove callback can be significantly simplified
by using device-managed functions. To be able to do this in the r8169
driver we need a device-managed version of pci_set_mwi first.
v2:
Change patch 1 based on Björn's review comments and add his Acked-by.
Heiner Kallweit (3):
PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi()
r8169: switch to device-managed functions in probe
r8169: remove netif_napi_del in probe error path
drivers/net/ethernet/realtek/r8169.c | 87 +++++++++---------------------------
drivers/pci/pci.c | 25 +++++++++++
include/linux/pci.h | 1 +
3 files changed, 46 insertions(+), 67 deletions(-)
--
2.15.1
^ permalink raw reply
* Re: [PATCH] ptr_ring: add barriers
From: George Cherian @ 2017-12-12 6:28 UTC (permalink / raw)
To: David Miller, mst
Cc: linux-kernel, george.cherian, jasowang, edumazet, netdev,
virtualization
In-Reply-To: <20171211.105308.1899676147655539775.davem@davemloft.net>
Hi David,
On 12/11/2017 09:23 PM, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Tue, 5 Dec 2017 21:29:37 +0200
>
>> Users of ptr_ring expect that it's safe to give the
>> data structure a pointer and have it be available
>> to consumers, but that actually requires an smb_wmb
>> or a stronger barrier.
>>
>> In absence of such barriers and on architectures that reorder writes,
>> consumer might read an un=initialized value from an skb pointer stored
>> in the skb array. This was observed causing crashes.
>>
>> To fix, add memory barriers. The barrier we use is a wmb, the
>> assumption being that producers do not need to read the value so we do
>> not need to order these reads.
>>
>> Reported-by: George Cherian <george.cherian@cavium.com>
>> Suggested-by: Jason Wang <jasowang@redhat.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> I'm asked for asking for testing feedback and did not get it in a
> reasonable amount of time.
>
The tests have completed more than 48 hours without any failures.
I won't interrupt the same and run for longer time.
In case of any issue I will report the same.
> So I'm applying this as-is, and queueing it up for -stable.
>
> Thank you.
Regards,
-George
>
^ permalink raw reply
* Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()
From: Al Viro @ 2017-12-12 6:20 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Linus Torvalds, netdev, linux-kernel
In-Reply-To: <20171211200224.23bc5df4@cakuba.netronome.com>
On Mon, Dec 11, 2017 at 08:02:24PM -0800, Jakub Kicinski wrote:
> On Mon, 11 Dec 2017 15:54:22 +0000, Al Viro wrote:
> > Essentially, it gives helpers for work with bitfields in fixed-endian.
> > Suppose we have e.g. a little-endian 32bit value with fixed layout;
> > expressing that as a bitfield would go like
> > struct foo {
> > unsigned foo:4; /* bits 0..3 */
> > unsigned :2;
> > unsigned bar:12; /* bits 6..17 */
> > unsigned baz:14; /* bits 18..31 */
> > }
> > Even for host-endian it doesn't work all that well - you end up with
> > ifdefs in structure definition and generated code stinks. For fixed-endian
> > it gets really painful, and people tend to use explicit shift-and-mask
> > kind of macros for accessing the fields (and often enough get the
> > endianness conversions wrong, at that). With these primitives
> >
> > struct foo v <=> __le32 v
> > v.foo = i ? 1 : 2 <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
> > f(4 + v.baz) <=> f(4 + le32_get_bits(v, 18, 14))
>
> Looks very useful. The [start bit, size] pair may not land itself
> too nicely to creating defines, though. Which is why in
> include/linux/bitfield.h we tried to use a shifted mask and work
> backwards from that single value what the start and size are. commit
> 3e9b3112ec74 ("add basic register-field manipulation macros") has the
> description. Could a similar trick perhaps be applicable here?
Umm... What's wrong with
#define FIELD_FOO 0,4
#define FIELD_BAR 6,12
#define FIELD_BAZ 18,14
A macro can bloody well expand to any sequence of tokens - le32_get_bits(v, FIELD_BAZ)
will become le32_get_bits(v, 18, 14) just fine. What's the problem with that?
^ permalink raw reply
* [PATCH v5 3/3] dt-bindings: timer: Add andestech atcpit100 timer binding doc
From: Rick Chen @ 2017-12-12 5:47 UTC (permalink / raw)
To: rickchen36, rick, linux-kernel, arnd, linus.walleij,
daniel.lezcano, linux-arch, tglx, jason, marc.zyngier, robh+dt,
netdev, deanbo422, devicetree, viro, dhowells, will.deacon,
linux-serial
Cc: Greentime Hu
In-Reply-To: <1513057621-19084-1-git-send-email-rickchen36@gmail.com>
Add a document to describe Andestech atcpit100 timer and
binding information.
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Signed-off-by: Greentime Hu <green.hu@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/timer/andestech,atcpit100-timer.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
new file mode 100644
index 0000000..14812f68
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt
@@ -0,0 +1,33 @@
+Andestech ATCPIT100 timer
+------------------------------------------------------------------
+ATCPIT100 is a generic IP block from Andes Technology, embedded in
+Andestech AE3XX platforms and other designs.
+
+This timer is a set of compact multi-function timers, which can be
+used as pulse width modulators (PWM) as well as simple timers.
+
+It supports up to 4 PIT channels. Each PIT channel is a
+multi-function timer and provide the following usage scenarios:
+One 32-bit timer
+Two 16-bit timers
+Four 8-bit timers
+One 16-bit PWM
+One 16-bit timer and one 8-bit PWM
+Two 8-bit timer and one 8-bit PWM
+
+Required properties:
+- compatible : Should be "andestech,atcpit100"
+- reg : Address and length of the register set
+- interrupts : Reference to the timer interrupt
+- clocks : a clock to provide the tick rate for "andestech,atcpit100"
+- clock-names : should be "PCLK" for the peripheral clock source.
+
+Examples:
+
+timer0: timer@f0400000 {
+ compatible = "andestech,atcpit100";
+ reg = <0xf0400000 0x1000>;
+ interrupts = <2 4>;
+ clocks = <&apb>;
+ clock-names = "PCLK";
+};
--
2.7.4
^ permalink raw reply related
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