* [PATCH 00/22] ReST conversion of text files without .txt extension
From: Mauro Carvalho Chehab @ 2019-07-22 11:07 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, linux-spi, dmaengine, netdev, linux-wimax,
devel, linux-i2c, linux-parisc, devel, linux-cifs, rcu, linux-iio,
openrisc, Greg Kroah-Hartman, Jonathan Corbet, linux-doc,
alsa-devel, linux-wireless, linux-rtc, linux-mips
This series converts the text files under Documentation with doesn't end
neither .txt or .rst and are not part of ABI or features[1].
This series is at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=rst_for_5_4_v2.1
And comes after the pending patches I had for v5.13 (some not applied
yet):
https://git.linuxtv.org/mchehab/experimental.git/log/?h=pending_docs_after_5.13-rc1
[1] I submitted already a series to handle ABI and features.
There are some files besides the ones there with, IMHO, it
doesn't make sense to convert.
So, I wrote a small ugly script to track the files waiting to be
converted:
#!/bin/bash
find Documentation/ -name '*.txt'|grep -vE '(features/|devicetree/|sphinx/|output/|dax-hv-api.txt|draft-ietf-cipso-ipsecurity-01.txt|translations)'
for i in $(find Documentation/ -type f|grep -v translations/|grep -v output/|grep -v devicetree|grep -v -E "\.(rst|txt|py|pyc|pl|dot|conf|svg|sh|awk|gif|S|inf|c|csv|css|vim|exceptions|modes)$"|grep -v ABI/ |grep -v Documentation/EDID/hex|grep -v dontdiff|grep -v Kconfig|grep -v Makefile|grep -v Module.symvers|grep -vE '\b(CodingStyle|SubmittingPatches|target-export-device|hotplug-script|wusb-cbaf)\b'|grep -v -E '(LICENSE|COPY|gitignore|Makefile|AUTHORS|TODO|CHANGES|CREDITS|ChangeLog)'|grep -v Documentation/virtual/kvm/devices/README); do echo $i; done
After this patch series, the script reports 358 files missing conversion, all ending with .txt.
From those, ~40 files are already at ReST format - the ones at Documentation/*.txt - except
for a couple of files there.
So, there's around 320 files left to be converted after this series,
with gives me hope that we may finally finish the conversion this
year. Let's see.
Mauro Carvalho Chehab (22):
docs: convert markdown documents to ReST
docs: i2c: convert to ReST and add to driver-api bookset
docs: w1: convert to ReST and add to the kAPI group of docs
docs: spi: convert to ReST and add it to the kABI bookset
docs: ipmb: place it at driver-api and convert to ReST
docs: packing: move it to core-api book and adjust markups
docs: admin-guide: add auxdisplay files to it after conversion to ReST
docs: README.buddha: convert to ReST and add to m68k book
docs: parisc: convert to ReST and add to documentation body
docs: openrisc: convert to ReST and add to documentation body
docs: isdn: convert to ReST and add to kAPI bookset
docs: fs: cifs: convert to ReST and add to admin-guide book
docs: fs: convert docs without extension to ReST
docs: fs: convert porting to ReST
docs: index.rst: don't use genindex for pdf output
docs: wimax: convert to ReST and add to admin-guide
docs: mips: add to the documentation body as ReST
docs: hwmon: pxe1610: convert to ReST format and add to the index
docs: nios2: add it to the main Documentation body
docs: net: convert two README files to ReST format
docs: rcu: convert some articles from html to ReST
docs: ABI: remove extension from sysfs-class-mic.txt
Documentation/ABI/stable/sysfs-bus-w1 | 2 +-
.../ABI/stable/sysfs-driver-w1_ds28e04 | 4 +-
.../ABI/stable/sysfs-driver-w1_ds28ea00 | 2 +-
.../{sysfs-class-mic.txt => sysfs-class-mic} | 0
.../Data-Structures/Data-Structures.html | 1391 -------
.../Data-Structures/Data-Structures.rst | 1163 ++++++
.../Expedited-Grace-Periods.html | 668 ----
.../Expedited-Grace-Periods.rst | 521 +++
.../Memory-Ordering/Tree-RCU-Diagram.html | 9 -
.../Tree-RCU-Memory-Ordering.html | 704 ----
.../Tree-RCU-Memory-Ordering.rst | 625 ++++
.../RCU/Design/Requirements/Requirements.html | 3330 -----------------
.../RCU/Design/Requirements/Requirements.rst | 2662 +++++++++++++
Documentation/RCU/index.rst | 5 +
Documentation/RCU/whatisRCU.txt | 4 +-
.../admin-guide/auxdisplay/cfag12864b.rst | 98 +
.../admin-guide/auxdisplay/index.rst | 16 +
.../admin-guide/auxdisplay/ks0108.rst | 50 +
.../AUTHORS => admin-guide/cifs/authors.rst} | 64 +-
.../CHANGES => admin-guide/cifs/changes.rst} | 4 +
Documentation/admin-guide/cifs/index.rst | 21 +
.../cifs/introduction.rst} | 8 +
.../cifs/TODO => admin-guide/cifs/todo.rst} | 87 +-
.../README => admin-guide/cifs/usage.rst} | 560 +--
.../cifs/winucase_convert.pl | 0
Documentation/admin-guide/index.rst | 3 +
.../wimax/i2400m.rst} | 145 +-
Documentation/admin-guide/wimax/index.rst | 19 +
.../wimax/wimax.rst} | 36 +-
Documentation/auxdisplay/cfag12864b | 105 -
Documentation/auxdisplay/ks0108 | 55 -
Documentation/core-api/index.rst | 3 +-
.../{packing.txt => core-api/packing.rst} | 81 +-
.../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 2 +-
Documentation/devicetree/writing-schema.md | 130 -
Documentation/devicetree/writing-schema.rst | 153 +
Documentation/driver-api/dmaengine/index.rst | 2 +-
Documentation/driver-api/index.rst | 1 +
Documentation/driver-api/ipmb.rst | 2 +-
Documentation/driver-api/soundwire/index.rst | 2 +-
...irectory-locking => directory-locking.rst} | 40 +-
Documentation/filesystems/index.rst | 4 +
.../filesystems/{Locking => locking.rst} | 257 +-
.../nfs/{Exporting => exporting.rst} | 31 +-
Documentation/filesystems/porting | 686 ----
Documentation/filesystems/porting.rst | 852 +++++
...entication.md => ubifs-authentication.rst} | 70 +-
Documentation/filesystems/vfs.rst | 2 +-
Documentation/hwmon/adm1021.rst | 2 +-
Documentation/hwmon/adm1275.rst | 2 +-
Documentation/hwmon/hih6130.rst | 2 +-
Documentation/hwmon/ibm-cffps.rst | 2 +-
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/lm25066.rst | 2 +-
Documentation/hwmon/max16064.rst | 2 +-
Documentation/hwmon/max16065.rst | 2 +-
Documentation/hwmon/max20751.rst | 2 +-
Documentation/hwmon/max34440.rst | 2 +-
Documentation/hwmon/max6650.rst | 2 +-
Documentation/hwmon/max8688.rst | 2 +-
Documentation/hwmon/menf21bmc.rst | 2 +-
Documentation/hwmon/pcf8591.rst | 2 +-
Documentation/hwmon/{pxe1610 => pxe1610.rst} | 33 +-
Documentation/hwmon/sht3x.rst | 2 +-
Documentation/hwmon/shtc1.rst | 2 +-
Documentation/hwmon/tmp103.rst | 2 +-
Documentation/hwmon/tps40422.rst | 2 +-
Documentation/hwmon/ucd9000.rst | 2 +-
Documentation/hwmon/ucd9200.rst | 2 +-
Documentation/hwmon/via686a.rst | 2 +-
Documentation/hwmon/zl6100.rst | 2 +-
.../busses/{i2c-ali1535 => i2c-ali1535.rst} | 13 +-
.../busses/{i2c-ali1563 => i2c-ali1563.rst} | 3 +
.../busses/{i2c-ali15x3 => i2c-ali15x3.rst} | 64 +-
Documentation/i2c/busses/i2c-amd-mp2 | 23 -
Documentation/i2c/busses/i2c-amd-mp2.rst | 25 +
.../i2c/busses/{i2c-amd756 => i2c-amd756.rst} | 8 +-
.../busses/{i2c-amd8111 => i2c-amd8111.rst} | 14 +-
.../{i2c-diolan-u2c => i2c-diolan-u2c.rst} | 3 +
.../i2c/busses/{i2c-i801 => i2c-i801.rst} | 33 +-
.../i2c/busses/{i2c-ismt => i2c-ismt.rst} | 20 +-
.../busses/{i2c-mlxcpld => i2c-mlxcpld.rst} | 6 +
.../busses/{i2c-nforce2 => i2c-nforce2.rst} | 33 +-
.../{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} | 6 +-
.../i2c/busses/{i2c-ocores => i2c-ocores.rst} | 22 +-
Documentation/i2c/busses/i2c-parport | 178 -
...2c-parport-light => i2c-parport-light.rst} | 8 +-
Documentation/i2c/busses/i2c-parport.rst | 190 +
.../busses/{i2c-pca-isa => i2c-pca-isa.rst} | 9 +-
.../i2c/busses/{i2c-piix4 => i2c-piix4.rst} | 18 +-
.../busses/{i2c-sis5595 => i2c-sis5595.rst} | 19 +-
Documentation/i2c/busses/i2c-sis630 | 58 -
Documentation/i2c/busses/i2c-sis630.rst | 63 +
.../i2c/busses/{i2c-sis96x => i2c-sis96x.rst} | 31 +-
.../busses/{i2c-taos-evm => i2c-taos-evm.rst} | 8 +-
.../i2c/busses/{i2c-via => i2c-via.rst} | 28 +-
.../i2c/busses/{i2c-viapro => i2c-viapro.rst} | 12 +-
Documentation/i2c/busses/index.rst | 33 +
.../i2c/busses/{scx200_acb => scx200_acb.rst} | 9 +-
.../i2c/{dev-interface => dev-interface.rst} | 94 +-
...-considerations => dma-considerations.rst} | 0
.../i2c/{fault-codes => fault-codes.rst} | 5 +-
.../i2c/{functionality => functionality.rst} | 22 +-
...ult-injection => gpio-fault-injection.rst} | 12 +-
.../i2c/{i2c-protocol => i2c-protocol.rst} | 28 +-
Documentation/i2c/{i2c-stub => i2c-stub.rst} | 20 +-
.../i2c/{i2c-topology => i2c-topology.rst} | 68 +-
Documentation/i2c/index.rst | 37 +
...ting-devices => instantiating-devices.rst} | 45 +-
.../muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} | 26 +-
...e-parameters => old-module-parameters.rst} | 27 +-
...eprom-backend => slave-eeprom-backend.rst} | 4 +-
.../{slave-interface => slave-interface.rst} | 33 +-
.../{smbus-protocol => smbus-protocol.rst} | 86 +-
Documentation/i2c/{summary => summary.rst} | 6 +-
...en-bit-addresses => ten-bit-addresses.rst} | 5 +
...pgrading-clients => upgrading-clients.rst} | 204 +-
.../{writing-clients => writing-clients.rst} | 94 +-
Documentation/index.rst | 8 +
.../isdn/{README.avmb1 => avmb1.rst} | 231 +-
Documentation/isdn/{CREDITS => credits.rst} | 7 +-
.../isdn/{README.gigaset => gigaset.rst} | 290 +-
.../isdn/{README.hysdn => hysdn.rst} | 125 +-
Documentation/isdn/index.rst | 24 +
.../{INTERFACE.CAPI => interface_capi.rst} | 182 +-
.../isdn/{README.mISDN => m_isdn.rst} | 5 +-
.../m68k/{README.buddha => buddha-driver.rst} | 95 +-
Documentation/m68k/index.rst | 1 +
.../{AU1xxx_IDE.README => au1xxx_ide.rst} | 89 +-
Documentation/mips/index.rst | 17 +
.../networking/caif/{README => caif.rst} | 88 +-
.../networking/device_drivers/index.rst | 2 +-
Documentation/networking/index.rst | 2 +-
.../{README => mac80211_hwsim.rst} | 28 +-
Documentation/nios2/{README => nios2.rst} | 1 +
Documentation/openrisc/index.rst | 18 +
.../openrisc/{README => openrisc_port.rst} | 25 +-
Documentation/openrisc/{TODO => todo.rst} | 9 +-
.../parisc/{debugging => debugging.rst} | 7 +
Documentation/parisc/index.rst | 18 +
.../parisc/{registers => registers.rst} | 59 +-
Documentation/sound/index.rst | 2 +-
.../spi/{butterfly => butterfly.rst} | 44 +-
Documentation/spi/index.rst | 22 +
Documentation/spi/{pxa2xx => pxa2xx.rst} | 95 +-
.../spi/{spi-lm70llp => spi-lm70llp.rst} | 17 +-
.../spi/{spi-sc18is602 => spi-sc18is602.rst} | 5 +-
.../spi/{spi-summary => spi-summary.rst} | 105 +-
Documentation/spi/{spidev => spidev.rst} | 30 +-
Documentation/w1/index.rst | 21 +
.../w1/masters/{ds2482 => ds2482.rst} | 16 +-
.../w1/masters/{ds2490 => ds2490.rst} | 6 +-
Documentation/w1/masters/index.rst | 14 +
Documentation/w1/masters/mxc-w1 | 12 -
Documentation/w1/masters/mxc-w1.rst | 17 +
.../w1/masters/{omap-hdq => omap-hdq.rst} | 12 +-
.../w1/masters/{w1-gpio => w1-gpio.rst} | 21 +-
Documentation/w1/slaves/index.rst | 16 +
.../w1/slaves/{w1_ds2406 => w1_ds2406.rst} | 4 +-
.../w1/slaves/{w1_ds2413 => w1_ds2413.rst} | 9 +
Documentation/w1/slaves/w1_ds2423 | 47 -
Documentation/w1/slaves/w1_ds2423.rst | 54 +
.../w1/slaves/{w1_ds2438 => w1_ds2438.rst} | 10 +-
.../w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} | 5 +
.../w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} | 16 +-
.../w1/slaves/{w1_therm => w1_therm.rst} | 11 +-
.../w1/{w1.generic => w1-generic.rst} | 88 +-
.../w1/{w1.netlink => w1-netlink.rst} | 89 +-
MAINTAINERS | 60 +-
drivers/auxdisplay/Kconfig | 2 +-
drivers/hwmon/atxp1.c | 2 +-
drivers/hwmon/smm665.c | 2 +-
drivers/i2c/Kconfig | 4 +-
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-i801.c | 2 +-
drivers/i2c/busses/i2c-taos-evm.c | 2 +-
drivers/i2c/i2c-core-base.c | 4 +-
drivers/iio/dummy/iio_simple_dummy.c | 4 +-
drivers/rtc/rtc-ds1374.c | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-butterfly.c | 2 +-
drivers/spi/spi-lm70llp.c | 2 +-
drivers/staging/isdn/hysdn/Kconfig | 2 +-
fs/cifs/export.c | 2 +-
fs/exportfs/expfs.c | 2 +-
fs/isofs/export.c | 2 +-
fs/orangefs/file.c | 2 +-
fs/orangefs/orangefs-kernel.h | 2 +-
include/linux/dcache.h | 2 +-
include/linux/exportfs.h | 2 +-
include/linux/i2c.h | 2 +-
include/linux/platform_data/sc18is602.h | 2 +-
192 files changed, 9538 insertions(+), 9201 deletions(-)
rename Documentation/ABI/testing/{sysfs-class-mic.txt => sysfs-class-mic} (100%)
delete mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.html
create mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.rst
delete mode 100644 Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.html
create mode 100644 Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
delete mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html
delete mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
create mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
delete mode 100644 Documentation/RCU/Design/Requirements/Requirements.html
create mode 100644 Documentation/RCU/Design/Requirements/Requirements.rst
create mode 100644 Documentation/admin-guide/auxdisplay/cfag12864b.rst
create mode 100644 Documentation/admin-guide/auxdisplay/index.rst
create mode 100644 Documentation/admin-guide/auxdisplay/ks0108.rst
rename Documentation/{filesystems/cifs/AUTHORS => admin-guide/cifs/authors.rst} (60%)
rename Documentation/{filesystems/cifs/CHANGES => admin-guide/cifs/changes.rst} (91%)
create mode 100644 Documentation/admin-guide/cifs/index.rst
rename Documentation/{filesystems/cifs/cifs.txt => admin-guide/cifs/introduction.rst} (98%)
rename Documentation/{filesystems/cifs/TODO => admin-guide/cifs/todo.rst} (58%)
rename Documentation/{filesystems/cifs/README => admin-guide/cifs/usage.rst} (72%)
rename Documentation/{filesystems => admin-guide}/cifs/winucase_convert.pl (100%)
rename Documentation/{wimax/README.i2400m => admin-guide/wimax/i2400m.rst} (69%)
create mode 100644 Documentation/admin-guide/wimax/index.rst
rename Documentation/{wimax/README.wimax => admin-guide/wimax/wimax.rst} (74%)
delete mode 100644 Documentation/auxdisplay/cfag12864b
delete mode 100644 Documentation/auxdisplay/ks0108
rename Documentation/{packing.txt => core-api/packing.rst} (61%)
delete mode 100644 Documentation/devicetree/writing-schema.md
create mode 100644 Documentation/devicetree/writing-schema.rst
rename Documentation/filesystems/{directory-locking => directory-locking.rst} (86%)
rename Documentation/filesystems/{Locking => locking.rst} (79%)
rename Documentation/filesystems/nfs/{Exporting => exporting.rst} (91%)
delete mode 100644 Documentation/filesystems/porting
create mode 100644 Documentation/filesystems/porting.rst
rename Documentation/filesystems/{ubifs-authentication.md => ubifs-authentication.rst} (95%)
rename Documentation/hwmon/{pxe1610 => pxe1610.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1535 => i2c-ali1535.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1563 => i2c-ali1563.rst} (93%)
rename Documentation/i2c/busses/{i2c-ali15x3 => i2c-ali15x3.rst} (72%)
delete mode 100644 Documentation/i2c/busses/i2c-amd-mp2
create mode 100644 Documentation/i2c/busses/i2c-amd-mp2.rst
rename Documentation/i2c/busses/{i2c-amd756 => i2c-amd756.rst} (79%)
rename Documentation/i2c/busses/{i2c-amd8111 => i2c-amd8111.rst} (66%)
rename Documentation/i2c/busses/{i2c-diolan-u2c => i2c-diolan-u2c.rst} (91%)
rename Documentation/i2c/busses/{i2c-i801 => i2c-i801.rst} (89%)
rename Documentation/i2c/busses/{i2c-ismt => i2c-ismt.rst} (81%)
rename Documentation/i2c/busses/{i2c-mlxcpld => i2c-mlxcpld.rst} (88%)
rename Documentation/i2c/busses/{i2c-nforce2 => i2c-nforce2.rst} (58%)
rename Documentation/i2c/busses/{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} (63%)
rename Documentation/i2c/busses/{i2c-ocores => i2c-ocores.rst} (82%)
delete mode 100644 Documentation/i2c/busses/i2c-parport
rename Documentation/i2c/busses/{i2c-parport-light => i2c-parport-light.rst} (91%)
create mode 100644 Documentation/i2c/busses/i2c-parport.rst
rename Documentation/i2c/busses/{i2c-pca-isa => i2c-pca-isa.rst} (72%)
rename Documentation/i2c/busses/{i2c-piix4 => i2c-piix4.rst} (92%)
rename Documentation/i2c/busses/{i2c-sis5595 => i2c-sis5595.rst} (74%)
delete mode 100644 Documentation/i2c/busses/i2c-sis630
create mode 100644 Documentation/i2c/busses/i2c-sis630.rst
rename Documentation/i2c/busses/{i2c-sis96x => i2c-sis96x.rst} (74%)
rename Documentation/i2c/busses/{i2c-taos-evm => i2c-taos-evm.rst} (91%)
rename Documentation/i2c/busses/{i2c-via => i2c-via.rst} (54%)
rename Documentation/i2c/busses/{i2c-viapro => i2c-viapro.rst} (87%)
create mode 100644 Documentation/i2c/busses/index.rst
rename Documentation/i2c/busses/{scx200_acb => scx200_acb.rst} (86%)
rename Documentation/i2c/{dev-interface => dev-interface.rst} (71%)
rename Documentation/i2c/{DMA-considerations => dma-considerations.rst} (100%)
rename Documentation/i2c/{fault-codes => fault-codes.rst} (98%)
rename Documentation/i2c/{functionality => functionality.rst} (91%)
rename Documentation/i2c/{gpio-fault-injection => gpio-fault-injection.rst} (97%)
rename Documentation/i2c/{i2c-protocol => i2c-protocol.rst} (83%)
rename Documentation/i2c/{i2c-stub => i2c-stub.rst} (93%)
rename Documentation/i2c/{i2c-topology => i2c-topology.rst} (89%)
create mode 100644 Documentation/i2c/index.rst
rename Documentation/i2c/{instantiating-devices => instantiating-devices.rst} (93%)
rename Documentation/i2c/muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} (85%)
rename Documentation/i2c/{old-module-parameters => old-module-parameters.rst} (75%)
rename Documentation/i2c/{slave-eeprom-backend => slave-eeprom-backend.rst} (90%)
rename Documentation/i2c/{slave-interface => slave-interface.rst} (94%)
rename Documentation/i2c/{smbus-protocol => smbus-protocol.rst} (82%)
rename Documentation/i2c/{summary => summary.rst} (96%)
rename Documentation/i2c/{ten-bit-addresses => ten-bit-addresses.rst} (95%)
rename Documentation/i2c/{upgrading-clients => upgrading-clients.rst} (54%)
rename Documentation/i2c/{writing-clients => writing-clients.rst} (91%)
rename Documentation/isdn/{README.avmb1 => avmb1.rst} (50%)
rename Documentation/isdn/{CREDITS => credits.rst} (96%)
rename Documentation/isdn/{README.gigaset => gigaset.rst} (74%)
rename Documentation/isdn/{README.hysdn => hysdn.rst} (80%)
create mode 100644 Documentation/isdn/index.rst
rename Documentation/isdn/{INTERFACE.CAPI => interface_capi.rst} (75%)
rename Documentation/isdn/{README.mISDN => m_isdn.rst} (89%)
rename Documentation/m68k/{README.buddha => buddha-driver.rst} (73%)
rename Documentation/mips/{AU1xxx_IDE.README => au1xxx_ide.rst} (67%)
create mode 100644 Documentation/mips/index.rst
rename Documentation/networking/caif/{README => caif.rst} (70%)
rename Documentation/networking/mac80211_hwsim/{README => mac80211_hwsim.rst} (81%)
rename Documentation/nios2/{README => nios2.rst} (96%)
create mode 100644 Documentation/openrisc/index.rst
rename Documentation/openrisc/{README => openrisc_port.rst} (80%)
rename Documentation/openrisc/{TODO => todo.rst} (78%)
rename Documentation/parisc/{debugging => debugging.rst} (94%)
create mode 100644 Documentation/parisc/index.rst
rename Documentation/parisc/{registers => registers.rst} (70%)
rename Documentation/spi/{butterfly => butterfly.rst} (71%)
create mode 100644 Documentation/spi/index.rst
rename Documentation/spi/{pxa2xx => pxa2xx.rst} (83%)
rename Documentation/spi/{spi-lm70llp => spi-lm70llp.rst} (88%)
rename Documentation/spi/{spi-sc18is602 => spi-sc18is602.rst} (92%)
rename Documentation/spi/{spi-summary => spi-summary.rst} (93%)
rename Documentation/spi/{spidev => spidev.rst} (90%)
create mode 100644 Documentation/w1/index.rst
rename Documentation/w1/masters/{ds2482 => ds2482.rst} (71%)
rename Documentation/w1/masters/{ds2490 => ds2490.rst} (98%)
create mode 100644 Documentation/w1/masters/index.rst
delete mode 100644 Documentation/w1/masters/mxc-w1
create mode 100644 Documentation/w1/masters/mxc-w1.rst
rename Documentation/w1/masters/{omap-hdq => omap-hdq.rst} (90%)
rename Documentation/w1/masters/{w1-gpio => w1-gpio.rst} (75%)
create mode 100644 Documentation/w1/slaves/index.rst
rename Documentation/w1/slaves/{w1_ds2406 => w1_ds2406.rst} (96%)
rename Documentation/w1/slaves/{w1_ds2413 => w1_ds2413.rst} (81%)
delete mode 100644 Documentation/w1/slaves/w1_ds2423
create mode 100644 Documentation/w1/slaves/w1_ds2423.rst
rename Documentation/w1/slaves/{w1_ds2438 => w1_ds2438.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} (88%)
rename Documentation/w1/slaves/{w1_therm => w1_therm.rst} (95%)
rename Documentation/w1/{w1.generic => w1-generic.rst} (59%)
rename Documentation/w1/{w1.netlink => w1-netlink.rst} (77%)
--
2.21.0
^ permalink raw reply
* Re: [PATCH] drivers: net: xgene: Remove acpi_has_method() calls
From: kbuild test robot @ 2019-07-22 11:05 UTC (permalink / raw)
To: Kelsey Skunberg
Cc: kbuild-all, iyappan, keyur, quan, davem, netdev, linux-kernel,
bjorn, rjw, skhan, linux-kernel-mentees, skunberg.kelsey
In-Reply-To: <20190722030401.69563-1-skunberg.kelsey@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 13636 bytes --]
Hi Kelsey,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc1 next-20190722]
[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/Kelsey-Skunberg/drivers-net-xgene-Remove-acpi_has_method-calls/20190722-132405
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function 'xgene_enet_reset':
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:13: error: invalid storage class for function 'xgene_enet_cle_bypass'
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:480:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
^~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:506:13: error: invalid storage class for function 'xgene_enet_clear'
static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
^~~~~~~~~~~~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:522:13: error: invalid storage class for function 'xgene_enet_shutdown'
static void xgene_enet_shutdown(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:532:13: error: invalid storage class for function 'xgene_enet_link_state'
static void xgene_enet_link_state(struct work_struct *work)
^~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:563:13: error: invalid storage class for function 'xgene_sgmac_enable_tx_pause'
static void xgene_sgmac_enable_tx_pause(struct xgene_enet_pdata *p, bool enable)
^~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:604:1: error: expected declaration or statement at end of input
};
^
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:599:29: warning: unused variable 'xgene_sgport_ops' [-Wunused-variable]
const struct xgene_port_ops xgene_sgport_ops = {
^~~~~~~~~~~~~~~~
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:582:28: warning: unused variable 'xgene_sgmac_ops' [-Wunused-variable]
const struct xgene_mac_ops xgene_sgmac_ops = {
^~~~~~~~~~~~~~~
At top level:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:437:12: warning: 'xgene_enet_reset' defined but not used [-Wunused-function]
static int xgene_enet_reset(struct xgene_enet_pdata *p)
^~~~~~~~~~~~~~~~
vim +/xgene_enet_cle_bypass +480 drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
32f784b50e14c65 Iyappan Subramanian 2014-10-13 479
32f784b50e14c65 Iyappan Subramanian 2014-10-13 @480 static void xgene_enet_cle_bypass(struct xgene_enet_pdata *p,
d6d489694fda7af Iyappan Subramanian 2016-12-01 481 u32 dst_ring_num, u16 bufpool_id,
d6d489694fda7af Iyappan Subramanian 2016-12-01 482 u16 nxtbufpool_id)
32f784b50e14c65 Iyappan Subramanian 2014-10-13 483 {
561fea6deacf72b Iyappan Subramanian 2015-04-28 484 u32 cle_bypass_reg0, cle_bypass_reg1;
ca6264545a9ffa8 Keyur Chudgar 2015-03-17 485 u32 offset = p->port_id * MAC_OFFSET;
d6d489694fda7af Iyappan Subramanian 2016-12-01 486 u32 data, fpsel, nxtfpsel;
32f784b50e14c65 Iyappan Subramanian 2014-10-13 487
561fea6deacf72b Iyappan Subramanian 2015-04-28 488 if (p->enet_id == XGENE_ENET1) {
561fea6deacf72b Iyappan Subramanian 2015-04-28 489 cle_bypass_reg0 = CLE_BYPASS_REG0_0_ADDR;
561fea6deacf72b Iyappan Subramanian 2015-04-28 490 cle_bypass_reg1 = CLE_BYPASS_REG1_0_ADDR;
561fea6deacf72b Iyappan Subramanian 2015-04-28 491 } else {
561fea6deacf72b Iyappan Subramanian 2015-04-28 492 cle_bypass_reg0 = XCLE_BYPASS_REG0_ADDR;
561fea6deacf72b Iyappan Subramanian 2015-04-28 493 cle_bypass_reg1 = XCLE_BYPASS_REG1_ADDR;
561fea6deacf72b Iyappan Subramanian 2015-04-28 494 }
561fea6deacf72b Iyappan Subramanian 2015-04-28 495
32f784b50e14c65 Iyappan Subramanian 2014-10-13 496 data = CFG_CLE_BYPASS_EN0;
561fea6deacf72b Iyappan Subramanian 2015-04-28 497 xgene_enet_wr_csr(p, cle_bypass_reg0 + offset, data);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 498
2c839337520b222 Iyappan Subramanian 2016-12-01 499 fpsel = xgene_enet_get_fpsel(bufpool_id);
d6d489694fda7af Iyappan Subramanian 2016-12-01 500 nxtfpsel = xgene_enet_get_fpsel(nxtbufpool_id);
d6d489694fda7af Iyappan Subramanian 2016-12-01 501 data = CFG_CLE_DSTQID0(dst_ring_num) | CFG_CLE_FPSEL0(fpsel) |
d6d489694fda7af Iyappan Subramanian 2016-12-01 502 CFG_CLE_NXTFPSEL0(nxtfpsel);
561fea6deacf72b Iyappan Subramanian 2015-04-28 503 xgene_enet_wr_csr(p, cle_bypass_reg1 + offset, data);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 504 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 505
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 @506 static void xgene_enet_clear(struct xgene_enet_pdata *pdata,
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 507 struct xgene_enet_desc_ring *ring)
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 508 {
2c839337520b222 Iyappan Subramanian 2016-12-01 509 u32 addr, data;
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 510
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 511 if (xgene_enet_is_bufpool(ring->id)) {
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 512 addr = ENET_CFGSSQMIFPRESET_ADDR;
2c839337520b222 Iyappan Subramanian 2016-12-01 513 data = BIT(xgene_enet_get_fpsel(ring->id));
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 514 } else {
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 515 addr = ENET_CFGSSQMIWQRESET_ADDR;
2c839337520b222 Iyappan Subramanian 2016-12-01 516 data = BIT(xgene_enet_ring_bufnum(ring->id));
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 517 }
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 518
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 519 xgene_enet_wr_ring_if(pdata, addr, data);
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 520 }
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 521
32f784b50e14c65 Iyappan Subramanian 2014-10-13 @522 static void xgene_enet_shutdown(struct xgene_enet_pdata *p)
32f784b50e14c65 Iyappan Subramanian 2014-10-13 523 {
bc61167ac816621 Iyappan Subramanian 2016-07-25 524 struct device *dev = &p->pdev->dev;
bc61167ac816621 Iyappan Subramanian 2016-07-25 525
bc61167ac816621 Iyappan Subramanian 2016-07-25 526 if (dev->of_node) {
bc61167ac816621 Iyappan Subramanian 2016-07-25 527 if (!IS_ERR(p->clk))
bc61167ac816621 Iyappan Subramanian 2016-07-25 528 clk_disable_unprepare(p->clk);
bc61167ac816621 Iyappan Subramanian 2016-07-25 529 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 530 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 531
32f784b50e14c65 Iyappan Subramanian 2014-10-13 @532 static void xgene_enet_link_state(struct work_struct *work)
32f784b50e14c65 Iyappan Subramanian 2014-10-13 533 {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 534 struct xgene_enet_pdata *p = container_of(to_delayed_work(work),
32f784b50e14c65 Iyappan Subramanian 2014-10-13 535 struct xgene_enet_pdata, link_work);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 536 struct net_device *ndev = p->ndev;
32f784b50e14c65 Iyappan Subramanian 2014-10-13 537 u32 link, poll_interval;
32f784b50e14c65 Iyappan Subramanian 2014-10-13 538
32f784b50e14c65 Iyappan Subramanian 2014-10-13 539 link = xgene_enet_link_status(p);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 540 if (link) {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 541 if (!netif_carrier_ok(ndev)) {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 542 netif_carrier_on(ndev);
9a8c5ddedd9805c Iyappan Subramanian 2016-07-25 543 xgene_sgmac_set_speed(p);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 544 xgene_sgmac_rx_enable(p);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 545 xgene_sgmac_tx_enable(p);
9a8c5ddedd9805c Iyappan Subramanian 2016-07-25 546 netdev_info(ndev, "Link is Up - %dMbps\n",
9a8c5ddedd9805c Iyappan Subramanian 2016-07-25 547 p->phy_speed);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 548 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 549 poll_interval = PHY_POLL_LINK_ON;
32f784b50e14c65 Iyappan Subramanian 2014-10-13 550 } else {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 551 if (netif_carrier_ok(ndev)) {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 552 xgene_sgmac_rx_disable(p);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 553 xgene_sgmac_tx_disable(p);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 554 netif_carrier_off(ndev);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 555 netdev_info(ndev, "Link is Down\n");
32f784b50e14c65 Iyappan Subramanian 2014-10-13 556 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 557 poll_interval = PHY_POLL_LINK_OFF;
32f784b50e14c65 Iyappan Subramanian 2014-10-13 558 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 559
32f784b50e14c65 Iyappan Subramanian 2014-10-13 560 schedule_delayed_work(&p->link_work, poll_interval);
32f784b50e14c65 Iyappan Subramanian 2014-10-13 561 }
32f784b50e14c65 Iyappan Subramanian 2014-10-13 562
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 @563 static void xgene_sgmac_enable_tx_pause(struct xgene_enet_pdata *p, bool enable)
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 564 {
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 565 u32 data, ecm_cfg_addr;
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 566
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 567 if (p->enet_id == XGENE_ENET1) {
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 568 ecm_cfg_addr = (!(p->port_id % 2)) ? CSR_ECM_CFG_0_ADDR :
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 569 CSR_ECM_CFG_1_ADDR;
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 570 } else {
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 571 ecm_cfg_addr = XG_MCX_ECM_CFG_0_ADDR;
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 572 }
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 573
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 574 data = xgene_enet_rd_mcx_csr(p, ecm_cfg_addr);
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 575 if (enable)
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 576 data |= MULTI_DPF_AUTOCTRL | PAUSE_XON_EN;
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 577 else
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 578 data &= ~(MULTI_DPF_AUTOCTRL | PAUSE_XON_EN);
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 579 xgene_enet_wr_mcx_csr(p, ecm_cfg_addr, data);
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 580 }
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 581
3cdb73091767649 Julia Lawall 2015-12-08 582 const struct xgene_mac_ops xgene_sgmac_ops = {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 583 .init = xgene_sgmac_init,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 584 .reset = xgene_sgmac_reset,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 585 .rx_enable = xgene_sgmac_rx_enable,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 586 .tx_enable = xgene_sgmac_tx_enable,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 587 .rx_disable = xgene_sgmac_rx_disable,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 588 .tx_disable = xgene_sgmac_tx_disable,
ca6d550c5dbe66e Iyappan Subramanian 2017-05-10 589 .get_drop_cnt = xgene_sgmac_get_drop_cnt,
9a8c5ddedd9805c Iyappan Subramanian 2016-07-25 590 .set_speed = xgene_sgmac_set_speed,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 591 .set_mac_addr = xgene_sgmac_set_mac_addr,
350b4e33b89378c Iyappan Subramanian 2016-12-01 592 .set_framesize = xgene_sgmac_set_frame_size,
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 593 .link_state = xgene_enet_link_state,
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 594 .enable_tx_pause = xgene_sgmac_enable_tx_pause,
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 595 .flowctl_tx = xgene_sgmac_flowctl_tx,
bb64fa09ac1b225 Iyappan Subramanian 2016-12-01 596 .flowctl_rx = xgene_sgmac_flowctl_rx
32f784b50e14c65 Iyappan Subramanian 2014-10-13 597 };
32f784b50e14c65 Iyappan Subramanian 2014-10-13 598
3cdb73091767649 Julia Lawall 2015-12-08 599 const struct xgene_port_ops xgene_sgport_ops = {
32f784b50e14c65 Iyappan Subramanian 2014-10-13 600 .reset = xgene_enet_reset,
cb11c062f9052c6 Iyappan Subramanian 2016-07-25 601 .clear = xgene_enet_clear,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 602 .cle_bypass = xgene_enet_cle_bypass,
32f784b50e14c65 Iyappan Subramanian 2014-10-13 603 .shutdown = xgene_enet_shutdown
32f784b50e14c65 Iyappan Subramanian 2014-10-13 @604 };
:::::: The code at line 480 was first introduced by commit
:::::: 32f784b50e14c653ad0f010fbd5921a5f8caf846 drivers: net: xgene: Add SGMII based 1GbE support
:::::: TO: Iyappan Subramanian <isubramanian@apm.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
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: 69531 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] ipvs: reduce kernel stack usage
From: Arnd Bergmann @ 2019-07-22 10:28 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Kees Cook, Wensong Zhang, Simon Horman, Julian Anastasov,
David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
James Smart, Dick Kennedy, James E . J . Bottomley,
Martin K . Petersen, Larry Finger, Florian Schilhabel,
Greg Kroah-Hartman, James Morris, linux-scsi, linux-kernel,
driverdevel, Network Development, lvs-devel, netfilter-devel,
coreteam, Ard Biesheuvel
In-Reply-To: <CA+FuTSexLuu8e1XHaY0ObGi46CgZnBpELecBr+kMgCU29Fa_gw@mail.gmail.com>
On Fri, Jun 28, 2019 at 9:59 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
> On Fri, Jun 28, 2019 at 8:40 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > With the new CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL option, the stack
> > usage in the ipvs debug output grows because each instance of
> > IP_VS_DBG_BUF() now has its own buffer of 160 bytes that add up
> > rather than reusing the stack slots:
> >
> > net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_sched_persist':
> > net/netfilter/ipvs/ip_vs_core.c:427:1: error: the frame size of 1052 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> > net/netfilter/ipvs/ip_vs_core.c: In function 'ip_vs_new_conn_out':
> > net/netfilter/ipvs/ip_vs_core.c:1231:1: error: the frame size of 1048 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> > net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_out':
> > net/netfilter/ipvs/ip_vs_ftp.c:397:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> > net/netfilter/ipvs/ip_vs_ftp.c: In function 'ip_vs_ftp_in':
> > net/netfilter/ipvs/ip_vs_ftp.c:555:1: error: the frame size of 1200 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
> >
> > Since printk() already has a way to print IPv4/IPv6 addresses using
> > the %pIS format string, use that instead,
>
> since these are sockaddr_in and sockaddr_in6, should that have the 'n'
> specifier to denote network byteorder?
I double-checked the implementation, and don't see that make any difference,
as 'n' is the default.
> > include/net/ip_vs.h | 71 +++++++++++++++++++--------------
> > net/netfilter/ipvs/ip_vs_core.c | 44 ++++++++++----------
> > net/netfilter/ipvs/ip_vs_ftp.c | 20 +++++-----
> > 3 files changed, 72 insertions(+), 63 deletions(-)
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index 3759167f91f5..3dfbeef67be6 100644
> > --- a/include/net/ip_vs.h
> > +++ b/include/net/ip_vs.h
> > @@ -227,6 +227,16 @@ static inline const char *ip_vs_dbg_addr(int af, char *buf, size_t buf_len,
> > sizeof(ip_vs_dbg_buf), addr, \
> > &ip_vs_dbg_idx)
> >
> > +#define IP_VS_DBG_SOCKADDR4(fam, addr, port) \
> > + (struct sockaddr*)&(struct sockaddr_in) \
> > + { .sin_family = (fam), .sin_addr = (addr)->in, .sin_port = (port) }
>
> might as well set .sin_family = AF_INET here and AF_INET6 below?
That would work just same, but I don't see any advantage. As the family
and port members are the same between sockaddr_in and sockaddr_in6,
the compiler can decide to set these regardless to the argument values
regardless of the condition.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-22 10:27 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB326667E86622C3ABD5CDE642D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On 22/07/2019 10:57, Jose Abreu wrote:
...
> Also, please add attached patch. You'll get a compiler warning, just
> disregard it.
Here you are ...
https://paste.ubuntu.com/p/H9Mvv37vN9/
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Ilias Apalodimas @ 2019-07-22 10:18 UTC (permalink / raw)
To: Jose Abreu
Cc: Jon Hunter, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <BN8PR12MB32661E919A8DEBC7095BAA12D3C80@BN8PR12MB3266.namprd12.prod.outlook.com>
On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
>
> > Let me know if you have any thoughts.
>
> Can you try attached patch ?
>
The log says someone calls panic() right?
Can we trye and figure were that happens during the stmmac init phase?
Thanks
/Ilias
^ permalink raw reply
* Re: [PATCH 4/4] ipvs: reduce kernel stack usage
From: Arnd Bergmann @ 2019-07-22 10:16 UTC (permalink / raw)
To: Julian Anastasov
Cc: Kees Cook, Wensong Zhang, Simon Horman, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, James Smart, Dick Kennedy,
James E . J . Bottomley, Martin K . Petersen, Larry Finger,
Florian Schilhabel, Greg Kroah-Hartman, James Morris, linux-scsi,
Linux Kernel Mailing List, driverdevel, Networking, lvs-devel,
netfilter-devel, coreteam, Ard Biesheuvel
In-Reply-To: <alpine.LFD.2.21.1906302308280.3788@ja.home.ssi.bg>
On Sun, Jun 30, 2019 at 10:37 PM Julian Anastasov <ja@ssi.bg> wrote:
> On Fri, 28 Jun 2019, Arnd Bergmann wrote:
> > struct ip_vs_conn *ctl_cp = cp->control;
> > if (!ctl_cp) {
> > - IP_VS_ERR_BUF("request control DEL for uncontrolled: "
> > - "%s:%d to %s:%d\n",
> > - IP_VS_DBG_ADDR(cp->af, &cp->caddr),
> > - ntohs(cp->cport),
> > - IP_VS_DBG_ADDR(cp->af, &cp->vaddr),
> > - ntohs(cp->vport));
> > + pr_err("request control DEL for uncontrolled: "
> > + "%pISp to %pISp\n",
(replying a bit late)
> ip_vs_dbg_addr() used compact form (%pI6c), so it would be
> better to use %pISc and %pISpc everywhere in IPVS...
done
> Also, note that before now port was printed with %d and
> ntohs() was used, now port should be in network order, so:
>
> - ntohs() should be removed
done
> - htons() should be added, if missing. At first look, this case
> is not present in IPVS, we have only ntohs() usage
I found one case in ip_vs_ftp_in() that needs it in order to subtract one:
IP_VS_DBG(7, "protocol %s %pISpc %pISpc\n",
ip_vs_proto_name(ipvsh->protocol),
- IP_VS_DBG_SOCKADDR(cp->af, &to, ntohs(port)),
+ IP_VS_DBG_SOCKADDR(cp->af, &to, port),
IP_VS_DBG_SOCKADDR(cp->af, &cp->vaddr,
- ntohs(cp->vport)-1));
+ htons(ntohs(cp->vport)-1)));
Thanks for the review, I'll send a new patch after some more
build testing on the new version.
Arnd
^ permalink raw reply
* Re: INFO: rcu detected stall in ext4_write_checks
From: Dmitry Vyukov @ 2019-07-22 10:03 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Paul E. McKenney, Theodore Ts'o, syzbot, Andreas Dilger,
David Miller, eladr, Ido Schimmel, Jiri Pirko, John Stultz,
linux-ext4, LKML, netdev, syzkaller-bugs, Thomas Gleixner,
Ingo Molnar
In-Reply-To: <20190715134651.GI3419@hirez.programming.kicks-ass.net>
On Mon, Jul 15, 2019 at 3:46 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Jul 15, 2019 at 03:33:11PM +0200, Dmitry Vyukov wrote:
> > On Mon, Jul 15, 2019 at 3:29 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Sun, Jul 14, 2019 at 11:49:15AM -0700, Paul E. McKenney wrote:
> > > > On Sun, Jul 14, 2019 at 05:48:00PM +0300, Dmitry Vyukov wrote:
> > > > > But short term I don't see any other solution than stop testing
> > > > > sched_setattr because it does not check arguments enough to prevent
> > > > > system misbehavior. Which is a pity because syzkaller has found some
> > > > > bad misconfigurations that were oversight on checking side.
> > > > > Any other suggestions?
> > > >
> > > > Keep the times down to a few seconds? Of course, that might also
> > > > fail to find interesting bugs.
> > >
> > > Right, if syzcaller can put a limit on the period/deadline parameters
> > > (and make sure to not write "-1" to
> > > /proc/sys/kernel/sched_rt_runtime_us) then per the in-kernel
> > > access-control should not allow these things to happen.
> >
> > Since we are racing with emails, could you suggest a 100% safe
> > parameters? Because I only hear people saying "safe", "sane",
> > "well-behaving" :)
> > If we move the check to user-space, it does not mean that we can get
> > away without actually defining what that means.
>
> Right, well, that's part of the problem. I think Paul just did the
> reverse math and figured that 95% of X must not be larger than my
> watchdog timeout and landed on 14 seconds.
>
> I'm thinking 4 seconds (or rather 4.294967296) would be a very nice
> number.
>
> > Now thinking of this, if we come up with some simple criteria, could
> > we have something like a sysctl that would allow only really "safe"
> > parameters?
>
> I suppose we could do that, something like:
> sysctl_deadline_period_{min,max}. I'll have to dig back a bit on where
> we last talked about that and what the problems where.
>
> For one, setting the min is a lot harder, but I suppose we can start at
> TICK_NSEC or something.
Now syzkaller will drop CAP_SYS_NICE for the test process:
https://github.com/google/syzkaller/commit/f3ad68446455acbe562e0057931e6256b8b991e8
I will close this bug report as invalid once the change reaches all
syzbot instances, if nobody plans any other on this bug.
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 9:57 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB3266362102CCB6B4DDE4BEA0D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]
From: Jose Abreu <joabreu@synopsys.com>
Date: Jul/22/2019, 10:47:44 (UTC+00:00)
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/22/2019, 10:37:18 (UTC+00:00)
>
> >
> > On 22/07/2019 08:23, Jose Abreu wrote:
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Jul/19/2019, 14:35:52 (UTC+00:00)
> > >
> > >>
> > >> On 19/07/2019 13:32, Jose Abreu wrote:
> > >>> From: Jon Hunter <jonathanh@nvidia.com>
> > >>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
> > >>>
> > >>>> I booted the board without using NFS and then started used dhclient to
> > >>>> bring up the network interface and it appears to be working fine. I can
> > >>>> even mount the NFS share fine. So it does appear to be particular to
> > >>>> using NFS to mount the rootfs.
> > >>>
> > >>> Damn. Can you send me your .config ?
> > >>
> > >> Yes no problem. Attached.
> > >
> > > Can you compile your image without modules (i.e. all built-in) and let
> > > me know if the error still happens ?
> >
> > I simply removed the /lib/modules directory from the NFS share and
> > verified that I still see the same issue. So it is not loading the
> > modules that is a problem.
>
> Well, I meant that loading modules can be an issue but that's not the
> way to verify that.
>
> You need to have all modules built-in so that it proves that no module
> will try to be loaded.
>
> Anyway, this is probably not the cause as you wouldn't even be able to
> compile kernel if you need a symbol from a module with stmmac built-in.
> Kconfig would complain about that.
>
> The other cause could be data corruption in the RX path. Are you able to
> send me packet dump by running wireshark either in the transmitter side
> (i.e. NFS server), or using some kind of switch ?
>
> ---
> Thanks,
> Jose Miguel Abreu
Also, please add attached patch. You'll get a compiler warning, just
disregard it.
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-stmmac-Debug-print.patch --]
[-- Type: application/octet-stream, Size: 1514 bytes --]
From b78be4f19e57b6a4d5f67bda1c52c90f6cd901ab Mon Sep 17 00:00:00 2001
Message-Id: <b78be4f19e57b6a4d5f67bda1c52c90f6cd901ab.1563789387.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 22 Jul 2019 11:52:28 +0200
Subject: [PATCH net] net: stmmac: Debug print
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0ac79f3e2cee..7a6920098dd0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3433,6 +3433,10 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
dma_sync_single_for_device(priv->device, buf->addr,
frame_len, DMA_FROM_DEVICE);
+ pr_info("%s: paddr=0x%llx, vaddr=0x%llx, len=%d", __func__,
+ buf->addr, page_address(buf->page),
+ frame_len);
+
if (netif_msg_pktdata(priv)) {
netdev_dbg(priv->dev, "frame received (%dbytes)",
frame_len);
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 9:47 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <49efad87-2f74-5804-af4c-33730f865c41@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/22/2019, 10:37:18 (UTC+00:00)
>
> On 22/07/2019 08:23, Jose Abreu wrote:
> > From: Jon Hunter <jonathanh@nvidia.com>
> > Date: Jul/19/2019, 14:35:52 (UTC+00:00)
> >
> >>
> >> On 19/07/2019 13:32, Jose Abreu wrote:
> >>> From: Jon Hunter <jonathanh@nvidia.com>
> >>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
> >>>
> >>>> I booted the board without using NFS and then started used dhclient to
> >>>> bring up the network interface and it appears to be working fine. I can
> >>>> even mount the NFS share fine. So it does appear to be particular to
> >>>> using NFS to mount the rootfs.
> >>>
> >>> Damn. Can you send me your .config ?
> >>
> >> Yes no problem. Attached.
> >
> > Can you compile your image without modules (i.e. all built-in) and let
> > me know if the error still happens ?
>
> I simply removed the /lib/modules directory from the NFS share and
> verified that I still see the same issue. So it is not loading the
> modules that is a problem.
Well, I meant that loading modules can be an issue but that's not the
way to verify that.
You need to have all modules built-in so that it proves that no module
will try to be loaded.
Anyway, this is probably not the cause as you wouldn't even be able to
compile kernel if you need a symbol from a module with stmmac built-in.
Kconfig would complain about that.
The other cause could be data corruption in the RX path. Are you able to
send me packet dump by running wireshark either in the transmitter side
(i.e. NFS server), or using some kind of switch ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Marc Kleine-Budde @ 2019-07-22 9:45 UTC (permalink / raw)
To: Ji-Ze Hong (Peter Hong), wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <1563776521-28317-1-git-send-email-hpeter+linux_kernel@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1789 bytes --]
On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote:
> This patch add support for Fintek PCIE to 2 CAN controller support
>
> Signed-off-by: Ji-Ze Hong (Peter Hong) <hpeter+linux_kernel@gmail.com>
> ---
> Changelog:
> v2:
> 1: Fix comment on the spinlock with write access.
> 2: Use ARRAY_SIZE instead of F81601_PCI_MAX_CHAN.
> 3: Check the strap pin outside the loop.
> 4: Fix the cleanup issue in f81601_pci_add_card().
> 5: Remove unused "channels" in struct f81601_pci_card.
>
> drivers/net/can/sja1000/Kconfig | 8 ++
> drivers/net/can/sja1000/Makefile | 1 +
> drivers/net/can/sja1000/f81601.c | 215 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/net/can/sja1000/f81601.c
> diff --git a/drivers/net/can/sja1000/f81601.c b/drivers/net/can/sja1000/f81601.c
> new file mode 100644
> index 000000000000..3c378de8764d
> --- /dev/null
> +++ b/drivers/net/can/sja1000/f81601.c
[...]
> +static void f81601_pci_del_card(struct pci_dev *pdev)
> +{
> + struct f81601_pci_card *card = pci_get_drvdata(pdev);
> + struct net_device *dev;
> + int i = 0;
> +
> + for (i = 0; i < ARRAY_SIZE(card->net_dev); i++) {
> + dev = card->net_dev[i];
> + if (!dev)
> + continue;
> +
> + dev_info(&pdev->dev, "%s: Removing %s\n", __func__, dev->name);
> +
> + unregister_sja1000dev(dev);
> + free_sja1000dev(dev);
> + }
> +
> + pcim_iounmap(pdev, card->addr);
Why do you need iounmap()?
> +}
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jon Hunter @ 2019-07-22 9:37 UTC (permalink / raw)
To: Jose Abreu, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai,
linux-tegra
In-Reply-To: <BN8PR12MB32665C1A106D3DCBF89CEA54D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On 22/07/2019 08:23, Jose Abreu wrote:
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/19/2019, 14:35:52 (UTC+00:00)
>
>>
>> On 19/07/2019 13:32, Jose Abreu wrote:
>>> From: Jon Hunter <jonathanh@nvidia.com>
>>> Date: Jul/19/2019, 13:30:10 (UTC+00:00)
>>>
>>>> I booted the board without using NFS and then started used dhclient to
>>>> bring up the network interface and it appears to be working fine. I can
>>>> even mount the NFS share fine. So it does appear to be particular to
>>>> using NFS to mount the rootfs.
>>>
>>> Damn. Can you send me your .config ?
>>
>> Yes no problem. Attached.
>
> Can you compile your image without modules (i.e. all built-in) and let
> me know if the error still happens ?
I simply removed the /lib/modules directory from the NFS share and
verified that I still see the same issue. So it is not loading the
modules that is a problem.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 2/3] net/xdp: convert put_page() to put_user_page*()
From: Christoph Hellwig @ 2019-07-22 9:34 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190722043012.22945-3-jhubbard@nvidia.com>
> diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
> index 83de74ca729a..9cbbb96c2a32 100644
> --- a/net/xdp/xdp_umem.c
> +++ b/net/xdp/xdp_umem.c
> @@ -171,8 +171,7 @@ static void xdp_umem_unpin_pages(struct xdp_umem *umem)
> for (i = 0; i < umem->npgs; i++) {
> struct page *page = umem->pgs[i];
>
> - set_page_dirty_lock(page);
> - put_page(page);
> + put_user_pages_dirty_lock(&page, 1);
Same here, we really should avoid the need for the loop here and
do the looping inside the helper.
^ permalink raw reply
* Re: [PATCH 1/3] drivers/gpu/drm/via: convert put_page() to put_user_page*()
From: Christoph Hellwig @ 2019-07-22 9:33 UTC (permalink / raw)
To: john.hubbard
Cc: Andrew Morton, Alexander Viro, Björn Töpel,
Boaz Harrosh, Christoph Hellwig, Daniel Vetter, Dan Williams,
Dave Chinner, David Airlie, David S . Miller, Ilya Dryomov,
Jan Kara, Jason Gunthorpe, Jens Axboe, Jérôme Glisse,
Johannes Thumshirn, Magnus Karlsson, Matthew Wilcox,
Miklos Szeredi, Ming Lei, Sage Weil, Santosh Shilimkar, Yan Zheng,
netdev, dri-devel, linux-mm, linux-rdma, bpf, LKML, John Hubbard
In-Reply-To: <20190722043012.22945-2-jhubbard@nvidia.com>
On Sun, Jul 21, 2019 at 09:30:10PM -0700, john.hubbard@gmail.com wrote:
> for (i = 0; i < vsg->num_pages; ++i) {
> if (NULL != (page = vsg->pages[i])) {
> if (!PageReserved(page) && (DMA_FROM_DEVICE == vsg->direction))
> - SetPageDirty(page);
> - put_page(page);
> + put_user_pages_dirty(&page, 1);
> + else
> + put_user_page(page);
> }
Can't just pass a dirty argument to put_user_pages? Also do we really
need a separate put_user_page for the single page case?
put_user_pages_dirty?
Also the PageReserved check looks bogus, as I can't see how a reserved
page can end up here. So IMHO the above snippled should really look
something like this:
put_user_pages(vsg->pages[i], vsg->num_pages,
vsg->direction == DMA_FROM_DEVICE);
in the end.
^ permalink raw reply
* Re: [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput
From: Stefano Garzarella @ 2019-07-22 9:14 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190722090835.GF24934@stefanha-x1.localdomain>
On Mon, Jul 22, 2019 at 10:08:35AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 17, 2019 at 01:30:25PM +0200, Stefano Garzarella wrote:
> > This series tries to increase the throughput of virtio-vsock with slight
> > changes.
> > While I was testing the v2 of this series I discovered an huge use of memory,
> > so I added patch 1 to mitigate this issue. I put it in this series in order
> > to better track the performance trends.
> >
> > v4:
> > - rebased all patches on current master (conflicts is Patch 4)
> > - Patch 1: added Stefan's R-b
> > - Patch 3: removed lock when buf_alloc is written [David];
> > moved this patch after "vsock/virtio: reduce credit update messages"
> > to make it clearer
> > - Patch 4: vhost_exceeds_weight() is recently introduced, so I've solved some
> > conflicts
>
> Stefano: Do you want to continue experimenting before we merge this
> patch series? The code looks functionally correct and the performance
> increases, so I'm happy for it to be merged.
I think we can merge this series.
I'll continue to do other experiments (e.g. removing TX workers, allocating
pages, etc.) but I think these changes are prerequisites for the other patches,
so we can merge them.
Thank you very much for the reviews!
Stefano
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Marc Kleine-Budde @ 2019-07-22 9:11 UTC (permalink / raw)
To: Ji-Ze Hong (Peter Hong), wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <b7c9026a-a887-bc84-3297-c319d18686c3@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1077 bytes --]
On 7/22/19 10:36 AM, Ji-Ze Hong (Peter Hong) wrote:
> Hi Marc,
>
> Marc Kleine-Budde 於 2019/7/22 下午 04:15 寫道:
>> On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote: >> +/* Probe F81601 based device for the SJA1000 chips and register each
>>> + * available CAN channel to SJA1000 Socket-CAN subsystem.
>>> + */
>>> +static int f81601_pci_add_card(struct pci_dev *pdev,
>>> + const struct pci_device_id *ent)
>>> +{
>>> + struct sja1000_priv *priv;
>>> + struct net_device *dev;
>>> + struct f81601_pci_card *card;
>>> + int err, i, count;
>>> + u8 tmp;
>>> +
>>> + if (pcim_enable_device(pdev) < 0) {
>>
>> I'm missing a corresponding disable_device().
>>
> I'm using managed pcim_enable_device(), Does it need call
> pci_disable_device() ??
Right.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/5] vsock/virtio: optimizations to increase the throughput
From: Stefan Hajnoczi @ 2019-07-22 9:08 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-1-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
On Wed, Jul 17, 2019 at 01:30:25PM +0200, Stefano Garzarella wrote:
> This series tries to increase the throughput of virtio-vsock with slight
> changes.
> While I was testing the v2 of this series I discovered an huge use of memory,
> so I added patch 1 to mitigate this issue. I put it in this series in order
> to better track the performance trends.
>
> v4:
> - rebased all patches on current master (conflicts is Patch 4)
> - Patch 1: added Stefan's R-b
> - Patch 3: removed lock when buf_alloc is written [David];
> moved this patch after "vsock/virtio: reduce credit update messages"
> to make it clearer
> - Patch 4: vhost_exceeds_weight() is recently introduced, so I've solved some
> conflicts
Stefano: Do you want to continue experimenting before we merge this
patch series? The code looks functionally correct and the performance
increases, so I'm happy for it to be merged.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] vsock/virtio: change the maximum packet size allowed
From: Stefan Hajnoczi @ 2019-07-22 9:07 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-6-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 495 bytes --]
On Wed, Jul 17, 2019 at 01:30:30PM +0200, Stefano Garzarella wrote:
> Since now we are able to split packets, we can avoid limiting
> their sizes to VIRTIO_VSOCK_DEFAULT_RX_BUF_SIZE.
> Instead, we can use VIRTIO_VSOCK_MAX_PKT_BUF_SIZE as the max
> packet size.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 4/5] vhost/vsock: split packets to send using multiple buffers
From: Stefan Hajnoczi @ 2019-07-22 9:06 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-5-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]
On Wed, Jul 17, 2019 at 01:30:29PM +0200, Stefano Garzarella wrote:
> If the packets to sent to the guest are bigger than the buffer
> available, we can split them, using multiple buffers and fixing
> the length in the packet header.
> This is safe since virtio-vsock supports only stream sockets.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> drivers/vhost/vsock.c | 66 ++++++++++++++++++-------
> net/vmw_vsock/virtio_transport_common.c | 15 ++++--
> 2 files changed, 60 insertions(+), 21 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/5] vsock/virtio: fix locking in virtio_transport_inc_tx_pkt()
From: Stefan Hajnoczi @ 2019-07-22 8:53 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-4-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
On Wed, Jul 17, 2019 at 01:30:28PM +0200, Stefano Garzarella wrote:
> fwd_cnt and last_fwd_cnt are protected by rx_lock, so we should use
> the same spinlock also if we are in the TX path.
>
> Move also buf_alloc under the same lock.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> include/linux/virtio_vsock.h | 2 +-
> net/vmw_vsock/virtio_transport_common.c | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net 1/2] net: stmmac: RX Descriptors need to be clean before setting buffers
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1563784666.git.joabreu@synopsys.com>
RX Descriptors are being cleaned after setting the buffers which may
lead to buffer addresses being wiped out.
Fix this by clearing earlier the RX Descriptors.
Fixes: 2af6106ae949 ("net: stmmac: Introducing support for Page Pool")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index c7c9e5f162e6..5f1294ce0216 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1295,6 +1295,8 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
"(%s) dma_rx_phy=0x%08x\n", __func__,
(u32)rx_q->dma_rx_phy);
+ stmmac_clear_rx_descriptors(priv, queue);
+
for (i = 0; i < DMA_RX_SIZE; i++) {
struct dma_desc *p;
@@ -1312,8 +1314,6 @@ static int init_dma_rx_desc_rings(struct net_device *dev, gfp_t flags)
rx_q->cur_rx = 0;
rx_q->dirty_rx = (unsigned int)(i - DMA_RX_SIZE);
- stmmac_clear_rx_descriptors(priv, queue);
-
/* Setup the chained descriptor addresses */
if (priv->mode == STMMAC_CHAIN_MODE) {
if (priv->extend_desc)
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/2] net: stmmac: Use kcalloc() instead of kmalloc_array()
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <cover.1563784666.git.joabreu@synopsys.com>
We need the memory to be zeroed upon allocation so use kcalloc()
instead.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5f1294ce0216..0ac79f3e2cee 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1555,9 +1555,8 @@ static int alloc_dma_rx_desc_resources(struct stmmac_priv *priv)
goto err_dma;
}
- rx_q->buf_pool = kmalloc_array(DMA_RX_SIZE,
- sizeof(*rx_q->buf_pool),
- GFP_KERNEL);
+ rx_q->buf_pool = kcalloc(DMA_RX_SIZE, sizeof(*rx_q->buf_pool),
+ GFP_KERNEL);
if (!rx_q->buf_pool)
goto err_dma;
@@ -1608,15 +1607,15 @@ static int alloc_dma_tx_desc_resources(struct stmmac_priv *priv)
tx_q->queue_index = queue;
tx_q->priv_data = priv;
- tx_q->tx_skbuff_dma = kmalloc_array(DMA_TX_SIZE,
- sizeof(*tx_q->tx_skbuff_dma),
- GFP_KERNEL);
+ tx_q->tx_skbuff_dma = kcalloc(DMA_TX_SIZE,
+ sizeof(*tx_q->tx_skbuff_dma),
+ GFP_KERNEL);
if (!tx_q->tx_skbuff_dma)
goto err_dma;
- tx_q->tx_skbuff = kmalloc_array(DMA_TX_SIZE,
- sizeof(struct sk_buff *),
- GFP_KERNEL);
+ tx_q->tx_skbuff = kcalloc(DMA_TX_SIZE,
+ sizeof(struct sk_buff *),
+ GFP_KERNEL);
if (!tx_q->tx_skbuff)
goto err_dma;
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/2] net: stmmac: Two fixes
From: Jose Abreu @ 2019-07-22 8:39 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel
Two fixes targeting -net.
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
Jose Abreu (2):
net: stmmac: RX Descriptors need to be clean before setting buffers
net: stmmac: Use kcalloc() instead of kmalloc_array()
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH V2 1/1] can: sja1000: f81601: add Fintek F81601 support
From: Ji-Ze Hong (Peter Hong) @ 2019-07-22 8:36 UTC (permalink / raw)
To: Marc Kleine-Budde, wg, peter_hong
Cc: davem, f.suligoi, linux-kernel, linux-can, netdev,
Ji-Ze Hong (Peter Hong)
In-Reply-To: <563b0d71-3c60-d32c-cf19-73611f68d45a@pengutronix.de>
Hi Marc,
Marc Kleine-Budde 於 2019/7/22 下午 04:15 寫道:
> On 7/22/19 8:22 AM, Ji-Ze Hong (Peter Hong) wrote: >> +/* Probe F81601 based device for the SJA1000 chips and register each
>> + * available CAN channel to SJA1000 Socket-CAN subsystem.
>> + */
>> +static int f81601_pci_add_card(struct pci_dev *pdev,
>> + const struct pci_device_id *ent)
>> +{
>> + struct sja1000_priv *priv;
>> + struct net_device *dev;
>> + struct f81601_pci_card *card;
>> + int err, i, count;
>> + u8 tmp;
>> +
>> + if (pcim_enable_device(pdev) < 0) {
>
> I'm missing a corresponding disable_device().
>
I'm using managed pcim_enable_device(), Does it need call
pci_disable_device() ??
Thanks
--
With Best Regards,
Peter Hong
^ permalink raw reply
* Re: [PATCH v4 2/5] vsock/virtio: reduce credit update messages
From: Stefan Hajnoczi @ 2019-07-22 8:36 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, linux-kernel, David S. Miller, virtualization, Jason Wang,
kvm, Michael S. Tsirkin
In-Reply-To: <20190717113030.163499-3-sgarzare@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Wed, Jul 17, 2019 at 01:30:27PM +0200, Stefano Garzarella wrote:
> In order to reduce the number of credit update messages,
> we send them only when the space available seen by the
> transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
> ---
> include/linux/virtio_vsock.h | 1 +
> net/vmw_vsock/virtio_transport_common.c | 16 +++++++++++++---
> 2 files changed, 14 insertions(+), 3 deletions(-)
It's an arbitrary limit but the risk of regressions is low since the
credit update traffic was so excessive:
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH V4] can: flexcan: fix stop mode acknowledgment
From: Joakim Zhang @ 2019-07-22 8:28 UTC (permalink / raw)
To: mkl@pengutronix.de, linux-can@vger.kernel.org
Cc: wg@grandegger.com, netdev@vger.kernel.org, dl-linux-imx
In-Reply-To: <20190702014316.26444-1-qiangqing.zhang@nxp.com>
Kindly Ping...
Best Regards,
Joakim Zhang
> -----Original Message-----
> From: Joakim Zhang
> Sent: 2019年7月2日 9:46
> To: mkl@pengutronix.de; linux-can@vger.kernel.org
> Cc: wg@grandegger.com; netdev@vger.kernel.org; dl-linux-imx
> <linux-imx@nxp.com>; Joakim Zhang <qiangqing.zhang@nxp.com>
> Subject: [PATCH V4] can: flexcan: fix stop mode acknowledgment
>
> To enter stop mode, the CPU should manually assert a global Stop Mode
> request and check the acknowledgment asserted by FlexCAN. The CPU must
> only consider the FlexCAN in stop mode when both request and
> acknowledgment conditions are satisfied.
>
> Fixes: de3578c198c6 ("can: flexcan: add self wakeup support")
> Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
>
> ChangeLog:
> V1->V2:
> * regmap_read()-->regmap_read_poll_timeout()
> V2->V3:
> * change the way of error return, it will make easy for function
> extension.
> V3->V4:
> * rebase to linux-next/master, as this is a fix.
> ---
> drivers/net/can/flexcan.c | 31 +++++++++++++++++++++++++++----
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c index
> 1c66fb2ad76b..bf1bd6f5dbb1 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
> @@ -400,9 +400,10 @@ static void flexcan_enable_wakeup_irq(struct
> flexcan_priv *priv, bool enable)
> priv->write(reg_mcr, ®s->mcr);
> }
>
> -static inline void flexcan_enter_stop_mode(struct flexcan_priv *priv)
> +static inline int flexcan_enter_stop_mode(struct flexcan_priv *priv)
> {
> struct flexcan_regs __iomem *regs = priv->regs;
> + unsigned int ackval;
> u32 reg_mcr;
>
> reg_mcr = priv->read(®s->mcr);
> @@ -412,20 +413,37 @@ static inline void flexcan_enter_stop_mode(struct
> flexcan_priv *priv)
> /* enable stop request */
> regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> 1 << priv->stm.req_bit, 1 << priv->stm.req_bit);
> +
> + /* get stop acknowledgment */
> + if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
> + ackval, ackval & (1 << priv->stm.ack_bit),
> + 0, FLEXCAN_TIMEOUT_US))
> + return -ETIMEDOUT;
> +
> + return 0;
> }
>
> -static inline void flexcan_exit_stop_mode(struct flexcan_priv *priv)
> +static inline int flexcan_exit_stop_mode(struct flexcan_priv *priv)
> {
> struct flexcan_regs __iomem *regs = priv->regs;
> + unsigned int ackval;
> u32 reg_mcr;
>
> /* remove stop request */
> regmap_update_bits(priv->stm.gpr, priv->stm.req_gpr,
> 1 << priv->stm.req_bit, 0);
>
> + /* get stop acknowledgment */
> + if (regmap_read_poll_timeout(priv->stm.gpr, priv->stm.ack_gpr,
> + ackval, !(ackval & (1 << priv->stm.ack_bit)),
> + 0, FLEXCAN_TIMEOUT_US))
> + return -ETIMEDOUT;
> +
> reg_mcr = priv->read(®s->mcr);
> reg_mcr &= ~FLEXCAN_MCR_SLF_WAK;
> priv->write(reg_mcr, ®s->mcr);
> +
> + return 0;
> }
>
> static inline void flexcan_error_irq_enable(const struct flexcan_priv *priv)
> @@ -1615,7 +1633,9 @@ static int __maybe_unused flexcan_suspend(struct
> device *device)
> */
> if (device_may_wakeup(device)) {
> enable_irq_wake(dev->irq);
> - flexcan_enter_stop_mode(priv);
> + err = flexcan_enter_stop_mode(priv);
> + if (err)
> + return err;
> } else {
> err = flexcan_chip_disable(priv);
> if (err)
> @@ -1665,10 +1685,13 @@ static int __maybe_unused
> flexcan_noirq_resume(struct device *device) {
> struct net_device *dev = dev_get_drvdata(device);
> struct flexcan_priv *priv = netdev_priv(dev);
> + int err;
>
> if (netif_running(dev) && device_may_wakeup(device)) {
> flexcan_enable_wakeup_irq(priv, false);
> - flexcan_exit_stop_mode(priv);
> + err = flexcan_exit_stop_mode(priv);
> + if (err)
> + return err;
> }
>
> return 0;
> --
> 2.17.1
^ 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