SPI NOR core changes:
- introduce 'struct spi_nor_controller_ops', - clean the Register Operations methods, - use dev_dbg insted of dev_err for low level info, - fix retlen handling in sst_write(), - fix silent truncations in spi_nor_read and spi_nor_read_raw(), - fix the clearing of QE bit on lock()/unlock(), - rework the disabling of the block write protection, - rework the Quad Enable methods, - make sure nor->spimem and nor->controller_ops are mutually exclusive, - set default Quad Enable method for ISSI flashes, - add support for few flashes. SPI NOR controller drivers changes: - intel-spi: - support chips without software sequencer, - add support for Intel Cannon Lake and Intel Comet Lake-H flashes. -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEHUIqys8OyG1eHf7fS1VPR6WNFOkFAl3Kep8ACgkQS1VPR6WN FOn9kgf/aKPgU6LR84YpwUKRZ4S+6K1H8SdDUt8v0FYSQ6oaTjF13fApg43WDja5 Zk0l5tlX7WIvlcRC6XKPhryZTXOKWojW1X8sguPYIZGzo7q82Eyda23jkw1QptWr VO9L/tdK4yVUbdtp6VS/FUF31PC0DtDoCzsfBSUgrZP2srFF1BtOJNUgyuDceoxo y3hEmINDnkaOvDDl/kbJjdEHG4PV8Vi4k0KE8deLpqlp8GDG1nkTeA1Sim7WjBPA ZZOdg9fmGI8H8+umQEnn06H4O95T2+fX+kDMCYo4RbgWyWlGv5TidgRREmC/cSbl YEPu6LCQoUZPVEvgolr/8Akf968ZiQ== =i15M -----END PGP SIGNATURE----- Merge tag 'spi-nor/for-5.5' into mtd/next SPI NOR core changes: - introduce 'struct spi_nor_controller_ops', - clean the Register Operations methods, - use dev_dbg insted of dev_err for low level info, - fix retlen handling in sst_write(), - fix silent truncations in spi_nor_read and spi_nor_read_raw(), - fix the clearing of QE bit on lock()/unlock(), - rework the disabling of the block write protection, - rework the Quad Enable methods, - make sure nor->spimem and nor->controller_ops are mutually exclusive, - set default Quad Enable method for ISSI flashes, - add support for few flashes. SPI NOR controller drivers changes: - intel-spi: - support chips without software sequencer, - add support for Intel Cannon Lake and Intel Comet Lake-H flashes.
This commit is contained in:
Miquel Raynal
commit
8389a7b909
986 changed files with 10363 additions and 9080 deletions
|
|
@ -615,8 +615,8 @@ on an IO device and is an example of this type.
|
|||
Protections
|
||||
-----------
|
||||
|
||||
A cgroup is protected to be allocated upto the configured amount of
|
||||
the resource if the usages of all its ancestors are under their
|
||||
A cgroup is protected upto the configured amount of the resource
|
||||
as long as the usages of all its ancestors are under their
|
||||
protected levels. Protections can be hard guarantees or best effort
|
||||
soft boundaries. Protections can also be over-committed in which case
|
||||
only upto the amount available to the parent is protected among
|
||||
|
|
@ -1096,7 +1096,10 @@ PAGE_SIZE multiple when read back.
|
|||
is within its effective min boundary, the cgroup's memory
|
||||
won't be reclaimed under any conditions. If there is no
|
||||
unprotected reclaimable memory available, OOM killer
|
||||
is invoked.
|
||||
is invoked. Above the effective min boundary (or
|
||||
effective low boundary if it is higher), pages are reclaimed
|
||||
proportionally to the overage, reducing reclaim pressure for
|
||||
smaller overages.
|
||||
|
||||
Effective min boundary is limited by memory.min values of
|
||||
all ancestor cgroups. If there is memory.min overcommitment
|
||||
|
|
@ -1118,7 +1121,10 @@ PAGE_SIZE multiple when read back.
|
|||
Best-effort memory protection. If the memory usage of a
|
||||
cgroup is within its effective low boundary, the cgroup's
|
||||
memory won't be reclaimed unless memory can be reclaimed
|
||||
from unprotected cgroups.
|
||||
from unprotected cgroups. Above the effective low boundary (or
|
||||
effective min boundary if it is higher), pages are reclaimed
|
||||
proportionally to the overage, reducing reclaim pressure for
|
||||
smaller overages.
|
||||
|
||||
Effective low boundary is limited by memory.low values of
|
||||
all ancestor cgroups. If there is memory.low overcommitment
|
||||
|
|
@ -2482,8 +2488,10 @@ system performance due to overreclaim, to the point where the feature
|
|||
becomes self-defeating.
|
||||
|
||||
The memory.low boundary on the other hand is a top-down allocated
|
||||
reserve. A cgroup enjoys reclaim protection when it's within its low,
|
||||
which makes delegation of subtrees possible.
|
||||
reserve. A cgroup enjoys reclaim protection when it's within its
|
||||
effective low, which makes delegation of subtrees possible. It also
|
||||
enjoys having reclaim pressure proportional to its overage when
|
||||
above its effective low.
|
||||
|
||||
The original high boundary, the hard limit, is defined as a strict
|
||||
limit that can not budge, even if the OOM killer has to be called.
|
||||
|
|
|
|||
|
|
@ -5302,6 +5302,10 @@
|
|||
the unplug protocol
|
||||
never -- do not unplug even if version check succeeds
|
||||
|
||||
xen_legacy_crash [X86,XEN]
|
||||
Crash from Xen panic notifier, without executing late
|
||||
panic() code such as dumping handler.
|
||||
|
||||
xen_nopvspin [X86,XEN]
|
||||
Disables the ticketlock slowpath using Xen PV
|
||||
optimizations.
|
||||
|
|
|
|||
|
|
@ -154,11 +154,18 @@ return virtual addresses to userspace from a 48-bit range.
|
|||
|
||||
Software can "opt-in" to receiving VAs from a 52-bit space by
|
||||
specifying an mmap hint parameter that is larger than 48-bit.
|
||||
|
||||
For example:
|
||||
maybe_high_address = mmap(~0UL, size, prot, flags,...);
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
maybe_high_address = mmap(~0UL, size, prot, flags,...);
|
||||
|
||||
It is also possible to build a debug kernel that returns addresses
|
||||
from a 52-bit space by enabling the following kernel config options:
|
||||
|
||||
.. code-block:: sh
|
||||
|
||||
CONFIG_EXPERT=y && CONFIG_ARM64_FORCE_52BIT=y
|
||||
|
||||
Note that this option is only intended for debugging applications
|
||||
|
|
|
|||
|
|
@ -107,6 +107,8 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX2 SMMUv3| #126 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Cavium | ThunderX2 Core | #219 | CAVIUM_TX2_ERRATUM_219 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
|||
|
|
@ -38,6 +38,7 @@ Core utilities
|
|||
protection-keys
|
||||
../RCU/index
|
||||
gcc-plugins
|
||||
symbol-namespaces
|
||||
|
||||
|
||||
Interfaces for kernel debugging
|
||||
|
|
|
|||
|
|
@ -98,6 +98,10 @@ limited. The actual limit depends on the hardware and the kernel
|
|||
configuration, but it is a good practice to use `kmalloc` for objects
|
||||
smaller than page size.
|
||||
|
||||
The address of a chunk allocated with `kmalloc` is aligned to at least
|
||||
ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
|
||||
alignment is also guaranteed to be at least the respective size.
|
||||
|
||||
For large allocations you can use :c:func:`vmalloc` and
|
||||
:c:func:`vzalloc`, or directly request pages from the page
|
||||
allocator. The memory allocated by `vmalloc` and related functions is
|
||||
|
|
|
|||
|
|
@ -41,6 +41,9 @@ smaller binary while the latter is 1.1 - 2 times faster.
|
|||
Both KASAN modes work with both SLUB and SLAB memory allocators.
|
||||
For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
|
||||
|
||||
To augment reports with last allocation and freeing stack of the physical page,
|
||||
it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
|
||||
|
||||
To disable instrumentation for specific files or directories, add a line
|
||||
similar to the following to the respective kernel Makefile:
|
||||
|
||||
|
|
|
|||
|
|
@ -89,6 +89,22 @@ To build, save output files in a separate directory with KBUILD_OUTPUT ::
|
|||
|
||||
$ export KBUILD_OUTPUT=/tmp/kselftest; make TARGETS="size timers" kselftest
|
||||
|
||||
Additionally you can use the "SKIP_TARGETS" variable on the make command
|
||||
line to specify one or more targets to exclude from the TARGETS list.
|
||||
|
||||
To run all tests but a single subsystem::
|
||||
|
||||
$ make -C tools/testing/selftests SKIP_TARGETS=ptrace run_tests
|
||||
|
||||
You can specify multiple tests to skip::
|
||||
|
||||
$ make SKIP_TARGETS="size timers" kselftest
|
||||
|
||||
You can also specify a restricted list of tests to run together with a
|
||||
dedicated skiplist::
|
||||
|
||||
$ make TARGETS="bpf breakpoints size timers" SKIP_TARGETS=bpf kselftest
|
||||
|
||||
See the top-level tools/testing/selftests/Makefile for the list of all
|
||||
possible targets.
|
||||
|
||||
|
|
|
|||
|
|
@ -85,4 +85,5 @@ examples:
|
|||
<&pd IMX_SC_R_DSP_RAM>;
|
||||
mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
|
||||
mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
|
||||
memory-region = <&dsp_reserved>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -43,13 +43,9 @@ properties:
|
|||
|
||||
dvdd-supply:
|
||||
description: DVdd voltage supply
|
||||
items:
|
||||
- const: dvdd
|
||||
|
||||
avdd-supply:
|
||||
description: AVdd voltage supply
|
||||
items:
|
||||
- const: avdd
|
||||
|
||||
adi,rejection-60-Hz-enable:
|
||||
description: |
|
||||
|
|
@ -99,6 +95,9 @@ required:
|
|||
examples:
|
||||
- |
|
||||
spi0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@0 {
|
||||
compatible = "adi,ad7192";
|
||||
reg = <0>;
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
* Advanced Interrupt Controller (AIC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-aic"
|
||||
<chip> can be "at91rm9200", "sama5d2", "sama5d3" or "sama5d4"
|
||||
- compatible: Should be:
|
||||
- "atmel,<chip>-aic" where <chip> can be "at91rm9200", "sama5d2",
|
||||
"sama5d3" or "sama5d4"
|
||||
- "microchip,<chip>-aic" where <chip> can be "sam9x60"
|
||||
|
||||
- interrupt-controller: Identifies the node as an interrupt controller.
|
||||
- #interrupt-cells: The number of cells to define the interrupts. It should be 3.
|
||||
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
|
||||
|
|
|
|||
|
|
@ -73,7 +73,6 @@ properties:
|
|||
- rc-genius-tvgo-a11mce
|
||||
- rc-gotview7135
|
||||
- rc-hauppauge
|
||||
- rc-hauppauge
|
||||
- rc-hisi-poplar
|
||||
- rc-hisi-tv-demo
|
||||
- rc-imon-mce
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ properties:
|
|||
- description: exclusive PHY reset line
|
||||
- description: shared reset line between the PCIe PHY and PCIe controller
|
||||
|
||||
resets-names:
|
||||
reset-names:
|
||||
items:
|
||||
- const: phy
|
||||
- const: pcie
|
||||
|
|
|
|||
|
|
@ -26,6 +26,8 @@ Required properties:
|
|||
- "renesas,hscif-r8a77470" for R8A77470 (RZ/G1C) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a774a1" for R8A774A1 (RZ/G2M) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a774a1" for R8A774A1 (RZ/G2M) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a774b1" for R8A774B1 (RZ/G2N) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a774b1" for R8A774B1 (RZ/G2N) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a774c0" for R8A774C0 (RZ/G2E) SCIF compatible UART.
|
||||
- "renesas,hscif-r8a774c0" for R8A774C0 (RZ/G2E) HSCIF compatible UART.
|
||||
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
|
||||
|
|
|
|||
|
|
@ -85,8 +85,8 @@ A child node must exist to represent the core DWC2 IP block. The name of
|
|||
the node is not important. The content of the node is defined in dwc2.txt.
|
||||
|
||||
PHY documentation is provided in the following places:
|
||||
- Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
|
||||
- Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
|
||||
- Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
|
||||
- Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb3-pcie-phy.yaml
|
||||
|
||||
Example device nodes:
|
||||
usb: usb@ffe09000 {
|
||||
|
|
|
|||
|
|
@ -63,7 +63,11 @@ properties:
|
|||
description:
|
||||
Set this flag to force EHCI reset after resume.
|
||||
|
||||
phys: true
|
||||
phys:
|
||||
description: PHY specifier for the USB PHY
|
||||
|
||||
phy-names:
|
||||
const: usb
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
@ -89,6 +93,7 @@ examples:
|
|||
interrupts = <39>;
|
||||
clocks = <&ahb_gates 1>;
|
||||
phys = <&usbphy 1>;
|
||||
phy-names = "usb";
|
||||
};
|
||||
|
||||
...
|
||||
|
|
|
|||
|
|
@ -67,7 +67,11 @@ properties:
|
|||
description:
|
||||
Overrides the detected port count
|
||||
|
||||
phys: true
|
||||
phys:
|
||||
description: PHY specifier for the USB PHY
|
||||
|
||||
phy-names:
|
||||
const: usb
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
|
@ -84,6 +88,7 @@ examples:
|
|||
interrupts = <64>;
|
||||
clocks = <&usb_clk 6>, <&ahb_gates 2>;
|
||||
phys = <&usbphy 1>;
|
||||
phy-names = "usb";
|
||||
};
|
||||
|
||||
...
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Required properties:
|
|||
"dma_ck": dma_bus clock for data transfer by DMA,
|
||||
"xhci_ck": controller clock
|
||||
|
||||
- phys : see usb-hcd.txt in the current directory
|
||||
- phys : see usb-hcd.yaml in the current directory
|
||||
|
||||
Optional properties:
|
||||
- wakeup-source : enable USB remote wakeup;
|
||||
|
|
@ -53,7 +53,7 @@ Optional properties:
|
|||
See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
|
||||
- imod-interval-ns: default interrupt moderation interval is 5000ns
|
||||
|
||||
additionally the properties from usb-hcd.txt (in the current directory) are
|
||||
additionally the properties from usb-hcd.yaml (in the current directory) are
|
||||
supported.
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Required properties:
|
|||
- clock-names : must contain "sys_ck" for clock of controller,
|
||||
the following clocks are optional:
|
||||
"ref_ck", "mcu_ck" and "dma_ck";
|
||||
- phys : see usb-hcd.txt in the current directory
|
||||
- phys : see usb-hcd.yaml in the current directory
|
||||
- dr_mode : should be one of "host", "peripheral" or "otg",
|
||||
refer to usb/generic.txt
|
||||
|
||||
|
|
@ -60,7 +60,7 @@ Optional properties:
|
|||
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
|
||||
bit1 for u3port1, ... etc;
|
||||
|
||||
additionally the properties from usb-hcd.txt (in the current directory) are
|
||||
additionally the properties from usb-hcd.yaml (in the current directory) are
|
||||
supported.
|
||||
|
||||
Sub-nodes:
|
||||
|
|
|
|||
|
|
@ -18,8 +18,13 @@ properties:
|
|||
description:
|
||||
List of all the USB PHYs on this HCD
|
||||
|
||||
phy-names:
|
||||
description:
|
||||
Name specifier for the USB PHY
|
||||
|
||||
examples:
|
||||
- |
|
||||
usb {
|
||||
phys = <&usb2_phy1>, <&usb3_phy1>;
|
||||
phy-names = "usb";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Required properties:
|
|||
- reg : Should contain 1 register ranges(address and length)
|
||||
- interrupts : UHCI controller interrupt
|
||||
|
||||
additionally the properties from usb-hcd.txt (in the current directory) are
|
||||
additionally the properties from usb-hcd.yaml (in the current directory) are
|
||||
supported.
|
||||
|
||||
Example:
|
||||
|
|
|
|||
|
|
@ -41,9 +41,9 @@ Optional properties:
|
|||
- usb3-lpm-capable: determines if platform is USB3 LPM capable
|
||||
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
|
||||
- imod-interval-ns: default interrupt moderation interval is 5000ns
|
||||
- phys : see usb-hcd.txt in the current directory
|
||||
- phys : see usb-hcd.yaml in the current directory
|
||||
|
||||
additionally the properties from usb-hcd.txt (in the current directory) are
|
||||
additionally the properties from usb-hcd.yaml (in the current directory) are
|
||||
supported.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Linux Hardware Monitoring
|
|||
|
||||
hwmon-kernel-api
|
||||
pmbus-core
|
||||
inspur-ipsps1
|
||||
submitting-patches
|
||||
sysfs-interface
|
||||
userspace-tools
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
Kernel driver inspur-ipsps1
|
||||
=======================
|
||||
===========================
|
||||
|
||||
Supported chips:
|
||||
|
||||
|
|
|
|||
|
|
@ -21,10 +21,17 @@ Supported chips:
|
|||
|
||||
* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
|
||||
|
||||
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri", "Carrizo"
|
||||
* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri",
|
||||
"Carrizo", "Stoney Ridge", "Bristol Ridge"
|
||||
|
||||
* AMD Family 16h processors: "Kabini", "Mullins"
|
||||
|
||||
* AMD Family 17h processors: "Zen", "Zen 2"
|
||||
|
||||
* AMD Family 18h processors: "Hygon Dhyana"
|
||||
|
||||
* AMD Family 19h processors: "Zen 3"
|
||||
|
||||
Prefix: 'k10temp'
|
||||
|
||||
Addresses scanned: PCI space
|
||||
|
|
@ -110,3 +117,12 @@ The maximum value for Tctl is available in the file temp1_max.
|
|||
If the BIOS has enabled hardware temperature control, the threshold at
|
||||
which the processor will throttle itself to avoid damage is available in
|
||||
temp1_crit and temp1_crit_hyst.
|
||||
|
||||
On some AMD CPUs, there is a difference between the die temperature (Tdie) and
|
||||
the reported temperature (Tctl). Tdie is the real measured temperature, and
|
||||
Tctl is used for fan control. While Tctl is always available as temp1_input,
|
||||
the driver exports Tdie temperature as temp2_input for those CPUs which support
|
||||
it.
|
||||
|
||||
Models from 17h family report relative temperature, the driver aims to
|
||||
compensate and report the real temperature.
|
||||
|
|
|
|||
|
|
@ -954,11 +954,6 @@ When kbuild executes, the following steps are followed (roughly):
|
|||
|
||||
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
|
||||
KBUILD_ARFLAGS Options for $(AR) when creating archives
|
||||
|
||||
$(KBUILD_ARFLAGS) set by the top level Makefile to "D" (deterministic
|
||||
mode) if this option is supported by $(AR).
|
||||
|
||||
KBUILD_LDS
|
||||
|
||||
The linker script with full path. Assigned by the top-level Makefile.
|
||||
|
|
|
|||
|
|
@ -498,10 +498,11 @@ build.
|
|||
will be written containing all exported symbols that were not
|
||||
defined in the kernel.
|
||||
|
||||
--- 6.3 Symbols From Another External Module
|
||||
6.3 Symbols From Another External Module
|
||||
----------------------------------------
|
||||
|
||||
Sometimes, an external module uses exported symbols from
|
||||
another external module. kbuild needs to have full knowledge of
|
||||
another external module. Kbuild needs to have full knowledge of
|
||||
all symbols to avoid spitting out warnings about undefined
|
||||
symbols. Three solutions exist for this situation.
|
||||
|
||||
|
|
@ -521,7 +522,7 @@ build.
|
|||
The top-level kbuild file would then look like::
|
||||
|
||||
#./Kbuild (or ./Makefile):
|
||||
obj-y := foo/ bar/
|
||||
obj-m := foo/ bar/
|
||||
|
||||
And executing::
|
||||
|
||||
|
|
|
|||
|
|
@ -16,16 +16,21 @@ the kernel may be unreproducible, and how to avoid them.
|
|||
Timestamps
|
||||
----------
|
||||
|
||||
The kernel embeds a timestamp in two places:
|
||||
The kernel embeds timestamps in three places:
|
||||
|
||||
* The version string exposed by ``uname()`` and included in
|
||||
``/proc/version``
|
||||
|
||||
* File timestamps in the embedded initramfs
|
||||
|
||||
By default the timestamp is the current time. This must be overridden
|
||||
using the `KBUILD_BUILD_TIMESTAMP`_ variable. If you are building
|
||||
from a git commit, you could use its commit date.
|
||||
* If enabled via ``CONFIG_IKHEADERS``, file timestamps of kernel
|
||||
headers embedded in the kernel or respective module,
|
||||
exposed via ``/sys/kernel/kheaders.tar.xz``
|
||||
|
||||
By default the timestamp is the current time and in the case of
|
||||
``kheaders`` the various files' modification times. This must
|
||||
be overridden using the `KBUILD_BUILD_TIMESTAMP`_ variable.
|
||||
If you are building from a git commit, you could use its commit date.
|
||||
|
||||
The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,
|
||||
and enables warnings if they are used. If you incorporate external
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ Contents:
|
|||
intel/ice
|
||||
google/gve
|
||||
mellanox/mlx5
|
||||
netronome/nfp
|
||||
pensando/ionic
|
||||
|
||||
.. only:: subproject and html
|
||||
|
|
|
|||
|
|
@ -36,8 +36,10 @@ Support
|
|||
=======
|
||||
For general Linux networking support, please use the netdev mailing
|
||||
list, which is monitored by Pensando personnel::
|
||||
|
||||
netdev@vger.kernel.org
|
||||
|
||||
For more specific support needs, please use the Pensando driver support
|
||||
email::
|
||||
drivers@pensando.io
|
||||
|
||||
drivers@pensando.io
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ supported flags are:
|
|||
* MSG_DONTWAIT, i.e. non-blocking operation.
|
||||
|
||||
recvmsg(2)
|
||||
^^^^^^^^^
|
||||
^^^^^^^^^^
|
||||
|
||||
In most cases recvmsg(2) is needed if you want to extract more information than
|
||||
recvfrom(2) can provide. For example package priority and timestamp. The
|
||||
|
|
|
|||
|
|
@ -92,16 +92,16 @@ under some conditions.
|
|||
Part III: Registering a Network Device to DIM
|
||||
==============================================
|
||||
|
||||
Net DIM API exposes the main function net_dim(struct net_dim *dim,
|
||||
struct net_dim_sample end_sample). This function is the entry point to the Net
|
||||
Net DIM API exposes the main function net_dim(struct dim *dim,
|
||||
struct dim_sample end_sample). This function is the entry point to the Net
|
||||
DIM algorithm and has to be called every time the driver would like to check if
|
||||
it should change interrupt moderation parameters. The driver should provide two
|
||||
data structures: struct net_dim and struct net_dim_sample. Struct net_dim
|
||||
data structures: struct dim and struct dim_sample. Struct dim
|
||||
describes the state of DIM for a specific object (RX queue, TX queue,
|
||||
other queues, etc.). This includes the current selected profile, previous data
|
||||
samples, the callback function provided by the driver and more.
|
||||
Struct net_dim_sample describes a data sample, which will be compared to the
|
||||
data sample stored in struct net_dim in order to decide on the algorithm's next
|
||||
Struct dim_sample describes a data sample, which will be compared to the
|
||||
data sample stored in struct dim in order to decide on the algorithm's next
|
||||
step. The sample should include bytes, packets and interrupts, measured by
|
||||
the driver.
|
||||
|
||||
|
|
@ -110,9 +110,9 @@ main net_dim() function. The recommended method is to call net_dim() on each
|
|||
interrupt. Since Net DIM has a built-in moderation and it might decide to skip
|
||||
iterations under certain conditions, there is no need to moderate the net_dim()
|
||||
calls as well. As mentioned above, the driver needs to provide an object of type
|
||||
struct net_dim to the net_dim() function call. It is advised for each entity
|
||||
using Net DIM to hold a struct net_dim as part of its data structure and use it
|
||||
as the main Net DIM API object. The struct net_dim_sample should hold the latest
|
||||
struct dim to the net_dim() function call. It is advised for each entity
|
||||
using Net DIM to hold a struct dim as part of its data structure and use it
|
||||
as the main Net DIM API object. The struct dim_sample should hold the latest
|
||||
bytes, packets and interrupts count. No need to perform any calculations, just
|
||||
include the raw data.
|
||||
|
||||
|
|
@ -132,19 +132,19 @@ usage is not complete but it should make the outline of the usage clear.
|
|||
|
||||
my_driver.c:
|
||||
|
||||
#include <linux/net_dim.h>
|
||||
#include <linux/dim.h>
|
||||
|
||||
/* Callback for net DIM to schedule on a decision to change moderation */
|
||||
void my_driver_do_dim_work(struct work_struct *work)
|
||||
{
|
||||
/* Get struct net_dim from struct work_struct */
|
||||
struct net_dim *dim = container_of(work, struct net_dim,
|
||||
work);
|
||||
/* Get struct dim from struct work_struct */
|
||||
struct dim *dim = container_of(work, struct dim,
|
||||
work);
|
||||
/* Do interrupt moderation related stuff */
|
||||
...
|
||||
|
||||
/* Signal net DIM work is done and it should move to next iteration */
|
||||
dim->state = NET_DIM_START_MEASURE;
|
||||
dim->state = DIM_START_MEASURE;
|
||||
}
|
||||
|
||||
/* My driver's interrupt handler */
|
||||
|
|
@ -152,13 +152,13 @@ int my_driver_handle_interrupt(struct my_driver_entity *my_entity, ...)
|
|||
{
|
||||
...
|
||||
/* A struct to hold current measured data */
|
||||
struct net_dim_sample dim_sample;
|
||||
struct dim_sample dim_sample;
|
||||
...
|
||||
/* Initiate data sample struct with current data */
|
||||
net_dim_sample(my_entity->events,
|
||||
my_entity->packets,
|
||||
my_entity->bytes,
|
||||
&dim_sample);
|
||||
dim_update_sample(my_entity->events,
|
||||
my_entity->packets,
|
||||
my_entity->bytes,
|
||||
&dim_sample);
|
||||
/* Call net DIM */
|
||||
net_dim(&my_entity->dim, dim_sample);
|
||||
...
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ instead of ``double-indenting`` the ``case`` labels. E.g.:
|
|||
case 'K':
|
||||
case 'k':
|
||||
mem <<= 10;
|
||||
/* fall through */
|
||||
fallthrough;
|
||||
default:
|
||||
break;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -122,14 +122,27 @@ memory adjacent to the stack (when built without `CONFIG_VMAP_STACK=y`)
|
|||
|
||||
Implicit switch case fall-through
|
||||
---------------------------------
|
||||
The C language allows switch cases to "fall through" when
|
||||
a "break" statement is missing at the end of a case. This,
|
||||
however, introduces ambiguity in the code, as it's not always
|
||||
clear if the missing break is intentional or a bug. As there
|
||||
have been a long list of flaws `due to missing "break" statements
|
||||
The C language allows switch cases to "fall-through" when a "break" statement
|
||||
is missing at the end of a case. This, however, introduces ambiguity in the
|
||||
code, as it's not always clear if the missing break is intentional or a bug.
|
||||
|
||||
As there have been a long list of flaws `due to missing "break" statements
|
||||
<https://cwe.mitre.org/data/definitions/484.html>`_, we no longer allow
|
||||
"implicit fall-through". In order to identify an intentional fall-through
|
||||
case, we have adopted the marking used by static analyzers: a comment
|
||||
saying `/* Fall through */`. Once the C++17 `__attribute__((fallthrough))`
|
||||
is more widely handled by C compilers, static analyzers, and IDEs, we can
|
||||
switch to using that instead.
|
||||
"implicit fall-through".
|
||||
|
||||
In order to identify intentional fall-through cases, we have adopted a
|
||||
pseudo-keyword macro 'fallthrough' which expands to gcc's extension
|
||||
__attribute__((__fallthrough__)). `Statement Attributes
|
||||
<https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_
|
||||
|
||||
When the C17/C18 [[fallthrough]] syntax is more commonly supported by
|
||||
C compilers, static analyzers, and IDEs, we can switch to using that syntax
|
||||
for the macro pseudo-keyword.
|
||||
|
||||
All switch/case blocks must end in one of:
|
||||
|
||||
break;
|
||||
fallthrough;
|
||||
continue;
|
||||
goto <label>;
|
||||
return [expression];
|
||||
|
|
|
|||
|
|
@ -1,109 +0,0 @@
|
|||
============
|
||||
Diamonds Rio
|
||||
============
|
||||
|
||||
Copyright (C) 1999, 2000 Bruce Tenison
|
||||
|
||||
Portions Copyright (C) 1999, 2000 David Nelson
|
||||
|
||||
Thanks to David Nelson for guidance and the usage of the scanner.txt
|
||||
and scanner.c files to model our driver and this informative file.
|
||||
|
||||
Mar. 2, 2000
|
||||
|
||||
Changes
|
||||
=======
|
||||
|
||||
- Initial Revision
|
||||
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
This README will address issues regarding how to configure the kernel
|
||||
to access a RIO 500 mp3 player.
|
||||
Before I explain how to use this to access the Rio500 please be warned:
|
||||
|
||||
.. warning::
|
||||
|
||||
Please note that this software is still under development. The authors
|
||||
are in no way responsible for any damage that may occur, no matter how
|
||||
inconsequential.
|
||||
|
||||
It seems that the Rio has a problem when sending .mp3 with low batteries.
|
||||
I suggest when the batteries are low and you want to transfer stuff that you
|
||||
replace it with a fresh one. In my case, what happened is I lost two 16kb
|
||||
blocks (they are no longer usable to store information to it). But I don't
|
||||
know if that's normal or not; it could simply be a problem with the flash
|
||||
memory.
|
||||
|
||||
In an extreme case, I left my Rio playing overnight and the batteries wore
|
||||
down to nothing and appear to have corrupted the flash memory. My RIO
|
||||
needed to be replaced as a result. Diamond tech support is aware of the
|
||||
problem. Do NOT allow your batteries to wear down to nothing before
|
||||
changing them. It appears RIO 500 firmware does not handle low battery
|
||||
power well at all.
|
||||
|
||||
On systems with OHCI controllers, the kernel OHCI code appears to have
|
||||
power on problems with some chipsets. If you are having problems
|
||||
connecting to your RIO 500, try turning it on first and then plugging it
|
||||
into the USB cable.
|
||||
|
||||
Contact Information
|
||||
-------------------
|
||||
|
||||
The main page for the project is hosted at sourceforge.net in the following
|
||||
URL: <http://rio500.sourceforge.net>. You can also go to the project's
|
||||
sourceforge home page at: <http://sourceforge.net/projects/rio500/>.
|
||||
There is also a mailing list: rio500-users@lists.sourceforge.net
|
||||
|
||||
Authors
|
||||
-------
|
||||
|
||||
Most of the code was written by Cesar Miquel <miquel@df.uba.ar>. Keith
|
||||
Clayton <kclayton@jps.net> is incharge of the PPC port and making sure
|
||||
things work there. Bruce Tenison <btenison@dibbs.net> is adding support
|
||||
for .fon files and also does testing. The program will mostly sure be
|
||||
re-written and Pete Ikusz along with the rest will re-design it. I would
|
||||
also like to thank Tri Nguyen <tmn_3022000@hotmail.com> who provided use
|
||||
with some important information regarding the communication with the Rio.
|
||||
|
||||
Additional Information and userspace tools
|
||||
|
||||
http://rio500.sourceforge.net/
|
||||
|
||||
|
||||
Requirements
|
||||
============
|
||||
|
||||
A host with a USB port running a Linux kernel with RIO 500 support enabled.
|
||||
|
||||
The driver is a module called rio500, which should be automatically loaded
|
||||
as you plug in your device. If that fails you can manually load it with
|
||||
|
||||
modprobe rio500
|
||||
|
||||
Udev should automatically create a device node as soon as plug in your device.
|
||||
If that fails, you can manually add a device for the USB rio500::
|
||||
|
||||
mknod /dev/usb/rio500 c 180 64
|
||||
|
||||
In that case, set appropriate permissions for /dev/usb/rio500 (don't forget
|
||||
about group and world permissions). Both read and write permissions are
|
||||
required for proper operation.
|
||||
|
||||
That's it. The Rio500 Utils at: http://rio500.sourceforge.net should
|
||||
be able to access the rio500.
|
||||
|
||||
Limits
|
||||
======
|
||||
|
||||
You can use only a single rio500 device at a time with your computer.
|
||||
|
||||
Bugs
|
||||
====
|
||||
|
||||
If you encounter any problems feel free to drop me an email.
|
||||
|
||||
Bruce Tenison
|
||||
btenison@dibbs.net
|
||||
Loading…
Add table
Add a link
Reference in a new issue