* Re: [PATCH nf-next] netfilter: nft_reject_bridge: remove unnecessary ttl set
From: Taehee Yoo @ 2018-06-11 16:54 UTC (permalink / raw)
To: davem, Steffen Klassert; +Cc: netdev, Taehee Yoo
In-Reply-To: <20180611163505.9827-1-ap420073@gmail.com>
2018-06-12 1:35 GMT+09:00 Taehee Yoo <ap420073@gmail.com>:
> In the nft_reject_br_send_v4_tcp_reset(), a ttl is set by
> the nf_reject_ip_tcphdr_put(). so, below code is unnecessary.
>
> Signed-off-by: Taehee Yoo <ap420073@gmail.com>
> ---
> net/bridge/netfilter/nft_reject_bridge.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/bridge/netfilter/nft_reject_bridge.c b/net/bridge/netfilter/nft_reject_bridge.c
> index eaf05de..e0b082c 100644
> --- a/net/bridge/netfilter/nft_reject_bridge.c
> +++ b/net/bridge/netfilter/nft_reject_bridge.c
> @@ -89,8 +89,7 @@ static void nft_reject_br_send_v4_tcp_reset(struct net *net,
> niph = nf_reject_iphdr_put(nskb, oldskb, IPPROTO_TCP,
> net->ipv4.sysctl_ip_default_ttl);
> nf_reject_ip_tcphdr_put(nskb, oldskb, oth);
> - niph->ttl = net->ipv4.sysctl_ip_default_ttl;
> - niph->tot_len = htons(nskb->len);
> + niph->tot_len = htons(nskb->len);
> ip_send_check(niph);
>
> nft_reject_br_push_etherhdr(oldskb, nskb);
> --
> 2.9.3
>
I'm so sorry, I sent this to you by mistake.
Please ignore this.
Thanks
^ permalink raw reply
* mainline: x86_64: kernel panic: RIP: 0010:__xfrm_policy_check+0xcb/0x690
From: Naresh Kamboju @ 2018-06-11 16:41 UTC (permalink / raw)
To: netdev
Cc: steffen.klassert, David S. Miller, herbert,
open list:KERNEL SELFTEST FRAMEWORK, open list
Kernel panic on x86_64 machine running mainline 4.17.0 kernel while testing
selftests bpf test_tunnel.sh test caused this kernel panic.
I have noticed this kernel panic start happening from
4.17.0-rc7-next-20180529 and still happening on 4.17.0-next-20180608.
[ 213.638287] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000008
++[ ip xfrm poli 213.674036] PGD 0 P4D 0
[ 213.674118] audit: type=1327 audit(1528917683.623:7):
proctitle=6970007866726D00706F6C69637900616464007372630031302E312E312E3130302F3332006473740031302E312E312E3230302F33320064697200696E00746D706C00737263003137322E31362E312E31303000647374003137322E31362E312E3230300070726F746F006573700072657169640031006D6F64650074756E6E
[ 213.677950] Oops: 0000 [#1] SMP PTI
cy[ add src 10.1. 213.677952] CPU: 2 PID: 0 Comm: swapper/2 Tainted:
G W 4.17.0-next-20180608 #1
[ 213.677953] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[ 213.726998] RIP: 0010:__xfrm_policy_check+0xcb/0x690
[ 213.731962] Code: 80 3d 0a d8 f1 00 00 0f 84 c1 02 00 00 4c 8b 25
2b af f4 00 e8 66 a6 6a ff 85 c0 74 0d 80 3d eb d7 f1 00 00 0f 84 d5
02 00 00 <49> 8b 44 24 08 48 85 c0 74 0c 48 8d b5 78 ff ff ff 4c 89 ff
ff d0
1.[100/32 dst 10. 213.750836] RSP: 0018:ffff91cf6fd03a48 EFLAGS: 00010246
[ 213.757441] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000002
[ 213.764566] RDX: ffffffffb863ebe0 RSI: 0000000000000000 RDI: 0000000000000000
[ 213.771688] RBP: ffff91cf6fd03b18 R08: ffffffffb863ebe0 R09: 0000000000000000
[ 213.778813] R10: ffff91cf6fd039d0 R11: 0000000000000000 R12: 0000000000000000
[ 213.785935] R13: ffff91cf5b23d84e R14: ffff91cf5b779f80 R15: ffff91cf5589cc00
[ 213.793062] FS: 0000000000000000(0000) GS:ffff91cf6fd00000(0000)
knlGS:0000000000000000
[ 213.801162] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 213.806900] CR2: 0000000000000008 CR3: 000000004201e001 CR4: 00000000003606e0
[ 213.814025] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 213.821200] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 213.828324] Call Trace:
[ 213.830769] <IRQ>
[ 213.832783] ? trace_hardirqs_on+0xd/0x10
[ 213.836819] __xfrm_policy_check2.constprop.36+0x6c/0xc0
[ 213.842131] tcp_v4_rcv+0x9ef/0xbd0
[ 213.845615] ? ip_local_deliver_finish+0x26/0x340
[ 213.850314] ip_local_deliver_finish+0xc1/0x340
[ 213.854843] ip_local_deliver+0x74/0x220
[ 213.858761] ? inet_del_offload+0x40/0x40
[ 213.862767] ip_rcv_finish+0x1f0/0x550
[ 213.866519] ip_rcv+0x282/0x480
[ 213.869657] ? ip_local_deliver_finish+0x340/0x340
[ 213.874448] __netif_receive_skb_core+0x3b2/0xd30
[ 213.879145] ? lock_acquire+0xd5/0x1c0
[ 213.882891] __netif_receive_skb+0x18/0x60
[ 213.886990] ? __netif_receive_skb+0x18/0x60
[ 213.891252] netif_receive_skb_internal+0x79/0x370
[ 213.896062] napi_gro_receive+0x138/0x1b0
[ 213.900121] igb_poll+0x610/0xe70
[ 213.903440] net_rx_action+0x246/0x4b0
[ 213.907190] ? lock_acquire+0xd5/0x1c0
[ 213.910933] ? igb_msix_ring+0x5e/0x70
[ 213.914681] __do_softirq+0xbf/0x493
[ 213.918260] irq_exit+0xc3/0xd0
[ 213.921405] do_IRQ+0x65/0x110
[ 213.924464] common_interrupt+0xf/0xf
[ 213.928128] </IRQ>
[ 213.930225] RIP: 0010:cpuidle_enter_state+0xa7/0x370
1.[1.200/32 dir i 213.935182] Code: 47 e8 bd 9a 7f ff 48 89 45 d0 0f
1f 44 00 00 31 ff e8 2d a9 7f ff 80 7d c7 00 0f 85 ee 01 00 00 e8 ae
9f 81 ff fb 48 8b 4d d0 <48> 2b 4d c8 48 ba cf f7 53 e3 a5 9b c4 20 48
89 c8 48 c1 f9 3f 48
[ 213.955445] RSP: 0018:ffffab2c01943e38 EFLAGS: 00000246 ORIG_RAX:
ffffffffffffffdc
[ 213.963002] RAX: ffff91cf6fd21ec0 RBX: 0000000000000002 RCX: 00000031bdd50c87
[ 213.970127] RDX: 00000031bdd50c87 RSI: 000000002aaaaaaa RDI: ffffffffb84ab752
[ 213.977250] RBP: ffffab2c01943e78 R08: 0000000000000061 R09: 0000000000000018
[ 213.984375] R10: ffffab2c01943e18 R11: 0000000000000092 R12: ffff91cf5ce88000
[ 213.991497] R13: ffffffffb94cf278 R14: 0000000000000002 R15: ffffffffb94cf260
[ 213.998624] ? cpuidle_enter_state+0xa2/0x370
[ 214.002982] ? cpuidle_enter_state+0xa2/0x370
[ 214.007332] cpuidle_enter+0x17/0x20
[ 214.010902] call_cpuidle+0x23/0x40
[ 214.014387] do_idle+0x1f0/0x250
[ 214.017613] cpu_startup_entry+0x73/0x80
[ 214.021538] start_secondary+0x175/0x1a0
[ 214.025465] secondary_startup_64+0xa5/0xb0
[ 214.029651] Modules linked in: cls_bpf xt_mark algif_hash af_alg
x86_pkg_temp_thermal fuse
[ 214.037941] CR2: 0000000000000008
[ 214.041255] ---[ end trace a0b077febc9b99ca ]---
[ 214.045874] RIP: 0010:__xfrm_policy_check+0xcb/0x690
n tmpl src 172.1[ 214.050838] Code: 80 3d 0a d8 f1 00 00 0f 84 c1 02
00 00 4c 8b 25 2b af f4 00 e8 66 a6 6a ff 85 c0 74 0d 80 3d eb d7 f1
00 00 0f 84 d5 02 00 00 <49> 8b 44 24 08 48 85 c0 74 0c 48 8d b5 78 ff
ff ff 4c 89 ff ff d0
[ 214.071103] RSP: 0018:ffff91cf6fd03a48 EFLAGS: 00010246
[ 214.076327] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000002
[ 214.083451] RDX: ffffffffb863ebe0 RSI: 0000000000000000 RDI: 0000000000000000
[ 214.090574] RBP: ffff91cf6fd03b18 R08: ffffffffb863ebe0 R09: 0000000000000000
[ 214.097699] R10: ffff91cf6fd039d0 R11: 0000000000000000 R12: 0000000000000000
[ 214.104821] R13: ffff91cf5b23d84e R14: ffff91cf5b779f80 R15: ffff91cf5589cc00
[ 214.111945] FS: 0000000000000000(0000) GS:ffff91cf6fd00000(0000)
knlGS:0000000000000000
[ 214.120022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 214.125760] CR2: 0000000000000008 CR3: 000000004201e001 CR4: 00000000003606e0
[ 214.132885] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 214.140009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 214.147131] Kernel panic - not syncing: Fatal exception in interrupt
[ 214.153519] Kernel Offset: 0x36c00000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[ 214.164292] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt ]---
[ 214.171852] ------------[ cut here ]------------
Kconfigs on this kernel,
-------------------------------
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
http://snapshots.linaro.org/openembedded/lkft/morty/intel-core2-32/rpb/linux-next/274/config
Test case source:
--------------------------
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/tools/testing/selftests/bpf/test_tunnel.sh#n565
steps to reproduce:
--------------------------
cd /tools/testing/selftests/bpf/
./test_tunnel.sh
Debugging shows it is coming from function
setup_xfrm_tunnel() {
<trim>
ip xfrm state add src 172.16.1.100 dst 172.16.1.200 proto esp spi 0x1 \
reqid 1 mode tunnel auth-trunc 'hmac(sha1)' \
0x1111111111111111111111111111111111111111 96 enc 'cbc(aes)' \
0x22222222222222222222222222222222
<trim>
}
Complete test log can be found in this location,
https://lkft.validation.linaro.org/scheduler/job/269604#L2092
Best regards
Naresh Kamboju
^ permalink raw reply
* Re: [PATCH 3/6] arcnet: com20020: Add com20020 io mapped version
From: kbuild test robot @ 2018-06-11 16:35 UTC (permalink / raw)
To: Andrea Greco
Cc: kbuild-all, davem, tobin, Andrea Greco, Michael Grzeschik,
linux-kernel, netdev
In-Reply-To: <20180611142635.20712-1-andrea.greco.gapmilano@gmail.com>
Hi Andrea,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-leds-Removed-leds-dependecy/20180611-222941
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/net/arcnet/com20020-io.c:34:45: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:2>*<noident> @@ got sn:2>*<noident> @@
drivers/net/arcnet/com20020-io.c:34:45: expected void [noderef] <asn:2>*<noident>
drivers/net/arcnet/com20020-io.c:34:45: got void *
drivers/net/arcnet/com20020-io.c:39:45: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] <asn:2>*<noident> @@ got sn:2>*<noident> @@
drivers/net/arcnet/com20020-io.c:39:45: expected void [noderef] <asn:2>*<noident>
drivers/net/arcnet/com20020-io.c:39:45: got void *
>> drivers/net/arcnet/com20020-io.c:44:22: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:2>*port @@ got void [noderef] <asn:2>*port @@
drivers/net/arcnet/com20020-io.c:44:22: expected void [noderef] <asn:2>*port
drivers/net/arcnet/com20020-io.c:44:22: got void *[noderef] <asn:2><noident>
drivers/net/arcnet/com20020-io.c:49:23: sparse: incorrect type in argument 1 (different address spaces) @@ expected void [noderef] <asn:2>*port @@ got void [noderef] <asn:2>*port @@
drivers/net/arcnet/com20020-io.c:49:23: expected void [noderef] <asn:2>*port
drivers/net/arcnet/com20020-io.c:49:23: got void *[noderef] <asn:2><noident>
>> drivers/net/arcnet/com20020-io.c:219:19: sparse: cast removes address space of expression
drivers/net/arcnet/com20020-io.c: In function 'io_arc_inb':
drivers/net/arcnet/com20020-io.c:34:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return ioread8((void *__iomem) addr + offset);
^
drivers/net/arcnet/com20020-io.c: In function 'io_arc_outb':
drivers/net/arcnet/com20020-io.c:39:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
iowrite8(value, (void *__iomem)addr + offset);
^
drivers/net/arcnet/com20020-io.c: In function 'io_arc_insb':
drivers/net/arcnet/com20020-io.c:44:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
ioread8_rep((void *__iomem) (addr + offset), buffer, count);
^
drivers/net/arcnet/com20020-io.c: In function 'io_arc_outsb':
drivers/net/arcnet/com20020-io.c:49:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
iowrite8_rep((void *__iomem) (addr + offset), buffer, count);
^
drivers/net/arcnet/com20020-io.c: In function 'com20020_probe':
drivers/net/arcnet/com20020-io.c:219:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
ioaddr = (int)devm_ioremap(&pdev->dev, iores->start,
^
drivers/net/arcnet/com20020-io.c:288:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
^
vim +34 drivers/net/arcnet/com20020-io.c
31
32 static unsigned int io_arc_inb(int addr, int offset)
33 {
> 34 return ioread8((void *__iomem) addr + offset);
35 }
36
37 static void io_arc_outb(int value, int addr, int offset)
38 {
> 39 iowrite8(value, (void *__iomem)addr + offset);
40 }
41
42 static void io_arc_insb(int addr, int offset, void *buffer, int count)
43 {
> 44 ioread8_rep((void *__iomem) (addr + offset), buffer, count);
45 }
46
47 static void io_arc_outsb(int addr, int offset, void *buffer, int count)
48 {
49 iowrite8_rep((void *__iomem) (addr + offset), buffer, count);
50 }
51
52 enum com20020_xtal_freq {
53 freq_10Mhz = 10,
54 freq_20Mhz = 20,
55 };
56
57 enum com20020_arcnet_speed {
58 arc_speed_10M_bps = 10000000,
59 arc_speed_5M_bps = 5000000,
60 arc_speed_2M50_bps = 2500000,
61 arc_speed_1M25_bps = 1250000,
62 arc_speed_625K_bps = 625000,
63 arc_speed_312K5_bps = 312500,
64 arc_speed_156K25_bps = 156250,
65 };
66
67 enum com20020_timeout {
68 arc_timeout_328us = 328000,
69 arc_timeout_164us = 164000,
70 arc_timeout_82us = 82000,
71 arc_timeout_20u5s = 20500,
72 };
73
74 static int setup_clock(int *clockp, int *clockm, int xtal, int arcnet_speed)
75 {
76 int pll_factor, req_clock_frq = 20;
77
78 switch (arcnet_speed) {
79 case arc_speed_10M_bps:
80 req_clock_frq = 80;
81 *clockp = 0;
82 break;
83 case arc_speed_5M_bps:
84 req_clock_frq = 40;
85 *clockp = 0;
86 break;
87 case arc_speed_2M50_bps:
88 *clockp = 0;
89 break;
90 case arc_speed_1M25_bps:
91 *clockp = 1;
92 break;
93 case arc_speed_625K_bps:
94 *clockp = 2;
95 break;
96 case arc_speed_312K5_bps:
97 *clockp = 3;
98 break;
99 case arc_speed_156K25_bps:
100 *clockp = 4;
101 break;
102 default:
103 return -EINVAL;
104 }
105
106 if (xtal != freq_10Mhz && xtal != freq_20Mhz)
107 return -EINVAL;
108
109 pll_factor = (unsigned int)req_clock_frq / xtal;
110
111 switch (pll_factor) {
112 case 1:
113 *clockm = 0;
114 break;
115 case 2:
116 *clockm = 1;
117 break;
118 case 4:
119 *clockm = 3;
120 break;
121 default:
122 return -EINVAL;
123 }
124
125 return 0;
126 }
127
128 static int setup_timeout(int *timeout)
129 {
130 switch (*timeout) {
131 case arc_timeout_328us:
132 *timeout = 0;
133 break;
134 case arc_timeout_164us:
135 *timeout = 1;
136 break;
137 case arc_timeout_82us:
138 *timeout = 2;
139 break;
140 case arc_timeout_20u5s:
141 *timeout = 3;
142 break;
143 default:
144 return -EINVAL;
145 }
146
147 return 0;
148 }
149
150 static int com20020_probe(struct platform_device *pdev)
151 {
152 struct device_node *np;
153 struct net_device *dev;
154 struct arcnet_local *lp;
155 struct resource res, *iores;
156 int ret, phy_reset;
157 u32 timeout, xtal, arc_speed;
158 int clockp, clockm;
159 bool backplane = false;
160 int ioaddr;
161
162 np = pdev->dev.of_node;
163
164 iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
165
166 ret = of_address_to_resource(np, 0, &res);
167 if (ret)
168 return ret;
169
170 ret = of_property_read_u32(np, "timeout-ns", &timeout);
171 if (ret) {
172 dev_err(&pdev->dev, "timeout is required param");
173 return ret;
174 }
175
176 ret = of_property_read_u32(np, "smsc,xtal-mhz", &xtal);
177 if (ret) {
178 dev_err(&pdev->dev, "xtal-mhz is required param");
179 return ret;
180 }
181
182 ret = of_property_read_u32(np, "bus-speed-bps", &arc_speed);
183 if (ret) {
184 dev_err(&pdev->dev, "Bus speed is required param");
185 return ret;
186 }
187
188 if (of_property_read_bool(np, "smsc,backplane-enabled"))
189 backplane = true;
190
191 phy_reset = of_get_named_gpio(np, "reset-gpios", 0);
192 if (!gpio_is_valid(phy_reset)) {
193 dev_err(&pdev->dev, "reset gpio not valid");
194 return phy_reset;
195 }
196
197 ret = devm_gpio_request_one(&pdev->dev, phy_reset, GPIOF_OUT_INIT_LOW,
198 "arcnet-reset");
199 if (ret) {
200 dev_err(&pdev->dev, "failed to get phy reset gpio: %d\n", ret);
201 return ret;
202 }
203
204 dev = alloc_arcdev(NULL);
205 dev->netdev_ops = &com20020_netdev_ops;
206 lp = netdev_priv(dev);
207
208 lp->card_flags = ARC_CAN_10MBIT;
209
210 /* Peak random address,
211 * if required user could set a new-one in userspace
212 */
213 get_random_bytes(dev->dev_addr, dev->addr_len);
214
215 if (!devm_request_mem_region(&pdev->dev, res.start, resource_size(&res),
216 lp->card_name))
217 return -EBUSY;
218
> 219 ioaddr = (int)devm_ioremap(&pdev->dev, iores->start,
220 resource_size(iores));
221 if (!ioaddr) {
222 dev_err(&pdev->dev, "ioremap fallied\n");
223 return -ENOMEM;
224 }
225
226 gpio_set_value_cansleep(phy_reset, 0);
227 ndelay(RESET_DELAY);
228 gpio_set_value_cansleep(phy_reset, 1);
229
230 lp->hw.arc_inb = io_arc_inb;
231 lp->hw.arc_outb = io_arc_outb;
232 lp->hw.arc_insb = io_arc_insb;
233 lp->hw.arc_outsb = io_arc_outsb;
234
235 /* ARCNET controller needs this access to detect bustype */
236 lp->hw.arc_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
237 lp->hw.arc_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
238
239 dev->base_addr = (unsigned long)ioaddr;
240
241 dev->irq = of_get_named_gpio(np, "interrupts", 0);
242 if (dev->irq == -EPROBE_DEFER) {
243 return dev->irq;
244 } else if (!gpio_is_valid(dev->irq)) {
245 dev_err(&pdev->dev, "irq-gpios not valid !");
246 return -EIO;
247 }
248 dev->irq = gpio_to_irq(dev->irq);
249
250 ret = setup_clock(&clockp, &clockm, xtal, arc_speed);
251 if (ret) {
252 dev_err(&pdev->dev,
253 "Impossible use oscillator:%dMhz and arcnet bus speed:%dKbps",
254 xtal, arc_speed / 1000);
255 return ret;
256 }
257
258 ret = setup_timeout(&timeout);
259 if (ret) {
260 dev_err(&pdev->dev, "Timeout:%d is not valid value", timeout);
261 return ret;
262 }
263
264 lp->backplane = (int)backplane;
265 lp->timeout = timeout;
266 lp->clockm = clockm;
267 lp->clockp = clockp;
268 lp->hw.owner = THIS_MODULE;
269
270 if (lp->hw.arc_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
271 ret = -EIO;
272 goto err_release_mem;
273 }
274
275 if (com20020_check(dev)) {
276 ret = -EIO;
277 goto err_release_mem;
278 }
279
280 ret = com20020_found(dev, IRQF_TRIGGER_FALLING);
281 if (ret)
282 goto err_release_mem;
283
284 dev_dbg(&pdev->dev, "probe Done\n");
285 return 0;
286
287 err_release_mem:
288 devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
289 devm_release_mem_region(&pdev->dev, res.start, resource_size(&res));
290 dev_err(&pdev->dev, "probe failed!\n");
291 return ret;
292 }
293
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH nf-next] netfilter: nft_reject_bridge: remove unnecessary ttl set
From: Taehee Yoo @ 2018-06-11 16:35 UTC (permalink / raw)
To: davem, steffen.klassert; +Cc: netdev, Taehee Yoo
In the nft_reject_br_send_v4_tcp_reset(), a ttl is set by
the nf_reject_ip_tcphdr_put(). so, below code is unnecessary.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
---
net/bridge/netfilter/nft_reject_bridge.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/netfilter/nft_reject_bridge.c b/net/bridge/netfilter/nft_reject_bridge.c
index eaf05de..e0b082c 100644
--- a/net/bridge/netfilter/nft_reject_bridge.c
+++ b/net/bridge/netfilter/nft_reject_bridge.c
@@ -89,8 +89,7 @@ static void nft_reject_br_send_v4_tcp_reset(struct net *net,
niph = nf_reject_iphdr_put(nskb, oldskb, IPPROTO_TCP,
net->ipv4.sysctl_ip_default_ttl);
nf_reject_ip_tcphdr_put(nskb, oldskb, oth);
- niph->ttl = net->ipv4.sysctl_ip_default_ttl;
- niph->tot_len = htons(nskb->len);
+ niph->tot_len = htons(nskb->len);
ip_send_check(niph);
nft_reject_br_push_etherhdr(oldskb, nskb);
--
2.9.3
^ permalink raw reply related
* [PULL] vhost: cleanups and fixes
From: Michael S. Tsirkin @ 2018-06-11 16:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: ohad, kevin, kvm, mst, netdev, liang.z.li, linux-remoteproc,
linux-kernel, stable, bjorn.andersson, mhocko, mhocko,
syzbot+87cfa083e727a224754b, akpm, virtualization
The following changes since commit 29dcea88779c856c7dc92040a0c01233263101d4:
Linux 4.17 (2018-06-03 14:15:21 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
for you to fetch changes up to aa15783ee62d57d69433101ede3e3ed11e48161d:
virtio: update the comments for transport features (2018-06-07 22:17:40 +0300)
----------------------------------------------------------------
virtio, vhost: features, fixes
VF support for virtio.
Free page hint request support for VM migration.
DMA barriers for virtio strong barriers.
Bugfixes.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
----------------------------------------------------------------
Michael S. Tsirkin (2):
virtio_ring: switch to dma_XX barriers for rpmsg
vhost: fix info leak due to uninitialized memory
Tiwei Bie (2):
virtio_pci: support enabling VFs
virtio: update the comments for transport features
Wei Wang (4):
mm: support reporting free page blocks
virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
mm/page_poison: expose page_poisoning_enabled to kernel modules
virtio-balloon: VIRTIO_BALLOON_F_PAGE_POISON
drivers/vhost/vhost.c | 3 +
drivers/virtio/virtio_balloon.c | 298 +++++++++++++++++++++++++++++++-----
drivers/virtio/virtio_pci_common.c | 30 ++++
drivers/virtio/virtio_pci_modern.c | 14 ++
include/linux/mm.h | 6 +
include/linux/virtio_ring.h | 4 +-
include/uapi/linux/virtio_balloon.h | 7 +
include/uapi/linux/virtio_config.h | 16 +-
mm/page_alloc.c | 97 ++++++++++++
mm/page_poison.c | 6 +
10 files changed, 439 insertions(+), 42 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)
From: Ricardo Ribalda Delgado @ 2018-06-11 16:21 UTC (permalink / raw)
To: Marcel Holtmann
Cc: LKML, open list:SERIAL DRIVERS, Lino Sanfilippo, David Miller,
Stefan Wahren, Rob Herring, Johan Hovold, netdev
In-Reply-To: <07871EF5-D1D3-4677-8100-B5E7F14DB302@holtmann.org>
Hi Marcel,
On Mon, Jun 11, 2018 at 5:52 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Ricardo,
>
> >>>> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export?
> >>>
> >>> The main purpose is to autoload drivers for devices that have been
> >>> created via sysfs or another module.
> >>>
> >>> Eg1: We have a serial port on a standard computer that has connected a
> >>> GPS module. Since it is something that is not in the ACPI nor the DT
> >>> table the user will run
> >>>
> >>> echo serdev_gps > /sys/bus/serial/devices/serial0/new_device
> >>>
> >>> Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c
> >>>
> >>> Modprobe does not know what module to load for that device unless
> >>> there is a matching MODULE_DEVICE_TABLE
> >>> Today, we have the same functionality for i2c devices
> >>> https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
> >>
> >> but why does this have to be the driver name? I would rather say, create a generic string that describes the hardware and then use that. I think you also want the special handling, as from USB for example, that lets you reference an existing .compatible or ACPI ID as reference so that the driver_data is copied.
> >
> > We can choose any name, but if there are no special variants (like the
> > rave-sp driver) I would prefer using the module name. We can of course
> > use more names, like the part number of the the device, but it is very
> > convenient to also use the module name, and other subsystems also do
> > that.
> >
> > If you want to add specific names for this device please let me know
> > and I will add them to the list. You know much more about this module
> > than myself.
>
> if we want to use the driver name, then why not build this into the new_device handling itself instead of duplicating that name in each serdev_device_id table. What is the reference here? For example platform device do matching on driver name if I recall this correctly.
We do the matching also over driver name at serdev_device_match():
if (sdrv->id_table)
return !!serdev_match_id(sdrv->id_table, sdev);
return strcmp(sdev->modalias, drv->name) == 0;
This is just for the module autoloading
>
> However what is most important is that device_get_match_data() actually works. There should be no difference between DT, ACPI or a dynamic device.
Agree, will take a look to this tomorrow morning.
>
> Regards
>
> Marcel
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH 3/6] arcnet: com20020: Add com20020 io mapped version
From: kbuild test robot @ 2018-06-11 16:15 UTC (permalink / raw)
To: Andrea Greco
Cc: kbuild-all, davem, tobin, Andrea Greco, Michael Grzeschik,
linux-kernel, netdev
In-Reply-To: <20180611142635.20712-1-andrea.greco.gapmilano@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 9979 bytes --]
Hi Andrea,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
[also build test WARNING on v4.17 next-20180608]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andrea-Greco/arcnet-leds-Removed-leds-dependecy/20180611-222941
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sparc64
All warnings (new ones prefixed by >>):
drivers/net//arcnet/com20020-io.c: In function 'io_arc_inb':
>> drivers/net//arcnet/com20020-io.c:34:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
return ioread8((void *__iomem) addr + offset);
^
drivers/net//arcnet/com20020-io.c: In function 'io_arc_outb':
drivers/net//arcnet/com20020-io.c:39:18: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
iowrite8(value, (void *__iomem)addr + offset);
^
drivers/net//arcnet/com20020-io.c: In function 'io_arc_insb':
drivers/net//arcnet/com20020-io.c:44:14: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
ioread8_rep((void *__iomem) (addr + offset), buffer, count);
^
drivers/net//arcnet/com20020-io.c: In function 'io_arc_outsb':
drivers/net//arcnet/com20020-io.c:49:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
iowrite8_rep((void *__iomem) (addr + offset), buffer, count);
^
drivers/net//arcnet/com20020-io.c: In function 'com20020_probe':
>> drivers/net//arcnet/com20020-io.c:219:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
ioaddr = (int)devm_ioremap(&pdev->dev, iores->start,
^
drivers/net//arcnet/com20020-io.c:288:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
^
vim +34 drivers/net//arcnet/com20020-io.c
31
32 static unsigned int io_arc_inb(int addr, int offset)
33 {
> 34 return ioread8((void *__iomem) addr + offset);
35 }
36
37 static void io_arc_outb(int value, int addr, int offset)
38 {
39 iowrite8(value, (void *__iomem)addr + offset);
40 }
41
42 static void io_arc_insb(int addr, int offset, void *buffer, int count)
43 {
> 44 ioread8_rep((void *__iomem) (addr + offset), buffer, count);
45 }
46
47 static void io_arc_outsb(int addr, int offset, void *buffer, int count)
48 {
49 iowrite8_rep((void *__iomem) (addr + offset), buffer, count);
50 }
51
52 enum com20020_xtal_freq {
53 freq_10Mhz = 10,
54 freq_20Mhz = 20,
55 };
56
57 enum com20020_arcnet_speed {
58 arc_speed_10M_bps = 10000000,
59 arc_speed_5M_bps = 5000000,
60 arc_speed_2M50_bps = 2500000,
61 arc_speed_1M25_bps = 1250000,
62 arc_speed_625K_bps = 625000,
63 arc_speed_312K5_bps = 312500,
64 arc_speed_156K25_bps = 156250,
65 };
66
67 enum com20020_timeout {
68 arc_timeout_328us = 328000,
69 arc_timeout_164us = 164000,
70 arc_timeout_82us = 82000,
71 arc_timeout_20u5s = 20500,
72 };
73
74 static int setup_clock(int *clockp, int *clockm, int xtal, int arcnet_speed)
75 {
76 int pll_factor, req_clock_frq = 20;
77
78 switch (arcnet_speed) {
79 case arc_speed_10M_bps:
80 req_clock_frq = 80;
81 *clockp = 0;
82 break;
83 case arc_speed_5M_bps:
84 req_clock_frq = 40;
85 *clockp = 0;
86 break;
87 case arc_speed_2M50_bps:
88 *clockp = 0;
89 break;
90 case arc_speed_1M25_bps:
91 *clockp = 1;
92 break;
93 case arc_speed_625K_bps:
94 *clockp = 2;
95 break;
96 case arc_speed_312K5_bps:
97 *clockp = 3;
98 break;
99 case arc_speed_156K25_bps:
100 *clockp = 4;
101 break;
102 default:
103 return -EINVAL;
104 }
105
106 if (xtal != freq_10Mhz && xtal != freq_20Mhz)
107 return -EINVAL;
108
109 pll_factor = (unsigned int)req_clock_frq / xtal;
110
111 switch (pll_factor) {
112 case 1:
113 *clockm = 0;
114 break;
115 case 2:
116 *clockm = 1;
117 break;
118 case 4:
119 *clockm = 3;
120 break;
121 default:
122 return -EINVAL;
123 }
124
125 return 0;
126 }
127
128 static int setup_timeout(int *timeout)
129 {
130 switch (*timeout) {
131 case arc_timeout_328us:
132 *timeout = 0;
133 break;
134 case arc_timeout_164us:
135 *timeout = 1;
136 break;
137 case arc_timeout_82us:
138 *timeout = 2;
139 break;
140 case arc_timeout_20u5s:
141 *timeout = 3;
142 break;
143 default:
144 return -EINVAL;
145 }
146
147 return 0;
148 }
149
150 static int com20020_probe(struct platform_device *pdev)
151 {
152 struct device_node *np;
153 struct net_device *dev;
154 struct arcnet_local *lp;
155 struct resource res, *iores;
156 int ret, phy_reset;
157 u32 timeout, xtal, arc_speed;
158 int clockp, clockm;
159 bool backplane = false;
160 int ioaddr;
161
162 np = pdev->dev.of_node;
163
164 iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
165
166 ret = of_address_to_resource(np, 0, &res);
167 if (ret)
168 return ret;
169
170 ret = of_property_read_u32(np, "timeout-ns", &timeout);
171 if (ret) {
172 dev_err(&pdev->dev, "timeout is required param");
173 return ret;
174 }
175
176 ret = of_property_read_u32(np, "smsc,xtal-mhz", &xtal);
177 if (ret) {
178 dev_err(&pdev->dev, "xtal-mhz is required param");
179 return ret;
180 }
181
182 ret = of_property_read_u32(np, "bus-speed-bps", &arc_speed);
183 if (ret) {
184 dev_err(&pdev->dev, "Bus speed is required param");
185 return ret;
186 }
187
188 if (of_property_read_bool(np, "smsc,backplane-enabled"))
189 backplane = true;
190
191 phy_reset = of_get_named_gpio(np, "reset-gpios", 0);
192 if (!gpio_is_valid(phy_reset)) {
193 dev_err(&pdev->dev, "reset gpio not valid");
194 return phy_reset;
195 }
196
197 ret = devm_gpio_request_one(&pdev->dev, phy_reset, GPIOF_OUT_INIT_LOW,
198 "arcnet-reset");
199 if (ret) {
200 dev_err(&pdev->dev, "failed to get phy reset gpio: %d\n", ret);
201 return ret;
202 }
203
204 dev = alloc_arcdev(NULL);
205 dev->netdev_ops = &com20020_netdev_ops;
206 lp = netdev_priv(dev);
207
208 lp->card_flags = ARC_CAN_10MBIT;
209
210 /* Peak random address,
211 * if required user could set a new-one in userspace
212 */
213 get_random_bytes(dev->dev_addr, dev->addr_len);
214
215 if (!devm_request_mem_region(&pdev->dev, res.start, resource_size(&res),
216 lp->card_name))
217 return -EBUSY;
218
> 219 ioaddr = (int)devm_ioremap(&pdev->dev, iores->start,
220 resource_size(iores));
221 if (!ioaddr) {
222 dev_err(&pdev->dev, "ioremap fallied\n");
223 return -ENOMEM;
224 }
225
226 gpio_set_value_cansleep(phy_reset, 0);
227 ndelay(RESET_DELAY);
228 gpio_set_value_cansleep(phy_reset, 1);
229
230 lp->hw.arc_inb = io_arc_inb;
231 lp->hw.arc_outb = io_arc_outb;
232 lp->hw.arc_insb = io_arc_insb;
233 lp->hw.arc_outsb = io_arc_outsb;
234
235 /* ARCNET controller needs this access to detect bustype */
236 lp->hw.arc_outb(0x00, ioaddr, COM20020_REG_W_COMMAND);
237 lp->hw.arc_inb(ioaddr, COM20020_REG_R_DIAGSTAT);
238
239 dev->base_addr = (unsigned long)ioaddr;
240
241 dev->irq = of_get_named_gpio(np, "interrupts", 0);
242 if (dev->irq == -EPROBE_DEFER) {
243 return dev->irq;
244 } else if (!gpio_is_valid(dev->irq)) {
245 dev_err(&pdev->dev, "irq-gpios not valid !");
246 return -EIO;
247 }
248 dev->irq = gpio_to_irq(dev->irq);
249
250 ret = setup_clock(&clockp, &clockm, xtal, arc_speed);
251 if (ret) {
252 dev_err(&pdev->dev,
253 "Impossible use oscillator:%dMhz and arcnet bus speed:%dKbps",
254 xtal, arc_speed / 1000);
255 return ret;
256 }
257
258 ret = setup_timeout(&timeout);
259 if (ret) {
260 dev_err(&pdev->dev, "Timeout:%d is not valid value", timeout);
261 return ret;
262 }
263
264 lp->backplane = (int)backplane;
265 lp->timeout = timeout;
266 lp->clockm = clockm;
267 lp->clockp = clockp;
268 lp->hw.owner = THIS_MODULE;
269
270 if (lp->hw.arc_inb(ioaddr, COM20020_REG_R_STATUS) == 0xFF) {
271 ret = -EIO;
272 goto err_release_mem;
273 }
274
275 if (com20020_check(dev)) {
276 ret = -EIO;
277 goto err_release_mem;
278 }
279
280 ret = com20020_found(dev, IRQF_TRIGGER_FALLING);
281 if (ret)
282 goto err_release_mem;
283
284 dev_dbg(&pdev->dev, "probe Done\n");
285 return 0;
286
287 err_release_mem:
288 devm_iounmap(&pdev->dev, (void __iomem *)ioaddr);
289 devm_release_mem_region(&pdev->dev, res.start, resource_size(&res));
290 dev_err(&pdev->dev, "probe failed!\n");
291 return ret;
292 }
293
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54207 bytes --]
^ permalink raw reply
* [net 5/5] ixgbe: Fix bit definitions and add support for testing for ipsec support
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch addresses two issues. First it adds the correct bit definitions
for the SECTXSTAT and SECRXSTAT registers. Then it makes use of those
definitions to test for if IPsec has been disabled on the part and if so we
do not enable it.
CC: stable <stable@vger.kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Reported-by: Andre Tomt <andre@tomt.net>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 14 +++++++++++++-
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 6 ++++--
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 7b23fb0c2d07..c116f459945d 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -975,10 +975,22 @@ void ixgbe_ipsec_rx(struct ixgbe_ring *rx_ring,
**/
void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter)
{
+ struct ixgbe_hw *hw = &adapter->hw;
struct ixgbe_ipsec *ipsec;
+ u32 t_dis, r_dis;
size_t size;
- if (adapter->hw.mac.type == ixgbe_mac_82598EB)
+ if (hw->mac.type == ixgbe_mac_82598EB)
+ return;
+
+ /* If there is no support for either Tx or Rx offload
+ * we should not be advertising support for IPsec.
+ */
+ t_dis = IXGBE_READ_REG(hw, IXGBE_SECTXSTAT) &
+ IXGBE_SECTXSTAT_SECTX_OFF_DIS;
+ r_dis = IXGBE_READ_REG(hw, IXGBE_SECRXSTAT) &
+ IXGBE_SECRXSTAT_SECRX_OFF_DIS;
+ if (t_dis || r_dis)
return;
ipsec = kzalloc(sizeof(*ipsec), GFP_KERNEL);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
index e8ed37749ab1..44cfb2021145 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_type.h
@@ -599,13 +599,15 @@ struct ixgbe_nvm_version {
#define IXGBE_SECTXCTRL_STORE_FORWARD 0x00000004
#define IXGBE_SECTXSTAT_SECTX_RDY 0x00000001
-#define IXGBE_SECTXSTAT_ECC_TXERR 0x00000002
+#define IXGBE_SECTXSTAT_SECTX_OFF_DIS 0x00000002
+#define IXGBE_SECTXSTAT_ECC_TXERR 0x00000004
#define IXGBE_SECRXCTRL_SECRX_DIS 0x00000001
#define IXGBE_SECRXCTRL_RX_DIS 0x00000002
#define IXGBE_SECRXSTAT_SECRX_RDY 0x00000001
-#define IXGBE_SECRXSTAT_ECC_RXERR 0x00000002
+#define IXGBE_SECRXSTAT_SECRX_OFF_DIS 0x00000002
+#define IXGBE_SECRXSTAT_ECC_RXERR 0x00000004
/* LinkSec (MacSec) Registers */
#define IXGBE_LSECTXCAP 0x08A00
--
2.17.1
^ permalink raw reply related
* [net 4/5] ixgbe: Avoid loopback and fix boolean logic in ipsec_stop_data
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch fixes two issues. First we add an early test for the Tx and Rx
security block ready bits. By doing this we can avoid the need for waits or
loopback in the event that the security block is already flushed out.
Secondly we fix the boolean logic that was testing for the Tx OR Rx ready
bits being set and change it so that we only exit if the Tx AND Rx ready
bits are both set.
CC: stable <stable@vger.kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 38d8cf75e9ad..7b23fb0c2d07 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -158,7 +158,16 @@ static void ixgbe_ipsec_stop_data(struct ixgbe_adapter *adapter)
reg |= IXGBE_SECRXCTRL_RX_DIS;
IXGBE_WRITE_REG(hw, IXGBE_SECRXCTRL, reg);
- IXGBE_WRITE_FLUSH(hw);
+ /* If both Tx and Rx are ready there are no packets
+ * that we need to flush so the loopback configuration
+ * below is not necessary.
+ */
+ t_rdy = IXGBE_READ_REG(hw, IXGBE_SECTXSTAT) &
+ IXGBE_SECTXSTAT_SECTX_RDY;
+ r_rdy = IXGBE_READ_REG(hw, IXGBE_SECRXSTAT) &
+ IXGBE_SECRXSTAT_SECRX_RDY;
+ if (t_rdy && r_rdy)
+ return;
/* If the tx fifo doesn't have link, but still has data,
* we can't clear the tx sec block. Set the MAC loopback
@@ -185,7 +194,7 @@ static void ixgbe_ipsec_stop_data(struct ixgbe_adapter *adapter)
IXGBE_SECTXSTAT_SECTX_RDY;
r_rdy = IXGBE_READ_REG(hw, IXGBE_SECRXSTAT) &
IXGBE_SECRXSTAT_SECRX_RDY;
- } while (!t_rdy && !r_rdy && limit--);
+ } while (!(t_rdy && r_rdy) && limit--);
/* undo loopback if we played with it earlier */
if (!link) {
--
2.17.1
^ permalink raw reply related
* [net 3/5] ixgbe: Move ipsec init function to before reset call
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch moves the IPsec init function in ixgbe_sw_init. This way it is a
bit more consistent with the placement of similar initialization functions
and is placed before the reset_hw call which should allow us to clean up
any link issues that may be introduced by the fact that we force the link
up if somehow the device had IPsec still enabled before the driver was
loaded.
In addition to the function move it is necessary to change the assignment
of netdev->features. The easiest way to do this is to just test for the
existence of adapter->ipsec and if it is present we set the feature bits.
CC: stable <stable@vger.kernel.org>
Fixes: 49a94d74d948 ("ixgbe: add ipsec engine start and stop routines")
Reported-by: Andre Tomt <andre@tomt.net>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 7 -------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 11 +++++++++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
index 344a1f213a5f..38d8cf75e9ad 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
@@ -1001,13 +1001,6 @@ void ixgbe_init_ipsec_offload(struct ixgbe_adapter *adapter)
adapter->netdev->xfrmdev_ops = &ixgbe_xfrmdev_ops;
-#define IXGBE_ESP_FEATURES (NETIF_F_HW_ESP | \
- NETIF_F_HW_ESP_TX_CSUM | \
- NETIF_F_GSO_ESP)
-
- adapter->netdev->features |= IXGBE_ESP_FEATURES;
- adapter->netdev->hw_enc_features |= IXGBE_ESP_FEATURES;
-
return;
err2:
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index a925f05ec342..8d061af276d3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6117,6 +6117,7 @@ static int ixgbe_sw_init(struct ixgbe_adapter *adapter,
#ifdef CONFIG_IXGBE_DCB
ixgbe_init_dcb(adapter);
#endif
+ ixgbe_init_ipsec_offload(adapter);
/* default flow control settings */
hw->fc.requested_mode = ixgbe_fc_full;
@@ -10429,6 +10430,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
if (hw->mac.type >= ixgbe_mac_82599EB)
netdev->features |= NETIF_F_SCTP_CRC;
+#ifdef CONFIG_XFRM_OFFLOAD
+#define IXGBE_ESP_FEATURES (NETIF_F_HW_ESP | \
+ NETIF_F_HW_ESP_TX_CSUM | \
+ NETIF_F_GSO_ESP)
+
+ if (adapter->ipsec)
+ netdev->features |= IXGBE_ESP_FEATURES;
+#endif
/* copy netdev features into list of user selectable features */
netdev->hw_features |= netdev->features |
NETIF_F_HW_VLAN_CTAG_FILTER |
@@ -10491,8 +10500,6 @@ static int ixgbe_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
NETIF_F_FCOE_MTU;
}
#endif /* IXGBE_FCOE */
- ixgbe_init_ipsec_offload(adapter);
-
if (adapter->flags2 & IXGBE_FLAG2_RSC_CAPABLE)
netdev->hw_features |= NETIF_F_LRO;
if (adapter->flags2 & IXGBE_FLAG2_RSC_ENABLED)
--
2.17.1
^ permalink raw reply related
* [net 2/5] ixgbe: Use CONFIG_XFRM_OFFLOAD instead of CONFIG_XFRM
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
There is no point in adding code if CONFIG_XFRM is defined that we won't
use unless CONFIG_XFRM_OFFLOAD is defined. So instead of leaving this code
floating around I am replacing the ifdef with what I believe is the correct
one so that we only include the code and variables if they will actually be
used.
CC: stable <stable@vger.kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4 ++--
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index fc534e91c6b2..144d5fe6b944 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -760,9 +760,9 @@ struct ixgbe_adapter {
#define IXGBE_RSS_KEY_SIZE 40 /* size of RSS Hash Key in bytes */
u32 *rss_key;
-#ifdef CONFIG_XFRM
+#ifdef CONFIG_XFRM_OFFLOAD
struct ixgbe_ipsec *ipsec;
-#endif /* CONFIG_XFRM */
+#endif /* CONFIG_XFRM_OFFLOAD */
};
static inline u8 ixgbe_max_rss_indices(struct ixgbe_adapter *adapter)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index f9e0dc041cfb..a925f05ec342 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9896,7 +9896,7 @@ ixgbe_features_check(struct sk_buff *skb, struct net_device *dev,
* the TSO, so it's the exception.
*/
if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) {
-#ifdef CONFIG_XFRM
+#ifdef CONFIG_XFRM_OFFLOAD
if (!skb->sp)
#endif
features &= ~NETIF_F_TSO;
--
2.17.1
^ permalink raw reply related
* [net 1/5] ixgbe: Fix setting of TC configuration for macvlan case
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem
Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene, stable,
Jeff Kirsher
In-Reply-To: <20180611161630.21338-1-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <alexander.h.duyck@intel.com>
When we were enabling macvlan interfaces we weren't correctly configuring
things until ixgbe_setup_tc was called a second time either by tweaking the
number of queues or increasing the macvlan count past 15.
The issue came down to the fact that num_rx_pools is not populated until
after the queues and interrupts are reinitialized.
Instead of trying to set it sooner we can just move the call to setup at
least 1 traffic class to the SR-IOV/VMDq setup function so that we just set
it for this one case. We already had a spot that was configuring the queues
for TC 0 in the code here anyway so it makes sense to also set the number
of TCs here as well.
CC: stable <stable@vger.kernel.org>
Fixes: 49cfbeb7a95c ("ixgbe: Fix handling of macvlan Tx offload")
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 8 ++++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 --------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
index 893a9206e718..d361f570ca37 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c
@@ -593,6 +593,14 @@ static bool ixgbe_set_sriov_queues(struct ixgbe_adapter *adapter)
}
#endif
+ /* To support macvlan offload we have to use num_tc to
+ * restrict the queues that can be used by the device.
+ * By doing this we can avoid reporting a false number of
+ * queues.
+ */
+ if (vmdq_i > 1)
+ netdev_set_num_tc(adapter->netdev, 1);
+
/* populate TC0 for use by pool 0 */
netdev_set_tc_queue(adapter->netdev, 0,
adapter->num_rx_queues_per_pool, 0);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 4929f7265598..f9e0dc041cfb 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -8822,14 +8822,6 @@ int ixgbe_setup_tc(struct net_device *dev, u8 tc)
} else {
netdev_reset_tc(dev);
- /* To support macvlan offload we have to use num_tc to
- * restrict the queues that can be used by the device.
- * By doing this we can avoid reporting a false number of
- * queues.
- */
- if (!tc && adapter->num_rx_pools > 1)
- netdev_set_num_tc(dev, 1);
-
if (adapter->hw.mac.type == ixgbe_mac_82598EB)
adapter->hw.fc.requested_mode = adapter->last_lfc_mode;
--
2.17.1
^ permalink raw reply related
* [net 0/5][pull request] Intel Wired LAN Driver Updates 2018-06-11
From: Jeff Kirsher @ 2018-06-11 16:16 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains fixes to ixgbe IPsec and MACVLAN.
Alex provides the 5 fixes in this series, starting with fixing an issue
where num_rx_pools was not being populated until after the queues and
interrupts were reinitialized when enabling MACVLAN interfaces. Updated
to use CONFIG_XFRM_OFFLOAD instead of CONFIG_XFRM, since the code
requires CONFIG_XFRM_OFFLOAD to be enabled. Moved the IPsec
initialization function to be more consistent with the placement of
similar initialization functions and before the call to reset the
hardware, which will clean up any link issues that may have been
introduced. Fixed the boolean logic that was testing for transmit OR
receive ready bits, when it should have been testing for transmit AND
receive ready bits. Fixed the bit definitions for SECTXSTAT and SECRXSTAT
registers and ensure that if IPsec is disabled on the part, do not
enable it.
The following are changes since commit f0dc7f9c6dd99891611fca5849cbc4c6965b690e:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue 10GbE
Alexander Duyck (5):
ixgbe: Fix setting of TC configuration for macvlan case
ixgbe: Use CONFIG_XFRM_OFFLOAD instead of CONFIG_XFRM
ixgbe: Move ipsec init function to before reset call
ixgbe: Avoid loopback and fix boolean logic in ipsec_stop_data
ixgbe: Fix bit definitions and add support for testing for ipsec
support
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 4 +--
.../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 34 +++++++++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 8 +++++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 21 ++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 6 ++--
5 files changed, 48 insertions(+), 25 deletions(-)
--
2.17.1
^ permalink raw reply
* Re: [PATCH net] ipv6: allow PMTU exceptions to local routes
From: Martin KaFai Lau @ 2018-06-11 16:07 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David Miller, netdev, kernel-team, lvs-devel
In-Reply-To: <20180610230254.6347-1-ja@ssi.bg>
On Mon, Jun 11, 2018 at 02:02:54AM +0300, Julian Anastasov wrote:
> IPVS setups with local client and remote tunnel server need
> to create exception for the local virtual IP. What we do is to
> change PMTU from 64KB (on "lo") to 1460 in the common case.
>
> Suggested-by: Martin KaFai Lau <kafai@fb.com>
> Fixes: 45e4fd26683c ("ipv6: Only create RTF_CACHE routes after encountering pmtu exception")
> Fixes: 7343ff31ebf0 ("ipv6: Don't create clones of host routes.")
> Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* locking in wimax/i2400m
From: Sebastian Andrzej Siewior @ 2018-06-11 16:05 UTC (permalink / raw)
To: Inaky Perez-Gonzalez, linux-wimax; +Cc: netdev, tglx
I tried to figure out if the URB-completion handler uses any locking and
stumbled here.
i2400m_pm_notifier() is called from process context. This function
invokes i2400m_fw_cache() + i2400m_fw_uncache(). Both functions do
spin_lock(&i2400m->rx_lock);
while in other places (say i2400mu_rxd()) it does
spin_lock_irqsave(&i2400m->rx_lock, flags);
So what do I miss? Is this lock never used in interrupt context and
lockdep didn't complain or did nobody try suspend with this driver
before?
>From what I can tell i2400m_dev_bootstrap() has the same locking
problem.
While here, I noticed that i2400m_fw_cache() does use GFP_ATOMIC which
should be GFP_KERNEL since the context can't be atomic at this point
(there is even request_firmware() later on).
I am also curious why there is NULL and ~0 because it does not seem to
make a difference in i2400m_fw_uncache() but I'm more interested in
the locking bits :)
Sebastian
^ permalink raw reply
* Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)
From: Marcel Holtmann @ 2018-06-11 15:52 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: LKML, open list:SERIAL DRIVERS, Lino Sanfilippo, David S. Miller,
Stefan Wahren, Rob Herring, Johan Hovold, netdev
In-Reply-To: <CAPybu_2ViGvN6egz-Ajq4+1fv6VAVFswuvSPAVmYH0a9R-Yjvw@mail.gmail.com>
Hi Ricardo,
>>>> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export?
>>>
>>> The main purpose is to autoload drivers for devices that have been
>>> created via sysfs or another module.
>>>
>>> Eg1: We have a serial port on a standard computer that has connected a
>>> GPS module. Since it is something that is not in the ACPI nor the DT
>>> table the user will run
>>>
>>> echo serdev_gps > /sys/bus/serial/devices/serial0/new_device
>>>
>>> Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c
>>>
>>> Modprobe does not know what module to load for that device unless
>>> there is a matching MODULE_DEVICE_TABLE
>>> Today, we have the same functionality for i2c devices
>>> https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
>>
>> but why does this have to be the driver name? I would rather say, create a generic string that describes the hardware and then use that. I think you also want the special handling, as from USB for example, that lets you reference an existing .compatible or ACPI ID as reference so that the driver_data is copied.
>
> We can choose any name, but if there are no special variants (like the
> rave-sp driver) I would prefer using the module name. We can of course
> use more names, like the part number of the the device, but it is very
> convenient to also use the module name, and other subsystems also do
> that.
>
> If you want to add specific names for this device please let me know
> and I will add them to the list. You know much more about this module
> than myself.
if we want to use the driver name, then why not build this into the new_device handling itself instead of duplicating that name in each serdev_device_id table. What is the reference here? For example platform device do matching on driver name if I recall this correctly.
However what is most important is that device_get_match_data() actually works. There should be no difference between DT, ACPI or a dynamic device.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm: Configure SCO routing automatically
From: Marcel Holtmann @ 2018-06-11 15:47 UTC (permalink / raw)
To: Rob Herring
Cc: Attila Tőkés, David S. Miller, Mark Rutland,
Johan Hedberg, Artiom Vaskov, netdev, devicetree,
linux-kernel@vger.kernel.org, open list:BLUETOOTH DRIVERS
In-Reply-To: <CAL_Jsq+a93Rpf3UAPBQ5QmA8KavberGXz76WCiZ7feHH5GgcDA@mail.gmail.com>
Hi Rob,
>>>> Added support to automatically configure the SCO packet routing at the
>>>> device setup. The SCO packets are used with the HSP / HFP profiles, but in
>>>> some devices (ex. CYW43438) they are routed to a PCM output by default. This
>>>> change allows sending the vendor specific HCI command to configure the SCO
>>>> routing. The parameters of the command are loaded from the device tree.
>>>
>>> Please wrap your commit msg.
>>
>>
>> Sure.
>>>
>>>
>>>>
>>>> Signed-off-by: Attila Tőkés <attitokes@gmail.com>
>>>> ---
>>>> .../bindings/net/broadcom-bluetooth.txt | 7 ++
>>>
>>> Please split bindings to separate patch.
>>
>>
>> Ok, I will split this in two.
>>>
>>>
>>>
>>>
>>>> drivers/bluetooth/hci_bcm.c | 72 +++++++++++++++++++
>>>> 2 files changed, 79 insertions(+)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>>>> b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>>>> index 4194ff7e..aea3a094 100644
>>>> --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>>>> +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>>>> @@ -21,6 +21,12 @@ Optional properties:
>>>> - clocks: clock specifier if external clock provided to the controller
>>>> - clock-names: should be "extclk"
>>>>
>>>> + SCO routing parameters:
>>>> + - sco-routing: 0-3 (PCM, Transport, Codec, I2S)
>>>> + - pcm-interface-rate: 0-4 (128 Kbps - 2048 Kbps)
>>>> + - pcm-frame-type: 0 (short), 1 (long)
>>>> + - pcm-sync-mode: 0 (slave), 1 (master)
>>>> + - pcm-clock-mode: 0 (slave), 1 (master)
>>>
>>> Are these Broadcom specific? Properties need either vendor prefix or
>>> to be documented in a common location. I think these look like the
>>> latter.
>>
>>
>> These will be used as parameters of a vendor specific (Broadcom/Cypress)
>> command configuring the SCO packet routing. See the Write_SCO_PCM_Int_Param
>> command from: http://www.cypress.com/file/298311/download.
>
> The DT should just describe how the h/w is hooked-up. What the s/w has
> to do based on that is the driver's problem which is certainly
> vendor/chip specific, but that is all irrelevant to the binding.
>
>> What would be the property names with a Broadcom / Cypress vendor prefix?
>>
>> brcm,sco-routing
>> brcm,pcm-interface-rate
>> brcm,pcm-frame-type
>> brcm,pcm-sync-mode
>> brcm,pcm-clock-mode
>>
>> ?
>
> Yes.
we can do this. However all pcm-* are optional if you switch the HCI transport. And sco-routing should default to HCI if that is not present. Meaning a driver should actively trying to change this. Nevertheless, it would be good if a driver reads the current settings.
In theory we could make sco-routing generic, but so many vendors have different modes, that we better keep this vendor specific.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_bcm: Configure SCO routing automatically
From: Rob Herring @ 2018-06-11 15:34 UTC (permalink / raw)
To: Attila Tőkés
Cc: David S. Miller, Mark Rutland, Marcel Holtmann, Johan Hedberg,
Artiom Vaskov, netdev, devicetree, linux-kernel@vger.kernel.org,
open list:BLUETOOTH DRIVERS
In-Reply-To: <CAMoM21HshLyv+Np1vOKYTAunsPCazyP-WESiaheNXHsC078S8g@mail.gmail.com>
On Sat, Jun 9, 2018 at 12:26 AM, Attila Tőkés <attitokes@gmail.com> wrote:
> Hello Rob,
>
> On Fri, Jun 8, 2018 at 8:25 PM, Rob Herring <robh+dt@kernel.org> wrote:
>>
>> On Fri, Jun 8, 2018 at 10:20 AM, <attitokes@gmail.com> wrote:
>> > From: Attila Tőkés <attitokes@gmail.com>
>> >
>> > Added support to automatically configure the SCO packet routing at the
>> > device setup. The SCO packets are used with the HSP / HFP profiles, but in
>> > some devices (ex. CYW43438) they are routed to a PCM output by default. This
>> > change allows sending the vendor specific HCI command to configure the SCO
>> > routing. The parameters of the command are loaded from the device tree.
>>
>> Please wrap your commit msg.
>
>
> Sure.
>>
>>
>> >
>> > Signed-off-by: Attila Tőkés <attitokes@gmail.com>
>> > ---
>> > .../bindings/net/broadcom-bluetooth.txt | 7 ++
>>
>> Please split bindings to separate patch.
>
>
> Ok, I will split this in two.
>>
>>
>>
>>
>> > drivers/bluetooth/hci_bcm.c | 72 +++++++++++++++++++
>> > 2 files changed, 79 insertions(+)
>> >
>> > diff --git
>> > a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>> > b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>> > index 4194ff7e..aea3a094 100644
>> > --- a/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>> > +++ b/Documentation/devicetree/bindings/net/broadcom-bluetooth.txt
>> > @@ -21,6 +21,12 @@ Optional properties:
>> > - clocks: clock specifier if external clock provided to the controller
>> > - clock-names: should be "extclk"
>> >
>> > + SCO routing parameters:
>> > + - sco-routing: 0-3 (PCM, Transport, Codec, I2S)
>> > + - pcm-interface-rate: 0-4 (128 Kbps - 2048 Kbps)
>> > + - pcm-frame-type: 0 (short), 1 (long)
>> > + - pcm-sync-mode: 0 (slave), 1 (master)
>> > + - pcm-clock-mode: 0 (slave), 1 (master)
>>
>> Are these Broadcom specific? Properties need either vendor prefix or
>> to be documented in a common location. I think these look like the
>> latter.
>
>
> These will be used as parameters of a vendor specific (Broadcom/Cypress)
> command configuring the SCO packet routing. See the Write_SCO_PCM_Int_Param
> command from: http://www.cypress.com/file/298311/download.
The DT should just describe how the h/w is hooked-up. What the s/w has
to do based on that is the driver's problem which is certainly
vendor/chip specific, but that is all irrelevant to the binding.
> What would be the property names with a Broadcom / Cypress vendor prefix?
>
> brcm,sco-routing
> brcm,pcm-interface-rate
> brcm,pcm-frame-type
> brcm,pcm-sync-mode
> brcm,pcm-clock-mode
>
> ?
Yes.
>
>>
>>
>> However, this also looks incomplete to me. For example, which SoC
>> I2S/PCM port is BT audio connected to and how does it fit into the
>> existing audio related bindings? There's been work on HDMI audio
>> bindings which would be similar (except for the SCO over UART at
>> least).
>
>
> The I2S / PCM pins of the Bluetooth chip most likely will not be connected
> to the host SoC. When used with a SoC we probably want tor route the SCO
> packets over the UART transport. A2DP data already goes here and we probably
> want the same for HSP / HFP.
Then that should be the default with no properties.
I imagine for phones, vendors want I2S hooked up for voice calls so
audio can be routed directly to/from the modem and the power hungry
apps processor can be kept in low power modes.
> For example in the Raspberry Pi 3 B, the CYW43438's PCM output is not
> connected (there is no I2S output), But it may be connected to any other
> device in other hardware.
>
> The purpose of this command is to tell the BT chip where to send the SCO
> packets. From the driver's perspective, it does not really matters where
> these pins are connected.
Bindings are for h/w description (and config to some extent).
>> > Example:
>> >
>> > @@ -31,5 +37,6 @@ Example:
>> > bluetooth {
>> > compatible = "brcm,bcm43438-bt";
>> > max-speed = <921600>;
>> > + sco-routing = <1>; /* 1 = transport (UART) */
>> > };
>> > };
>> > diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
>> > index ddbd8c6a..0e729534 100644
>> > --- a/drivers/bluetooth/hci_bcm.c
>> > +++ b/drivers/bluetooth/hci_bcm.c
>> > @@ -83,6 +83,16 @@
>> > * @hu: pointer to HCI UART controller struct,
>> > * used to disable flow control during runtime suspend and system
>> > sleep
>> > * @is_suspended: whether flow control is currently disabled
>> > + *
>> > + * SCO routing parameters:
>> > + * used as the parameters for the bcm_set_pcm_int_params command
>> > + * @sco_routing:
>> > + * >= 255 (skip SCO routing configuration)
>> > + * 0-3 (PCM, Transport, Codec, I2S)
>> > + * @pcm_interface_rate: 0-4 (128 Kbps - 2048 Kbps)
>> > + * @pcm_frame_type: 0 (short), 1 (long)
>> > + * @pcm_sync_mode: 0 (slave), 1 (master)
>> > + * @pcm_clock_mode: 0 (slave), 1 (master)
>> > */
>> > struct bcm_device {
>> > /* Must be the first member, hci_serdev.c expects this. */
>> > @@ -114,6 +124,13 @@ struct bcm_device {
>> > struct hci_uart *hu;
>> > bool is_suspended;
>> > #endif
>> > +
>> > + /* SCO routing parameters */
>> > + u8 sco_routing;
>> > + u8 pcm_interface_rate;
>> > + u8 pcm_frame_type;
>> > + u8 pcm_sync_mode;
>> > + u8 pcm_clock_mode;
>> > };
>> >
>> > /* generic bcm uart resources */
>> > @@ -189,6 +206,40 @@ static int bcm_set_baudrate(struct hci_uart *hu,
>> > unsigned int speed)
>> > return 0;
>> > }
>> >
>> > +static int bcm_configure_sco_routing(struct hci_uart *hu, struct
>> > bcm_device *bcm_dev)
>> > +{
>> > + struct hci_dev *hdev = hu->hdev;
>> > + struct sk_buff *skb;
>> > + struct bcm_set_pcm_int_params params;
>> > +
>> > + if (bcm_dev->sco_routing >= 0xff) {
>> > + /* SCO routing configuration should be skipped */
>> > + return 0;
>> > + }
>> > +
>> > + bt_dev_dbg(hdev, "BCM: Configuring SCO routing (%d %d %d %d
>> > %d)",
>> > + bcm_dev->sco_routing,
>> > bcm_dev->pcm_interface_rate, bcm_dev->pcm_frame_type,
>> > + bcm_dev->pcm_sync_mode,
>> > bcm_dev->pcm_clock_mode);
>> > +
>> > + params.routing = bcm_dev->sco_routing;
>> > + params.rate = bcm_dev->pcm_interface_rate;
>> > + params.frame_sync = bcm_dev->pcm_frame_type;
>> > + params.sync_mode = bcm_dev->pcm_sync_mode;
>> > + params.clock_mode = bcm_dev->pcm_clock_mode;
>> > +
>> > + /* Send the SCO routing configuration command */
>> > + skb = __hci_cmd_sync(hdev, 0xfc1c, sizeof(params), ¶ms,
>> > HCI_CMD_TIMEOUT);
>> > + if (IS_ERR(skb)) {
>> > + int err = PTR_ERR(skb);
>> > + bt_dev_err(hdev, "BCM: failed to configure SCO routing
>> > (%d)", err);
>> > + return err;
>> > + }
>> > +
>> > + kfree_skb(skb);
>> > +
>> > + return 0;
>> > +}
>> > +
>> > /* bcm_device_exists should be protected by bcm_device_lock */
>> > static bool bcm_device_exists(struct bcm_device *device)
>> > {
>> > @@ -534,6 +585,9 @@ static int bcm_setup(struct hci_uart *hu)
>> > host_set_baudrate(hu, speed);
>> > }
>> >
>> > + /* Configure SCO routing if needed */
>> > + bcm_configure_sco_routing(hu, bcm->dev);
>> > +
>> > finalize:
>> > release_firmware(fw);
>> >
>> > @@ -1004,9 +1058,21 @@ static int bcm_acpi_probe(struct bcm_device *dev)
>> > }
>> > #endif /* CONFIG_ACPI */
>> >
>> > +static void read_u8_device_property(struct device *device, const char
>> > *property, u8 *destination) {
>> > + u32 temp;
>> > + if (device_property_read_u32(device, property, &temp) == 0) {
>> > + *destination = temp & 0xff;
>> > + }
>> > +}
>> > +
>> > static int bcm_of_probe(struct bcm_device *bdev)
>> > {
>> > device_property_read_u32(bdev->dev, "max-speed",
>> > &bdev->oper_speed);
>> > + read_u8_device_property(bdev->dev, "sco-routing",
>> > &bdev->sco_routing);
>> > + read_u8_device_property(bdev->dev, "pcm-interface-rate",
>> > &bdev->pcm_interface_rate);
>> > + read_u8_device_property(bdev->dev, "pcm-frame-type",
>> > &bdev->pcm_frame_type);
>> > + read_u8_device_property(bdev->dev, "pcm-sync-mode",
>> > &bdev->pcm_sync_mode);
>> > + read_u8_device_property(bdev->dev, "pcm-clock-mode",
>> > &bdev->pcm_clock_mode);
>>
>> These are actually broken because the DT properties are 32-bit.
>>
> The properties from device tree are read as 32-bit values, then they are
> truncated to 8-bit (see the read_u8_device_property function above). Is
> anything wrong with this?
Ah, NM, I missed the wrapper.
Rob
^ permalink raw reply
* Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)
From: Ricardo Ribalda Delgado @ 2018-06-11 15:33 UTC (permalink / raw)
To: Marcel Holtmann
Cc: LKML, open list:SERIAL DRIVERS, Lino Sanfilippo, David Miller,
Stefan Wahren, Rob Herring, Johan Hovold, netdev
In-Reply-To: <B4BC9DB0-2D7C-4F9D-99FE-8227D4DC3D54@holtmann.org>
Hi Marcel,
On Mon, Jun 11, 2018 at 5:28 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Marcel,
>
> >> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export?
> >
> > The main purpose is to autoload drivers for devices that have been
> > created via sysfs or another module.
> >
> > Eg1: We have a serial port on a standard computer that has connected a
> > GPS module. Since it is something that is not in the ACPI nor the DT
> > table the user will run
> >
> > echo serdev_gps > /sys/bus/serial/devices/serial0/new_device
> >
> > Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c
> >
> > Modprobe does not know what module to load for that device unless
> > there is a matching MODULE_DEVICE_TABLE
> > Today, we have the same functionality for i2c devices
> > https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
>
> but why does this have to be the driver name? I would rather say, create a generic string that describes the hardware and then use that. I think you also want the special handling, as from USB for example, that lets you reference an existing .compatible or ACPI ID as reference so that the driver_data is copied.
We can choose any name, but if there are no special variants (like the
rave-sp driver) I would prefer using the module name. We can of course
use more names, like the part number of the the device, but it is very
convenient to also use the module name, and other subsystems also do
that.
If you want to add specific names for this device please let me know
and I will add them to the list. You know much more about this module
than myself.
Thanks!
>
> Regards
>
> Marcel
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)
From: Marcel Holtmann @ 2018-06-11 15:28 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: LKML, open list:SERIAL DRIVERS, Lino Sanfilippo, David S. Miller,
Stefan Wahren, Rob Herring, Johan Hovold, netdev
In-Reply-To: <CAPybu_0=ykAcCx=nZyrv90YRfihDxi3s2+Nz+6UP8Fwd5eH2-A@mail.gmail.com>
Hi Marcel,
>> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export?
>
> The main purpose is to autoload drivers for devices that have been
> created via sysfs or another module.
>
> Eg1: We have a serial port on a standard computer that has connected a
> GPS module. Since it is something that is not in the ACPI nor the DT
> table the user will run
>
> echo serdev_gps > /sys/bus/serial/devices/serial0/new_device
>
> Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c
>
> Modprobe does not know what module to load for that device unless
> there is a matching MODULE_DEVICE_TABLE
> Today, we have the same functionality for i2c devices
> https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
but why does this have to be the driver name? I would rather say, create a generic string that describes the hardware and then use that. I think you also want the special handling, as from USB for example, that lets you reference an existing .compatible or ACPI ID as reference so that the driver_data is copied.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Stephen Hemminger @ 2018-06-11 15:22 UTC (permalink / raw)
To: Siwei Liu
Cc: Michael S. Tsirkin, Jiri Pirko, kys, haiyangz, David Miller,
Samudrala, Sridhar, Netdev, Stephen Hemminger
In-Reply-To: <CADGSJ22Fok88EY+vgU-i5HVsyJNdS5g5Oe1W3vvNy7_q+2_2HA@mail.gmail.com>
On Fri, 8 Jun 2018 17:42:21 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Fri, Jun 8, 2018 at 5:02 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Fri, 8 Jun 2018 16:44:12 -0700
> > Siwei Liu <loseweigh@gmail.com> wrote:
> >
> >> On Fri, Jun 8, 2018 at 4:18 PM, Stephen Hemminger
> >> <stephen@networkplumber.org> wrote:
> >> > On Fri, 8 Jun 2018 15:25:59 -0700
> >> > Siwei Liu <loseweigh@gmail.com> wrote:
> >> >
> >> >> On Wed, Jun 6, 2018 at 2:24 PM, Stephen Hemminger
> >> >> <stephen@networkplumber.org> wrote:
> >> >> > On Wed, 6 Jun 2018 15:30:27 +0300
> >> >> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >> >
> >> >> >> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> >> >> >> > Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> >> >> >> > >The net failover should be a simple library, not a virtual
> >> >> >> > >object with function callbacks (see callback hell).
> >> >> >> >
> >> >> >> > Why just a library? It should do a common things. I think it should be a
> >> >> >> > virtual object. Looks like your patch again splits the common
> >> >> >> > functionality into multiple drivers. That is kind of backwards attitude.
> >> >> >> > I don't get it. We should rather focus on fixing the mess the
> >> >> >> > introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> >> >> >> > model.
> >> >> >>
> >> >> >> So it seems that at least one benefit for netvsc would be better
> >> >> >> handling of renames.
> >> >> >>
> >> >> >> Question is how can this change to 3-netdev happen? Stephen is
> >> >> >> concerned about risk of breaking some userspace.
> >> >> >>
> >> >> >> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> >> >> >> address, and you said then "why not use existing network namespaces
> >> >> >> rather than inventing a new abstraction". So how about it then? Do you
> >> >> >> want to find a way to use namespaces to hide the PV device for netvsc
> >> >> >> compatibility?
> >> >> >>
> >> >> >
> >> >> > Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> >> >> > startups that all demand eth0 always be present. And VF may come and go.
> >> >> > After this history, there is a strong motivation not to change how kernel
> >> >> > behaves. Switching to 3 device model would be perceived as breaking
> >> >> > existing userspace.
> >> >> >
> >> >> > With virtio you can work it out with the distro's yourself.
> >> >> > There is no pre-existing semantics to deal with.
> >> >> >
> >> >> > For the virtio, I don't see the need for IFF_HIDDEN.
> >> >>
> >> >> I have a somewhat different view regarding IFF_HIDDEN. The purpose of
> >> >> that flag, as well as the 1-netdev model, is to have a means to
> >> >> inherit the interface name from the VF, and to eliminate playing hacks
> >> >> around renaming devices, customizing udev rules and et al. Why
> >> >> inheriting VF's name important? To allow existing config/setup around
> >> >> VF continues to work across kernel feature upgrade. Most of network
> >> >> config files in all distros are based on interface names. Few are MAC
> >> >> address based but making lower slaves hidden would cover the rest. And
> >> >> most importantly, preserving the same level of user experience as
> >> >> using raw VF interface once getting all ndo_ops and ethtool_ops
> >> >> exposed. This is essential to realize transparent live migration that
> >> >> users dont have to learn and be aware of the undertaken.
> >> >
> >> > Inheriting the VF name will fail in the migration scenario.
> >> > It is perfectly reasonable to migrate a guest to another machine where
> >> > the VF PCI address is different. And since current udev/systemd model
> >> > is to base network device name off of PCI address, the device will change
> >> > name when guest is migrated.
> >> >
> >> The scenario of having VF on a different PCI address on post migration
> >> is essentially equal to plugging in a new NIC. Why it has to pair with
> >> the original PV? A sepearte PV device should be in place to pair the
> >> new VF.
> >
> > The host only guarantees that the PV device will be on the same network.
> > It does not make any PCI guarantees. The way Windows works is to find
> > the device based on "serial number" which is an Hyper-V specific attribute
> > of PCI devices.
> >
> > I considered naming off of serial number but that won't work for the
> > case where PV device is present first and VF arrives later. The serial
> > number is attribute of VF, not the PV which is there first.
>
> I assume the PV can get that information ahead of time before VF
> arrives? Without it how do you match the device when you see a VF
> coming with some serial number? Is it possible for PV to get the
> matching SN even earlier during probe time? Or it has to depend on the
> presence of vPCI bridge to generate this SN?
NO. the PV device does not know ahead of time and there are scenario
where the serial and PCI info can change when it does arrive. These
are test cases (not something people usually do). Example on WS2016:
Guest configured with two or more vswitches and NICs.
SR-IOV is not enabled
Later:
On Hyper-V console (or Powershell command line) on host SR-IOV
is enabled on the second NIC.
The guest will be notified of new PCI device; the "serial number"
will be 1.
If same process is repeated but in this case the first NIC has
SR-IOV enabled, it will get serial # 1.
I agree with Jakub. What you are proposing is backwards. The VF
must be thought of as a dependent of PV device not vice/versa.
> >
> > Your ideas about having the PCI information of the VF form the name
> > of the failover device have the same problem. The PV device may
> > be the only one present on boot.
>
> Yeah, this is a chicken-egg problem indeed, and that was the reason
> why I supply the BDF info for PV to name the master interface.
> However, the ACPI PCI slot needs to depend on the PCI bus enumeration
> so that can't be predictable. Would it make sense to only rename when
> the first time a matching VF appears and PV interface isn't brought
> up, then the failover master would always stick to the name
> afterwards? I think it should cover most scenarios as it's usually
> during boot time (dracut) the VF first appears and the PV interface at
> the time then shouldn't have been configured yet.
>
> -Siwei
>
> >
> >
> >> > On Azure, the VF maybe removed (by host) at any time and then later
> >> > reattached. There is no guarantee that VF will show back up at
> >> > the same synthetic PCI address. It will likely have a different
> >> > PCI domain value.
> >>
> >> This is something QEMU can do and make sure the PCI address is
> >> consistent after migration.
> >>
> >> -Siwei
> >
^ permalink raw reply
* Re: [PATCH net] failover: eliminate callback hell
From: Stephen Hemminger @ 2018-06-11 15:17 UTC (permalink / raw)
To: Siwei Liu
Cc: Samudrala, Sridhar, Michael S. Tsirkin, Jiri Pirko, kys, haiyangz,
David Miller, Netdev, Stephen Hemminger
In-Reply-To: <CADGSJ22LCkzvE-f3KSQDfn8iHKHmE+bh6sRuM9zGx3m0ALExSA@mail.gmail.com>
On Fri, 8 Jun 2018 15:54:38 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Wed, Jun 6, 2018 at 2:54 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
> >
> >
> > On 6/6/2018 2:24 PM, Stephen Hemminger wrote:
> >>
> >> On Wed, 6 Jun 2018 15:30:27 +0300
> >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>
> >>> On Wed, Jun 06, 2018 at 09:25:12AM +0200, Jiri Pirko wrote:
> >>>>
> >>>> Tue, Jun 05, 2018 at 05:42:31AM CEST, stephen@networkplumber.org wrote:
> >>>>>
> >>>>> The net failover should be a simple library, not a virtual
> >>>>> object with function callbacks (see callback hell).
> >>>>
> >>>> Why just a library? It should do a common things. I think it should be a
> >>>> virtual object. Looks like your patch again splits the common
> >>>> functionality into multiple drivers. That is kind of backwards attitude.
> >>>> I don't get it. We should rather focus on fixing the mess the
> >>>> introduction of netvsc-bonding caused and switch netvsc to 3-netdev
> >>>> model.
> >>>
> >>> So it seems that at least one benefit for netvsc would be better
> >>> handling of renames.
> >>>
> >>> Question is how can this change to 3-netdev happen? Stephen is
> >>> concerned about risk of breaking some userspace.
> >>>
> >>> Stephen, this seems to be the usecase that IFF_HIDDEN was trying to
> >>> address, and you said then "why not use existing network namespaces
> >>> rather than inventing a new abstraction". So how about it then? Do you
> >>> want to find a way to use namespaces to hide the PV device for netvsc
> >>> compatibility?
> >>>
> >> Netvsc can't work with 3 dev model. MS has worked with enough distro's and
> >> startups that all demand eth0 always be present. And VF may come and go.
> >> After this history, there is a strong motivation not to change how kernel
> >> behaves. Switching to 3 device model would be perceived as breaking
> >> existing userspace.
> >
> >
> > I think it should be possible for netvsc to work with 3 dev model if the
> > only
> > requirement is that eth0 will always be present. With net_failover, you will
> > see eth0 and eth0nsby OR with older distros eth0 and eth1. It may be an
> > issue
> > if somehow there is userspace requirement that there can be only 2 netdevs,
> > not 3
> > when VF is plugged.
> >
> > eth0 will be the net_failover device and eth0nsby/eth1 will be the netvsc
> > device
> > and the IP address gets configured on eth0. Will this be an issue?
> >
> Did you realize that the eth0 name in the current 3-netdev code can't
> be consistently persisted across reboot, if you have more than one VFs
> to pair with? On one boot it got eth0/eth0nsby, on the next it may get
> eth1/eth1nsby on the same interface.
>
> It won't be useable by default until you add some custom udev rules.
>
I think there is no reason to break things by moving netvsc to 3 device
model.
The first device probed is always the same on Hyper-V/Azure, and always
comes up as eth0. The order comes from the fact that they are reported
to guest in that order and currently vmbus probe is single threaded.
^ permalink raw reply
* Re: [PATCH v2 15/24] net: qualcomm: MODULE_DEVICE_TABLE(serdev)
From: Ricardo Ribalda Delgado @ 2018-06-11 15:09 UTC (permalink / raw)
To: Marcel Holtmann
Cc: LKML, open list:SERIAL DRIVERS, Lino Sanfilippo, David Miller,
Stefan Wahren, Rob Herring, Johan Hovold, netdev
In-Reply-To: <CCB7FF79-F89A-4421-A6C0-E0663BEE6065@holtmann.org>
Hi Marcel,
On Mon, Jun 11, 2018 at 3:01 PM Marcel Holtmann <marcel@holtmann.org> wrote:
>
>
> the commit message is misleading me. If I build something with ACPI or DT support, then modinfo will show all modalias information for ACPI and DT compatible strings. What else does udev/modprobe actually need? Is something broken with the modalias export?
The main purpose is to autoload drivers for devices that have been
created via sysfs or another module.
Eg1: We have a serial port on a standard computer that has connected a
GPS module. Since it is something that is not in the ACPI nor the DT
table the user will run
echo serdev_gps > /sys/bus/serial/devices/serial0/new_device
Eg2 module: https://github.com/ribalda/linux/blob/415bb3f0076c2b846ebe5409589b8e1e3004f55a/drivers/tty/serdev/test_platform.c
Modprobe does not know what module to load for that device unless
there is a matching MODULE_DEVICE_TABLE
Today, we have the same functionality for i2c devices
https://www.kernel.org/doc/Documentation/i2c/instantiating-devices
I guess the commit message is really bad :), sorry about that. Any
suggestions to improve it?
Thanks!
>
> Regards
>
> Marcel
>
--
Ricardo Ribalda
^ permalink raw reply
* Re: [iproute2-next v2 1/2] tipc: JSON support for showing nametable
From: Stephen Hemminger @ 2018-06-11 15:05 UTC (permalink / raw)
To: Hoang Le; +Cc: netdev, tipc-discussion
In-Reply-To: <1528683420-15006-1-git-send-email-hoang.h.le@dektech.com.au>
On Mon, 11 Jun 2018 09:16:59 +0700
Hoang Le <hoang.h.le@dektech.com.au> wrote:
> @@ -33,6 +35,8 @@ static void about(struct cmdl *cmdl)
> "\n"
> "Options:\n"
> " -h, --help \t\tPrint help for last given command\n"
> + " -j, --json \t\tJson format printouts\n"
> + " -p, --pretty \t\tpretty print\n"
> "\n"
You should also update manual page: man/man8/tipc-nametable.8
Just cut/paste text from ip or tc pages.
^ permalink raw reply
* Re: Qualcomm rmnet driver and qmi_wwan
From: Daniele Palmas @ 2018-06-11 14:30 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: Bjørn Mork, Dan Williams, netdev
In-Reply-To: <4b74bb1d92b9e9351bc504d18f96116b@codeaurora.org>
Hi Subash,
2018-06-09 19:55 GMT+02:00 Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org>:
>> thanks, I will test it on Monday.
>>
>> Just a question for my knowledge: is the new sysfs attribute really
>> needed? I mean, is there not any other way to understand from qmi_wwan
>> without user intervention that there is the rmnet device attached?
>>
>> Regards,
>> Daniele
>>
>
> Hi Daniele
>
> You can check for the rx_handler attached to qmi_wwan dev and see if it
> belongs to rmnet. You can use the attached patch for it but it think the
> sysfs way might be a bit cleaner.
>
both patches work properly for me.
Maybe it could be helpful in the first patch to add a print when
pass-through setting fails if raw-ip has not been set, just to let the
user know what is happening.
Thanks,
Daniele
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox