[PATCH v3 1/5] scsi: ufs: enable WriteBooster on some pre-3.1 UFS devices
WriteBooster feature can be supported by some pre-3.1 UFS devices
by upgrading firmware.
To enable WriteBooster feature in such devices, introduce a device
quirk to relax the entrance condition of ufshcd_wb_probe() to allow
host driver to check those devices' WriteBooster capability.
WriteBooster feature can be available if below all conditions are
satisfied,
1. Host enables WriteBooster capability
2. UFS 3.1 device or UFS pre-3.1 device with quirk
UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled
3. Device descriptor has dExtendedUFSFeaturesSupport field
4. WriteBooster support is specified in above field
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs_quirks.h | 7
drivers/scsi/ufs/ufshcd.c | 66 ++-
2 files changed, 48 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/ufs/ufs_quirks.h b/drivers/scsi/ufs/ufs_quirks.h
index df7a1e6805a3..e3175a63c676 100644
--- a/drivers/scsi/ufs/ufs_quirks.h
+++ b/drivers/scsi/ufs/ufs_quirks.h
@@ -101,4 +101,11 @@ struct ufs_dev_fix {
*/
#define UFS_DEVICE_QUIRK_HOST_VS_DEBUGSAVECONFIGTIME (1 << 9)
+/*
+ * Some pre-3.1 UFS devices can support extended features by upgrading
+ * the firmware. Enable this quirk to make UFS core driver probe and enable
+ * supported features on such devices.
+ */
+#define UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES (1 << 10)
+
#endif /* UFS_QUIRKS_H_ */
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 915e963398c4..c6668799d956 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -229,6 +229,8 @@ static struct ufs_dev_fix ufs_fixups[] = {
UFS_DEVICE_QUIRK_HOST_PA_SAVECONFIGTIME),
UFS_FIX(UFS_VENDOR_SKHYNIX, "hB8aL1" /*H28U62301AMR*/,
UFS_DEVICE_QUIRK_HOST_VS_DEBUGSAVECONFIGTIME),
+ UFS_FIX(UFS_VENDOR_SKHYNIX, "H9HQ21AFAMZDAR",
+ UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES),
END_FIX
};
@@ -6800,9 +6802,19 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
static void ufshcd_wb_probe(struct ufs_hba *hba, u8 *desc_buf)
{
+ if (!ufshcd_is_wb_allowed(hba))
+ return;
+
+ if (hba->desc_size.dev_desc <= DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP)
+ goto wb_disabled;
+
hba->dev_info.d_ext_ufs_feature_sup =
get_unaligned_be32(desc_buf +
DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP);
+
+ if (!(hba->dev_info.d_ext_ufs_feature_sup & UFS_DEV_WRITE_BOOSTER_SUP))
+ goto wb_disabled;
+
/*
* WB may be supported but not configured while provisioning.
* The spec says, in dedicated wb buffer mode,
@@ -6818,11 +6830,29 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8
*desc_buf)
hba->dev_info.b_presrv_uspc_en =
desc_buf[DEVICE_DESC_PARAM_WB_PRESRV_USRSPC_EN];
- if (!((hba->dev_info.d_ext_ufs_feature_sup &
-UFS_DEV_WRITE_BOOSTER_SUP) &&
- hba->dev_info.b_wb_buffer_type &&
+ if (!(hba->dev_info.b_wb_buffer_type &&
hba->dev_info.d_wb_alloc_units))
- hba->caps &= ~UFSHCD_CAP_WB_EN;
+ goto wb_disabled;
+
+ return;
+
+wb_disabled:
+ hba->caps &= ~UFSHCD_CAP_WB_EN;
+}
+
+static void ufs_fixup_device_setup(struct ufs_hba *hba)
+{
+ struct ufs_dev_fix *f;
+ struct ufs_dev_info *dev_info = &hba->dev_info;
+
+ for (f = ufs_fixups; f->quirk; f++) {
+ if ((f->wmanufacturerid == dev_info->wmanufacturerid ||
+f->wmanufacturerid == UFS_ANY_VENDOR) &&
+((dev_info->model &&
+ STR_PRFX_EQUAL(f->model, dev_info->model)) ||
+ !strcmp(f->model, UFS_ANY_MODEL)))
+ hba->dev_quirks |= f->quirk;
+ }
}
static int ufs_get_device_desc(struct ufs_hba *hba)
@@ -6862,10 +6892,6 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
model_index = desc_buf[DEVICE_DESC_PARAM_PRDCT_NAME];
- /* Enable WB only for UFS-3.1 */
- if (dev_info->wspecversion >= 0x310)
- ufshcd_wb_probe(hba, desc_buf);
-
err = ufshcd_read_string_desc(hba, model_index,
&dev_info->model, SD_ASCII_STD);
if (err < 0) {
@@ -6874,6 +6900,13 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
goto out;
}
+ ufs_fixup_device_setup(hba);
+
+ /* Enable WB only for UFS-3.1 */
+ if (dev_info->wspecversion >= 0x310 ||
+ (hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES))
+ ufshcd_wb_probe(hba, desc_buf);
+
/*
* ufshcd_read_string_desc returns size of the string
* reset the error value
@@ -6893,21 +6926,6 @@ static void ufs_put_device_desc(struct ufs_hba *hba)
dev_info->model = NULL;
}
-static void ufs_fixup_device_setup(struct ufs_hba *hba
[PATCH v3 0/5] scsi: ufs: support LU Dedicated buffer type for WriteBooster
Hi, This patchset adds LU dedicated buffer mode support for WriteBooster. In the meanwhile, enable WriteBooster capability on MediaTek UFS platforms. v2 -> v3: - Introduce a device quirk to support WriteBooster in pre-3.1 UFS devices (Avri Altman) - Fix WriteBooster related sysfs nodes. Now all WriteBooster related sysfs nodes are specifically mapped to the LUN with WriteBooster enabled in LU Dedicated buffer mode (Avri Altman) v1 -> v2: - Change the definition name of WriteBooster buffer mode to correspond to specification (Bean Huo) - Add patch #5: "scsi: ufs: cleanup WriteBooster feature" Stanley Chu (5): scsi: ufs: enable WriteBooster on some pre-3.1 UFS devices scsi: ufs: add "index" in parameter list of ufshcd_query_flag() scsi: ufs: add LU Dedicated buffer mode support for WriteBooster scsi: ufs-mediatek: enable WriteBooster capability scsi: ufs: cleanup WriteBooster feature drivers/scsi/ufs/ufs-mediatek.c | 3 + drivers/scsi/ufs/ufs-sysfs.c| 14 ++- drivers/scsi/ufs/ufs.h | 7 ++ drivers/scsi/ufs/ufs_quirks.h | 7 ++ drivers/scsi/ufs/ufshcd.c | 156 +--- drivers/scsi/ufs/ufshcd.h | 3 +- 6 files changed, 135 insertions(+), 55 deletions(-) -- 2.18.0
[PATCH 07/37] docs: networking: convert xfrm_device.txt to ReST
- add SPDX header;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../{xfrm_device.txt => xfrm_device.rst} | 33 ---
2 files changed, 23 insertions(+), 11 deletions(-)
rename Documentation/networking/{xfrm_device.txt => xfrm_device.rst} (92%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 75521e6c473b..e31f6cb564b4 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -117,6 +117,7 @@ Contents:
vxlan
x25-iface
x25
+ xfrm_device
.. only:: subproject and html
diff --git a/Documentation/networking/xfrm_device.txt
b/Documentation/networking/xfrm_device.rst
similarity index 92%
rename from Documentation/networking/xfrm_device.txt
rename to Documentation/networking/xfrm_device.rst
index a1c904dc70dc..da1073acda96 100644
--- a/Documentation/networking/xfrm_device.txt
+++ b/Documentation/networking/xfrm_device.rst
@@ -1,7 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
===
XFRM device - offloading the IPsec computations
===
+
Shannon Nelson
@@ -19,7 +21,7 @@ hardware offload.
Userland access to the offload is typically through a system such as
libreswan or KAME/raccoon, but the iproute2 'ip xfrm' command set can
be handy when experimenting. An example command might look something
-like this:
+like this::
ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \
reqid 0x07 replay-window 32 \
@@ -34,15 +36,17 @@ Yes, that's ugly, but that's what shell scripts and/or
libreswan are for.
Callbacks to implement
==
-/* from include/linux/netdevice.h */
-struct xfrmdev_ops {
+::
+
+ /* from include/linux/netdevice.h */
+ struct xfrmdev_ops {
int (*xdo_dev_state_add) (struct xfrm_state *x);
void(*xdo_dev_state_delete) (struct xfrm_state *x);
void(*xdo_dev_state_free) (struct xfrm_state *x);
bool(*xdo_dev_offload_ok) (struct sk_buff *skb,
struct xfrm_state *x);
void(*xdo_dev_state_advance_esn) (struct xfrm_state *x);
-};
+ };
The NIC driver offering ipsec offload will need to implement these
callbacks to make the offload available to the network stack's
@@ -58,6 +62,8 @@ At probe time and before the call to register_netdev(), the
driver should
set up local data structures and XFRM callbacks, and set the feature bits.
The XFRM code's listener will finish the setup on NETDEV_REGISTER.
+::
+
adapter->netdev->xfrmdev_ops = &ixgbe_xfrmdev_ops;
adapter->netdev->features |= NETIF_F_HW_ESP;
adapter->netdev->hw_enc_features |= NETIF_F_HW_ESP;
@@ -65,16 +71,20 @@ The XFRM code's listener will finish the setup on
NETDEV_REGISTER.
When new SAs are set up with a request for "offload" feature, the
driver's xdo_dev_state_add() will be given the new SA to be offloaded
and an indication of whether it is for Rx or Tx. The driver should
+
- verify the algorithm is supported for offloads
- store the SA information (key, salt, target-ip, protocol, etc)
- enable the HW offload of the SA
- return status value:
+
+ === ===
0 success
-EOPNETSUPP offload not supported, try SW IPsec
other fail the request
+ === ===
The driver can also set an offload_handle in the SA, an opaque void pointer
-that can be used to convey context into the fast-path offload requests.
+that can be used to convey context into the fast-path offload requests::
xs->xso.offload_handle = context;
@@ -88,7 +98,7 @@ return true of false to signify its support.
When ready to send, the driver needs to inspect the Tx packet for the
offload information, including the opaque context, and set up the packet
-send accordingly.
+send accordingly::
xs = xfrm_input_state(skb);
context = xs->xso.offload_handle;
@@ -105,18 +115,21 @@ the packet's skb. At this point the data should be
decrypted but the
IPsec headers are still in the packet data; they are removed later up
the stack in xfrm_input().
- find and hold the SA that was used to the Rx skb
+ find and hold the SA that was used to the Rx skb::
+
get spi, protocol, and destination IP from packet headers
xs = find xs from (spi, protocol, dest_IP)
xfrm_state_hold(xs);
- store the state information into the skb
+ store the state information into the skb::
[PATCH 09/37] docs: networking: convert xfrm_sync.txt to ReST
- add SPDX header;
- add a document title;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../{xfrm_sync.txt => xfrm_sync.rst} | 66 ---
2 files changed, 44 insertions(+), 23 deletions(-)
rename Documentation/networking/{xfrm_sync.txt => xfrm_sync.rst} (82%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 3fe70efb632e..ec83bd95e4e9 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -119,6 +119,7 @@ Contents:
x25
xfrm_device
xfrm_proc
+ xfrm_sync
.. only:: subproject and html
diff --git a/Documentation/networking/xfrm_sync.txt
b/Documentation/networking/xfrm_sync.rst
similarity index 82%
rename from Documentation/networking/xfrm_sync.txt
rename to Documentation/networking/xfrm_sync.rst
index 8d88e0f2ec49..6246503ceab2 100644
--- a/Documentation/networking/xfrm_sync.txt
+++ b/Documentation/networking/xfrm_sync.rst
@@ -1,3 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+XFRM
+
The sync patches work is based on initial patches from
Krisztian and others and additional patches
@@ -40,30 +45,32 @@ The netlink message types are:
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
A XFRM_MSG_GETAE does not have TLVs.
+
A XFRM_MSG_NEWAE will have at least two TLVs (as is
discussed further below).
-aevent_id structure looks like:
+aevent_id structure looks like::
struct xfrm_aevent_id {
- struct xfrm_usersa_id sa_id;
- xfrm_address_t saddr;
- __u32 flags;
- __u32 reqid;
+struct xfrm_usersa_id sa_id;
+xfrm_address_t saddr;
+__u32 flags;
+__u32 reqid;
};
The unique SA is identified by the combination of xfrm_usersa_id,
reqid and saddr.
flags are used to indicate different things. The possible
-flags are:
-XFRM_AE_RTHR=1, /* replay threshold*/
-XFRM_AE_RVAL=2, /* replay value */
-XFRM_AE_LVAL=4, /* lifetime value */
-XFRM_AE_ETHR=8, /* expiry timer threshold */
-XFRM_AE_CR=16, /* Event cause is replay update */
-XFRM_AE_CE=32, /* Event cause is timer expiry */
-XFRM_AE_CU=64, /* Event cause is policy update */
+flags are::
+
+ XFRM_AE_RTHR=1, /* replay threshold*/
+ XFRM_AE_RVAL=2, /* replay value */
+ XFRM_AE_LVAL=4, /* lifetime value */
+ XFRM_AE_ETHR=8, /* expiry timer threshold */
+ XFRM_AE_CR=16, /* Event cause is replay update */
+ XFRM_AE_CE=32, /* Event cause is timer expiry */
+ XFRM_AE_CU=64, /* Event cause is policy update */
How these flags are used is dependent on the direction of the
message (kernel<->user) as well the cause (config, query or event).
@@ -80,23 +87,27 @@ to get notified of these events.
-
a) byte value (XFRMA_LTIME_VAL)
+
This TLV carries the running/current counter for byte lifetime since
last event.
b)replay value (XFRMA_REPLAY_VAL)
+
This TLV carries the running/current counter for replay sequence since
last event.
c)replay threshold (XFRMA_REPLAY_THRESH)
+
This TLV carries the threshold being used by the kernel to trigger events
when the replay sequence is exceeded.
d) expiry timer (XFRMA_ETIMER_THRESH)
+
This is a timer value in milliseconds which is used as the nagle
value to rate limit the events.
3) Default configurations for the parameters:
---
+-
By default these events should be turned off unless there is
at least one listener registered to listen to the multicast
@@ -108,6 +119,7 @@ we also provide default threshold values for these
different parameters
in case they are not specified.
the two sysctls/proc entries are:
+
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
units of time of 100ms. The default is 10 (1 second)
@@ -120,37 +132,45 @@ in incremental packet count. The default is two packets.
a) XFRM_MSG_GETAE issued by user-->kernel.
-XFRM_MSG_GETAE does not carry any TLVs.
+ XFRM_MSG_GETAE does not carry any TLVs.
+
The response is a XFRM_MSG_NEWAE which is formatted based on what
XFRM_MSG_GETAE queried for.
+
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
-*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
-*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
+* if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_TH
[PATCH 08/37] docs: networking: convert xfrm_proc.txt to ReST
- add SPDX header;
- adjust title markup;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../{xfrm_proc.txt => xfrm_proc.rst} | 31 +++
2 files changed, 32 insertions(+)
rename Documentation/networking/{xfrm_proc.txt => xfrm_proc.rst} (95%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index e31f6cb564b4..3fe70efb632e 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -118,6 +118,7 @@ Contents:
x25-iface
x25
xfrm_device
+ xfrm_proc
.. only:: subproject and html
diff --git a/Documentation/networking/xfrm_proc.txt
b/Documentation/networking/xfrm_proc.rst
similarity index 95%
rename from Documentation/networking/xfrm_proc.txt
rename to Documentation/networking/xfrm_proc.rst
index 2eae619ab67b..0a771c5a7399 100644
--- a/Documentation/networking/xfrm_proc.txt
+++ b/Documentation/networking/xfrm_proc.rst
@@ -1,5 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
XFRM proc - /proc/net/xfrm_* files
==
+
Masahide NAKAMURA
@@ -14,42 +18,58 @@ as part of the linux private MIB. These counters can be
viewed in
Inbound errors
~~
+
XfrmInError:
All errors which is not matched others
+
XfrmInBufferError:
No buffer is left
+
XfrmInHdrError:
Header error
+
XfrmInNoStates:
No state is found
i.e. Either inbound SPI, address, or IPsec protocol at SA is wrong
+
XfrmInStateProtoError:
Transformation protocol specific error
e.g. SA key is wrong
+
XfrmInStateModeError:
Transformation mode specific error
+
XfrmInStateSeqError:
Sequence error
i.e. Sequence number is out of window
+
XfrmInStateExpired:
State is expired
+
XfrmInStateMismatch:
State has mismatch option
e.g. UDP encapsulation type is mismatch
+
XfrmInStateInvalid:
State is invalid
+
XfrmInTmplMismatch:
No matching template for states
e.g. Inbound SAs are correct but SP rule is wrong
+
XfrmInNoPols:
No policy is found for states
e.g. Inbound SAs are correct but no SP is found
+
XfrmInPolBlock:
Policy discards
+
XfrmInPolError:
Policy error
+
XfrmAcquireError:
State hasn't been fully acquired before use
+
XfrmFwdHdrError:
Forward routing of a packet is not allowed
@@ -57,26 +77,37 @@ Outbound errors
~~~
XfrmOutError:
All errors which is not matched others
+
XfrmOutBundleGenError:
Bundle generation error
+
XfrmOutBundleCheckError:
Bundle check error
+
XfrmOutNoStates:
No state is found
+
XfrmOutStateProtoError:
Transformation protocol specific error
+
XfrmOutStateModeError:
Transformation mode specific error
+
XfrmOutStateSeqError:
Sequence error
i.e. Sequence number overflow
+
XfrmOutStateExpired:
State is expired
+
XfrmOutPolBlock:
Policy discards
+
XfrmOutPolDead:
Policy is dead
+
XfrmOutPolError:
Policy error
+
XfrmOutStateInvalid:
State is invalid, perhaps expired
--
2.25.4
[PATCH 20/37] docs: networking: device drivers: convert dec/dmfe.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- comment out text-only TOC from html/pdf output;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../device_drivers/dec/{dmfe.txt => dmfe.rst} | 35 +++
.../networking/device_drivers/index.rst | 1 +
MAINTAINERS | 2 +-
drivers/net/ethernet/dec/tulip/Kconfig| 2 +-
4 files changed, 23 insertions(+), 17 deletions(-)
rename Documentation/networking/device_drivers/dec/{dmfe.txt => dmfe.rst} (68%)
diff --git a/Documentation/networking/device_drivers/dec/dmfe.txt
b/Documentation/networking/device_drivers/dec/dmfe.rst
similarity index 68%
rename from Documentation/networking/device_drivers/dec/dmfe.txt
rename to Documentation/networking/device_drivers/dec/dmfe.rst
index 25320bf19c86..c4cf809cad84 100644
--- a/Documentation/networking/device_drivers/dec/dmfe.txt
+++ b/Documentation/networking/device_drivers/dec/dmfe.rst
@@ -1,6 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux
+==
+
Note: This driver doesn't have a maintainer.
-Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
@@ -16,29 +21,29 @@ GNU General Public License for more details.
This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801
ethernet cards ( CNET
10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET
cards too ).If you
didn't compile this driver as a module, it will automatically load itself on
boot and print a
-line similar to :
+line similar to::
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
-If you compiled this driver as a module, you have to load it on boot.You can
load it with command :
+If you compiled this driver as a module, you have to load it on boot.You can
load it with command::
insmod dmfe
This way it will autodetect the device mode.This is the suggested way to load
the module.Or you can pass
-a mode= setting to module while loading, like :
+a mode= setting to module while loading, like::
insmod dmfe mode=0 # Force 10M Half Duplex
insmod dmfe mode=1 # Force 100M Half Duplex
insmod dmfe mode=4 # Force 10M Full Duplex
insmod dmfe mode=5 # Force 100M Full Duplex
-Next you should configure your network interface with a command similar to :
+Next you should configure your network interface with a command similar to::
ifconfig eth0 172.22.3.18
- ^^^
+ ^^^
Your IP Address
-Then you may have to modify the default routing table with command :
+Then you may have to modify the default routing table with command::
route add default eth0
@@ -48,10 +53,10 @@ Now your ethernet card should be up and running.
TODO:
-Implement pci_driver::suspend() and pci_driver::resume() power management
methods.
-Check on 64 bit boxes.
-Check and fix on big endian boxes.
-Test and make sure PCI latency is now correct for all cases.
+- Implement pci_driver::suspend() and pci_driver::resume() power management
methods.
+- Check on 64 bit boxes.
+- Check and fix on big endian boxes.
+- Test and make sure PCI latency is now correct for all cases.
Authors:
@@ -60,7 +65,7 @@ Sten Wang: Original Author
Contributors:
-Marcelo Tosatti
-Alan Cox
-Jeff Garzik
-Vojtech Pavlik
+- Marcelo Tosatti
+- Alan Cox
+- Jeff Garzik
+- Vojtech Pavlik
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 4ad13ffb5800..09728e964ce1 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -35,6 +35,7 @@ Contents:
cirrus/cs89x0
davicom/dm9000
dec/de4x5
+ dec/dmfe
.. only:: subproject and html
diff --git a/MAINTAINERS b/MAINTAINERS
index 91098b704635..b92568479a71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4710,7 +4710,7 @@ F:net/ax25/sysctl_net_ax25.c
DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER
L: net...@vger.kernel.org
S: Orphan
-F: Documentation/networking/device_drivers/dec/dmfe.txt
+F: Documentation/networking/device_drivers/dec/dmfe.rst
F: drivers/net/ethernet/dec/tulip/dmfe.c
DC390/AM53C974 SCSI driver
diff --git a/drivers/net/ethernet/dec/tulip/Kconfig
b/drivers/net/ethernet/dec/tulip/Kconfig
index 8c4245d94bb2..177f36f4b89d 100644
--- a/drivers/net/ethernet/dec/tulip/Kconfig
+++ b/drivers/net/ethernet/dec/tulip/Kconfig
@@ -138
[PATCH 30/37] docs: networking: device drivers: convert sb1000.txt to ReST
- add SPDX header; - add a document title; - adjust titles and chapters, adding proper markups; - mark code blocks and literals as such; - mark lists as such; - adjust identation, whitespaces and blank lines where needed; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab --- .../networking/device_drivers/index.rst | 1 + .../networking/device_drivers/sb1000.rst | 222 ++ .../networking/device_drivers/sb1000.txt | 207 drivers/net/Kconfig | 2 +- 4 files changed, 224 insertions(+), 208 deletions(-) create mode 100644 Documentation/networking/device_drivers/sb1000.rst delete mode 100644 Documentation/networking/device_drivers/sb1000.txt diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 66ed884548cc..77270d59943b 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -45,6 +45,7 @@ Contents: neterion/s2io neterion/vxge qualcomm/rmnet + sb1000 .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/sb1000.rst b/Documentation/networking/device_drivers/sb1000.rst new file mode 100644 index ..c8582ca4034d --- /dev/null +++ b/Documentation/networking/device_drivers/sb1000.rst @@ -0,0 +1,222 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +SB100 device driver +=== + +sb1000 is a module network device driver for the General Instrument (also known +as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card +which is used by a number of cable TV companies to provide cable modem access. +It's a one-way downstream-only cable modem, meaning that your upstream net link +is provided by your regular phone modem. + +This driver was written by Franco Venturi . He deserves +a great deal of thanks for this wonderful piece of code! + +Needed tools + + +Support for this device is now a part of the standard Linux kernel. The +driver source code file is drivers/net/sb1000.c. In addition to this +you will need: + +1. The "cmconfig" program. This is a utility which supplements "ifconfig" + to configure the cable modem and network interface (usually called "cm0"); + +2. Several PPP scripts which live in /etc/ppp to make connecting via your + cable modem easy. + + These utilities can be obtained from: + + http://www.jacksonville.net/~fventuri/ + + in Franco's original source code distribution .tar.gz file. Support for + the sb1000 driver can be found at: + + - http://web.archive.org/web/%2E/http://home.adelphia.net/~siglercm/sb1000.html + - http://web.archive.org/web/%2E/http://linuxpower.cx/~cable/ + + along with these utilities. + +3. The standard isapnp tools. These are necessary to configure your SB1000 + card at boot time (or afterwards by hand) since it's a PnP card. + + If you don't have these installed as a standard part of your Linux + distribution, you can find them at: + + http://www.roestock.demon.co.uk/isapnptools/ + + or check your Linux distribution binary CD or their web site. For help with + isapnp, pnpdump, or /etc/isapnp.conf, go to: + + http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html + +Using the driver + + +To make the SB1000 card work, follow these steps: + +1. Run ``make config``, or ``make menuconfig``, or ``make xconfig``, whichever + you prefer, in the top kernel tree directory to set up your kernel + configuration. Make sure to say "Y" to "Prompt for development drivers" + and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard + networking questions to get TCP/IP and PPP networking support. + +2. **BEFORE** you build the kernel, edit drivers/net/sb1000.c. Make sure + to redefine the value of READ_DATA_PORT to match the I/O address used + by isapnp to access your PnP cards. This is the value of READPORT in + /etc/isapnp.conf or given by the output of pnpdump. + +3. Build and install the kernel and modules as usual. + +4. Boot your new kernel following the usual procedures. + +5. Set up to configure the new SB1000 PnP card by capturing the output + of "pnpdump" to a file and editing this file to set the correct I/O ports, + IRQ, and DMA settings for all your PnP cards. Make sure none of the settings + conflict with one another. Then test this configuration by running the + "isapnp" command with your new config file as the input. Check for + errors and fix as necessary. (As an aside, I use I/O ports 0x110 and + 0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.) + Then save the finished config file as /etc/isapnp.conf for proper + configuration on subsequent reboots. + +6. Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of + the others referenced above. As root, unpac
[PATCH 37/37] docs: networking: arcnet-hardware.rst: don't duplicate chapter names
Since changeset 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst"),
auto-references for chapters are generated. This is a nice feature, but
has a drawback: no chapters can have the same sumber.
So, we need to change two chapter titles, to avoid warnings when
building the docs.
Fixes: 58ad30cf91f0 ("docs: fix reference to core-api/namespaces.rst")
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/arcnet-hardware.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/arcnet-hardware.rst
b/Documentation/networking/arcnet-hardware.rst
index b5a1a020c824..ac249ac8fcf2 100644
--- a/Documentation/networking/arcnet-hardware.rst
+++ b/Documentation/networking/arcnet-hardware.rst
@@ -1296,8 +1296,8 @@ DIP Switches:
1 0xC400 (guessed - crashes tested system)
=
-CNet Technology Inc.
-
+CNet Technology Inc. (8-bit cards)
+==
120 Series (8-bit cards)
@@ -1520,8 +1520,8 @@ The jumpers labeled EXT1 and EXT2 are used to determine
the timeout
parameters. These two jumpers are normally left open.
-CNet Technology Inc.
-
+CNet Technology Inc. (16-bit cards)
+===
160 Series (16-bit cards)
-
--
2.25.4
RE: [PATCH 1/4] fs: Implement close-on-fork
Eric,
Thanks for the suggestion. I looked into it and noticed that do_close_on_exec()
appears to have some optimizations as well:
> set = fdt->close_on_exec[i];
> if (!set)
> continue;
If we interleave the close-on-exec and close-on-fork flags then this
optimization will have to be removed. Do you have a sense of which optimization
provides the most benefit?
I noticed a couple of other issues with the original patch that I will need to
investigate or rework:
1) I'm not sure dup_fd() is the best place to check the close-on-fork flag. For
example, the ksys_unshare() > unshare_fd() > dup_fd() execution path seems
suspect. I will either add a parameter to the function indicating if the flag
should be checked or do a separate function, like do_close_on_fork().
2) If the close-on-fork flag is set, then __clear_open_fd() should be called
instead of just __clear_bit(). This will ensure that fdt->full_fds_bits() is
updated.
3) Need to investigate if the close-on-fork (or close-on-exec) flags need to be
cleared when the file is closed as part of the close-on-fork execution path.
Others -- I will respond to feedback outside of implementation details in a
separate message.
Thanks,
Nate
-Original Message-
From: Eric Dumazet
Sent: Monday, April 20, 2020 05:26
To: Karstens, Nate ; Alexander Viro
; Jeff Layton ; J. Bruce Fields
; Arnd Bergmann ; Richard Henderson
; Ivan Kokshaysky ; Matt Turner
; James E.J. Bottomley
; Helge Deller ; David S.
Miller ; Jakub Kicinski ;
linux-fsde...@vger.kernel.org; linux-a...@vger.kernel.org;
linux-al...@vger.kernel.org; linux-par...@vger.kernel.org;
sparcli...@vger.kernel.org; net...@vger.kernel.org; linux-kernel@vger.kernel.org
Cc: Changli Gao
Subject: Re: [PATCH 1/4] fs: Implement close-on-fork
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless
you trust the sender and know the content is safe.
On 4/20/20 12:15 AM, Nate Karstens wrote:
> The close-on-fork flag causes the file descriptor to be closed
> atomically in the child process before the child process returns from
> fork(). Implement this feature and provide a method to get/set the
> close-on-fork flag using fcntl(2).
>
> This functionality was approved by the Austin Common Standards
> Revision Group for inclusion in the next revision of the POSIX
> standard (see issue 1318 in the Austin Group Defect Tracker).
Oh well... yet another feature slowing down a critical path.
>
> Co-developed-by: Changli Gao
> Signed-off-by: Changli Gao
> Signed-off-by: Nate Karstens
> ---
> fs/fcntl.c | 2 ++
> fs/file.c | 50 +-
> include/linux/fdtable.h| 7
> include/linux/file.h | 2 ++
> include/uapi/asm-generic/fcntl.h | 5 +--
> tools/include/uapi/asm-generic/fcntl.h | 5 +--
> 6 files changed, 66 insertions(+), 5 deletions(-)
>
> diff --git a/fs/fcntl.c b/fs/fcntl.c
> index 2e4c0fa2074b..23964abf4a1a 100644
> --- a/fs/fcntl.c
> +++ b/fs/fcntl.c
> @@ -335,10 +335,12 @@ static long do_fcntl(int fd, unsigned int cmd, unsigned
> long arg,
> break;
> case F_GETFD:
> err = get_close_on_exec(fd) ? FD_CLOEXEC : 0;
> + err |= get_close_on_fork(fd) ? FD_CLOFORK : 0;
> break;
> case F_SETFD:
> err = 0;
> set_close_on_exec(fd, arg & FD_CLOEXEC);
> + set_close_on_fork(fd, arg & FD_CLOFORK);
> break;
> case F_GETFL:
> err = filp->f_flags;
> diff --git a/fs/file.c b/fs/file.c
> index c8a4e4c86e55..de7260ba718d 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -57,6 +57,8 @@ static void copy_fd_bitmaps(struct fdtable *nfdt, struct
> fdtable *ofdt,
> memset((char *)nfdt->open_fds + cpy, 0, set);
> memcpy(nfdt->close_on_exec, ofdt->close_on_exec, cpy);
> memset((char *)nfdt->close_on_exec + cpy, 0, set);
> + memcpy(nfdt->close_on_fork, ofdt->close_on_fork, cpy);
> + memset((char *)nfdt->close_on_fork + cpy, 0, set);
>
I suggest we group the two bits of a file (close_on_exec, close_on_fork)
together, so that we do not have to dirty two separate cache lines.
Otherwise we will add yet another cache line miss at every file opening/closing
for processes with big file tables.
Ie having a _single_ bitmap array, even bit for close_on_exec, odd bit for
close_on_fork
static inline void __set_close_on_exec(unsigned int fd, struct fdtable *fdt) {
__set_bit(fd * 2, fdt->close_on_fork_exec); }
static inline void __set_close_on_fork(unsigned int fd, struct fdtable *fdt) {
__set_bit(fd * 2 + 1, fdt->close_on_fork_exec); }
Also the F_GETFD/F_SETFD implementation must use a single function call, to not
acquire the spinlock twice.
[PATCH 25/37] docs: networking: device drivers: convert intel/ipw2200.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- comment out text-only TOC from html/pdf output;
- use copyright symbol;
- use :field: markup;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../intel/{ipw2200.txt => ipw2200.rst}| 410 ++
MAINTAINERS | 2 +-
drivers/net/wireless/intel/ipw2x00/Kconfig| 2 +-
4 files changed, 235 insertions(+), 180 deletions(-)
rename Documentation/networking/device_drivers/intel/{ipw2200.txt =>
ipw2200.rst} (64%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 54ed10f3d1a7..f9ce0089ec7d 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -40,6 +40,7 @@ Contents:
freescale/dpaa
freescale/gianfar
intel/ipw2100
+ intel/ipw2200
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/intel/ipw2200.txt
b/Documentation/networking/device_drivers/intel/ipw2200.rst
similarity index 64%
rename from Documentation/networking/device_drivers/intel/ipw2200.txt
rename to Documentation/networking/device_drivers/intel/ipw2200.rst
index b7658bed4906..0cb42d2fd7e5 100644
--- a/Documentation/networking/device_drivers/intel/ipw2200.txt
+++ b/Documentation/networking/device_drivers/intel/ipw2200.rst
@@ -1,8 +1,15 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
-Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
+==
+Intel(R) PRO/Wireless 2915ABG Driver for Linux
+==
-Intel(R) PRO/Wireless 2200BG Network Connection
-Intel(R) PRO/Wireless 2915ABG Network Connection
+
+Support for:
+
+- Intel(R) PRO/Wireless 2200BG Network Connection
+- Intel(R) PRO/Wireless 2915ABG Network Connection
Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
@@ -10,37 +17,37 @@ both hardware adapters listed above. In this document the
Intel(R)
PRO/Wireless 2915ABG Driver for Linux will be used to reference the
unified driver.
-Copyright (C) 2004-2006, Intel Corporation
+Copyright |copy| 2004-2006, Intel Corporation
README.ipw2200
-Version: 1.1.2
-Date : March 30, 2006
+:Version: 1.1.2
+:Date: March 30, 2006
-Index
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-1. Introduction
-1.1. Overview of features
-1.2. Module parameters
-1.3. Wireless Extension Private Methods
-1.4. Sysfs Helper Files
-1.5. Supported channels
-2. Ad-Hoc Networking
-3. Interacting with Wireless Tools
-3.1. iwconfig mode
-3.2. iwconfig sens
-4. About the Version Numbers
-5. Firmware installation
-6. Support
-7. License
+.. Index
+0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+1. Introduction
+1.1. Overview of features
+1.2. Module parameters
+1.3. Wireless Extension Private Methods
+1.4. Sysfs Helper Files
+1.5. Supported channels
+2. Ad-Hoc Networking
+3. Interacting with Wireless Tools
+3.1. iwconfig mode
+3.2. iwconfig sens
+4. About the Version Numbers
+5. Firmware installation
+6. Support
+7. License
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-Important Notice FOR ALL USERS OR DISTRIBUTORS
+0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+=
+
+Important Notice FOR ALL USERS OR DISTRIBUTORS
Intel wireless LAN adapters are engineered, manufactured, tested, and
quality checked to ensure that they meet all necessary local and
@@ -56,7 +63,7 @@ product is granted. Intel's wireless LAN's EEPROM, firmware,
and
software driver are designed to carefully control parameters that affect
radio operation and to ensure electromagnetic compliance (EMC). These
parameters include, without limitation, RF power, spectrum usage,
-channel scanning, and human exposure.
+channel scanning, and human exposure.
For these reasons Intel cannot permit any manipulation by third parties
of the software provided in binary format with the wireless WLAN
@@ -70,7 +77,7 @@ no liability, under any theory of liability for any issues
associated
with the modified products, including without limitation, claims under
the warranty and/or issues arising from regulatory non-compliance, and
(iii) Intel will not provide or be required to assist in providing
-support to any third parties for such modified products.
+support to any third parties for such modified products.
Note: Many regulatory agencies co
[PATCH 33/37] docs: networking: device drivers: convert ti/cpsw.txt to ReST
- add SPDX header; - adjust titles and chapters, adding proper markups; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines where needed; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab --- .../networking/device_drivers/index.rst | 1 + .../networking/device_drivers/ti/cpsw.rst | 587 ++ .../networking/device_drivers/ti/cpsw.txt | 541 3 files changed, 588 insertions(+), 541 deletions(-) create mode 100644 Documentation/networking/device_drivers/ti/cpsw.rst delete mode 100644 Documentation/networking/device_drivers/ti/cpsw.txt diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index b3c0c473de2b..1d3b664e6921 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -48,6 +48,7 @@ Contents: sb1000 smsc/smc9 ti/cpsw_switchdev + ti/cpsw .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/ti/cpsw.rst b/Documentation/networking/device_drivers/ti/cpsw.rst new file mode 100644 index ..a88946bd188b --- /dev/null +++ b/Documentation/networking/device_drivers/ti/cpsw.rst @@ -0,0 +1,587 @@ +.. SPDX-License-Identifier: GPL-2.0 + +== +Texas Instruments CPSW ethernet driver +== + +Multiqueue & CBS & MQPRIO += + + +The cpsw has 3 CBS shapers for each external ports. This document +describes MQPRIO and CBS Qdisc offload configuration for cpsw driver +based on examples. It potentially can be used in audio video bridging +(AVB) and time sensitive networking (TSN). + +The following examples were tested on AM572x EVM and BBB boards. + +Test setup +== + +Under consideration two examples with AM572x EVM running cpsw driver +in dual_emac mode. + +Several prerequisites: + +- TX queues must be rated starting from txq0 that has highest priority +- Traffic classes are used starting from 0, that has highest priority +- CBS shapers should be used with rated queues +- The bandwidth for CBS shapers has to be set a little bit more then + potential incoming rate, thus, rate of all incoming tx queues has + to be a little less +- Real rates can differ, due to discreetness +- Map skb-priority to txq is not enough, also skb-priority to l2 prio + map has to be created with ip or vconfig tool +- Any l2/socket prio (0 - 7) for classes can be used, but for + simplicity default values are used: 3 and 2 +- only 2 classes tested: A and B, but checked and can work with more, + maximum allowed 4, but only for 3 rate can be set. + +Test setup for examples +=== + +:: + + +---+ + |--+| + | | Workstation0 | + |E | MAC 18:03:73:66:87:42 | ++-+ +--|t || +|| 1 | E | | |h |./tsn_listener -d \ | +| Target board: | 0 | t |--+ |0 | 18:03:73:66:87:42 -i eth0 \| +| AM572x EVM| 0 | h | | | -s 1500| +|| 0 | 0 | |--+| +| Only 2 classes: |Mb +---| +---+ +| class A, class B || +||+---| +---+ +|| 1 | E | |--+| +|| 0 | t | | | Workstation1 | +|| 0 | h |--+ |E | MAC 20:cf:30:85:7d:fd | +||Mb | 1 | +--|t || ++-+ |h |./tsn_listener -d \ | + |0 | 20:cf:30:85:7d:fd -i eth0 \| + | | -s 1500| + |--+| + +---+ + + +Example 1: One port tx AVB configuration scheme for target board + + +(prints and scheme for AM572x evm, applicable for single port boards) + +- tc - traffic class +- txq - transmit queue +- p - priority +- f - fifo (cpsw fifo) +- S - shaper configured + +:: + ++--+ u +| +---+ +---+ +--+ +--+ | s +| | | | | | | | | | e +| | App 1 | | App 2 | | Apps | | Apps | | r +| | Class A | | Class B
[PATCH 34/37] docs: networking: device drivers: convert ti/tlan.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark tables as such;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../device_drivers/ti/{tlan.txt => tlan.rst} | 73 ---
MAINTAINERS | 2 +-
drivers/net/ethernet/ti/Kconfig | 2 +-
drivers/net/ethernet/ti/tlan.c| 2 +-
5 files changed, 52 insertions(+), 28 deletions(-)
rename Documentation/networking/device_drivers/ti/{tlan.txt => tlan.rst} (73%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 1d3b664e6921..adc0bf65fb02 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -49,6 +49,7 @@ Contents:
smsc/smc9
ti/cpsw_switchdev
ti/cpsw
+ ti/tlan
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/ti/tlan.txt
b/Documentation/networking/device_drivers/ti/tlan.rst
similarity index 73%
rename from Documentation/networking/device_drivers/ti/tlan.txt
rename to Documentation/networking/device_drivers/ti/tlan.rst
index 34550dfcef74..4fdc0907f4fc 100644
--- a/Documentation/networking/device_drivers/ti/tlan.txt
+++ b/Documentation/networking/device_drivers/ti/tlan.rst
@@ -1,20 +1,33 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+TLAN driver for Linux
+=
+
+:Version: 1.14a
+
(C) 1997-1998 Caldera, Inc.
+
(C) 1998 James Banks
+
(C) 1999-2001 Torben Mathiasen
For driver information/updates visit http://www.compaq.com
-TLAN driver for Linux, version 1.14a
-README
-I. Supported Devices.
+
+I. Supported Devices
+
Only PCI devices will work with this driver.
Supported:
+
+= = ===
Vendor ID Device ID Name
+= = ===
0e11 ae32Compaq Netelligent 10/100 TX PCI UTP
0e11 ae34Compaq Netelligent 10 T PCI UTP
0e11 ae35Compaq Integrated NetFlex 3/P
@@ -25,13 +38,14 @@ I. Supported Devices.
0e11 b030Compaq Netelligent 10/100 TX UTP
0e11 f130Compaq NetFlex 3/P
0e11 f150Compaq NetFlex 3/P
-108d 0012Olicom OC-2325
+108d 0012Olicom OC-2325
108d 0013Olicom OC-2183
-108d 0014Olicom OC-2326
+108d 0014Olicom OC-2326
+= = ===
Caveats:
-
+
I am not sure if 100BaseTX daughterboards (for those cards which
support such things) will work. I haven't had any solid evidence
either way.
@@ -41,21 +55,25 @@ I. Supported Devices.
The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested,
but I do not expect any problems.
-
-II. Driver Options
+
+II. Driver Options
+==
+
1. You can append debug=x to the end of the insmod line to get
- debug messages, where x is a bit field where the bits mean
+ debug messages, where x is a bit field where the bits mean
the following:
-
+
+ =
0x01 Turn on general debugging messages.
0x02 Turn on receive debugging messages.
0x04 Turn on transmit debugging messages.
0x08 Turn on list debugging messages.
+ =
2. You can append aui=1 to the end of the insmod line to cause
- the adapter to use the AUI interface instead of the 10 Base T
- interface. This is also what to do if you want to use the BNC
+ the adapter to use the AUI interface instead of the 10 Base T
+ interface. This is also what to do if you want to use the BNC
connector on a TLAN based device. (Setting this option on a
device that does not have an AUI/BNC connector will probably
cause it to not function correctly.)
@@ -70,41 +88,45 @@ II. Driver Options
5. You have to use speed=X duplex=Y together now. If you just
do "insmod tlan.o speed=100" the driver will do Auto-Neg.
- To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10
+ To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10
duplex=1".
6. If the driver is built into the kernel, you can use the 3rd
and 4th parameters to set aui and debug respectively. For
-
[PATCH 36/37] net: docs: add page_pool.rst to index.rst
This file is already in ReST format. Add it to the net index.rst, in order to make it part of the documentation body. Signed-off-by: Mauro Carvalho Chehab --- Documentation/networking/index.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index f5733ca4fbcb..0186e276690a 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -25,6 +25,7 @@ Contents: failover net_dim net_failover + page_pool phy sfp-phylink alias -- 2.25.4
[PATCH 35/37] docs: networking: device drivers: convert toshiba/spider_net.txt to ReST
- add SPDX header;
- adjust title markup;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../{spider_net.txt => spider_net.rst}| 58 +--
MAINTAINERS | 2 +-
3 files changed, 30 insertions(+), 31 deletions(-)
rename Documentation/networking/device_drivers/toshiba/{spider_net.txt =>
spider_net.rst} (88%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index adc0bf65fb02..e18dad11bc72 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -50,6 +50,7 @@ Contents:
ti/cpsw_switchdev
ti/cpsw
ti/tlan
+ toshiba/spider_net
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/toshiba/spider_net.txt
b/Documentation/networking/device_drivers/toshiba/spider_net.rst
similarity index 88%
rename from Documentation/networking/device_drivers/toshiba/spider_net.txt
rename to Documentation/networking/device_drivers/toshiba/spider_net.rst
index b0b75f8463b3..fe5b32be15cd 100644
--- a/Documentation/networking/device_drivers/toshiba/spider_net.txt
+++ b/Documentation/networking/device_drivers/toshiba/spider_net.rst
@@ -1,6 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
-The Spidernet Device Driver
-===
+===
+The Spidernet Device Driver
+===
Written by Linas Vepstas
@@ -78,15 +80,15 @@ GDACTDPA, tail and head pointers. It will also summarize
the contents
of the ring, starting at the tail pointer, and listing the status
of the descrs that follow.
-A typical example of the output, for a nearly idle system, might be
+A typical example of the output, for a nearly idle system, might be::
-net eth1: Total number of descrs=256
-net eth1: Chain tail located at descr=20
-net eth1: Chain head is at 20
-net eth1: HW curr desc (GDACTDPA) is at 21
-net eth1: Have 1 descrs with stat=x40800101
-net eth1: HW next desc (GDACNEXTDA) is at 22
-net eth1: Last 255 descrs with stat=xa080
+net eth1: Total number of descrs=256
+net eth1: Chain tail located at descr=20
+net eth1: Chain head is at 20
+net eth1: HW curr desc (GDACTDPA) is at 21
+net eth1: Have 1 descrs with stat=x40800101
+net eth1: HW next desc (GDACNEXTDA) is at 22
+net eth1: Last 255 descrs with stat=xa080
In the above, the hardware has filled in one descr, number 20. Both
head and tail are pointing at 20, because it has not yet been emptied.
@@ -101,11 +103,11 @@ The status x4... corresponds to "full" and status xa...
corresponds
to "empty". The actual value printed is RXCOMST_A.
In the device driver source code, a different set of names are
-used for these same concepts, so that
+used for these same concepts, so that::
-"empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa
-"full" == SPIDER_NET_DESCR_FRAME_END == 0x4
-"not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf
+"empty" == SPIDER_NET_DESCR_CARDOWNED == 0xa
+"full" == SPIDER_NET_DESCR_FRAME_END == 0x4
+"not in use" == SPIDER_NET_DESCR_NOT_IN_USE == 0xf
The RX RAM full bug/feature
@@ -137,19 +139,19 @@ while the hardware is waiting for a different set of
descrs to become
empty.
A call to show_rx_chain() at this point indicates the nature of the
-problem. A typical print when the network is hung shows the following:
+problem. A typical print when the network is hung shows the following::
-net eth1: Spider RX RAM full, incoming packets might be discarded!
-net eth1: Total number of descrs=256
-net eth1: Chain tail located at descr=255
-net eth1: Chain head is at 255
-net eth1: HW curr desc (GDACTDPA) is at 0
-net eth1: Have 1 descrs with stat=xa080
-net eth1: HW next desc (GDACNEXTDA) is at 1
-net eth1: Have 127 descrs with stat=x40800101
-net eth1: Have 1 descrs with stat=x4081
-net eth1: Have 126 descrs with stat=x40800101
-net eth1: Last 1 descrs with stat=xa080
+net eth1: Spider RX RAM full, incoming packets might be discarded!
+net eth1: Total number of descrs=256
+net eth1: Chain tail located at descr=255
+net eth1: Chain head is at 255
+net eth1: HW curr desc (GDACTDPA) is at 0
+net eth1: Have 1 descrs with stat=xa080
+net eth1: HW next desc (GDACNEXTDA) is at 1
+net eth1: Have 127 descrs with stat=x40800101
+net eth1: Have 1 descrs with stat=x4081
+net eth1: Have 126 descrs with stat=x40800101
+net eth1: Last 1 descrs with stat=xa080
Both the tail and head pointers are pointing at descr 255, which is
marked xa... which is "empty". Thus, from the OS point of view, there
@@ -198,7 +200,3 @@ For large packets, this mechanism generates a relatively
small number
[PATCH 24/37] docs: networking: device drivers: convert intel/ipw2100.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- comment out text-only TOC from html/pdf output;
- use copyright symbol;
- use :field: markup;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../intel/{ipw2100.txt => ipw2100.rst}| 242 ++
MAINTAINERS | 2 +-
drivers/net/wireless/intel/ipw2x00/Kconfig| 2 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
5 files changed, 140 insertions(+), 109 deletions(-)
rename Documentation/networking/device_drivers/intel/{ipw2100.txt =>
ipw2100.rst} (70%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index cec3415ee459..54ed10f3d1a7 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -39,6 +39,7 @@ Contents:
dlink/dl2k
freescale/dpaa
freescale/gianfar
+ intel/ipw2100
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/intel/ipw2100.txt
b/Documentation/networking/device_drivers/intel/ipw2100.rst
similarity index 70%
rename from Documentation/networking/device_drivers/intel/ipw2100.txt
rename to Documentation/networking/device_drivers/intel/ipw2100.rst
index 6f85e1d06031..d54ad522f937 100644
--- a/Documentation/networking/device_drivers/intel/ipw2100.txt
+++ b/Documentation/networking/device_drivers/intel/ipw2100.rst
@@ -1,31 +1,37 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
-Intel(R) PRO/Wireless 2100 Driver for Linux in support of:
+===
+Intel(R) PRO/Wireless 2100 Driver for Linux
+===
-Intel(R) PRO/Wireless 2100 Network Connection
+Support for:
-Copyright (C) 2003-2006, Intel Corporation
+- Intel(R) PRO/Wireless 2100 Network Connection
+
+Copyright |copy| 2003-2006, Intel Corporation
README.ipw2100
-Version: git-1.1.5
-Date : January 25, 2006
+:Version: git-1.1.5
+:Date:January 25, 2006
+
+.. Index
+
+0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+1. Introduction
+2. Release git-1.1.5 Current Features
+3. Command Line Parameters
+4. Sysfs Helper Files
+5. Radio Kill Switch
+6. Dynamic Firmware
+7. Power Management
+8. Support
+9. License
+
-Index
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-1. Introduction
-2. Release git-1.1.5 Current Features
-3. Command Line Parameters
-4. Sysfs Helper Files
-5. Radio Kill Switch
-6. Dynamic Firmware
-7. Power Management
-8. Support
-9. License
-
-
-0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
+=
Important Notice FOR ALL USERS OR DISTRIBUTORS
@@ -75,10 +81,10 @@ obtain a tested driver from Intel Customer Support at:
http://www.intel.com/support/wireless/sb/CS-006408.htm
1. Introduction
+===
-This document provides a brief overview of the features supported by the
-IPW2100 driver project. The main project website, where the latest
+This document provides a brief overview of the features supported by the
+IPW2100 driver project. The main project website, where the latest
development version of the driver can be found, is:
http://ipw2100.sourceforge.net
@@ -89,10 +95,11 @@ for the driver project.
2. Release git-1.1.5 Current Supported Features
+===
+
- Managed (BSS) and Ad-Hoc (IBSS)
- WEP (shared key and open)
-- Wireless Tools support
+- Wireless Tools support
- 802.1x (tested with XSupplicant 1.0.1)
Enabled (but not supported) features:
@@ -105,11 +112,11 @@ performed on a given feature.
3. Command Line Parameters
+==
If the driver is built as a module, the following optional parameters are used
by entering them on the command line with the modprobe command using this
-syntax:
+syntax::
modprobe ipw2100 [=<,VAL2>...]
@@ -119,61 +126,76 @@ For example, to disable the radio on driver loading,
enter:
The ipw2100 driver supports the following module parameters:
-Name Value Example:
-debug 0x0-0x debug=1024
-mode 0,1,2 mode=1 /* AdHoc */
-channelint channel=3 /* Only valid in AdHoc or
Monitor */
-associate boolean associate=0 /* Do NOT auto associate */
-disableboolean disable=1 /* Do not power the HW */
+= =
[PATCH 31/37] docs: networking: device drivers: convert smsc/smc9.txt to ReST
- add SPDX header; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines where needed; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab --- .../networking/device_drivers/index.rst | 1 + .../networking/device_drivers/smsc/smc9.rst | 49 +++ .../networking/device_drivers/smsc/smc9.txt | 42 drivers/net/ethernet/smsc/Kconfig | 4 +- 4 files changed, 52 insertions(+), 44 deletions(-) create mode 100644 Documentation/networking/device_drivers/smsc/smc9.rst delete mode 100644 Documentation/networking/device_drivers/smsc/smc9.txt diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 77270d59943b..3479e6f576c3 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -46,6 +46,7 @@ Contents: neterion/vxge qualcomm/rmnet sb1000 + smsc/smc9 .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/smsc/smc9.rst b/Documentation/networking/device_drivers/smsc/smc9.rst new file mode 100644 index ..7cdcb9139942 --- /dev/null +++ b/Documentation/networking/device_drivers/smsc/smc9.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +SMC 9 Driver + + +Revision 0.12 + +3/5/96 + +Copyright 1996 Erik Stahlman + +Released under terms of the GNU General Public License. + +This file contains the instructions and caveats for my SMC9xxx driver. You +should not be using the driver without reading this file. + +Things to note about installation: + + 1. The driver should work on all kernels from 1.2.13 until 1.3.71. + (A kernel patch is supplied for 1.3.71 ) + + 2. If you include this into the kernel, you might need to change some + options, such as for forcing IRQ. + + + 3. To compile as a module, run 'make'. + Make will give you the appropriate options for various kernel support. + + 4. Loading the driver as a module:: + + use: insmod smc9194.o + optional parameters: + io=: your base address + irq=xx : your irq + ifport=x :0 for whatever is default + 1 for twisted pair + 2 for AUI ( or BNC on some cards ) + +How to obtain the latest version? + +FTP: + ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz + ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz + + +Contacting me: +e...@mail.vt.edu + diff --git a/Documentation/networking/device_drivers/smsc/smc9.txt b/Documentation/networking/device_drivers/smsc/smc9.txt deleted file mode 100644 index d1e15074e43d.. --- a/Documentation/networking/device_drivers/smsc/smc9.txt +++ /dev/null @@ -1,42 +0,0 @@ - -SMC 9 Driver -Revision 0.12 -3/5/96 -Copyright 1996 Erik Stahlman -Released under terms of the GNU General Public License. - -This file contains the instructions and caveats for my SMC9xxx driver. You -should not be using the driver without reading this file. - -Things to note about installation: - - 1. The driver should work on all kernels from 1.2.13 until 1.3.71. - (A kernel patch is supplied for 1.3.71 ) - - 2. If you include this into the kernel, you might need to change some - options, such as for forcing IRQ. - - - 3. To compile as a module, run 'make' . - Make will give you the appropriate options for various kernel support. - - 4. Loading the driver as a module : - - use: insmod smc9194.o - optional parameters: - io=: your base address - irq=xx : your irq - ifport=x :0 for whatever is default - 1 for twisted pair - 2 for AUI ( or BNC on some cards ) - -How to obtain the latest version? - -FTP: - ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz - ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz - - -Contacting me: -e...@mail.vt.edu - diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig index 64ca1b36b91e..4fcc5858a750 100644 --- a/drivers/net/ethernet/smsc/Kconfig +++ b/drivers/net/ethernet/smsc/Kconfig @@ -28,7 +28,7 @@ config SMC9194 option if you have a DELL laptop with the docking station, or another SMC9192/9194 based chipset. Say Y if you want it compiled into the kernel, and read the file - . + . To compile this driver as a module, choose M here. The module will be called smc9194. @@ -43,7 +43,7 @@ config SMC91X This is a driver for SMC's 91x series of Ethernet chipsets, including the SMC91C94 and the SMC91C111. Say Y if you want it compiled into the kernel, and read the file - . + .
[PATCH 15/37] docs: networking: device drivers: convert aquantia/atlantic.txt to ReST
- add SPDX header;
- use copyright symbol;
- adjust title and its markup;
- comment out text-only TOC from html/pdf output;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../aquantia/{atlantic.txt => atlantic.rst} | 373 +++---
.../networking/device_drivers/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 227 insertions(+), 149 deletions(-)
rename Documentation/networking/device_drivers/aquantia/{atlantic.txt =>
atlantic.rst} (63%)
diff --git a/Documentation/networking/device_drivers/aquantia/atlantic.txt
b/Documentation/networking/device_drivers/aquantia/atlantic.rst
similarity index 63%
rename from Documentation/networking/device_drivers/aquantia/atlantic.txt
rename to Documentation/networking/device_drivers/aquantia/atlantic.rst
index 2013fcedc2da..595ddef1c8b3 100644
--- a/Documentation/networking/device_drivers/aquantia/atlantic.txt
+++ b/Documentation/networking/device_drivers/aquantia/atlantic.rst
@@ -1,83 +1,96 @@
-Marvell(Aquantia) AQtion Driver for the aQuantia Multi-Gigabit PCI Express
-Family of Ethernet Adapters
-=
-
-Contents
-
-
-- Identifying Your Adapter
-- Configuration
-- Supported ethtool options
-- Command Line Parameters
-- Config file parameters
-- Support
-- License
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+
+===
+Marvell(Aquantia) AQtion Driver
+===
+
+For the aQuantia Multi-Gigabit PCI Express Family of Ethernet Adapters
+
+.. Contents
+
+- Identifying Your Adapter
+- Configuration
+- Supported ethtool options
+- Command Line Parameters
+- Config file parameters
+- Support
+- License
Identifying Your Adapter
-The driver in this release is compatible with AQC-100, AQC-107, AQC-108 based
ethernet adapters.
+The driver in this release is compatible with AQC-100, AQC-107, AQC-108
+based ethernet adapters.
SFP+ Devices (for AQC-100 based adapters)
---
+-
-This release tested with passive Direct Attach Cables (DAC) and SFP+/LC
Optical Transceiver.
+This release tested with passive Direct Attach Cables (DAC) and SFP+/LC
+Optical Transceiver.
Configuration
-=
- Viewing Link Messages
- -
+=
+
+Viewing Link Messages
+-
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages on
- your console, set dmesg to eight by entering the following:
+ your console, set dmesg to eight by entering the following::
dmesg -n 8
- NOTE: This setting is not saved across reboots.
+ .. note::
- Jumbo Frames
-
+ This setting is not saved across reboots.
+
+Jumbo Frames
+
The driver supports Jumbo Frames for all adapters. Jumbo Frames support is
enabled by changing the MTU to a value larger than the default of 1500.
The maximum value for the MTU is 16000. Use the `ip` command to
- increase the MTU size. For example:
+ increase the MTU size. For example::
-ip link set mtu 16000 dev enp1s0
+ ip link set mtu 16000 dev enp1s0
- ethtool
- ---
+ethtool
+---
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. The latest
ethtool version is required for this functionality.
- NAPI
-
+NAPI
+
NAPI (Rx polling mode) is supported in the atlantic driver.
Supported ethtool options
-
- Viewing adapter settings
- -
- ethtool
+=
- Output example:
+Viewing adapter settings
+
+
+ ::
+
+ethtool
+
+ Output example::
Settings for enp1s0:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
-1000baseT/Full
-1baseT/Full
-2500baseT/Full
-5000baseT/Full
+ 1000baseT/Full
+ 1baseT/Full
+ 2500baseT/Full
+ 5000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 100baseT/Full
-1000baseT/Full
-1baseT/Full
-2500baseT/Full
-5000baseT/Full
+ 1000baseT/Full
+ 1baseT/Full
+
[PATCH 32/37] docs: networking: device drivers: convert ti/cpsw_switchdev.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- use :field: markup;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
...{cpsw_switchdev.txt => cpsw_switchdev.rst} | 239 ++
2 files changed, 137 insertions(+), 103 deletions(-)
rename Documentation/networking/device_drivers/ti/{cpsw_switchdev.txt =>
cpsw_switchdev.rst} (51%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 3479e6f576c3..b3c0c473de2b 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -47,6 +47,7 @@ Contents:
qualcomm/rmnet
sb1000
smsc/smc9
+ ti/cpsw_switchdev
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/ti/cpsw_switchdev.txt
b/Documentation/networking/device_drivers/ti/cpsw_switchdev.rst
similarity index 51%
rename from Documentation/networking/device_drivers/ti/cpsw_switchdev.txt
rename to Documentation/networking/device_drivers/ti/cpsw_switchdev.rst
index 12855ab268b8..1241ecac73bd 100644
--- a/Documentation/networking/device_drivers/ti/cpsw_switchdev.txt
+++ b/Documentation/networking/device_drivers/ti/cpsw_switchdev.rst
@@ -1,30 +1,44 @@
-* Texas Instruments CPSW switchdev based ethernet driver 2.0
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+Texas Instruments CPSW switchdev based ethernet driver
+==
+
+:Version: 2.0
+
+Port renaming
+=
-- Port renaming
On older udev versions renaming of ethX to swXpY will not be automatically
supported
-In order to rename via udev:
-ip -d link show dev sw0p1 | grep switchid
-SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
-ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+In order to rename via udev::
+ip -d link show dev sw0p1 | grep switchid
+
+SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}==, \
+ ATTR{phys_port_name}!="", NAME="sw0$attr{phys_port_name}"
+
+
+Dual mac mode
+=
-
-# Dual mac mode
-
- The new (cpsw_new.c) driver is operating in dual-emac mode by default, thus
-working as 2 individual network interfaces. Main differences from legacy CPSW
-driver are:
+ working as 2 individual network interfaces. Main differences from legacy CPSW
+ driver are:
+
- optimized promiscuous mode: The P0_UNI_FLOOD (both ports) is enabled in
-addition to ALLMULTI (current port) instead of ALE_BYPASS.
-So, Ports in promiscuous mode will keep possibility of mcast and vlan
filtering,
-which is provides significant benefits when ports are joined to the same
bridge,
-but without enabling "switch" mode, or to different bridges.
+ addition to ALLMULTI (current port) instead of ALE_BYPASS.
+ So, Ports in promiscuous mode will keep possibility of mcast and vlan
+ filtering, which is provides significant benefits when ports are joined
+ to the same bridge, but without enabling "switch" mode, or to different
+ bridges.
- learning disabled on ports as it make not too much sense for
segregated ports - no forwarding in HW.
- enabled basic support for devlink.
+ ::
+
devlink dev show
platform/48484000.switch
@@ -38,22 +52,25 @@ but without enabling "switch" mode, or to different bridges.
cmode runtime value false
Devlink configuration parameters
-
+
+
See Documentation/networking/devlink/ti-cpsw-switch.rst
-
-# Bridging in dual mac mode
-
+Bridging in dual mac mode
+=
+
The dual_mac mode requires two vids to be reserved for internal purposes,
which, by default, equal CPSW Port numbers. As result, bridge has to be
-configured in vlan unaware mode or default_pvid has to be adjusted.
+configured in vlan unaware mode or default_pvid has to be adjusted::
ip link add name br0 type bridge
ip link set dev br0 type bridge vlan_filtering 0
echo 0 > /sys/class/net/br0/bridge/default_pvid
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
- - or -
+
+or::
+
ip link add name br0 type bridge
ip link set dev br0 type bridge vlan_filtering 0
echo 100 > /sys/class/net/br0/bridge/default_pvid
@@ -61,11 +78,12 @@ configured in vlan unaware mode or default_pvid has to be
adjusted.
ip link set dev sw0p1 master br0
ip link set dev sw0p2 master br0
-
-# Enabling "switch"
-
+Enabling "switch"
+=
+
The Switch mode can be enabled by configuring devlink driver
[PATCH 16/37] docs: networking: device drivers: convert chelsio/cxgb.txt to ReST
- add SPDX header;
- use copyright symbol;
- adjust titles and chapters, adding proper markups;
- comment out text-only TOC from html/pdf output;
- mark code blocks and literals as such;
- add notes markups;
- mark tables as such;
- mark lists as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../chelsio/{cxgb.txt => cxgb.rst}| 183 +++---
.../networking/device_drivers/index.rst | 1 +
drivers/net/ethernet/chelsio/Kconfig | 2 +-
3 files changed, 114 insertions(+), 72 deletions(-)
rename Documentation/networking/device_drivers/chelsio/{cxgb.txt => cxgb.rst}
(81%)
diff --git a/Documentation/networking/device_drivers/chelsio/cxgb.txt
b/Documentation/networking/device_drivers/chelsio/cxgb.rst
similarity index 81%
rename from Documentation/networking/device_drivers/chelsio/cxgb.txt
rename to Documentation/networking/device_drivers/chelsio/cxgb.rst
index 20a887615c4a..435dce5fa2c7 100644
--- a/Documentation/networking/device_drivers/chelsio/cxgb.txt
+++ b/Documentation/networking/device_drivers/chelsio/cxgb.rst
@@ -1,13 +1,18 @@
- Chelsio N210 10Gb Ethernet Network Controller
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
- Driver Release Notes for Linux
+=
+Chelsio N210 10Gb Ethernet Network Controller
+=
- Version 2.1.1
+Driver Release Notes for Linux
- June 20, 2005
+Version 2.1.1
+
+June 20, 2005
+
+.. Contents
-CONTENTS
-
INTRODUCTION
FEATURES
PERFORMANCE
@@ -16,7 +21,7 @@ CONTENTS
SUPPORT
-INTRODUCTION
+Introduction
This document describes the Linux driver for Chelsio 10Gb Ethernet Network
@@ -24,11 +29,11 @@ INTRODUCTION
compatible with the Chelsio N110 model 10Gb NICs.
-FEATURES
+Features
- Adaptive Interrupts (adaptive-rx)
- -
+Adaptive Interrupts (adaptive-rx)
+-
This feature provides an adaptive algorithm that adjusts the interrupt
coalescing parameters, allowing the driver to dynamically adapt the latency
@@ -39,24 +44,24 @@ FEATURES
ethtool manpage for additional usage information.
By default, adaptive-rx is disabled.
- To enable adaptive-rx:
+ To enable adaptive-rx::
ethtool -C adaptive-rx on
- To disable adaptive-rx, use ethtool:
+ To disable adaptive-rx, use ethtool::
ethtool -C adaptive-rx off
After disabling adaptive-rx, the timer latency value will be set to 50us.
- You may set the timer latency after disabling adaptive-rx:
+ You may set the timer latency after disabling adaptive-rx::
ethtool -C rx-usecs
- An example to set the timer latency value to 100us on eth0:
+ An example to set the timer latency value to 100us on eth0::
ethtool -C eth0 rx-usecs 100
- You may also provide a timer latency value while disabling adaptive-rx:
+ You may also provide a timer latency value while disabling adaptive-rx::
ethtool -C adaptive-rx off rx-usecs
@@ -64,13 +69,13 @@ FEATURES
will be set to the specified value until changed by the user or until
adaptive-rx is enabled.
- To view the status of the adaptive-rx and timer latency values:
+ To view the status of the adaptive-rx and timer latency values::
ethtool -c
- TCP Segmentation Offloading (TSO) Support
- -
+TCP Segmentation Offloading (TSO) Support
+-
This feature, also known as "large send", enables a system's protocol stack
to offload portions of outbound TCP processing to a network interface card
@@ -80,20 +85,20 @@ FEATURES
Please see the ethtool manpage for additional usage information.
By default, TSO is enabled.
- To disable TSO:
+ To disable TSO::
ethtool -K tso off
- To enable TSO:
+ To enable TSO::
ethtool -K tso on
- To view the status of TSO:
+ To view the status of TSO::
ethtool -k
-PERFORMANCE
+Performance
===
The following information is provided as an example of how to change system
@@ -111,59 +116,81 @@ PERFORMANCE
your system. You may want to write a script that runs at boot-up which
includes the optimal settings for your system.
- Setting PCI Latency Timer:
- setpci -d 1425:* 0x0c.l=0xF800
+ Setting PCI Latency Timer::
+
+ setpci -d 1425::
+
+* 0x0c.l=0xF800
+
+ Disabling TCP timestamp::
- Disabling TCP timestamp:
sysctl -w net.ipv4.tcp_timestamps=0
- Disabling SACK:
+ Disabling SACK::
+
sysctl -w net.ipv4.tcp_sack=0
- Setting large number of incoming connection requests:
+ Setting large number of incoming connection requests::
+
sysctl -w net.ipv4.tcp_ma
[PATCH 27/37] docs: networking: device drivers: convert neterion/s2io.txt to ReST
- add SPDX header; - add a document title; - comment out text-only TOC from html/pdf output; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines where needed; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab --- .../networking/device_drivers/index.rst | 1 + .../device_drivers/neterion/s2io.rst | 196 ++ .../device_drivers/neterion/s2io.txt | 141 - MAINTAINERS | 2 +- drivers/net/ethernet/neterion/Kconfig | 2 +- 5 files changed, 199 insertions(+), 143 deletions(-) create mode 100644 Documentation/networking/device_drivers/neterion/s2io.rst delete mode 100644 Documentation/networking/device_drivers/neterion/s2io.txt diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 575f0043b03e..da1f8438d4ea 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -42,6 +42,7 @@ Contents: intel/ipw2100 intel/ipw2200 microsoft/netvsc + neterion/s2io .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/neterion/s2io.rst b/Documentation/networking/device_drivers/neterion/s2io.rst new file mode 100644 index ..c5673ec4559b --- /dev/null +++ b/Documentation/networking/device_drivers/neterion/s2io.rst @@ -0,0 +1,196 @@ +.. SPDX-License-Identifier: GPL-2.0 + += +Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver += + +Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver. + +.. Contents + - 1. Introduction + - 2. Identifying the adapter/interface + - 3. Features supported + - 4. Command line parameters + - 5. Performance suggestions + - 6. Available Downloads + + +1. Introduction +=== +This Linux driver supports Neterion's Xframe I PCI-X 1.0 and +Xframe II PCI-X 2.0 adapters. It supports several features +such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on. +See below for complete list of features. + +All features are supported for both IPv4 and IPv6. + +2. Identifying the adapter/interface + + +a. Insert the adapter(s) in your system. +b. Build and load driver:: + + # insmod s2io.ko + +c. View log messages:: + + # dmesg | tail -40 + +You will see messages similar to:: + + eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA + eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA + eth4: Device is on 64 bit 133MHz PCIX(M1) bus + +The above messages identify the adapter type(Xframe I/II), adapter revision, +driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X). +In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed +as well. + +To associate an interface with a physical adapter use "ethtool -p ". +The corresponding adapter's LED will blink multiple times. + +3. Features supported += +a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes, + modifiable using ip command. + +b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit + and receive, TSO. + +c. Multi-buffer receive mode. Scattering of packet across multiple + buffers. Currently driver supports 2-buffer mode which yields + significant performance improvement on certain platforms(SGI Altix, + IBM xSeries). + +d. MSI/MSI-X. Can be enabled on platforms which support this feature + (IA64, Xeon) resulting in noticeable performance improvement(up to 7% + on certain platforms). + +e. Statistics. Comprehensive MAC-level and software statistics displayed + using "ethtool -S" option. + +f. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings, + with multiple steering options. + +4. Command line parameters +== + +a. tx_fifo_num + Number of transmit queues + +Valid range: 1-8 + +Default: 1 + +b. rx_ring_num + Number of receive rings + +Valid range: 1-8 + +Default: 1 + +c. tx_fifo_len + Size of each transmit queue + +Valid range: Total length of all queues should not exceed 8192 + +Default: 4096 + +d. rx_ring_sz + Size of each receive ring(in 4K blocks) + +Valid range: Limited by memory on system + +Default: 30 + +e. intr_type + Specifies interrupt type. Possible values 0(INTA), 2(MSI-X) + +Valid values: 0, 2 + +Default: 2 + +5. Performance suggestions +== + +General: + +a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration) +b. Set TCP windows size to optimal value. + +For instance, for MTU=1500 a value of 210K has been observed to result in +good performance:: + + # sysctl -w net.ipv4.tcp_rmem="21 21 21" +
[PATCH 13/37] docs: networking: device drivers: convert 3com/vortex.txt to ReST
- add SPDX header;
- add a document title;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../3com/{vortex.txt => vortex.rst} | 223 +-
.../networking/device_drivers/index.rst | 1 +
MAINTAINERS | 2 +-
drivers/net/ethernet/3com/3c59x.c | 4 +-
drivers/net/ethernet/3com/Kconfig | 2 +-
5 files changed, 123 insertions(+), 109 deletions(-)
rename Documentation/networking/device_drivers/3com/{vortex.txt => vortex.rst}
(72%)
diff --git a/Documentation/networking/device_drivers/3com/vortex.txt
b/Documentation/networking/device_drivers/3com/vortex.rst
similarity index 72%
rename from Documentation/networking/device_drivers/3com/vortex.txt
rename to Documentation/networking/device_drivers/3com/vortex.rst
index 587f3fcfbcae..800add5be338 100644
--- a/Documentation/networking/device_drivers/3com/vortex.txt
+++ b/Documentation/networking/device_drivers/3com/vortex.rst
@@ -1,5 +1,13 @@
-Documentation/networking/device_drivers/3com/vortex.txt
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+3Com Vortex device driver
+=
+
+Documentation/networking/device_drivers/3com/vortex.rst
+
Andrew Morton
+
30 April 2000
@@ -8,12 +16,12 @@ driver for Linux, 3c59x.c.
The driver was written by Donald Becker
-Don is no longer the prime maintainer of this version of the driver.
+Don is no longer the prime maintainer of this version of the driver.
Please report problems to one or more of:
- Andrew Morton
- Netdev mailing list
- Linux kernel mailing list
+- Andrew Morton
+- Netdev mailing list
+- Linux kernel mailing list
Please note the 'Reporting and Diagnosing Problems' section at the end
of this file.
@@ -24,58 +32,58 @@ Since kernel 2.3.99-pre6, this driver incorporates the
support for the
This driver supports the following hardware:
- 3c590 Vortex 10Mbps
- 3c592 EISA 10Mbps Demon/Vortex
- 3c597 EISA Fast Demon/Vortex
- 3c595 Vortex 100baseTx
- 3c595 Vortex 100baseT4
- 3c595 Vortex 100base-MII
- 3c900 Boomerang 10baseT
- 3c900 Boomerang 10Mbps Combo
- 3c900 Cyclone 10Mbps TPO
- 3c900 Cyclone 10Mbps Combo
- 3c900 Cyclone 10Mbps TPC
- 3c900B-FL Cyclone 10base-FL
- 3c905 Boomerang 100baseTx
- 3c905 Boomerang 100baseT4
- 3c905B Cyclone 100baseTx
- 3c905B Cyclone 10/100/BNC
- 3c905B-FX Cyclone 100baseFx
- 3c905C Tornado
- 3c920B-EMB-WNM (ATI Radeon 9100 IGP)
- 3c980 Cyclone
- 3c980C Python-T
- 3cSOHO100-TX Hurricane
- 3c555 Laptop Hurricane
- 3c556 Laptop Tornado
- 3c556B Laptop Hurricane
- 3c575 [Megahertz] 10/100 LAN CardBus
- 3c575 Boomerang CardBus
- 3CCFE575BT Cyclone CardBus
- 3CCFE575CT Tornado CardBus
- 3CCFE656 Cyclone CardBus
- 3CCFEM656B Cyclone+Winmodem CardBus
- 3CXFEM656C Tornado+Winmodem CardBus
- 3c450 HomePNA Tornado
- 3c920 Tornado
- 3c982 Hydra Dual Port A
- 3c982 Hydra Dual Port B
- 3c905B-T4
- 3c920B-EMB-WNM Tornado
+ - 3c590 Vortex 10Mbps
+ - 3c592 EISA 10Mbps Demon/Vortex
+ - 3c597 EISA Fast Demon/Vortex
+ - 3c595 Vortex 100baseTx
+ - 3c595 Vortex 100baseT4
+ - 3c595 Vortex 100base-MII
+ - 3c900 Boomerang 10baseT
+ - 3c900 Boomerang 10Mbps Combo
+ - 3c900 Cyclone 10Mbps TPO
+ - 3c900 Cyclone 10Mbps Combo
+ - 3c900 Cyclone 10Mbps TPC
+ - 3c900B-FL Cyclone 10base-FL
+ - 3c905 Boomerang 100baseTx
+ - 3c905 Boomerang 100baseT4
+ - 3c905B Cyclone 100baseTx
+ - 3c905B Cyclone 10/100/BNC
+ - 3c905B-FX Cyclone 100baseFx
+ - 3c905C Tornado
+ - 3c920B-EMB-WNM (ATI Radeon 9100 IGP)
+ - 3c980 Cyclone
+ - 3c980C Python-T
+ - 3cSOHO100-TX Hurricane
+ - 3c555 Laptop Hurricane
+ - 3c556 Laptop Tornado
+ - 3c556B Laptop Hurricane
+ - 3c575 [Megahertz] 10/100 LAN CardBus
+ - 3c575 Boomerang CardBus
+ - 3CCFE575BT Cyclone CardBus
+ - 3CCFE575CT Tornado CardBus
+ - 3CCFE656 Cyclone CardBus
+ - 3CCFEM656B Cyclone+Winmodem CardBus
+ - 3CXFEM656C Tornado+Winmodem CardBus
+ - 3c450 HomePNA Tornado
+ - 3c920 Tornado
+ - 3c982 Hydra Dual Port A
+ - 3c982 Hydra Dual Port B
+ - 3c905B-T4
+ - 3c920B-EMB-WNM Tornado
Module parameters
=
There are several parameters which may be provided to the driver when
-its module is loaded. These are usually placed in /etc/modprobe.d/*.conf
-configuration files. Example:
+its module is loaded. These are usually placed in ``/etc/modprobe.d/*.conf``
+configuration files. Example::
-options 3c59x debug=3 rx
Re: [PATCH v2 2/4] PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits" property
[+Robin - to check on dma-ranges intepretation]
I would need RobH and Robin to review this.
Also, An ACK from Tom is required - for the whole series.
On Fri, Apr 17, 2020 at 05:13:20PM +0530, Kishon Vijay Abraham I wrote:
> Cadence PCIe core driver (host mode) uses "cdns,no-bar-match-nbits"
> property to configure the number of bits passed through from PCIe
> address to internal address in Inbound Address Translation register.
>
> However standard PCI dt-binding already defines "dma-ranges" to
> describe the address range accessible by PCIe controller. Parse
> "dma-ranges" property to configure the number of bits passed
> through from PCIe address to internal address in Inbound Address
> Translation register.
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/pci/controller/cadence/pcie-cadence-host.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
> b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 9b1c3966414b..60f912a657b9 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -206,8 +206,10 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
> struct device *dev = rc->pcie.dev;
> struct platform_device *pdev = to_platform_device(dev);
> struct device_node *np = dev->of_node;
> + struct of_pci_range_parser parser;
> struct pci_host_bridge *bridge;
> struct list_head resources;
> + struct of_pci_range range;
> struct cdns_pcie *pcie;
> struct resource *res;
> int ret;
> @@ -222,8 +224,15 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
> rc->max_regions = 32;
> of_property_read_u32(np, "cdns,max-outbound-regions", &rc->max_regions);
>
> - rc->no_bar_nbits = 32;
> - of_property_read_u32(np, "cdns,no-bar-match-nbits", &rc->no_bar_nbits);
> + if (!of_pci_dma_range_parser_init(&parser, np))
> + if (of_pci_range_parser_one(&parser, &range))
> + rc->no_bar_nbits = ilog2(range.size);
> +
> + if (!rc->no_bar_nbits) {
> + rc->no_bar_nbits = 32;
> + of_property_read_u32(np, "cdns,no-bar-match-nbits",
> + &rc->no_bar_nbits);
> + }
>
> rc->vendor_id = 0x;
> of_property_read_u16(np, "vendor-id", &rc->vendor_id);
> --
> 2.17.1
>
[PATCH 12/37] docs: networking: device drivers: convert 3com/3c509.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- add notes markups;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../3com/{3c509.txt => 3c509.rst} | 158 +++---
.../networking/device_drivers/index.rst | 1 +
2 files changed, 98 insertions(+), 61 deletions(-)
rename Documentation/networking/device_drivers/3com/{3c509.txt => 3c509.rst}
(68%)
diff --git a/Documentation/networking/device_drivers/3com/3c509.txt
b/Documentation/networking/device_drivers/3com/3c509.rst
similarity index 68%
rename from Documentation/networking/device_drivers/3com/3c509.txt
rename to Documentation/networking/device_drivers/3com/3c509.rst
index fbf722e15ac3..47f706bacdd9 100644
--- a/Documentation/networking/device_drivers/3com/3c509.txt
+++ b/Documentation/networking/device_drivers/3com/3c509.rst
@@ -1,17 +1,21 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher)
-
+=
This file contains the instructions and caveats for v1.18c and higher versions
of the 3c509 driver. You should not use the driver without reading this file.
release 1.0
+
28 February 2002
+
Current maintainer (corrections to):
David Ruggiero
-
-
-(0) Introduction
+Introduction
+
The following are notes and information on using the 3Com EtherLink III series
ethercards in Linux. These cards are commonly known by the most widely-used
@@ -21,11 +25,11 @@ be (but sometimes are) confused with the similarly-numbered
PCI-bus "3c905"
provided by the module 3c509.c, which has code to support all of the following
models:
- 3c509 (original ISA card)
- 3c509B (later revision of the ISA card; supports full-duplex)
- 3c589 (PCMCIA)
- 3c589B (later revision of the 3c589; supports full-duplex)
- 3c579 (EISA)
+ - 3c509 (original ISA card)
+ - 3c509B (later revision of the ISA card; supports full-duplex)
+ - 3c589 (PCMCIA)
+ - 3c589B (later revision of the 3c589; supports full-duplex)
+ - 3c579 (EISA)
Large portions of this documentation were heavily borrowed from the guide
written the original author of the 3c509 driver, Donald Becker. The master
@@ -33,32 +37,34 @@ copy of that document, which contains notes on older
versions of the driver,
currently resides on Scyld web server: http://www.scyld.com/.
-(1) Special Driver Features
+Special Driver Features
+===
Overriding card settings
The driver allows boot- or load-time overriding of the card's detected IOADDR,
IRQ, and transceiver settings, although this capability shouldn't generally be
needed except to enable full-duplex mode (see below). An example of the syntax
-for LILO parameters for doing this:
+for LILO parameters for doing this::
-ether=10,0x310,3,0x3c509,eth0
+ether=10,0x310,3,0x3c509,eth0
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
with other card types when overriding the I/O address. When the driver is
loaded as a module, only the IRQ may be overridden. For example,
setting two cards to IRQ10 and IRQ11 is done by using the irq module
-option:
+option::
options 3c509 irq=10,11
-(2) Full-duplex mode
+Full-duplex mode
+
The v1.18c driver added support for the 3c509B's full-duplex capabilities.
In order to enable and successfully use full-duplex mode, three conditions
-must be met:
+must be met:
(a) You must have a Etherlink III card model whose hardware supports full-
duplex operations. Currently, the only members of the 3c509 family that are
@@ -78,27 +84,32 @@ duplex-capable Ethernet switch (*not* a hub), or a
full-duplex-capable NIC on
another system that's connected directly to the 3c509B via a crossover cable.
Full-duplex mode can be enabled using 'ethtool'.
-
-/Extremely important caution concerning full-duplex mode/
-Understand that the 3c509B's hardware's full-duplex support is much more
-limited than that provide by more modern network interface cards. Although
-at the physical layer of the network it fully supports full-duplex operation,
-the card was designed before the current Ethernet auto-negotiation (N-way)
-spec was written. This means that the 3c509B family ***cannot and will not
-auto-negotiate a full-duplex connection with its link partner under any
-circumstances, no matter how it is initialized***. If the full-duplex mode
-of the 3c509B is enabled, its link partner wil
[PATCH 28/37] docs: networking: device drivers: convert neterion/vxge.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- comment out text-only TOC from html/pdf output;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../neterion/{vxge.txt => vxge.rst} | 60 +--
MAINTAINERS | 2 +-
drivers/net/ethernet/neterion/Kconfig | 2 +-
4 files changed, 44 insertions(+), 21 deletions(-)
rename Documentation/networking/device_drivers/neterion/{vxge.txt => vxge.rst}
(80%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index da1f8438d4ea..55837244eaad 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -43,6 +43,7 @@ Contents:
intel/ipw2200
microsoft/netvsc
neterion/s2io
+ neterion/vxge
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/neterion/vxge.txt
b/Documentation/networking/device_drivers/neterion/vxge.rst
similarity index 80%
rename from Documentation/networking/device_drivers/neterion/vxge.txt
rename to Documentation/networking/device_drivers/neterion/vxge.rst
index abfec245f97c..589c6b15c63d 100644
--- a/Documentation/networking/device_drivers/neterion/vxge.txt
+++ b/Documentation/networking/device_drivers/neterion/vxge.rst
@@ -1,24 +1,30 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
Neterion's (Formerly S2io) X3100 Series 10GbE PCIe Server Adapter Linux driver
==
-Contents
-
+.. Contents
-1) Introduction
-2) Features supported
-3) Configurable driver parameters
-4) Troubleshooting
+ 1) Introduction
+ 2) Features supported
+ 3) Configurable driver parameters
+ 4) Troubleshooting
+
+1. Introduction
+===
-1) Introduction:
-
This Linux driver supports all Neterion's X3100 series 10 GbE PCIe I/O
Virtualized Server adapters.
+
The X3100 series supports four modes of operation, configurable via
-firmware -
- Single function mode
- Multi function mode
- SRIOV mode
- MRIOV mode
+firmware:
+
+ - Single function mode
+ - Multi function mode
+ - SRIOV mode
+ - MRIOV mode
+
The functions share a 10GbE link and the pci-e bus, but hardly anything else
inside the ASIC. Features like independent hw reset, statistics, bandwidth/
priority allocation and guarantees, GRO, TSO, interrupt moderation etc are
@@ -26,41 +32,49 @@ supported independently on each function.
(See below for a complete list of features supported for both IPv4 and IPv6)
-2) Features supported:
---
+2. Features supported
+=
i) Single function mode (up to 17 queues)
ii) Multi function mode (up to 17 functions)
iii) PCI-SIG's I/O Virtualization
+
- Single Root mode: v1.0 (up to 17 functions)
- Multi-Root mode: v1.0 (up to 17 functions)
iv) Jumbo frames
+
X3100 Series supports MTU up to 9600 bytes, modifiable using
ip command.
v) Offloads supported: (Enabled by default)
- Checksum offload (TCP/UDP/IP) on transmit and receive paths
- TCP Segmentation Offload (TSO) on transmit path
- Generic Receive Offload (GRO) on receive path
+
+ - Checksum offload (TCP/UDP/IP) on transmit and receive paths
+ - TCP Segmentation Offload (TSO) on transmit path
+ - Generic Receive Offload (GRO) on receive path
vi) MSI-X: (Enabled by default)
+
Resulting in noticeable performance improvement (up to 7% on certain
platforms).
vii) NAPI: (Enabled by default)
+
For better Rx interrupt moderation.
viii)RTH (Receive Traffic Hash): (Enabled by default)
+
Receive side steering for better scaling.
ix) Statistics
+
Comprehensive MAC-level and software statistics displayed using
"ethtool -S" option.
x) Multiple hardware queues: (Enabled by default)
+
Up to 17 hardware based transmit and receive data channels, with
multiple steering options (transmit multiqueue enabled by default).
@@ -69,25 +83,33 @@ x) Multiple hardware queues: (Enabled by default)
i) max_config_dev
Specifies maximum device functions to be enabled.
+
Valid range: 1-8
ii) max_config_port
Specifies number of ports to be enabled.
+
Valid range: 1,2
+
Default: 1
-iii)max_config_vpath
+iii) max_config_vpath
Specifies maximum VPATH(s) configured for each device function.
+
Valid range: 1-17
iv) vlan_tag_strip
Enables/disables vlan tag stripping from all received tagged frames that
are n
[PATCH 03/37] docs: networking: convert vrf.txt to ReST
- add SPDX header; - adjust title markup; - Add a subtitle for the first section; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab --- Documentation/networking/index.rst | 1 + Documentation/networking/vrf.rst | 451 + Documentation/networking/vrf.txt | 418 -- MAINTAINERS| 2 +- 4 files changed, 453 insertions(+), 419 deletions(-) create mode 100644 Documentation/networking/vrf.rst delete mode 100644 Documentation/networking/vrf.txt diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index ca0b0dbfd9ad..2227b9f4509d 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -113,6 +113,7 @@ Contents: tproxy tuntap udplite + vrf .. only:: subproject and html diff --git a/Documentation/networking/vrf.rst b/Documentation/networking/vrf.rst new file mode 100644 index ..0dde145043bc --- /dev/null +++ b/Documentation/networking/vrf.rst @@ -0,0 +1,451 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +Virtual Routing and Forwarding (VRF) + + +The VRF Device +== + +The VRF device combined with ip rules provides the ability to create virtual +routing and forwarding domains (aka VRFs, VRF-lite to be specific) in the +Linux network stack. One use case is the multi-tenancy problem where each +tenant has their own unique routing tables and in the very least need +different default gateways. + +Processes can be "VRF aware" by binding a socket to the VRF device. Packets +through the socket then use the routing table associated with the VRF +device. An important feature of the VRF device implementation is that it +impacts only Layer 3 and above so L2 tools (e.g., LLDP) are not affected +(ie., they do not need to be run in each VRF). The design also allows +the use of higher priority ip rules (Policy Based Routing, PBR) to take +precedence over the VRF device rules directing specific traffic as desired. + +In addition, VRF devices allow VRFs to be nested within namespaces. For +example network namespaces provide separation of network interfaces at the +device layer, VLANs on the interfaces within a namespace provide L2 separation +and then VRF devices provide L3 separation. + +Design +-- +A VRF device is created with an associated route table. Network interfaces +are then enslaved to a VRF device:: + ++-+ +| vrf-blue | ===> route table 10 ++-+ + ||| ++--+ +--+ +-+ +| eth1 | | eth2 | ... |bond1| ++--+ +--+ +-+ + | | + +--+ +--+ + | eth8 | | eth9 | + +--+ +--+ + +Packets received on an enslaved device and are switched to the VRF device +in the IPv4 and IPv6 processing stacks giving the impression that packets +flow through the VRF device. Similarly on egress routing rules are used to +send packets to the VRF device driver before getting sent out the actual +interface. This allows tcpdump on a VRF device to capture all packets into +and out of the VRF as a whole\ [1]_. Similarly, netfilter\ [2]_ and tc rules +can be applied using the VRF device to specify rules that apply to the VRF +domain as a whole. + +.. [1] Packets in the forwarded state do not flow through the device, so those + packets are not seen by tcpdump. Will revisit this limitation in a + future release. + +.. [2] Iptables on ingress supports PREROUTING with skb->dev set to the real + ingress device and both INPUT and PREROUTING rules with skb->dev set to + the VRF device. For egress POSTROUTING and OUTPUT rules can be written + using either the VRF device or real egress device. + +Setup +- +1. VRF device is created with an association to a FIB table. + e.g,:: + + ip link add vrf-blue type vrf table 10 + ip link set dev vrf-blue up + +2. An l3mdev FIB rule directs lookups to the table associated with the device. + A single l3mdev rule is sufficient for all VRFs. The VRF device adds the + l3mdev rule for IPv4 and IPv6 when the first device is created with a + default preference of 1000. Users may delete the rule if desired and add + with a different priority or install per-VRF rules. + + Prior to the v4.8 kernel iif and oif rules are needed for each VRF device:: + + ip ru add oif vrf-blue table 10 + ip ru add iif vrf-blue table 10 + +3. Set the default route for the table (and hence default route for the VRF):: + + ip route add table 10 unreachable default metric 427819827
[PATCH 17/37] docs: networking: device drivers: convert cirrus/cs89x0.txt to ReST
- add SPDX header;
- adjust title markup;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../cirrus/{cs89x0.txt => cs89x0.rst} | 557 +-
.../networking/device_drivers/index.rst | 1 +
drivers/net/ethernet/cirrus/Kconfig | 2 +-
3 files changed, 292 insertions(+), 268 deletions(-)
rename Documentation/networking/device_drivers/cirrus/{cs89x0.txt =>
cs89x0.rst} (61%)
diff --git a/Documentation/networking/device_drivers/cirrus/cs89x0.txt
b/Documentation/networking/device_drivers/cirrus/cs89x0.rst
similarity index 61%
rename from Documentation/networking/device_drivers/cirrus/cs89x0.txt
rename to Documentation/networking/device_drivers/cirrus/cs89x0.rst
index 0e190180eec8..e5c283940ac5 100644
--- a/Documentation/networking/device_drivers/cirrus/cs89x0.txt
+++ b/Documentation/networking/device_drivers/cirrus/cs89x0.rst
@@ -1,79 +1,84 @@
+.. SPDX-License-Identifier: GPL-2.0
-NOTE
-
+
+Cirrus Logic LAN CS8900/CS8920 Ethernet Adapters
+
-This document was contributed by Cirrus Logic for kernel 2.2.5. This version
-has been updated for 2.3.48 by Andrew Morton.
+.. note::
+
+ This document was contributed by Cirrus Logic for kernel 2.2.5. This
version
+ has been updated for 2.3.48 by Andrew Morton.
+
+ Still, this is too outdated! A major cleanup is needed here.
Cirrus make a copy of this driver available at their website, as
described below. In general, you should use the driver version which
comes with your Linux distribution.
-
-CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
Linux Network Interface Driver ver. 2.00
-===
-
-
-TABLE OF CONTENTS
-
-1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
-1.1 Product Overview
-1.2 Driver Description
- 1.2.1 Driver Name
- 1.2.2 File in the Driver Package
-1.3 System Requirements
-1.4 Licensing Information
-
-2.0 ADAPTER INSTALLATION and CONFIGURATION
-2.1 CS8900-based Adapter Configuration
-2.2 CS8920-based Adapter Configuration
-
-3.0 LOADING THE DRIVER AS A MODULE
-
-4.0 COMPILING THE DRIVER
-4.1 Compiling the Driver as a Loadable Module
-4.2 Compiling the driver to support memory mode
-4.3 Compiling the driver to support Rx DMA
-
-5.0 TESTING AND TROUBLESHOOTING
-5.1 Known Defects and Limitations
-5.2 Testing the Adapter
-5.2.1 Diagnostic Self-Test
-5.2.2 Diagnostic Network Test
-5.3 Using the Adapter's LEDs
-5.4 Resolving I/O Conflicts
-
-6.0 TECHNICAL SUPPORT
-6.1 Contacting Cirrus Logic's Technical Support
-6.2 Information Required Before Contacting Technical Support
-6.3 Obtaining the Latest Driver Version
-6.4 Current maintainer
-6.5 Kernel boot parameters
-
-
-1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
-===
-
-
-1.1 PRODUCT OVERVIEW
-
-The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow
-IEEE 802.3 standards and support half or full-duplex operation in ISA bus
-computers on 10 Mbps Ethernet networks. The adapters are designed for
operation
-in 16-bit ISA or EISA bus expansion slots and are available in
-10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5
-or fiber networks).
-
-CS8920-based adapters are similar to the CS8900-based adapter with additional
-features for Plug and Play (PnP) support and Wakeup Frame recognition. As
-such, the configuration procedures differ somewhat between the two types of
-adapters. Refer to the "Adapter Configuration" section for details on
+
+
+.. TABLE OF CONTENTS
+
+ 1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
+ 1.1 Product Overview
+ 1.2 Driver Description
+ 1.2.1 Driver Name
+ 1.2.2 File in the Driver Package
+ 1.3 System Requirements
+ 1.4 Licensing Information
+
+ 2.0 ADAPTER INSTALLATION and CONFIGURATION
+ 2.1 CS8900-based Adapter Configuration
+ 2.2 CS8920-based Adapter Configuration
+
+ 3.0 LOADING THE DRIVER AS A MODULE
+
+ 4.0 COMPILING THE DRIVER
+ 4.1 Compiling the Driver as a Loadable Module
+ 4.2 Compiling the driver to support memory mode
+ 4.3 Compiling the driver to support Rx DMA
+
+ 5.0 TESTING AND TROUBLESHOOTING
+ 5.1 Known Defects and Limitations
+ 5.2 Testing the Adapter
+ 5.2.1 Diagnostic Self-Test
+ 5.2.2 Diagnostic Network Test
+ 5.3 Using the Adapter's LEDs
+ 5.4 Resolving I/O Conflicts
+
+ 6.0 TECHNICAL SUPPORT
+ 6.1 Contacting Cirrus Logic's Technical Support
+ 6.2 Information Required Before Contacting Technical Support
+ 6.3 Ob
[PATCH 06/37] docs: networking: convert x25.txt to ReST
Not much to be done here:
- add SPDX header;
- add a document title;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
Documentation/networking/{x25.txt => x25.rst} | 4
net/x25/Kconfig | 2 +-
3 files changed, 6 insertions(+), 1 deletion(-)
rename Documentation/networking/{x25.txt => x25.rst} (96%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 7a4bdbc111b0..75521e6c473b 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -116,6 +116,7 @@ Contents:
vrf
vxlan
x25-iface
+ x25
.. only:: subproject and html
diff --git a/Documentation/networking/x25.txt b/Documentation/networking/x25.rst
similarity index 96%
rename from Documentation/networking/x25.txt
rename to Documentation/networking/x25.rst
index c91c6d7159ff..00e45d384ba0 100644
--- a/Documentation/networking/x25.txt
+++ b/Documentation/networking/x25.rst
@@ -1,4 +1,8 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
Linux X.25 Project
+==
As my third year dissertation at University I have taken it upon myself to
write an X.25 implementation for Linux. My aim is to provide a complete X.25
diff --git a/net/x25/Kconfig b/net/x25/Kconfig
index a328f79885d1..9f0d58b0b90b 100644
--- a/net/x25/Kconfig
+++ b/net/x25/Kconfig
@@ -20,7 +20,7 @@ config X25
You can read more about X.25 at
.
Information about X.25 for Linux is contained in the files
- and
+ and
.
One connects to an X.25 network either with a dedicated network card
--
2.25.4
[PATCH 11/37] docs: networking: convert z8530drv.txt to ReST
- add SPDX header;
- use copyright symbol;
- adjust titles and chapters, adding proper markups;
- mark tables as such;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../networking/{z8530drv.txt => z8530drv.rst} | 609 +-
MAINTAINERS | 2 +-
drivers/net/hamradio/Kconfig | 4 +-
drivers/net/hamradio/scc.c| 2 +-
5 files changed, 324 insertions(+), 294 deletions(-)
rename Documentation/networking/{z8530drv.txt => z8530drv.rst} (57%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 1630801cec19..f5733ca4fbcb 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -121,6 +121,7 @@ Contents:
xfrm_proc
xfrm_sync
xfrm_sysctl
+ z8530drv
.. only:: subproject and html
diff --git a/Documentation/networking/z8530drv.txt
b/Documentation/networking/z8530drv.rst
similarity index 57%
rename from Documentation/networking/z8530drv.txt
rename to Documentation/networking/z8530drv.rst
index 2206abbc3e1b..d2942760f167 100644
--- a/Documentation/networking/z8530drv.txt
+++ b/Documentation/networking/z8530drv.rst
@@ -1,33 +1,30 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
+
+=
+SCC.C - Linux driver for Z8530 based HDLC cards for AX.25
+=
+
+
This is a subset of the documentation. To use this driver you MUST have the
full package from:
Internet:
-=
-1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz
+1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz
-2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz
+2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz
Please note that the information in this document may be hopelessly outdated.
A new version of the documentation, along with links to other important
Linux Kernel AX.25 documentation and programs, is available on
http://yaina.de/jreuter
--
+Copyright |copy| 1993,2000 by Joerg Reuter DL1BKE
+portions Copyright |copy| 1993 Guido ten Dolle PE1NNZ
-SCC.C - Linux driver for Z8530 based HDLC cards for AX.25
-
-
-
-(c) 1993,2000 by Joerg Reuter DL1BKE
-
-portions (c) 1993 Guido ten Dolle PE1NNZ
-
-for the complete copyright notice see >> Copying.Z8530DRV <<
-
-
-
+for the complete copyright notice see >> Copying.Z8530DRV <<
1. Initialization of the driver
===
@@ -50,7 +47,7 @@ AX.25-HOWTO on how to emulate a KISS TNC on network device
drivers.
(If you're going to compile the driver as a part of the kernel image,
skip this chapter and continue with 1.2)
-Before you can use a module, you'll have to load it with
+Before you can use a module, you'll have to load it with::
insmod scc.o
@@ -75,61 +72,73 @@ The file itself consists of two main sections.
==
The hardware setup section defines the following parameters for each
-Z8530:
+Z8530::
-chip1
-data_a 0x300 # data port A
-ctrl_a 0x304 # control port A
-data_b 0x301 # data port B
-ctrl_b 0x305 # control port B
-irq 5 # IRQ No. 5
-pclock 4915200 # clock
-board BAYCOM # hardware type
-esccno # enhanced SCC chip? (8580/85180/85280)
-vector 0 # latch for interrupt vector
-special no # address of special function register
-option 0 # option to set via sfr
+chip1
+data_a 0x300 # data port A
+ctrl_a 0x304 # control port A
+data_b 0x301 # data port B
+ctrl_b 0x305 # control port B
+irq 5 # IRQ No. 5
+pclock 4915200 # clock
+board BAYCOM # hardware type
+esccno # enhanced SCC chip? (8580/85180/85280)
+vector 0 # latch for interrupt vector
+special no # address of special function register
+option 0 # option to set via sfr
-chip - this is just a delimiter to make sccinit a bit simpler to
+chip
+ - this is just a delimiter to make sccinit a bit simpler to
program. A parameter has n
[PATCH 26/37] docs: networking: device drivers: convert microsoft/netvsc.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../microsoft/{netvsc.txt => netvsc.rst} | 57 +++
MAINTAINERS | 2 +-
3 files changed, 36 insertions(+), 24 deletions(-)
rename Documentation/networking/device_drivers/microsoft/{netvsc.txt =>
netvsc.rst} (83%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index f9ce0089ec7d..575f0043b03e 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -41,6 +41,7 @@ Contents:
freescale/gianfar
intel/ipw2100
intel/ipw2200
+ microsoft/netvsc
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/microsoft/netvsc.txt
b/Documentation/networking/device_drivers/microsoft/netvsc.rst
similarity index 83%
rename from Documentation/networking/device_drivers/microsoft/netvsc.txt
rename to Documentation/networking/device_drivers/microsoft/netvsc.rst
index cd63556b27a0..c3f51c672a68 100644
--- a/Documentation/networking/device_drivers/microsoft/netvsc.txt
+++ b/Documentation/networking/device_drivers/microsoft/netvsc.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
Hyper-V network driver
==
@@ -10,15 +13,15 @@ Windows 10.
Features
- Checksum offload
-
+Checksum offload
+
The netvsc driver supports checksum offload as long as the
Hyper-V host version does. Windows Server 2016 and Azure
support checksum offload for TCP and UDP for both IPv4 and
IPv6. Windows Server 2012 only supports checksum offload for TCP.
- Receive Side Scaling
-
+Receive Side Scaling
+
Hyper-V supports receive side scaling. For TCP & UDP, packets can
be distributed among available queues based on IP address and port
number.
@@ -32,30 +35,37 @@ Features
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
- To include UDP port numbers in hashing:
-ethtool -N eth0 rx-flow-hash udp4 sdfn
- To exclude UDP port numbers in hashing:
-ethtool -N eth0 rx-flow-hash udp4 sd
- To show UDP hash level:
-ethtool -n eth0 rx-flow-hash udp4
-
- Generic Receive Offload, aka GRO
-
+
+ To include UDP port numbers in hashing::
+
+ ethtool -N eth0 rx-flow-hash udp4 sdfn
+
+ To exclude UDP port numbers in hashing::
+
+ ethtool -N eth0 rx-flow-hash udp4 sd
+
+ To show UDP hash level::
+
+ ethtool -n eth0 rx-flow-hash udp4
+
+Generic Receive Offload, aka GRO
+
The driver supports GRO and it is enabled by default. GRO coalesces
like packets and significantly reduces CPU usage under heavy Rx
load.
- Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
- -
+Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
+-
The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet
processing overhead by coalescing multiple TCP segments when possible. The
feature is enabled by default on VMs running on Windows Server 2019 and
- later. It may be changed by ethtool command:
+ later. It may be changed by ethtool command::
+
ethtool -K eth0 lro on
ethtool -K eth0 lro off
- SR-IOV support
- --
+SR-IOV support
+--
Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV
is enabled in both the vSwitch and the guest configuration, then the
Virtual Function (VF) device is passed to the guest as a PCI
@@ -70,8 +80,8 @@ Features
flow direction is desired, these should be applied directly to the
VF slave device.
- Receive Buffer
- --
+Receive Buffer
+--
Packets are received into a receive area which is created when device
is probed. The receive area is broken into MTU sized chunks and each may
contain one or more packets. The number of receive sections may be changed
@@ -83,8 +93,8 @@ Features
will use slower method to handle very large packets or if the send buffer
area is exhausted.
- XDP support
- ---
+XDP support
+---
XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early
stage when packets arrive at a NIC card. The goal is to increase performance
for packet processing, reducing the overhead of SKB allocation and other
@@ -99,7 +109,8 @@ Features
overwritten by setting of synthetic NIC.
XDP
[PATCH 29/37] docs: networking: device drivers: convert qualcomm/rmnet.txt to ReST
- add SPDX header;
- add a document title;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../networking/device_drivers/index.rst | 1 +
.../qualcomm/{rmnet.txt => rmnet.rst} | 43 ---
MAINTAINERS | 2 +-
3 files changed, 30 insertions(+), 16 deletions(-)
rename Documentation/networking/device_drivers/qualcomm/{rmnet.txt =>
rmnet.rst} (73%)
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 55837244eaad..66ed884548cc 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -44,6 +44,7 @@ Contents:
microsoft/netvsc
neterion/s2io
neterion/vxge
+ qualcomm/rmnet
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/qualcomm/rmnet.txt
b/Documentation/networking/device_drivers/qualcomm/rmnet.rst
similarity index 73%
rename from Documentation/networking/device_drivers/qualcomm/rmnet.txt
rename to Documentation/networking/device_drivers/qualcomm/rmnet.rst
index 6b341eaf2062..70643b58de05 100644
--- a/Documentation/networking/device_drivers/qualcomm/rmnet.txt
+++ b/Documentation/networking/device_drivers/qualcomm/rmnet.rst
@@ -1,4 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Rmnet Driver
+
+
1. Introduction
+===
rmnet driver is used for supporting the Multiplexing and aggregation
Protocol (MAP). This protocol is used by all recent chipsets using Qualcomm
@@ -18,17 +25,18 @@ sending aggregated bunch of MAP frames. rmnet driver will
de-aggregate
these MAP frames and send them to appropriate PDN's.
2. Packet format
+
a. MAP packet (data / control)
MAP header has the same endianness of the IP packet.
-Packet format -
+Packet format::
-Bit 0 1 2-7 8 - 15 16 - 31
-Function Command / Data Reserved Pad Multiplexer IDPayload length
-Bit32 - x
-Function Raw Bytes
+ Bit 0 1 2-7 8 - 15 16 - 31
+ Function Command / Data Reserved Pad Multiplexer IDPayload
length
+ Bit32 - x
+ Function Raw Bytes
Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command
or data packet. Control packet is used for transport level flow control. Data
@@ -44,24 +52,27 @@ Multiplexer ID is to indicate the PDN on which data has to
be sent.
Payload length includes the padding length but does not include MAP header
length.
-b. MAP packet (command specific)
+b. MAP packet (command specific)::
-Bit 0 1 2-7 8 - 15 16 - 31
-Function Command Reserved Pad Multiplexer IDPayload length
-Bit 32 - 3940 - 4546 - 47 48 - 63
-Function Command nameReserved Command Type Reserved
-Bit 64 - 95
-Function Transaction ID
-Bit 96 - 127
-Function Command data
+Bit 0 1 2-7 8 - 15 16 - 31
+Function Command Reserved Pad Multiplexer IDPayload
length
+Bit 32 - 3940 - 4546 - 47 48 - 63
+Function Command nameReserved Command Type Reserved
+Bit 64 - 95
+Function Transaction ID
+Bit 96 - 127
+Function Command data
Command 1 indicates disabling flow while 2 is enabling flow
-Command types -
+Command types
+
+= ==
0 for MAP command request
1 is to acknowledge the receipt of a command
2 is for unsupported commands
3 is for error during processing of commands
+= ==
c. Aggregation
@@ -71,9 +82,11 @@ packets and either ACK the MAP command or deliver the IP
packet to the
network stack as needed
MAP header|IP Packet|Optional padding|MAP header|IP Packet|Optional padding
+
MAP header|IP Packet|Optional padding|MAP header|Command Packet|Optional pad...
3. Userspace configuration
+==
rmnet userspace configuration is done through netlink library librmnetctl
and command line utility rmnetcli. Utility is hosted in codeaurora forum git.
diff --git a/MAINTAINERS b/MAINTAINERS
index 91da0be7f69e..0054a0a87d5f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14066,7 +14066,7 @@ M: Subash Abhinov Kasiviswanathan
M: Sean Tranchetti
L: net...@vger.kernel.org
S: Maintained
-F: Documentation/networking/device_drivers/qualcomm/rmnet.txt
+F: Documentation/networking/device_drivers/qualcomm/rmnet.rst
F: drivers/net/ethernet/qualcomm/rmnet/
F: include/linux/if_rmnet.h
--
2.25.4
[PATCH 22/37] docs: networking: device drivers: convert freescale/dpaa.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- use :field: markup;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../freescale/{dpaa.txt => dpaa.rst} | 139 ++
.../networking/device_drivers/index.rst | 1 +
2 files changed, 75 insertions(+), 65 deletions(-)
rename Documentation/networking/device_drivers/freescale/{dpaa.txt =>
dpaa.rst} (79%)
diff --git a/Documentation/networking/device_drivers/freescale/dpaa.txt
b/Documentation/networking/device_drivers/freescale/dpaa.rst
similarity index 79%
rename from Documentation/networking/device_drivers/freescale/dpaa.txt
rename to Documentation/networking/device_drivers/freescale/dpaa.rst
index b06601ff9200..241c6c6f6e68 100644
--- a/Documentation/networking/device_drivers/freescale/dpaa.txt
+++ b/Documentation/networking/device_drivers/freescale/dpaa.rst
@@ -1,12 +1,14 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
The QorIQ DPAA Ethernet Driver
==
Authors:
-Madalin Bucur
-Camelia Groza
+- Madalin Bucur
+- Camelia Groza
-Contents
-
+.. Contents
- DPAA Ethernet Overview
- DPAA Ethernet Supported SoCs
@@ -34,7 +36,7 @@ following drivers in the Linux kernel:
- Queue Manager (QMan), Buffer Manager (BMan)
drivers/soc/fsl/qbman
-A simplified view of the dpaa_eth interfaces mapped to FMan MACs:
+A simplified view of the dpaa_eth interfaces mapped to FMan MACs::
dpaa_eth /eth0\ ... /ethN\
driver| | | |
@@ -42,89 +44,93 @@ A simplified view of the dpaa_eth interfaces mapped to FMan
MACs:
-Ports / Tx Rx \.../ Tx Rx \
FMan| | | |
-MACs | MAC0 | | MACN |
- / dtsec0 \ ... / dtsecN \ (or tgec)
-/ \ / \(or memac)
+/ dtsec0 \ ... / dtsecN \ (or tgec)
+ / \ / \(or memac)
- -- --- -- -
FMan, FMan Port, FMan SP, FMan MURAM drivers
-
FMan HW blocks: MURAM, MACs, Ports, SP
-
-The dpaa_eth relation to the QMan, BMan and FMan:
-
+The dpaa_eth relation to the QMan, BMan and FMan::
+
+
dpaa_eth /eth0\
driver/ \
- -^- -^- -^- ----
QMan driver / \ / \ / \ \ / | BMan|
- |Rx | |Rx | |Tx | |Tx | | driver |
+|Rx | |Rx | |Tx | |Tx | | driver |
- |Dfl| |Err| |Cnf| |FQs| | |
QMan HW|FQ | |FQ | |FQs| | | | |
- / \ / \ / \ \ / | |
+/ \ / \ / \ \ / | |
- --- --- --- -v--
-|FMan QMI | |
-| FMan HW FMan BMI | BMan HW |
- ---
+ |FMan QMI | |
+ | FMan HW FMan BMI | BMan HW |
+ ---
where the acronyms used above (and in the code) are:
-DPAA = Data Path Acceleration Architecture
-FMan = DPAA Frame Manager
-QMan = DPAA Queue Manager
-BMan = DPAA Buffers Manager
-QMI = QMan interface in FMan
-BMI = BMan interface in FMan
-FMan SP = FMan Storage Profiles
-MURAM = Multi-user RAM in FMan
-FQ = QMan Frame Queue
-Rx Dfl FQ = default reception FQ
-Rx Err FQ = Rx error frames FQ
-Tx Cnf FQ = Tx confirmation FQs
-Tx FQs = transmission frame queues
-dtsec = datapath three speed Ethernet controller (10/100/1000 Mbps)
-tgec = ten gigabit Ethernet controller (10 Gbps)
-memac = multirate Ethernet MAC (10/100/1000/1)
+
+=== ===
+DPAA Data Path Acceleration Architecture
+FMan DPAA Frame Manager
+QMan DPAA Queue Manager
+BMan DPAA Buffers Manager
+QMIQMan interface in FMan
+BMIBMan interface in FMan
+FMan SPFMan Storage Profiles
+MURAM Multi-user RAM in FMan
+FQ QMan Frame Queue
+Rx Dfl FQ default reception FQ
+Rx Err FQ Rx error frames FQ
+Tx Cnf FQ Tx confirmation FQs
+Tx FQs transmission frame queues
+dtsec datapath three speed Ethernet controller (10/100/1000 Mbps)
+tgec ten gigabit Ethernet controller (10 Gbps)
+memac multirate Ethernet MAC (10/100/1000/1)
+=== ===
DPAA Ethernet Supported SoCs
[PATCH 19/37] docs: networking: device drivers: convert dec/de4x5.txt to ReST
- add SPDX header;
- add a document title;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../dec/{de4x5.txt => de4x5.rst} | 105 ++
.../networking/device_drivers/index.rst | 1 +
drivers/net/ethernet/dec/tulip/Kconfig| 2 +-
3 files changed, 60 insertions(+), 48 deletions(-)
rename Documentation/networking/device_drivers/dec/{de4x5.txt => de4x5.rst}
(78%)
diff --git a/Documentation/networking/device_drivers/dec/de4x5.txt
b/Documentation/networking/device_drivers/dec/de4x5.rst
similarity index 78%
rename from Documentation/networking/device_drivers/dec/de4x5.txt
rename to Documentation/networking/device_drivers/dec/de4x5.rst
index 452aac58341d..e03e9c631879 100644
--- a/Documentation/networking/device_drivers/dec/de4x5.txt
+++ b/Documentation/networking/device_drivers/dec/de4x5.rst
@@ -1,48 +1,54 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+DEC EtherWORKS Ethernet De4x5 cards
+===
+
Originally, this driver waswritten for the Digital Equipment
Corporation series of EtherWORKS Ethernet cards:
-DE425 TP/COAX EISA
- DE434 TP PCI
- DE435 TP/COAX/AUI PCI
- DE450 TP/COAX/AUI PCI
- DE500 10/100 PCI Fasternet
+- DE425 TP/COAX EISA
+- DE434 TP PCI
+- DE435 TP/COAX/AUI PCI
+- DE450 TP/COAX/AUI PCI
+- DE500 10/100 PCI Fasternet
but it will now attempt to support all cards which conform to the
Digital Semiconductor SROM Specification.The driver currently
recognises the following chips:
-DC21040 (no SROM)
- DC21041[A]
- DC21140[A]
- DC21142
- DC21143
+- DC21040 (no SROM)
+- DC21041[A]
+- DC21140[A]
+- DC21142
+- DC21143
So far the driver is known to work with the following cards:
-KINGSTON
- Linksys
- ZNYX342
- SMC8432
- SMC9332 (w/new SROM)
- ZNYX31[45]
- ZNYX346 10/100 4 port (can act as a 10/100 bridge!)
+- KINGSTON
+- Linksys
+- ZNYX342
+- SMC8432
+- SMC9332 (w/new SROM)
+- ZNYX31[45]
+- ZNYX346 10/100 4 port (can act as a 10/100 bridge!)
The driver has been tested on a relatively busy network using the DE425,
DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
-16M of data to a DECstation 5000/200 as follows:
+16M of data to a DECstation 5000/200 as follows::
-TCP UDP
- TX RX TX RX
-DE425 1030k 997k 1170k 1128k
-DE434 1063k 995k 1170k 1125k
-DE435 1063k 995k 1170k 1125k
-DE500 1063k 998k 1170k 1125k in 10Mb/s mode
+ TCP UDP
+ TX RX TX RX
+ DE425 1030k 997k 1170k 1128k
+ DE434 1063k 995k 1170k 1125k
+ DE435 1063k 995k 1170k 1125k
+ DE500 1063k 998k 1170k 1125k in 10Mb/s mode
All values are typical (in kBytes/sec) from a sample of 4 for each
measurement. Their error is +/-20k on a quiet (private) network and also
depend on what load the CPU has.
-=
+
The ability to load this driver as a loadable module has been included
and used extensively during the driver development (to save those long
@@ -55,31 +61,33 @@
0) have a copy of the loadable modules code installed on your system.
1) copy de4x5.c from the /linux/drivers/net directory to your favourite
-temporary directory.
+ temporary directory.
2) for fixed autoprobes (not recommended), edit the source code near
-line 5594 to reflect the I/O address you're using, or assign these when
-loading by:
+ line 5594 to reflect the I/O address you're using, or assign these when
+ loading by::
- insmod de4x5 io=0xghh where g = bus number
- hh = device number
+ insmod de4x5 io=0xghh where g = bus number
+ hh = device number
- NB: autoprobing for modules is now supported by default. You may just
- use:
+ .. note::
- insmod de4x5
+ autoprobing for modules is now supported by default. You may just
+ use::
- to load all available boards. For a specific board, still use
+ insmod de4x5
+
+ to load all available boards. For a specific board, still use
the 'io=?' above.
3) compil
[PATCH 01/37] docs: networking: convert tuntap.txt to ReST
- add SPDX header;
- use copyright symbol;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../networking/{tuntap.txt => tuntap.rst} | 200 ++
MAINTAINERS | 2 +-
drivers/net/Kconfig | 2 +-
4 files changed, 119 insertions(+), 86 deletions(-)
rename Documentation/networking/{tuntap.txt => tuntap.rst} (58%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index b423b2db5f96..e7a683f0528d 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -111,6 +111,7 @@ Contents:
team
timestamping
tproxy
+ tuntap
.. only:: subproject and html
diff --git a/Documentation/networking/tuntap.txt
b/Documentation/networking/tuntap.rst
similarity index 58%
rename from Documentation/networking/tuntap.txt
rename to Documentation/networking/tuntap.rst
index 0104830d5075..a59d1dd6fdcc 100644
--- a/Documentation/networking/tuntap.txt
+++ b/Documentation/networking/tuntap.rst
@@ -1,20 +1,28 @@
-Universal TUN/TAP device driver.
-Copyright (C) 1999-2000 Maxim Krasnyansky
+.. SPDX-License-Identifier: GPL-2.0
+.. include::
- Linux, Solaris drivers
- Copyright (C) 1999-2000 Maxim Krasnyansky
+===
+Universal TUN/TAP device driver
+===
- FreeBSD TAP driver
- Copyright (c) 1999-2000 Maksim Yevmenkin
+Copyright |copy| 1999-2000 Maxim Krasnyansky
+
+ Linux, Solaris drivers
+ Copyright |copy| 1999-2000 Maxim Krasnyansky
+
+ FreeBSD TAP driver
+ Copyright |copy| 1999-2000 Maksim Yevmenkin
Revision of this document 2002 by Florian Thiel
1. Description
- TUN/TAP provides packet reception and transmission for user space programs.
+==
+
+ TUN/TAP provides packet reception and transmission for user space programs.
It can be seen as a simple Point-to-Point or Ethernet device, which,
- instead of receiving packets from physical media, receives them from
- user space program and instead of sending packets via physical media
- writes them to the user space program.
+ instead of receiving packets from physical media, receives them from
+ user space program and instead of sending packets via physical media
+ writes them to the user space program.
In order to use the driver a program has to open /dev/net/tun and issue a
corresponding ioctl() to register a network device with the kernel. A network
@@ -33,41 +41,51 @@ Copyright (C) 1999-2000 Maxim Krasnyansky
br_sigio.c - bridge based on async io and SIGIO signal.
However, the best example is VTun http://vtun.sourceforge.net :))
-2. Configuration
- Create device node:
+2. Configuration
+
+
+ Create device node::
+
mkdir /dev/net (if it doesn't exist already)
mknod /dev/net/tun c 10 200
-
- Set permissions:
+
+ Set permissions::
+
e.g. chmod 0666 /dev/net/tun
- There's no harm in allowing the device to be accessible by non-root users,
- since CAP_NET_ADMIN is required for creating network devices or for
- connecting to network devices which aren't owned by the user in question.
- If you want to create persistent devices and give ownership of them to
- unprivileged users, then you need the /dev/net/tun device to be usable by
- those users.
+
+ There's no harm in allowing the device to be accessible by non-root users,
+ since CAP_NET_ADMIN is required for creating network devices or for
+ connecting to network devices which aren't owned by the user in question.
+ If you want to create persistent devices and give ownership of them to
+ unprivileged users, then you need the /dev/net/tun device to be usable by
+ those users.
Driver module autoloading
Make sure that "Kernel module loader" - module auto-loading
support is enabled in your kernel. The kernel should load it on
first access.
-
- Manual loading
- insert the module by hand:
-modprobe tun
+
+ Manual loading
+
+ insert the module by hand::
+
+ modprobe tun
If you do it the latter way, you have to load the module every time you
need it, if you do it the other way it will be automatically loaded when
/dev/net/tun is being opened.
-3. Program interface
- 3.1 Network device allocation:
+3. Program interface
+
- char *dev should be the name of the device with a format string (e.g.
- "tun%d"), but (as far as I can see) this can be any valid network device
name.
- Note that the character pointer becomes overwritten with the real device name
- (e.g. "tun0")
+3.1 Network device allocation
+-
+
+``char *dev`` should be the name of the
[PATCH 21/37] docs: networking: device drivers: convert dlink/dl2k.txt to ReST
- add SPDX header;
- mark code blocks and literals as such;
- mark lists as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../dlink/{dl2k.txt => dl2k.rst} | 228 ++
.../networking/device_drivers/index.rst | 1 +
drivers/net/ethernet/dlink/dl2k.c | 2 +-
3 files changed, 132 insertions(+), 99 deletions(-)
rename Documentation/networking/device_drivers/dlink/{dl2k.txt => dl2k.rst}
(59%)
diff --git a/Documentation/networking/device_drivers/dlink/dl2k.txt
b/Documentation/networking/device_drivers/dlink/dl2k.rst
similarity index 59%
rename from Documentation/networking/device_drivers/dlink/dl2k.txt
rename to Documentation/networking/device_drivers/dlink/dl2k.rst
index cba74f7a3abc..ccdb5d0d7460 100644
--- a/Documentation/networking/device_drivers/dlink/dl2k.txt
+++ b/Documentation/networking/device_drivers/dlink/dl2k.rst
@@ -1,10 +1,13 @@
+.. SPDX-License-Identifier: GPL-2.0
-D-Link DL2000-based Gigabit Ethernet Adapter Installation
-for Linux
-May 23, 2002
+=
+D-Link DL2000-based Gigabit Ethernet Adapter Installation
+=
+
+May 23, 2002
+
+.. Contents
-Contents
-
- Compatibility List
- Quick Install
- Compiling the Driver
@@ -15,12 +18,13 @@ Contents
Compatibility List
-=
+==
+
Adapter Support:
-D-Link DGE-550T Gigabit Ethernet Adapter.
-D-Link DGE-550SX Gigabit Ethernet Adapter.
-D-Link DL2000-based Gigabit Ethernet Adapter.
+- D-Link DGE-550T Gigabit Ethernet Adapter.
+- D-Link DGE-550SX Gigabit Ethernet Adapter.
+- D-Link DL2000-based Gigabit Ethernet Adapter.
The driver support Linux kernel 2.4.7 later. We had tested it
@@ -34,28 +38,32 @@ on the environments below.
Quick Install
=
-Install linux driver as following command:
+Install linux driver as following command::
+
+1. make all
+2. insmod dl2k.ko
+3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0
+ ^^^\\
+ IP NETMASK
-1. make all
-2. insmod dl2k.ko
-3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0
- ^^^\\
- IP NETMASK
Now eth0 should active, you can test it by "ping" or get more information by
"ifconfig". If tested ok, continue the next step.
-4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
-5. Add the following line to /etc/modprobe.d/dl2k.conf:
+4. ``cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net``
+5. Add the following line to /etc/modprobe.d/dl2k.conf::
+
alias eth0 dl2k
-6. Run depmod to updated module indexes.
-7. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
+
+6. Run ``depmod`` to updated module indexes.
+7. Run ``netconfig`` or ``netconf`` to create configuration script ifcfg-eth0
located at /etc/sysconfig/network-scripts or create it manually.
+
[see - Configuration Script Sample]
8. Driver will automatically load and configure at next boot time.
Compiling the Driver
- In Linux, NIC drivers are most commonly configured as loadable modules.
+In Linux, NIC drivers are most commonly configured as loadable modules.
The approach of building a monolithic kernel has become obsolete. The driver
can be compiled as part of a monolithic kernel, but is strongly discouraged.
The remainder of this section assumes the driver is built as a loadable module.
@@ -73,93 +81,108 @@ to compile and link the driver:
CD-ROM drive
-[root@XXX /] mkdir cdrom
-[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom
-[root@XXX /] cd root
-[root@XXX /root] mkdir dl2k
-[root@XXX /root] cd dl2k
-[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k
-[root@XXX dl2k] tar xfvz dl2k.tgz
-[root@XXX dl2k] make all
+::
+
+[root@XXX /] mkdir cdrom
+[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom
+[root@XXX /] cd root
+[root@XXX /root] mkdir dl2k
+[root@XXX /root] cd dl2k
+[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k
+[root@XXX dl2k] tar xfvz dl2k.tgz
+[root@XXX dl2k] make all
Floppy disc drive
-
-[root@XXX /] cd root
-[root@XXX /root] mkdir dl2k
-[root@XXX /root] cd dl2k
-[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k
-[root@XXX dl2k] tar xfvz dl2k.tgz
-[root@XXX dl2k] make all
+::
+
+[root@XXX /] cd root
+[root@XXX /root] mkdir dl2k
+[root@XXX /root] cd dl2k
+[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k
+[root@XXX dl2k] tar xfvz dl2k.tgz
+[root@XXX dl2k] make all
Installing the Driver
=
- Manual Installation
- ---
+Manual Installation
+---
[PATCH 23/37] docs: networking: device drivers: convert freescale/gianfar.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- use :field: markup;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../freescale/{gianfar.txt => gianfar.rst}| 21 +--
.../networking/device_drivers/index.rst | 1 +
2 files changed, 16 insertions(+), 6 deletions(-)
rename Documentation/networking/device_drivers/freescale/{gianfar.txt =>
gianfar.rst} (82%)
diff --git a/Documentation/networking/device_drivers/freescale/gianfar.txt
b/Documentation/networking/device_drivers/freescale/gianfar.rst
similarity index 82%
rename from Documentation/networking/device_drivers/freescale/gianfar.txt
rename to Documentation/networking/device_drivers/freescale/gianfar.rst
index ba1daea7f2e4..9c4a91d3824b 100644
--- a/Documentation/networking/device_drivers/freescale/gianfar.txt
+++ b/Documentation/networking/device_drivers/freescale/gianfar.rst
@@ -1,10 +1,15 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
The Gianfar Ethernet Driver
+===
-Author: Andy Fleming
-Updated: 2005-07-28
+:Author: Andy Fleming
+:Updated: 2005-07-28
-CHECKSUM OFFLOADING
+Checksum Offloading
+===
The eTSEC controller (first included in parts from late 2005 like
the 8548) has the ability to perform TCP, UDP, and IP checksums
@@ -15,13 +20,15 @@ packets. Use ethtool to enable or disable this feature for
RX
and TX.
VLAN
+
In order to use VLAN, please consult Linux documentation on
configuring VLANs. The gianfar driver supports hardware insertion and
extraction of VLAN headers, but not filtering. Filtering will be
done by the kernel.
-MULTICASTING
+Multicasting
+
The gianfar driver supports using the group hash table on the
TSEC (and the extended hash table on the eTSEC) for multicast
@@ -29,13 +36,15 @@ filtering. On the eTSEC, the exact-match MAC registers are
used
before the hash tables. See Linux documentation on how to join
multicast groups.
-PADDING
+Padding
+===
The gianfar driver supports padding received frames with 2 bytes
to align the IP header to a 16-byte boundary, when supported by
hardware.
-ETHTOOL
+Ethtool
+===
The gianfar driver supports the use of ethtool for many
configuration options. You must run ethtool only on currently
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 7e59ee43c030..cec3415ee459 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -38,6 +38,7 @@ Contents:
dec/dmfe
dlink/dl2k
freescale/dpaa
+ freescale/gianfar
.. only:: subproject and html
--
2.25.4
[PATCH 10/37] docs: networking: convert xfrm_sysctl.txt to ReST
Not much to be done here:
- add SPDX header;
- add a document title;
- add a chapter's markup;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst | 1 +
.../networking/{xfrm_sysctl.txt => xfrm_sysctl.rst}| 7 +++
2 files changed, 8 insertions(+)
rename Documentation/networking/{xfrm_sysctl.txt => xfrm_sysctl.rst} (52%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index ec83bd95e4e9..1630801cec19 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -120,6 +120,7 @@ Contents:
xfrm_device
xfrm_proc
xfrm_sync
+ xfrm_sysctl
.. only:: subproject and html
diff --git a/Documentation/networking/xfrm_sysctl.txt
b/Documentation/networking/xfrm_sysctl.rst
similarity index 52%
rename from Documentation/networking/xfrm_sysctl.txt
rename to Documentation/networking/xfrm_sysctl.rst
index 5bbd16792fe1..47b9bbdd0179 100644
--- a/Documentation/networking/xfrm_sysctl.txt
+++ b/Documentation/networking/xfrm_sysctl.rst
@@ -1,4 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+XFRM Syscall
+
+
/proc/sys/net/core/xfrm_* Variables:
+
xfrm_acq_expires - INTEGER
default 30 - hard timeout in seconds for acquire requests
--
2.25.4
Re: [PATCH 1/5] arm/arm64: smccc: Update link to latest SMCCC specification
On 30/04/2020 12:48, Sudeep Holla wrote: The current link gets redirected to the revision B published in November 2016 though it actually points to the original revision A published in June 2013. Let us update the link to point to the latest version, so that it doesn't get stal anytime soon. Currently it points to v1.2 published in s/stal/stale/ otherwise: Reviewed-by: Steven Price March 2020. Signed-off-by: Sudeep Holla --- include/linux/arm-smccc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h index 59494df0f55b..6c1d1eda3be4 100644 --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -10,7 +10,7 @@ /* * This file provides common defines for ARM SMC Calling Convention as * specified in - * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html + * https://developer.arm.com/docs/den0028/latest */ #define ARM_SMCCC_STD_CALL _AC(0,U)
[PATCH 05/37] docs: networking: convert x25-iface.txt to ReST
Not much to be done here:
- add SPDX header;
- adjust title markup;
- remove a tail whitespace;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst | 1 +
.../networking/{x25-iface.txt => x25-iface.rst}| 10 --
include/uapi/linux/if_x25.h| 2 +-
net/x25/Kconfig| 2 +-
4 files changed, 11 insertions(+), 4 deletions(-)
rename Documentation/networking/{x25-iface.txt => x25-iface.rst} (96%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index a72fdfb391b6..7a4bdbc111b0 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -115,6 +115,7 @@ Contents:
udplite
vrf
vxlan
+ x25-iface
.. only:: subproject and html
diff --git a/Documentation/networking/x25-iface.txt
b/Documentation/networking/x25-iface.rst
similarity index 96%
rename from Documentation/networking/x25-iface.txt
rename to Documentation/networking/x25-iface.rst
index 7f213b556e85..df401891dce6 100644
--- a/Documentation/networking/x25-iface.txt
+++ b/Documentation/networking/x25-iface.rst
@@ -1,4 +1,10 @@
- X.25 Device Driver Interface 1.1
+.. SPDX-License-Identifier: GPL-2.0
+
+-
+X.25 Device Driver Interface
+-
+
+Version 1.1
Jonathan Naylor 26.12.96
@@ -99,7 +105,7 @@ reduced by the following measures or a combination thereof:
(1) Drivers for kernel versions 2.4.x and above should always check the
return value of netif_rx(). If it returns NET_RX_DROP, the
driver's LAPB protocol must not confirm reception of the frame
-to the peer.
+to the peer.
This will reliably suppress packet loss. The LAPB protocol will
automatically cause the peer to re-transmit the dropped packet
later.
diff --git a/include/uapi/linux/if_x25.h b/include/uapi/linux/if_x25.h
index 5d962448345f..3a5938e38370 100644
--- a/include/uapi/linux/if_x25.h
+++ b/include/uapi/linux/if_x25.h
@@ -18,7 +18,7 @@
#include
-/* Documentation/networking/x25-iface.txt */
+/* Documentation/networking/x25-iface.rst */
#define X25_IFACE_DATA 0x00
#define X25_IFACE_CONNECT 0x01
#define X25_IFACE_DISCONNECT 0x02
diff --git a/net/x25/Kconfig b/net/x25/Kconfig
index 2ecb2e5e241e..a328f79885d1 100644
--- a/net/x25/Kconfig
+++ b/net/x25/Kconfig
@@ -21,7 +21,7 @@ config X25
.
Information about X.25 for Linux is contained in the files
and
- .
+ .
One connects to an X.25 network either with a dedicated network card
using the X.21 protocol (not yet supported by Linux) or one can do
--
2.25.4
[PATCH 18/37] docs: networking: device drivers: convert davicom/dm9000.txt to ReST
- add SPDX header;
- add a document title;
- mark lists as such;
- mark tables as such;
- mark code blocks and literals as such;
- use the right horizontal tag markup;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../davicom/{dm9000.txt => dm9000.rst}| 24 +++
.../networking/device_drivers/index.rst | 1 +
2 files changed, 15 insertions(+), 10 deletions(-)
rename Documentation/networking/device_drivers/davicom/{dm9000.txt =>
dm9000.rst} (92%)
diff --git a/Documentation/networking/device_drivers/davicom/dm9000.txt
b/Documentation/networking/device_drivers/davicom/dm9000.rst
similarity index 92%
rename from Documentation/networking/device_drivers/davicom/dm9000.txt
rename to Documentation/networking/device_drivers/davicom/dm9000.rst
index 5552e2e575c5..d5458da01083 100644
--- a/Documentation/networking/device_drivers/davicom/dm9000.txt
+++ b/Documentation/networking/device_drivers/davicom/dm9000.rst
@@ -1,7 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
DM9000 Network driver
=
Copyright 2008 Simtec Electronics,
+
Ben Dooks
@@ -30,9 +34,9 @@ These resources should be specified in that order, as the
ordering of the
two address regions is important (the driver expects these to be address
and then data).
-An example from arch/arm/mach-s3c2410/mach-bast.c is:
+An example from arch/arm/mach-s3c2410/mach-bast.c is::
-static struct resource bast_dm9k_resource[] = {
+ static struct resource bast_dm9k_resource[] = {
[0] = {
.start = S3C2410_CS5 + BAST_PA_DM9000,
.end = S3C2410_CS5 + BAST_PA_DM9000 + 3,
@@ -48,14 +52,14 @@ static struct resource bast_dm9k_resource[] = {
.end = IRQ_DM9000,
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL,
}
-};
+ };
-static struct platform_device bast_device_dm9k = {
+ static struct platform_device bast_device_dm9k = {
.name = "dm9000",
.id = 0,
.num_resources = ARRAY_SIZE(bast_dm9k_resource),
.resource = bast_dm9k_resource,
-};
+ };
Note the setting of the IRQ trigger flag in bast_dm9k_resource[2].flags,
as this will generate a warning if it is not present. The trigger from
@@ -64,13 +68,13 @@ handler to ensure that the IRQ is setup correctly.
This shows a typical platform device, without the optional configuration
platform data supplied. The next example uses the same resources, but adds
-the optional platform data to pass extra configuration data:
+the optional platform data to pass extra configuration data::
-static struct dm9000_plat_data bast_dm9k_platdata = {
+ static struct dm9000_plat_data bast_dm9k_platdata = {
.flags = DM9000_PLATF_16BITONLY,
-};
+ };
-static struct platform_device bast_device_dm9k = {
+ static struct platform_device bast_device_dm9k = {
.name = "dm9000",
.id = 0,
.num_resources = ARRAY_SIZE(bast_dm9k_resource),
@@ -78,7 +82,7 @@ static struct platform_device bast_device_dm9k = {
.dev= {
.platform_data = &bast_dm9k_platdata,
}
-};
+ };
The platform data is defined in include/linux/dm9000.h and described below.
diff --git a/Documentation/networking/device_drivers/index.rst
b/Documentation/networking/device_drivers/index.rst
index 0b39342e2a1f..e8db57fef2e9 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -33,6 +33,7 @@ Contents:
aquantia/atlantic
chelsio/cxgb
cirrus/cs89x0
+ davicom/dm9000
.. only:: subproject and html
--
2.25.4
[PATCH 02/37] docs: networking: convert udplite.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark lists as such;
- mark tables as such;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../networking/{udplite.txt => udplite.rst} | 175 ++
2 files changed, 95 insertions(+), 81 deletions(-)
rename Documentation/networking/{udplite.txt => udplite.rst} (65%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index e7a683f0528d..ca0b0dbfd9ad 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -112,6 +112,7 @@ Contents:
timestamping
tproxy
tuntap
+ udplite
.. only:: subproject and html
diff --git a/Documentation/networking/udplite.txt
b/Documentation/networking/udplite.rst
similarity index 65%
rename from Documentation/networking/udplite.txt
rename to Documentation/networking/udplite.rst
index 53a726855e49..2c225f28b7b2 100644
--- a/Documentation/networking/udplite.txt
+++ b/Documentation/networking/udplite.rst
@@ -1,6 +1,8 @@
- ===
- The UDP-Lite protocol (RFC 3828)
- ===
+.. SPDX-License-Identifier: GPL-2.0
+
+
+The UDP-Lite protocol (RFC 3828)
+
UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
@@ -11,39 +13,43 @@
This file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:
- o The UDP-Lite Homepage:
-
http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
- From here you can also download some example application source code.
+ - The UDP-Lite Homepage:
+
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
- o The UDP-Lite HOWTO on
-
http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
- files/UDP-Lite-HOWTO.txt
+ From here you can also download some example application source code.
- o The Wireshark UDP-Lite WiKi (with capture files):
- https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
+ - The UDP-Lite HOWTO on
+
http://web.archive.org/web/%2E/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
- o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
+ - The Wireshark UDP-Lite WiKi (with capture files):
+ https://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
+ - The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
- I) APPLICATIONS
+
+1. Applications
+===
Several applications have been ported successfully to UDP-Lite. Ethereal
- (now called wireshark) has UDP-Litev4/v6 support by default.
+ (now called wireshark) has UDP-Litev4/v6 support by default.
+
Porting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.
-
- II) PROGRAMMING API
+2. Programming API
+==
UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
- very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
- call so that the statement looks like:
+ very easy: simply add ``IPPROTO_UDPLITE`` as the last argument of the
+ socket(2) call so that the statement looks like::
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
- or, respectively,
+ or, respectively,
+
+ ::
s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
@@ -56,10 +62,10 @@
* Sender checksum coverage: UDPLITE_SEND_CSCOV
- For example,
+ For example::
-int val = 20;
-setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
+ int val = 20;
+ setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
sets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
@@ -74,10 +80,10 @@
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
- packets with a minimum coverage of 20 are admitted:
+ packets with a minimum coverage of 20 are admitted::
-int min = 20;
-setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
+
[PATCH 00/37]net: manually convert files to ReST format - part 3 (final)
That's the third part (and the final one) of my work to convert the networking
text files into ReST. it is based on linux-next next-20200430 branch.
The full series (including those ones) are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs
The built output documents, on html format is at:
https://www.infradead.org/~mchehab/kernel_docs/networking/
Mauro Carvalho Chehab (37):
docs: networking: convert tuntap.txt to ReST
docs: networking: convert udplite.txt to ReST
docs: networking: convert vrf.txt to ReST
docs: networking: convert vxlan.txt to ReST
docs: networking: convert x25-iface.txt to ReST
docs: networking: convert x25.txt to ReST
docs: networking: convert xfrm_device.txt to ReST
docs: networking: convert xfrm_proc.txt to ReST
docs: networking: convert xfrm_sync.txt to ReST
docs: networking: convert xfrm_sysctl.txt to ReST
docs: networking: convert z8530drv.txt to ReST
docs: networking: device drivers: convert 3com/3c509.txt to ReST
docs: networking: device drivers: convert 3com/vortex.txt to ReST
docs: networking: device drivers: convert amazon/ena.txt to ReST
docs: networking: device drivers: convert aquantia/atlantic.txt to
ReST
docs: networking: device drivers: convert chelsio/cxgb.txt to ReST
docs: networking: device drivers: convert cirrus/cs89x0.txt to ReST
docs: networking: device drivers: convert davicom/dm9000.txt to ReST
docs: networking: device drivers: convert dec/de4x5.txt to ReST
docs: networking: device drivers: convert dec/dmfe.txt to ReST
docs: networking: device drivers: convert dlink/dl2k.txt to ReST
docs: networking: device drivers: convert freescale/dpaa.txt to ReST
docs: networking: device drivers: convert freescale/gianfar.txt to
ReST
docs: networking: device drivers: convert intel/ipw2100.txt to ReST
docs: networking: device drivers: convert intel/ipw2200.txt to ReST
docs: networking: device drivers: convert microsoft/netvsc.txt to ReST
docs: networking: device drivers: convert neterion/s2io.txt to ReST
docs: networking: device drivers: convert neterion/vxge.txt to ReST
docs: networking: device drivers: convert qualcomm/rmnet.txt to ReST
docs: networking: device drivers: convert sb1000.txt to ReST
docs: networking: device drivers: convert smsc/smc9.txt to ReST
docs: networking: device drivers: convert ti/cpsw_switchdev.txt to
ReST
docs: networking: device drivers: convert ti/cpsw.txt to ReST
docs: networking: device drivers: convert ti/tlan.txt to ReST
docs: networking: device drivers: convert toshiba/spider_net.txt to
ReST
net: docs: add page_pool.rst to index.rst
docs: networking: arcnet-hardware.rst: don't duplicate chapter names
Documentation/networking/arcnet-hardware.rst | 8 +-
.../3com/{3c509.txt => 3c509.rst} | 158 +++--
.../3com/{vortex.txt => vortex.rst} | 223 ---
.../amazon/{ena.txt => ena.rst} | 142 ++--
.../aquantia/{atlantic.txt => atlantic.rst} | 373 ++-
.../chelsio/{cxgb.txt => cxgb.rst}| 183 --
.../cirrus/{cs89x0.txt => cs89x0.rst} | 557
.../davicom/{dm9000.txt => dm9000.rst}| 24 +-
.../dec/{de4x5.txt => de4x5.rst} | 105 +--
.../device_drivers/dec/{dmfe.txt => dmfe.rst} | 35 +-
.../dlink/{dl2k.txt => dl2k.rst} | 228 ---
.../freescale/{dpaa.txt => dpaa.rst} | 139 ++--
.../freescale/{gianfar.txt => gianfar.rst}| 21 +-
.../networking/device_drivers/index.rst | 24 +
.../intel/{ipw2100.txt => ipw2100.rst}| 242 ---
.../intel/{ipw2200.txt => ipw2200.rst}| 410 +++-
.../microsoft/{netvsc.txt => netvsc.rst} | 57 +-
.../device_drivers/neterion/s2io.rst | 196 ++
.../device_drivers/neterion/s2io.txt | 141
.../neterion/{vxge.txt => vxge.rst} | 60 +-
.../qualcomm/{rmnet.txt => rmnet.rst} | 43 +-
.../networking/device_drivers/sb1000.rst | 222 +++
.../networking/device_drivers/sb1000.txt | 207 --
.../networking/device_drivers/smsc/smc9.rst | 49 ++
.../networking/device_drivers/smsc/smc9.txt | 42 --
.../networking/device_drivers/ti/cpsw.rst | 587 +
.../networking/device_drivers/ti/cpsw.txt | 541
...{cpsw_switchdev.txt => cpsw_switchdev.rst} | 239 ---
.../device_drivers/ti/{tlan.txt => tlan.rst} | 73 ++-
.../{spider_net.txt => spider_net.rst}| 58 +-
Documentation/networking/index.rst| 12 +
.../networking/{tuntap.txt => tuntap.rst} | 200 +++---
.../networking/{udplite.txt => udplite.rst} | 175 ++---
Documentation/networking/vrf.rst | 451 +
Documentation/networking/vrf.txt | 418
.../networking/{vxlan.txt => vxlan.rst} | 33 +-
.../{x25-iface.txt => x25-iface.rst} | 10 +-
Documentation/networking/{x25.txt => x25.rst}
Re: [PATCH RFC v2 00/11] dwmac-meson8b Ethernet RX delay configuration
Hi Andrew, On Wed, Apr 29, 2020 at 11:29 PM Andrew Lunn wrote: > > > - Khadas VIM2 seems to have the RX delay built into the PCB trace > > length. When I enable the RX delay on the PHY or MAC I can't get any > > data through. I expect that we will have the same situation on all > > GXBB, GXM, AXG, G12A, G12B and SM1 boards > > Hi Martin > > Can you actually see this on the PCB? The other possibility is that > the bootloader is configuring something, which is not getting > overridden when linux starts up. at least it doesn't jump straight into my eye. I checked in u-boot and Linux, and for both the RX delay is disabled in the PHY as well as in the MAC. The schematics of the Khadas VIM2 also show the the RX delay in the PHY is turned off by pin-strapping, see page 7 on the right: [0] It's the same for the Khadas VIM3 schematics, also on page 7: [1] There are also high resolution images of the Khadas VIM3 online so you can look at it yourself (I couldn't find any for the Khadas VIM2 which is what I have): [2] I agree that we need to get an answer to the RX delay question on the arm64 SoCs. If there's no way to find out from the existing resources then I can contact Khadas and ask them about the PCB trace length on VIM2, VIM3 and VIM3L (these are the ones with RGMII PHYs). For the older SoCs the RX delay has to be provided by either the MAC or the PHY and right now we're not configuring it. We cannot simply enable the RX delay at the PHY level because the bootloader enables it in the MAC (so we have to turn it off there). So it would be great if you could still review this series. Martin [0] https://dl.khadas.com/Hardware/VIM2/Schematic/VIM2_V12_Sch.pdf [1] https://dl.khadas.com/Hardware/VIM3/Schematic/VIM3_V12_Sch.pdf [2] https://forum.khadas.com/t/khadas-vim3-is-launching-on-24-june/4103
Re: [PATCH liburing] test/sfr: basic test for sync_file_range
On 5/1/20 8:38 AM, Pavel Begunkov wrote: > Just call it and check that it doesn't hang and returns success. Applied, thanks. -- Jens Axboe
Re: KASAN: use-after-free Read in inet_diag_bc_sk
syzbot has bisected this bug to:
commit b1f3e43dbfacfcd95296b0f80f84b186add9ef54
Author: Dmitry Yakunin
Date: Thu Apr 30 15:51:15 2020 +
inet_diag: add support for cgroup filter
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=106b15f810
start commit: 37ecb5b8 hinic: Use kmemdup instead of kzalloc and memcpy
git tree: net-next
final crash:https://syzkaller.appspot.com/x/report.txt?x=126b15f810
console output: https://syzkaller.appspot.com/x/log.txt?x=146b15f810
kernel config: https://syzkaller.appspot.com/x/.config?x=b1494ce3fbc02154
dashboard link: https://syzkaller.appspot.com/bug?extid=13bef047dbfffa5cd1af
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12296e6010
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=150c6f0210
Reported-by: syzbot+13bef047dbfffa5cd...@syzkaller.appspotmail.com
Fixes: b1f3e43dbfac ("inet_diag: add support for cgroup filter")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH 2/5] arm/arm64: smccc: Add the definition for SMCCCv1.2 version/error codes
On 30/04/2020 12:48, Sudeep Holla wrote: Add the definition for SMCCC v1.2 version and new error code added. While at it, also add a note that ARM DEN 0070A is deprecated and is now merged into the main SMCCC specification(ARM DEN 0028C). Signed-off-by: Sudeep Holla Reviewed-by: Steven Price --- include/linux/arm-smccc.h | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h index 6c1d1eda3be4..9d9a2e42e919 100644 --- a/include/linux/arm-smccc.h +++ b/include/linux/arm-smccc.h @@ -56,6 +56,7 @@ #define ARM_SMCCC_VERSION_1_0 0x1 #define ARM_SMCCC_VERSION_1_1 0x10001 +#define ARM_SMCCC_VERSION_1_2 0x10002 #define ARM_SMCCC_VERSION_FUNC_ID \ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \ @@ -314,10 +315,14 @@ asmlinkage void __arm_smccc_hvc(unsigned long a0, unsigned long a1, */ #define arm_smccc_1_1_hvc(...)__arm_smccc_1_1(SMCCC_HVC_INST, __VA_ARGS__) -/* Return codes defined in ARM DEN 0070A */ +/* + * Return codes defined in ARM DEN 0070A + * ARM DEN 0070A is now merged/consolidated into ARM DEN 0028C + */ #define SMCCC_RET_SUCCESS 0 #define SMCCC_RET_NOT_SUPPORTED -1 #define SMCCC_RET_NOT_REQUIRED-2 +#define SMCCC_RET_INVALID_PARAMETER-3 /* * Like arm_smccc_1_1* but always returns SMCCC_RET_NOT_SUPPORTED.
[PATCH 14/37] docs: networking: device drivers: convert amazon/ena.txt to ReST
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- mark tables as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
.../amazon/{ena.txt => ena.rst} | 142 +++---
.../networking/device_drivers/index.rst | 1 +
MAINTAINERS | 2 +-
3 files changed, 91 insertions(+), 54 deletions(-)
rename Documentation/networking/device_drivers/amazon/{ena.txt => ena.rst}
(86%)
diff --git a/Documentation/networking/device_drivers/amazon/ena.txt
b/Documentation/networking/device_drivers/amazon/ena.rst
similarity index 86%
rename from Documentation/networking/device_drivers/amazon/ena.txt
rename to Documentation/networking/device_drivers/amazon/ena.rst
index 1bb55c7b604c..11af6388ea87 100644
--- a/Documentation/networking/device_drivers/amazon/ena.txt
+++ b/Documentation/networking/device_drivers/amazon/ena.rst
@@ -1,8 +1,12 @@
-Linux kernel driver for Elastic Network Adapter (ENA) family:
-=
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Linux kernel driver for Elastic Network Adapter (ENA) family
+
+
+Overview
+
-Overview:
-=
ENA is a networking interface designed to make good use of modern CPU
features and system architectures.
@@ -35,32 +39,40 @@ debug logs.
Some of the ENA devices support a working mode called Low-latency
Queue (LLQ), which saves several more microseconds.
-Supported PCI vendor ID/device IDs:
+Supported PCI vendor ID/device IDs
+==
+
+= ===
+1d0f:0ec2 ENA PF
+1d0f:1ec2 ENA PF with LLQ support
+1d0f:ec20 ENA VF
+1d0f:ec21 ENA VF with LLQ support
+= ===
+
+ENA Source Code Directory Structure
===
-1d0f:0ec2 - ENA PF
-1d0f:1ec2 - ENA PF with LLQ support
-1d0f:ec20 - ENA VF
-1d0f:ec21 - ENA VF with LLQ support
-ENA Source Code Directory Structure:
-
-ena_com.[ch] - Management communication layer. This layer is
-responsible for the handling all the management
-(admin) communication between the device and the
-driver.
-ena_eth_com.[ch] - Tx/Rx data path.
-ena_admin_defs.h - Definition of ENA management interface.
-ena_eth_io_defs.h - Definition of ENA data path interface.
-ena_common_defs.h - Common definitions for ena_com layer.
-ena_regs_defs.h - Definition of ENA PCI memory-mapped (MMIO) registers.
-ena_netdev.[ch] - Main Linux kernel driver.
-ena_syfsfs.[ch] - Sysfs files.
-ena_ethtool.c - ethtool callbacks.
-ena_pci_id_tbl.h - Supported device IDs.
+= ==
+ena_com.[ch]Management communication layer. This layer is
+ responsible for the handling all the management
+ (admin) communication between the device and the
+ driver.
+ena_eth_com.[ch]Tx/Rx data path.
+ena_admin_defs.hDefinition of ENA management interface.
+ena_eth_io_defs.h Definition of ENA data path interface.
+ena_common_defs.h Common definitions for ena_com layer.
+ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers.
+ena_netdev.[ch] Main Linux kernel driver.
+ena_syfsfs.[ch] Sysfs files.
+ena_ethtool.c ethtool callbacks.
+ena_pci_id_tbl.hSupported device IDs.
+= ==
Management Interface:
=
+
ENA management interface is exposed by means of:
+
- PCIe Configuration Space
- Device Registers
- Admin Queue (AQ) and Admin Completion Queue (ACQ)
@@ -78,6 +90,7 @@ vendor-specific extensions. Most of the management operations
are
framed in a generic Get/Set feature command.
The following admin queue commands are supported:
+
- Create I/O submission queue
- Create I/O completion queue
- Destroy I/O submission queue
@@ -96,12 +109,16 @@ be reported using ACQ. AENQ events are subdivided into
groups. Each
group may have multiple syndromes, as shown below
The events are:
+
+ ===
Group Syndrome
- Link state change - X -
- Fatal error - X -
+ ===
+ Link state change **X**
+ Fatal error **X**
NotificationSuspend traffic
NotificationResume traffic
- Keep-Alive - X -
+ Keep-Alive **X**
+ ===
ACQ and AENQ share the same MSI-X
[PATCH 04/37] docs: networking: convert vxlan.txt to ReST
- add SPDX header;
- adjust title markup;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/networking/index.rst| 1 +
.../networking/{vxlan.txt => vxlan.rst} | 33 ---
2 files changed, 22 insertions(+), 12 deletions(-)
rename Documentation/networking/{vxlan.txt => vxlan.rst} (73%)
diff --git a/Documentation/networking/index.rst
b/Documentation/networking/index.rst
index 2227b9f4509d..a72fdfb391b6 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -114,6 +114,7 @@ Contents:
tuntap
udplite
vrf
+ vxlan
.. only:: subproject and html
diff --git a/Documentation/networking/vxlan.txt
b/Documentation/networking/vxlan.rst
similarity index 73%
rename from Documentation/networking/vxlan.txt
rename to Documentation/networking/vxlan.rst
index c28f4989c3f0..ce239fa01848 100644
--- a/Documentation/networking/vxlan.txt
+++ b/Documentation/networking/vxlan.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
Virtual eXtensible Local Area Networking documentation
==
@@ -21,8 +24,9 @@ neighbors GRE and VLAN. Configuring VXLAN requires the
version of
iproute2 that matches the kernel release where VXLAN was first merged
upstream.
-1. Create vxlan device
- # ip link add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 dstport 4789
+1. Create vxlan device::
+
+# ip link add vxlan0 type vxlan id 42 group 239.1.1.1 dev eth1 dstport 4789
This creates a new device named vxlan0. The device uses the multicast
group 239.1.1.1 over eth1 to handle traffic for which there is no
@@ -32,20 +36,25 @@ pre-dates the IANA's selection of a standard destination
port number
and uses the Linux-selected value by default to maintain backwards
compatibility.
-2. Delete vxlan device
- # ip link delete vxlan0
+2. Delete vxlan device::
-3. Show vxlan info
- # ip -d link show vxlan0
+# ip link delete vxlan0
+
+3. Show vxlan info::
+
+# ip -d link show vxlan0
It is possible to create, destroy and display the vxlan
forwarding table using the new bridge command.
-1. Create forwarding table entry
- # bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0
+1. Create forwarding table entry::
-2. Delete forwarding table entry
- # bridge fdb delete 00:17:42:8a:b4:05 dev vxlan0
+# bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0
-3. Show forwarding table
- # bridge fdb show dev vxlan0
+2. Delete forwarding table entry::
+
+# bridge fdb delete 00:17:42:8a:b4:05 dev vxlan0
+
+3. Show forwarding table::
+
+# bridge fdb show dev vxlan0
--
2.25.4
Re: [PATCH 3/5] arm/arm64: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead
On 30/04/2020 12:48, Sudeep Holla wrote:
Instead of maintaining 2 sets of enums/macros for tracking SMCCC version,
let us drop smccc_version enum and use ARM_SMCCC_VERSION_1_x directly
instead.
Signed-off-by: Sudeep Holla
Reviewed-by: Steven Price
---
arch/arm64/kernel/paravirt.c | 2 +-
drivers/firmware/psci/psci.c | 8
include/linux/psci.h | 7 +--
3 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
index 1ef702b0be2d..295d66490584 100644
--- a/arch/arm64/kernel/paravirt.c
+++ b/arch/arm64/kernel/paravirt.c
@@ -120,7 +120,7 @@ static bool has_pv_steal_clock(void)
struct arm_smccc_res res;
/* To detect the presence of PV time support we require SMCCC 1.1+ */
- if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
return false;
arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index 2937d44b5df4..6a56d7196697 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -54,12 +54,12 @@ bool psci_tos_resident_on(int cpu)
struct psci_operations psci_ops = {
.conduit = SMCCC_CONDUIT_NONE,
- .smccc_version = SMCCC_VERSION_1_0,
+ .smccc_version = ARM_SMCCC_VERSION_1_0,
};
enum arm_smccc_conduit arm_smccc_1_1_get_conduit(void)
{
- if (psci_ops.smccc_version < SMCCC_VERSION_1_1)
+ if (psci_ops.smccc_version < ARM_SMCCC_VERSION_1_1)
return SMCCC_CONDUIT_NONE;
return psci_ops.conduit;
@@ -411,8 +411,8 @@ static void __init psci_init_smccc(void)
if (feature != PSCI_RET_NOT_SUPPORTED) {
u32 ret;
ret = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
- if (ret == ARM_SMCCC_VERSION_1_1) {
- psci_ops.smccc_version = SMCCC_VERSION_1_1;
+ if (ret >= ARM_SMCCC_VERSION_1_1) {
+ psci_ops.smccc_version = ret;
ver = ret;
}
}
diff --git a/include/linux/psci.h b/include/linux/psci.h
index a67712b73b6c..29bd0671e5bb 100644
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -21,11 +21,6 @@ bool psci_power_state_is_valid(u32 state);
int psci_set_osi_mode(void);
bool psci_has_osi_support(void);
-enum smccc_version {
- SMCCC_VERSION_1_0,
- SMCCC_VERSION_1_1,
-};
-
struct psci_operations {
u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
@@ -36,7 +31,7 @@ struct psci_operations {
unsigned long lowest_affinity_level);
int (*migrate_info_type)(void);
enum arm_smccc_conduit conduit;
- enum smccc_version smccc_version;
+ u32 smccc_version;
};
extern struct psci_operations psci_ops;
[PULL REQUEST] i2c for v5.7
Linus, I2C has three driver bugfixes this time, and two reverts because the original patches revealed underlying problems which the Tegra guys are now working on. Please pull. Thanks, Wolfram The following changes since commit 6a8b55ed4056ea5559ebe4f6a4b247f627870d4c: Linux 5.7-rc3 (2020-04-26 13:51:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current-fixed for you to fetch changes up to c926c87b8e36dcc0ea5c2a0a0227ed4f32d0516a: i2c: aspeed: Avoid i2c interrupt status clear race condition. (2020-04-30 16:12:33 +0200) Dan Carpenter (1): i2c: amd-mp2-pci: Fix Oops in amd_mp2_pci_init() error handling Rayagonda Kokatanur (1): i2c: iproc: generate stop event for slave writes Wolfram Sang (2): Revert "i2c: tegra: Synchronize DMA before termination" Revert "i2c: tegra: Better handle case where CPU0 is busy for a long time" ryan_chen (1): i2c: aspeed: Avoid i2c interrupt status clear race condition. drivers/i2c/busses/i2c-amd-mp2-pci.c | 2 +- drivers/i2c/busses/i2c-aspeed.c | 5 - drivers/i2c/busses/i2c-bcm-iproc.c | 3 +++ drivers/i2c/busses/i2c-tegra.c | 36 4 files changed, 20 insertions(+), 26 deletions(-) signature.asc Description: PGP signature
Re: [PATCH 03/37] docs: networking: convert vrf.txt to ReST
On 5/1/20 8:44 AM, Mauro Carvalho Chehab wrote: > - add SPDX header; > - adjust title markup; > - Add a subtitle for the first section; > - mark code blocks and literals as such; > - adjust identation, whitespaces and blank lines; > - add to networking/index.rst. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/networking/index.rst | 1 + > Documentation/networking/vrf.rst | 451 + > Documentation/networking/vrf.txt | 418 -- > MAINTAINERS| 2 +- > 4 files changed, 453 insertions(+), 419 deletions(-) > create mode 100644 Documentation/networking/vrf.rst > delete mode 100644 Documentation/networking/vrf.txt > Acked-by: David Ahern
Re: [PATCHv6 0/6] n_gsm serdev support and GNSS driver for droid4
* Pavel Machek [200430 22:27]:
>
> > My guess is that at least with the pending ofono patches, we just
> > want to use the raw interface for /dev/gsmtty* interface and stop
> > pretending we have a modem that is AT compatible.
>
> I tried to get it to work... it was not fun and I did not get far.
OK. Yeah it's now 2020 and still dealing with serial port stuff :)
> I pushed my results...
>
> user@devuan:/my/ofono$ git push
> Counting objects: 10, done.
> Delta compression using up to 2 threads.
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (10/10), 1.17 KiB | 0 bytes/s, done.
> Total 10 (delta 8), reused 0 (delta 0)
> remote: Resolving deltas: 100% (8/8), completed with 8 local objects.
> To github.com:pavelmachek/ofono.git
>fd34ca20..9042014b mux-v1.29-1 -> mux-v1.29-1
OK :) I still need to update the ALSA related patches on top
of this $subject series.
Also what I've noticed is that modprobe n_gsm debug=0xff hex output is
currently broken since commit 091cb0994edd ("lib/hexdump: make
print_hex_dump_bytes() a nop on !DEBUG builds"). Reverting the commit
fixes it.
Stephen, any ideas what should be changed to fix it?
Regards,
Tony
Re: [PATCH 13/15] scsi: sas: avoid gcc-10 zero-length-bounds warning
On Fri, 2020-05-01 at 09:54 +0200, Arnd Bergmann wrote:
> On Fri, May 1, 2020 at 9:48 AM John Garry
> wrote:
> > On 30/04/2020 22:30, Arnd Bergmann wrote:
> > > This should really be a flexible-array member, but the structure
> > > already has such a member, swapping it out with sense_data[]
> > > would cause many more warnings elsewhere.
> > >
> >
> >
> > Hi Arnd,
> >
> > If we really prefer flexible-array members over zero-length array
> > members, then could we have a union of flexible-array members? I'm
> > not sure if that's a good idea TBH (or even permitted), as these
> > structures are defined by the SAS spec and good practice to keep as
> > consistent as possible, but just wondering.
>
> gcc does not allow flexible-array members inside of a union, or more
> than one flexible-array member at the end of a structure.
>
> I found one hack that would work, but I think it's too ugly and
> likely not well-defined either:
>
> struct ssp_response_iu {
> ...
> struct {
> u8 dummy[0]; /* a struct must have at least one
> non-flexible member */
If gcc is now warning about zero length members, why isn't it warning
about this one ... are unions temporarily excluded?
> u8 resp_data[]; /* allowed here because it's at
> the one of a struct */
> };
> u8 sense_data[];
> } __attribute__ ((packed));
Let's go back to what the standard says: we want the data beyond the
ssp_response_iu to be addressable either as sense_data if it's an error
return or resp_data if it's a real response. What about trying to use
an alias attribute inside the structure ... will that work on gcc-10?
James
Re: [PATCH] power: charger-manager: clarify num_properties starting value
Hi, On Fri, May 01, 2020 at 04:30:43PM +0200, Michał Mirosław wrote: > Initialize num_properties with length of the copied array instead > of relying on previously memcpy'd value. This makes it clear how > the array and the counter are related. > > Signed-off-by: Michał Mirosław > --- Thanks, queued. -- Sebastian > drivers/power/supply/charger-manager.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/power/supply/charger-manager.c > b/drivers/power/supply/charger-manager.c > index 415a9efa6816..2ef53dc1f2fb 100644 > --- a/drivers/power/supply/charger-manager.c > +++ b/drivers/power/supply/charger-manager.c > @@ -1729,7 +1729,7 @@ static int charger_manager_probe(struct platform_device > *pdev) > memcpy(properties, default_charger_props, > sizeof(enum power_supply_property) * > ARRAY_SIZE(default_charger_props)); > - num_properties = psy_default.num_properties; > + num_properties = ARRAY_SIZE(default_charger_props); > > /* Find which optional psy-properties are available */ > fuel_gauge = power_supply_get_by_name(desc->psy_fuel_gauge); > -- > 2.20.1 > signature.asc Description: PGP signature
Re: [PATCH v3 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Hi Chun-Kuang,
Thank you for your review.
On 1/5/20 16:26, Chun-Kuang Hu wrote:
> Hi, Enric:
>
> Enric Balletbo i Serra 於 2020年4月17日 週五
> 下午11:06寫道：
>>
>> Use the drm_bridge_connector helper to create a connector for pipelines
>> that use drm_bridge. This allows splitting connector operations across
>> multiple bridges when necessary, instead of having the last bridge in
>> the chain creating the connector and handling all connector operations
>> internally.
>>
>> Signed-off-by: Enric Balletbo i Serra
>> ---
>>
>> Changes in v3:
>> - Move the bridge.type line to the patch that adds drm_bridge support.
>> (Laurent Pinchart)
>>
>> Changes in v2: None
>>
>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> index 157097c63b23..85f76b01ae4d 100644
>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
>> @@ -17,6 +17,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -183,6 +184,7 @@ struct mtk_dsi {
>> struct drm_encoder encoder;
>> struct drm_bridge bridge;
>> struct drm_bridge *next_bridge;
>> + struct drm_connector *connector;
>> struct phy *phy;
>>
>> void __iomem *regs;
>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device
>> *drm, struct mtk_dsi *dsi)
>> */
>> dsi->encoder.possible_crtcs = 1;
>>
>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR);
>> if (ret)
>> goto err_cleanup_encoder;
>>
>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
>> + if (IS_ERR(dsi->connector)) {
>> + DRM_ERROR("Unable to create bridge connector\n");
>> + ret = PTR_ERR(dsi->connector);
>> + goto err_cleanup_encoder;
>> + }
>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
>> +
>
> I'm not very clear about how brige-connector works, but why connector
> does not attach to panel?
>
Laurent or other drm maintainers might have more details than me, but, AFAIK the
drm_bridge_connector_init initializes a connector for a chain of bridges that
starts at the @encoder. At this point you don't know which bridge is connected
to the panel physically but doesn't really matter as what you know is that will
be only one connector in the chain.
Thanks,
Enric
> Regards,
> Chun-Kuang.
>
>> return 0;
>>
>> err_cleanup_encoder:
>> --
>> 2.25.1
>>
Re: [PATCH v1 1/1] PCI/AER: Use _OSC negotiation to determine AER ownership
On Fri, May 01, 2020 at 02:40:23PM +, austin.bo...@dell.com wrote: > On 4/30/2020 6:02 PM, Bjorn Helgaas wrote: > > [Austin, help us understand the FIRMWARE_FIRST bit! :)] > > > > On Thu, Apr 30, 2020 at 05:40:22PM -0500, Bjorn Helgaas wrote: > >> On Sun, Apr 26, 2020 at 11:30:06AM -0700, > >> sathyanarayanan.kuppusw...@linux.intel.com wrote: > >>> From: Kuppuswamy Sathyanarayanan > >>> > >>> > >>> Currently PCIe AER driver uses HEST FIRMWARE_FIRST bit to > >>> determine the PCIe AER Capability ownership between OS and > >>> firmware. This support is added based on following spec > >>> reference. > >>> > >>> Per ACPI spec r6.3, table 18-387, 18-388, 18-389, HEST table > >>> flags field BIT-0 and BIT-1 can be used to expose the > >>> ownership of error source between firmware and OSPM. > >>> > >>> Bit [0] - FIRMWARE_FIRST: If set, indicates that system > >>> firmware will handle errors from this source > >>> first. > >>> Bit [1] – GLOBAL: If set, indicates that the settings > >>> contained in this structure apply globally to all > >>> PCI Express Bridges. > >>> > >>> Although above spec reference states that setting > >>> FIRMWARE_FIRST bit means firmware will handle the error source > >>> first, it does not explicitly state anything about AER > >>> ownership. So using HEST to determine AER ownership is > >>> incorrect. > >>> > >>> Also, as per following specification references, _OSC can be > >>> used to negotiate the AER ownership between firmware and OS. > >>> Details are, > >>> > >>> Per ACPI spec r6.3, sec 6.2.11.3, table titled “Interpretation > >>> of _OSC Control Field” and as per PCI firmware specification r3.2, > >>> sec 4.5.1, table 4-5, OS can set bit 3 of _OSC control field > >>> to request control over PCI Express AER. If the OS successfully > >>> receives control of this feature, it must handle error reporting > >>> through the AER Capability as described in the PCI Express Base > >>> Specification. > >>> > >>> Since above spec references clearly states _OSC can be used to > >>> determine AER ownership, don't depend on HEST FIRMWARE_FIRST bit. > >> I pulled out the _OSC part of this to a separate patch. What's left > >> is below, and is essentially equivalent to Alex's patch: > >> > >> https://lore.kernel.org/r/20190326172343.28946-3-mr.nuke...@gmail.com/ > >> > >> I like what this does, but what I don't like is the fact that we now > >> have this thing called pcie_aer_get_firmware_first() that is not > >> connected with the ACPI FIRMWARE_FIRST bit at all. > > > > Austin, if we remove this, we'll have no PCIe-related code that looks > > at the HEST FIRMWARE_FIRST bit at all. Presumably it's there for some > > reason, but I'm not sure what the reason is. > > > > Alex's mail [1] has a nice table of _OSC AER/HEST FFS bits that looks > > useful, but the only actionable thing I can see is that in the (1,1) > > case, OSPM should do some initialization with masks/enables. > > > > But I have no clue what that means or how to connect that with the > > spec. What are the masks/enables? Is that something connected with > > ERST? > > > > [1] https://lore.kernel.org/r/20190326172343.28946-1-mr.nuke...@gmail.com/ > > The only values that make sense to me are (1, 0) for full native OS > init/handling of AER and (0, 1) for the firmware first model where > firmware does the init and handles errors first then passes control to > the OS. For these cases the FIRMWARE_FIRST flag in HEST is redundant and > not needed. > > We did discuss the (1, 1) case in the ACPI working group and there were > a potential use case (which Alex documented in the link you provided) > but there is nothing specified in the standard about how that model > would actually work AFAICT. And no x86 system has the hardware support > needed for what was proposed that I'm aware of (not sure about other > architectures). > > So unless and until someone documents how the firmware and OS are > supposed to behave in the (1, 1) or (0, 0) scenario and expresses a need > for those models, I would not bother adding support for them. Just my 2 > cents. Perfect, I think we should ignore the FIRMWARE_FIRST bit in the HEST PCIe entries for now. Thanks a lot for your help with this! Bjorn
Re: [PATCH 0/3] small fixes for-5.7
On 5/1/20 8:09 AM, Pavel Begunkov wrote: > I split the sent patchset, please consider this part for current. > > I'll send a test for [1] in a day or so. > > Regarding [3], Jens, I haven't looked properly yet, how long > splice can wait on a inode mutex, but it can be problematic, > especially for latencies. How about go safe for-5.7, and > maybe think something out for next? Agree, let's play it safe for 5.7, and look further into expanding this for 5.8 so we don't always have to go async. Series looks good to me, applied. Thanks Pavel! -- Jens Axboe
Re: [PATCH v3 5/6] blktrace: break out of blktrace setup on concurrent calls
On Wed, Apr 29, 2020 at 11:49:37AM +0200, Greg KH wrote:
> On Wed, Apr 29, 2020 at 07:46:26AM +, Luis Chamberlain wrote:
> > diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
> > index 5c52976bd762..383045f67cb8 100644
> > --- a/kernel/trace/blktrace.c
> > +++ b/kernel/trace/blktrace.c
> > @@ -516,6 +518,11 @@ static int do_blk_trace_setup(struct request_queue *q,
> > char *name, dev_t dev,
> > */
> > strreplace(buts->name, '/', '_');
> >
> > + if (q->blk_trace) {
> > + pr_warn("Concurrent blktraces are not allowed\n");
> > + return -EBUSY;
>
> You have access to a block device here, please use dev_warn() instead
> here for that, that makes it obvious as to what device a "concurrent
> blktrace" was attempted for.
The block device may be empty, one example is for scsi-generic, but I'll
use buts->name.
Luis
Re: [RFC PATCH v2 0/3] Prefer working VT console over SPCR and device-tree chosen stdout-path
On 01/05/2020 16:16, Andy Shevchenko wrote: > On Fri, May 1, 2020 at 2:11 PM Alper Nebi Yasak > wrote: >> I'm assuming "by default" here means "without console arguments" >> regardless of firmware requests. This paragraph (with small changes) is >> repeated on many other Kconfig descriptions (drivers/tty/serial/Kconfig, >> drivers/tty/serial/8250/Kconfig, arch/sparc/Kconfig from grepping for >> '/dev/tty0' on **/Kconfig). >> >> From Documentation/admin-guide/serial-console.rst: >> >>> You can specify multiple console= options on the kernel command line. >>> [...] >>> Note that you can only define one console per device type (serial, video). >>> >>> If no console device is specified, the first device found capable of >>> acting as a system console will be used. At this time, the system >>> first looks for a VGA card and then for a serial port. So if you don't >>> have a VGA card in your system the first serial port will automatically >>> become the console. >> >> and later on: >> >>> Note that if you boot without a ``console=`` option (or with >>> ``console=/dev/tty0``), ``/dev/console`` is the same as ``/dev/tty0``. >>> In that case everything will still work. > > I'm wondering if behaviour is changed if you put console=tty1 instead > of console=tty0. Just tested again with the QEMU aarch64 VM. Comparing console=tty1 and console=tty0 cases: /proc/consoles has tty1 instead of tty0 (both also has ttyAMA0), and `echo '/dev/console is here' >>/dev/console` goes to vt1 instead of the currently visible vt. Same difference before and after this patchset.
Re: [PATCH 5/5] arm/arm64: smccc: Add ARCH_SOC_ID support
On 30/04/2020 12:48, Sudeep Holla wrote:
SMCCC v1.2 adds a new optional function SMCCC_ARCH_SOC_ID to obtain a
SiP defined SoC identification value. Add support for the same.
Also using the SoC bus infrastructure, let us expose the platform
specific SoC atrributes under sysfs. We also provide custom sysfs for
the vendor ID as JEP-106 bank and identification code.
Signed-off-by: Sudeep Holla
---
drivers/firmware/psci/Makefile | 2 +-
drivers/firmware/psci/soc_id.c | 148 +
include/linux/arm-smccc.h | 5 ++
3 files changed, 154 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/psci/soc_id.c
diff --git a/drivers/firmware/psci/Makefile b/drivers/firmware/psci/Makefile
index 1956b882470f..c0b0c9ca57e4 100644
--- a/drivers/firmware/psci/Makefile
+++ b/drivers/firmware/psci/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
#
-obj-$(CONFIG_ARM_PSCI_FW) += psci.o
+obj-$(CONFIG_ARM_PSCI_FW) += psci.o soc_id.o
obj-$(CONFIG_ARM_PSCI_CHECKER)+= psci_checker.o
diff --git a/drivers/firmware/psci/soc_id.c b/drivers/firmware/psci/soc_id.c
new file mode 100644
index ..820f69dad7f5
--- /dev/null
+++ b/drivers/firmware/psci/soc_id.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Arm Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SOCID_JEP106_BANK_IDX_MASK GENMASK(30, 24)
+#define SOCID_JEP106_ID_CODE_MASK GENMASK(23, 16)
+#define SOCID_IMP_DEF_SOC_ID_MASK GENMASK(15, 0)
+#define JEP106_BANK_IDX(x) (u8)(FIELD_GET(SOCID_JEP106_BANK_IDX_MASK, (x)))
+#define JEP106_ID_CODE(x) (u8)(FIELD_GET(SOCID_JEP106_ID_CODE_MASK, (x)))
+#define IMP_DEF_SOC_ID(x) (u16)(FIELD_GET(SOCID_IMP_DEF_SOC_ID_MASK, (x)))
+
+static int soc_id_version;
+static struct soc_device *soc_dev;
+static struct soc_device_attribute *soc_dev_attr;
+
+static int smccc_map_error_codes(unsigned long a0)
+{
+ if (a0 == SMCCC_RET_INVALID_PARAMETER)
+ return -EINVAL;
+ if (a0 == SMCCC_RET_NOT_SUPPORTED)
+ return -EOPNOTSUPP;
+ return 0;
It seems odd to special case just those errors. While they are the only
errors we expect, any result with the high bit set is an error (arguably
a bug in the firmware) so should really cause an error return.
+}
+
+static int smccc_soc_id_support_check(void)
+{
+ struct arm_smccc_res res;
+
+ if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE) {
+ pr_err("%s: invalid SMCCC conduit\n", __func__);
+ return -EOPNOTSUPP;
+ }
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
+ARM_SMCCC_ARCH_SOC_ID, &res);
+
+ return smccc_map_error_codes(res.a0);
+}
+
+static ssize_t
+jep106_cont_bank_code_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ return sprintf(buf, "%02x\n", JEP106_BANK_IDX(soc_id_version) + 1);
+}
+
+static DEVICE_ATTR_RO(jep106_cont_bank_code);
+
+static ssize_t
+jep106_identification_code_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%02x\n", JEP106_ID_CODE(soc_id_version) & 0x7F);
It seems odd to have the mask defined to include a bit that is then
always masked off. From the spec I presume this is a parity bit, but it
would be good to have a comment explaining this.
+}
+
+static DEVICE_ATTR_RO(jep106_identification_code);
+
+static struct attribute *jep106_id_attrs[] = {
+ &dev_attr_jep106_cont_bank_code.attr,
+ &dev_attr_jep106_identification_code.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(jep106_id);
+
+static int __init smccc_soc_init(void)
+{
+ struct device *dev;
+ int ret, soc_id_rev;
+ struct arm_smccc_res res;
+ static char soc_id_str[8], soc_id_rev_str[12];
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
+ return 0;
NIT: Do we actually need to check the version here - or would probing
ARM_SMCCC_ARCH_FEATURES_FUNC_ID as is done below sufficient? I'm not
aware of this relying on any new semantics that v1.2 added.
+
+ ret = smccc_soc_id_support_check();
+ if (ret)
+ return ret;
This seems odd - if the version is >=1.2 but doesn't support SOC_ID then it's an error return?
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
+
+ ret = smccc_map_error_codes(res.a0);
+ if (ret)
+ return ret;
+
+ soc_id_version = res.a0;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
+
+ ret = smccc_map_error_codes(res.a0);
+ if (ret)
+ return ret;
+
+ soc_id_rev = res.a0;
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ sprintf(soc_id_str, "0x%04x",
[PATCH 2/3] fsi: occ: Add support for P10
The P10 OCC has a different SRAM address for the command and response
buffers. In addition, the SBE commands to access the SRAM have changed
format. Add versioning to the driver to handle these differences.
Signed-off-by: Eddie James
---
drivers/fsi/fsi-occ.c | 126 ++
1 file changed, 92 insertions(+), 34 deletions(-)
diff --git a/drivers/fsi/fsi-occ.c b/drivers/fsi/fsi-occ.c
index 7da9c81759ac..942eff4032b0 100644
--- a/drivers/fsi/fsi-occ.c
+++ b/drivers/fsi/fsi-occ.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,13 @@
#define OCC_CMD_DATA_BYTES 4090
#define OCC_RESP_DATA_BYTES4089
-#define OCC_SRAM_CMD_ADDR 0xFFFBE000
-#define OCC_SRAM_RSP_ADDR 0xFFFBF000
+#define OCC_P9_SRAM_CMD_ADDR 0xFFFBE000
+#define OCC_P9_SRAM_RSP_ADDR 0xFFFBF000
+
+#define OCC_P10_SRAM_CMD_ADDR 0xD000
+#define OCC_P10_SRAM_RSP_ADDR 0xE000
+
+#define OCC_P10_SRAM_MODE 0x58/* Normal mode, OCB channel 2 */
/*
* Assume we don't have much FFDC, if we do we'll overflow and
@@ -37,11 +43,14 @@
#define OCC_TIMEOUT_MS 1000
#define OCC_CMD_IN_PRG_WAIT_MS 50
+enum versions { occ_p9, occ_p10 };
+
struct occ {
struct device *dev;
struct device *sbefifo;
char name[32];
int idx;
+ enum versions version;
struct miscdevice mdev;
struct mutex occ_lock;
};
@@ -235,29 +244,43 @@ static int occ_verify_checksum(struct occ_response *resp,
u16 data_length)
return 0;
}
-static int occ_getsram(struct occ *occ, u32 address, void *data, ssize_t len)
+static int occ_getsram(struct occ *occ, u32 offset, void *data, ssize_t len)
{
u32 data_len = ((len + 7) / 8) * 8; /* must be multiples of 8 B */
- size_t resp_len, resp_data_len;
- __be32 *resp, cmd[5];
- int rc;
+ size_t cmd_len, resp_len, resp_data_len;
+ __be32 *resp, cmd[6];
+ int idx = 0, rc;
/*
* Magic sequence to do SBE getsram command. SBE will fetch data from
* specified SRAM address.
*/
- cmd[0] = cpu_to_be32(0x5);
+ switch (occ->version) {
+ default:
+ case occ_p9:
+ cmd_len = 5;
+ cmd[2] = cpu_to_be32(1);/* Normal mode */
+ cmd[3] = cpu_to_be32(OCC_P9_SRAM_RSP_ADDR + offset);
+ break;
+ case occ_p10:
+ idx = 1;
+ cmd_len = 6;
+ cmd[2] = cpu_to_be32(OCC_P10_SRAM_MODE);
+ cmd[3] = 0;
+ cmd[4] = cpu_to_be32(OCC_P10_SRAM_RSP_ADDR + offset);
+ break;
+ }
+
+ cmd[0] = cpu_to_be32(cmd_len);
cmd[1] = cpu_to_be32(SBEFIFO_CMD_GET_OCC_SRAM);
- cmd[2] = cpu_to_be32(1);
- cmd[3] = cpu_to_be32(address);
- cmd[4] = cpu_to_be32(data_len);
+ cmd[4 + idx] = cpu_to_be32(data_len);
resp_len = (data_len >> 2) + OCC_SBE_STATUS_WORDS;
resp = kzalloc(resp_len << 2, GFP_KERNEL);
if (!resp)
return -ENOMEM;
- rc = sbefifo_submit(occ->sbefifo, cmd, 5, resp, &resp_len);
+ rc = sbefifo_submit(occ->sbefifo, cmd, cmd_len, resp, &resp_len);
if (rc)
goto free;
@@ -287,20 +310,21 @@ static int occ_getsram(struct occ *occ, u32 address, void
*data, ssize_t len)
return rc;
}
-static int occ_putsram(struct occ *occ, u32 address, const void *data,
- ssize_t len)
+static int occ_putsram(struct occ *occ, const void *data, ssize_t len)
{
size_t cmd_len, buf_len, resp_len, resp_data_len;
u32 data_len = ((len + 7) / 8) * 8; /* must be multiples of 8 B */
__be32 *buf;
- int rc;
+ int idx = 0, rc;
+
+ cmd_len = (occ->version == occ_p10) ? 6 : 5;
/*
* We use the same buffer for command and response, make
* sure it's big enough
*/
resp_len = OCC_SBE_STATUS_WORDS;
- cmd_len = (data_len >> 2) + 5;
+ cmd_len += data_len >> 2;
buf_len = max(cmd_len, resp_len);
buf = kzalloc(buf_len << 2, GFP_KERNEL);
if (!buf)
@@ -312,11 +336,23 @@ static int occ_putsram(struct occ *occ, u32 address,
const void *data,
*/
buf[0] = cpu_to_be32(cmd_len);
buf[1] = cpu_to_be32(SBEFIFO_CMD_PUT_OCC_SRAM);
- buf[2] = cpu_to_be32(1);
- buf[3] = cpu_to_be32(address);
- buf[4] = cpu_to_be32(data_len);
- memcpy(&buf[5], data, len);
+ switch (occ->version) {
+ default:
+ case occ_p9:
+ buf[2] = cpu_to_be32(1);/* Normal mode */
+ buf[3] = cpu_to_be32(OCC_P9_SRAM_CMD_ADDR);
+ break;
+ case occ_p10:
+ idx = 1;
+ buf[2] = cpu_to_be32(OCC_P10_SRAM_MODE);
+ buf[3] = 0;
+ buf[4] = cpu_to_be32(OCC_P10_SRAM_CMD_ADDR);
+ brea
[PATCH 1/3] dt-bindings: fsi: Add P10 OCC device documentation
Add the P10 compatible string. Signed-off-by: Eddie James --- Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt index 99ca9862a586..e73358075a90 100644 --- a/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt +++ b/Documentation/devicetree/bindings/fsi/ibm,p9-occ.txt @@ -1,13 +1,13 @@ -Device-tree bindings for FSI-attached POWER9 On-Chip Controller (OCC) -- +Device-tree bindings for FSI-attached POWER9/POWER10 On-Chip Controller (OCC) +- -This is the binding for the P9 On-Chip Controller accessed over FSI from a -service processor. See fsi.txt for details on bindings for FSI slave and CFAM +This is the binding for the P9 or P10 On-Chip Controller accessed over FSI from +a service processor. See fsi.txt for details on bindings for FSI slave and CFAM nodes. The OCC is not an FSI slave device itself, rather it is accessed -through the SBE fifo. +through the SBE FIFO. Required properties: - - compatible = "ibm,p9-occ" + - compatible = "ibm,p9-occ" or "ibm,p10-occ" Examples: -- 2.24.0
[PATCH 3/3] hwmon: (occ) Add new temperature sensor type
The latest version of the On-Chip Controller (OCC) has a different
format for the temperature sensor data. Add a new temperature sensor
version to handle this data.
Signed-off-by: Eddie James
---
drivers/hwmon/occ/common.c | 75 ++
1 file changed, 75 insertions(+)
diff --git a/drivers/hwmon/occ/common.c b/drivers/hwmon/occ/common.c
index 30e18eb60da7..52af0e728232 100644
--- a/drivers/hwmon/occ/common.c
+++ b/drivers/hwmon/occ/common.c
@@ -41,6 +41,14 @@ struct temp_sensor_2 {
u8 value;
} __packed;
+struct temp_sensor_10 {
+ u32 sensor_id;
+ u8 fru_type;
+ u8 value;
+ u8 throttle;
+ u8 reserved;
+} __packed;
+
struct freq_sensor_1 {
u16 sensor_id;
u16 value;
@@ -307,6 +315,60 @@ static ssize_t occ_show_temp_2(struct device *dev,
return snprintf(buf, PAGE_SIZE - 1, "%u\n", val);
}
+static ssize_t occ_show_temp_10(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int rc;
+ u32 val = 0;
+ struct temp_sensor_10 *temp;
+ struct occ *occ = dev_get_drvdata(dev);
+ struct occ_sensors *sensors = &occ->sensors;
+ struct sensor_device_attribute_2 *sattr = to_sensor_dev_attr_2(attr);
+
+ rc = occ_update_response(occ);
+ if (rc)
+ return rc;
+
+ temp = ((struct temp_sensor_10 *)sensors->temp.data) + sattr->index;
+
+ switch (sattr->nr) {
+ case 0:
+ val = get_unaligned_be32(&temp->sensor_id);
+ break;
+ case 1:
+ val = temp->value;
+ if (val == OCC_TEMP_SENSOR_FAULT)
+ return -EREMOTEIO;
+
+ /*
+* VRM doesn't return temperature, only alarm bit. This
+* attribute maps to tempX_alarm instead of tempX_input for
+* VRM
+*/
+ if (temp->fru_type != OCC_FRU_TYPE_VRM) {
+ /* sensor not ready */
+ if (val == 0)
+ return -EAGAIN;
+
+ val *= 1000;
+ }
+ break;
+ case 2:
+ val = temp->fru_type;
+ break;
+ case 3:
+ val = temp->value == OCC_TEMP_SENSOR_FAULT;
+ break;
+ case 4:
+ val = temp->throttle * 1000;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return snprintf(buf, PAGE_SIZE - 1, "%u\n", val);
+}
+
static ssize_t occ_show_freq_1(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -745,6 +807,10 @@ static int occ_setup_sensor_attrs(struct occ *occ)
num_attrs += (sensors->temp.num_sensors * 4);
show_temp = occ_show_temp_2;
break;
+ case 0x10:
+ num_attrs += (sensors->temp.num_sensors * 5);
+ show_temp = occ_show_temp_10;
+ break;
default:
sensors->temp.num_sensors = 0;
}
@@ -844,6 +910,15 @@ static int occ_setup_sensor_attrs(struct occ *occ)
attr->sensor = OCC_INIT_ATTR(attr->name, 0444,
show_temp, NULL, 3, i);
attr++;
+
+ if (sensors->temp.version == 0x10) {
+ snprintf(attr->name, sizeof(attr->name),
+"temp%d_max", s);
+ attr->sensor = OCC_INIT_ATTR(attr->name, 0444,
+show_temp, NULL,
+4, i);
+ attr++;
+ }
}
}
--
2.24.0
[PATCH 0/3] occ: Add support for P10
The OCC in the P10 has a number of differences from the P9. Add some logic to handle the differences in accessing the OCC from the service processor, and support the new temperature sensor type. Eddie James (3): dt-bindings: fsi: Add P10 OCC device documentation fsi: occ: Add support for P10 hwmon: (occ) Add new temperature sensor type .../devicetree/bindings/fsi/ibm,p9-occ.txt| 12 +- drivers/fsi/fsi-occ.c | 126 +- drivers/hwmon/occ/common.c| 75 +++ 3 files changed, 173 insertions(+), 40 deletions(-) -- 2.24.0
Re: [PATCH 0/4] Add support for constant power-supply property tables
Hi, On Mon, Apr 13, 2020 at 08:38:49PM +0200, Sebastian Reichel wrote: > This marks the properties and usb_types entries in > struct power_supply_desc as const, so that drivers > can constify those tables. > > Sebastian Reichel (4): > power: supply: core: Constify usb_types > power: supply: charger-manager: Prepare for const properties > power: supply: generic-adc-battery: Prepare for const properties > power: supply: core: Constify properties > > drivers/power/supply/charger-manager.c | 40 -- > drivers/power/supply/generic-adc-battery.c | 22 ++-- > drivers/power/supply/power_supply_sysfs.c | 2 +- > include/linux/power_supply.h | 4 +-- > 4 files changed, 36 insertions(+), 32 deletions(-) I merged the charger-manager and generic-adc-battery patches with Enric's RB, but took over Michał Mirosław's variant for the other bits. -- Sebastian signature.asc Description: PGP signature
Greetings to you
Greetings to you, I hope that this letter finds you in the best of health and spirit. My name is Rose Gordan, Please I kindly request for your attention, I have a very important business to discuss with you privately and in a much matured manner but i will give the details upon receipt of your response, Thank you in advance! Yours sincerely, Rose.
Re: [PATCH] pinctrl: qcom: Add affinity callbacks to msmgpio IRQ chip
Hi,
On Thu, Apr 30, 2020 at 11:31 PM Maulik Shah wrote:
>
> From: Venkata Narendra Kumar Gutta
>
> Wakeup capable GPIO IRQs routed via PDC are not being migrated when a CPU
> is hotplugged. Add affinity callbacks to msmgpio IRQ chip to update the
> affinity of wakeup capable IRQs.
>
> Fixes: e35a6ae0eb3a ("pinctrl/msm: Setup GPIO chip in hierarchy")
> Signed-off-by: Venkata Narendra Kumar Gutta
> [mkshah: updated commit text and minor code fixes]
> Signed-off-by: Maulik Shah
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 25 +
> 1 file changed, 25 insertions(+)
Tested-by: Douglas Anderson
Re: [PATCH v2 4/4] PCI: cadence: Fix to read 32-bit Vendor ID/Device ID property from DT
On Fri, Apr 17, 2020 at 05:13:22PM +0530, Kishon Vijay Abraham I wrote:
> The PCI Bus Binding specification (IEEE Std 1275-1994 Revision 2.1 [1])
> defines both Vendor ID and Device ID to be 32-bits. Fix
> pcie-cadence-host.c driver to read 32-bit Vendor ID and Device ID
> properties from device tree.
>
> [1] -> https://www.devicetree.org/open-firmware/bindings/pci/pci2_1.pdf
>
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/pci/controller/cadence/pcie-cadence-host.c | 4 ++--
> drivers/pci/controller/cadence/pcie-cadence.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
I don't see how you would use a 32-bit value for a 16-bit register so
certainly the struct cdns_pcie_rc fields size is questionable anyway.
I *assume* you are referring to 4.1.2.1 and the property list
encoded as "encode-int".
I would like to get RobH's opinion on this - I don't know myself
whether the PCI OF bindings you added are still relevant and how
they should be interpreted.
Thanks
Lorenzo
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c
> b/drivers/pci/controller/cadence/pcie-cadence-host.c
> index 8f72967f298f..31e67c9c88cf 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-host.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
> @@ -229,10 +229,10 @@ int cdns_pcie_host_setup(struct cdns_pcie_rc *rc)
> }
>
> rc->vendor_id = 0x;
> - of_property_read_u16(np, "vendor-id", &rc->vendor_id);
> + of_property_read_u32(np, "vendor-id", &rc->vendor_id);
>
> rc->device_id = 0x;
> - of_property_read_u16(np, "device-id", &rc->device_id);
> + of_property_read_u32(np, "device-id", &rc->device_id);
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "reg");
> pcie->reg_base = devm_ioremap_resource(dev, res);
> diff --git a/drivers/pci/controller/cadence/pcie-cadence.h
> b/drivers/pci/controller/cadence/pcie-cadence.h
> index 6bd89a21bb1c..df14ad002fe9 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence.h
> +++ b/drivers/pci/controller/cadence/pcie-cadence.h
> @@ -262,8 +262,8 @@ struct cdns_pcie_rc {
> struct resource *bus_range;
> void __iomem*cfg_base;
> u32 no_bar_nbits;
> - u16 vendor_id;
> - u16 device_id;
> + u32 vendor_id;
> + u32 device_id;
> };
>
> /**
> --
> 2.17.1
>
[PATCH v4 2/4] power: supply: core: add input voltage/current measurements
Introduce input voltage and current limits and measurements.
This makes room for e.g. VBUS measurements in USB chargers.
Signed-off-by: Michał Mirosław
---
v2: add parameter checking in power_supply_hwmon_read_string()
v3: remove power_supply_hwmon_read_string() parameter checks
as it is internal API (suggested by Guenter Roeck)
---
drivers/power/supply/power_supply_hwmon.c | 97 +--
drivers/power/supply/power_supply_sysfs.c | 2 +
include/linux/power_supply.h | 2 +
3 files changed, 96 insertions(+), 5 deletions(-)
diff --git a/drivers/power/supply/power_supply_hwmon.c
b/drivers/power/supply/power_supply_hwmon.c
index f5d538485aaa..3863b2a73ecf 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -13,12 +13,17 @@ struct power_supply_hwmon {
unsigned long *props;
};
+static const char *const ps_input_label[] = {
+ "battery",
+ "external source",
+};
+
static const char *const ps_temp_label[] = {
"temp",
"ambient temp",
};
-static int power_supply_hwmon_in_to_property(u32 attr)
+static int power_supply_hwmon_in0_to_property(u32 attr)
{
switch (attr) {
case hwmon_in_average:
@@ -34,7 +39,31 @@ static int power_supply_hwmon_in_to_property(u32 attr)
}
}
-static int power_supply_hwmon_curr_to_property(u32 attr)
+static int power_supply_hwmon_in1_to_property(u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_max:
+ return POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT;
+ case hwmon_in_input:
+ return POWER_SUPPLY_PROP_INPUT_VOLTAGE_NOW;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int power_supply_hwmon_in_to_property(u32 attr, int channel)
+{
+ switch (channel) {
+ case 0:
+ return power_supply_hwmon_in0_to_property(attr);
+ case 1:
+ return power_supply_hwmon_in1_to_property(attr);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int power_supply_hwmon_curr0_to_property(u32 attr)
{
switch (attr) {
case hwmon_curr_average:
@@ -48,6 +77,30 @@ static int power_supply_hwmon_curr_to_property(u32 attr)
}
}
+static int power_supply_hwmon_curr1_to_property(u32 attr)
+{
+ switch (attr) {
+ case hwmon_curr_max:
+ return POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT;
+ case hwmon_curr_input:
+ return POWER_SUPPLY_PROP_INPUT_CURRENT_NOW;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int power_supply_hwmon_curr_to_property(u32 attr, int channel)
+{
+ switch (channel) {
+ case 0:
+ return power_supply_hwmon_curr0_to_property(attr);
+ case 1:
+ return power_supply_hwmon_curr1_to_property(attr);
+ default:
+ return -EINVAL;
+ }
+}
+
static int power_supply_hwmon_temp_to_property(u32 attr, int channel)
{
if (channel) {
@@ -87,9 +140,9 @@ power_supply_hwmon_to_property(enum hwmon_sensor_types type,
{
switch (type) {
case hwmon_in:
- return power_supply_hwmon_in_to_property(attr);
+ return power_supply_hwmon_in_to_property(attr, channel);
case hwmon_curr:
- return power_supply_hwmon_curr_to_property(attr);
+ return power_supply_hwmon_curr_to_property(attr, channel);
case hwmon_temp:
return power_supply_hwmon_temp_to_property(attr, channel);
default:
@@ -100,7 +153,9 @@ power_supply_hwmon_to_property(enum hwmon_sensor_types type,
static bool power_supply_hwmon_is_a_label(enum hwmon_sensor_types type,
u32 attr)
{
- return type == hwmon_temp && attr == hwmon_temp_label;
+ return (type == hwmon_temp && attr == hwmon_temp_label) ||
+ (type == hwmon_in && attr == hwmon_in_label) ||
+ (type == hwmon_curr && attr == hwmon_curr_label);
}
struct hwmon_type_attr_list {
@@ -114,7 +169,19 @@ static const u32 ps_temp_attrs[] = {
hwmon_temp_min_alarm, hwmon_temp_max_alarm,
};
+static const u32 ps_in_attrs[] = {
+ hwmon_in_input, hwmon_in_average,
+ hwmon_in_min, hwmon_in_max,
+};
+
+static const u32 ps_curr_attrs[] = {
+ hwmon_curr_input, hwmon_curr_average,
+ hwmon_curr_max,
+};
+
static const struct hwmon_type_attr_list ps_type_attrs[hwmon_max] = {
+ [hwmon_in] = { ps_in_attrs, ARRAY_SIZE(ps_in_attrs) },
+ [hwmon_curr] = { ps_curr_attrs, ARRAY_SIZE(ps_curr_attrs) },
[hwmon_temp] = { ps_temp_attrs, ARRAY_SIZE(ps_temp_attrs) },
};
@@ -186,6 +253,11 @@ static int power_supply_hwmon_read_string(struct device
*dev,
const char **str)
{
switch (type) {
+ case hwmon_in:
+ case hwmon_curr:
+ *str = ps_input_label[channel];
+ break;
+
ca
[PATCH v4 4/4] power: supply: core: document measurement points
Document used prefixes for input/output/storage voltages and currents. Signed-off-by: Michał Mirosław --- Documentation/power/power_supply_class.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/power/power_supply_class.rst b/Documentation/power/power_supply_class.rst index 7b8c42f8b1de..c41b25aaa755 100644 --- a/Documentation/power/power_supply_class.rst +++ b/Documentation/power/power_supply_class.rst @@ -28,6 +28,12 @@ indication (including whether to use it at all) are fully controllable by user and/or specific machine defaults, per design principles of LED framework). +There are three defined points of measurement for the benefit of mobile and +UPS-like power supplies: INPUT (external power source), OUTPUT (power output +from the module), and unmarked (power flowing to/from a storage element, +eg. battery). Battery is viewed as a power source, so current flowing to +the battery (charging it) is shown negative. + Attributes/properties ~ -- 2.20.1
[PATCH v4 1/4] power: supply: core: tabularize HWMON temperature labels
Rework power_supply_hwmon_read_string() to check it's parameters.
This allows to extend it later with labels for other types of
measurements.
Signed-off-by: Michał Mirosław
---
v2: split from fix temperature labels
v3: remove power_supply_hwmon_read_string() parameter checks
as it is internal API (suggested by Guenter Roeck)
v4: remove unreachable() as it triggers compiler bugs
---
drivers/power/supply/power_supply_hwmon.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/power/supply/power_supply_hwmon.c
b/drivers/power/supply/power_supply_hwmon.c
index af72e5693f65..f5d538485aaa 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -13,6 +13,11 @@ struct power_supply_hwmon {
unsigned long *props;
};
+static const char *const ps_temp_label[] = {
+ "temp",
+ "ambient temp",
+};
+
static int power_supply_hwmon_in_to_property(u32 attr)
{
switch (attr) {
@@ -180,7 +185,20 @@ static int power_supply_hwmon_read_string(struct device
*dev,
u32 attr, int channel,
const char **str)
{
- *str = channel ? "temp ambient" : "temp";
+ switch (type) {
+ case hwmon_temp:
+ *str = ps_temp_label[channel];
+ break;
+ default:
+ /* unreachable, but see:
+* gcc bug #51513 [1] and clang bug #978 [2]
+*
+* [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51513
+* [2] https://github.com/ClangBuiltLinux/linux/issues/978
+*/
+ break;
+ }
+
return 0;
}
--
2.20.1
[PATCH v4 3/4] power: supply: core: add output voltage measurements
Add support for supply output voltage to be measured and configured.
This might be different from the voltage on the storage element (battery).
Signed-off-by: Michał Mirosław
---
drivers/power/supply/power_supply_hwmon.c | 25 +++
drivers/power/supply/power_supply_sysfs.c | 3 +++
include/linux/power_supply.h | 3 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/power/supply/power_supply_hwmon.c
b/drivers/power/supply/power_supply_hwmon.c
index 3863b2a73ecf..626a344fbad1 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -16,6 +16,7 @@ struct power_supply_hwmon {
static const char *const ps_input_label[] = {
"battery",
"external source",
+ "load",
};
static const char *const ps_temp_label[] = {
@@ -51,6 +52,20 @@ static int power_supply_hwmon_in1_to_property(u32 attr)
}
}
+static int power_supply_hwmon_in2_to_property(u32 attr)
+{
+ switch (attr) {
+ case hwmon_in_min:
+ return POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MIN;
+ case hwmon_in_max:
+ return POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MAX;
+ case hwmon_in_input:
+ return POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_NOW;
+ default:
+ return -EINVAL;
+ }
+}
+
static int power_supply_hwmon_in_to_property(u32 attr, int channel)
{
switch (channel) {
@@ -58,6 +73,8 @@ static int power_supply_hwmon_in_to_property(u32 attr, int
channel)
return power_supply_hwmon_in0_to_property(attr);
case 1:
return power_supply_hwmon_in1_to_property(attr);
+ case 2:
+ return power_supply_hwmon_in2_to_property(attr);
default:
return -EINVAL;
}
@@ -399,6 +416,11 @@ static const struct hwmon_channel_info
*power_supply_hwmon_info[] = {
HWMON_I_LABEL |
HWMON_I_MAX |
+ HWMON_I_INPUT,
+
+ HWMON_I_LABEL |
+ HWMON_I_MIN |
+ HWMON_I_MAX |
HWMON_I_INPUT),
NULL
@@ -469,6 +491,9 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
case POWER_SUPPLY_PROP_INPUT_VOLTAGE_NOW:
case POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT:
+ case POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MIN:
+ case POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MAX:
+ case POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_NOW:
set_bit(prop, psyhw->props);
break;
default:
diff --git a/drivers/power/supply/power_supply_sysfs.c
b/drivers/power/supply/power_supply_sysfs.c
index 1d1fb69516a8..fb6f113b52bb 100644
--- a/drivers/power/supply/power_supply_sysfs.c
+++ b/drivers/power/supply/power_supply_sysfs.c
@@ -278,6 +278,9 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(input_voltage_now),
POWER_SUPPLY_ATTR(input_voltage_limit),
POWER_SUPPLY_ATTR(input_power_limit),
+ POWER_SUPPLY_ATTR(output_voltage_now),
+ POWER_SUPPLY_ATTR(output_voltage_min),
+ POWER_SUPPLY_ATTR(output_voltage_max),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index 5313d1284aad..f1ff8d230488 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -132,6 +132,9 @@ enum power_supply_property {
POWER_SUPPLY_PROP_INPUT_VOLTAGE_NOW,
POWER_SUPPLY_PROP_INPUT_VOLTAGE_LIMIT,
POWER_SUPPLY_PROP_INPUT_POWER_LIMIT,
+ POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MIN,
+ POWER_SUPPLY_PROP_OUTPUT_VOLTAGE_MAX,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
--
2.20.1
[PATCH v4 0/4] power: supply: core: extend with new properties
This series extend power supply class core with additional properties for measurements of power supply input and output power. v4 is a rebase on top of recently applied first part of v3, including patch 1 workaround for gcc and clang bugs. Michał Mirosław (4): power: supply: core: tabularize HWMON temperature labels power: supply: core: add input voltage/current measurements power: supply: core: add output voltage measurements power: supply: core: document measurement points Documentation/power/power_supply_class.rst | 6 + drivers/power/supply/power_supply_hwmon.c | 142 - drivers/power/supply/power_supply_sysfs.c | 5 + include/linux/power_supply.h | 5 + 4 files changed, 152 insertions(+), 6 deletions(-) -- 2.20.1
Re: [RFC][PATCH] x86/ftrace: Have ftrace trampolines turn read-only at the end of system boot up
On Fri, May 01, 2020 at 09:24:04AM -0400, Steven Rostedt wrote: > On Fri, 1 May 2020 00:17:06 -0500 > Josh Poimboeuf wrote: > > > > Would it be easier to just call a new __text_poke_bp() which skips the > > > SYSTEM_BOOTING check, since you know the trampoline will always be > > > read-only? > > > > > > Like: > > > > early_trace_init() is called after mm_init(), so I thought it might > > work, but I guess not: > > Yeah, I was about to say that this happens before mm_init() ;-) It happens *after* mm_init(). But now text_poke() has a dependency on poking_init(), has a dependency on proc_caches_init(), which has a dependency on kmem_cache_init_late(), etc. So how early do you need early_trace_init()? I'm assuming moving it to after kmem_cache_init_late() would be too late. > It's why we already have magic for enabling function tracing the first time. > > Do you see anything wrong with this current solution? It probably needs > more comments, but I wanted to get acceptance on the logic before I go and > pretty it up and send a non RFC patch. Assuming we can't get text_poke() working earlier, it seems reasonable to me. -- Josh
Re: [PATCH 4.4 00/70] 4.4.221-rc1 review
On 01/05/2020 14:20, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.221 release. > There are 70 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.221-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.4: 6 builds: 6 pass, 0 fail 12 boots: 12 pass, 0 fail 19 tests: 19 pass, 0 fail Linux version: 4.4.221-rc1-gbe0a2ec77b53 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH] arm64: perf_event: Fix time_offset for arch timer
Hi all, On Thu, Apr 30, 2020 at 05:18:15PM +0100, Will Deacon wrote: > On Thu, Apr 30, 2020 at 06:04:36PM +0200, Peter Zijlstra wrote: > > On Thu, Apr 30, 2020 at 04:29:23PM +0100, Marc Zyngier wrote: > > > > > I wonder if we could/should make __sched_clock_offset available even when > > > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK isn't defined. It feels like it would > > > help with this particular can or worm... > > > > Errrgh. __sched_clock_offset is only needed on x86 because we transition > > from one clock device to another on boot. It really shouldn't exist on > > anything sane. > > I think we still transition from jiffies on arm64, because we don't register > with sched_clock until the timer driver probes. Marc, is that right? > > > Let me try and understand your particular problem better. > > I think the long and short of it is that userspace needs a way to convert > the raw counter cycles into a ns value that can be compared against values > coming out of sched_clock. To do this accurately, I think it needs the > cycles value at the point when sched_clock was initialised. Will's understanding is exactly what I want to resolve in this patch. The background info is for the ARM SPE [1] decoding with perf tool, if the timestamp is enabled, it uses the generic timer's counter as timestamp source. SPE trace data only contains the raw counter cycles, as Will mentioned, the perf tool needs to convert it to a coordinate value with sched_clock. This is why this patch tries to calculate the offset between the raw counter's ns value and sched_clock, eventually this offset value will be used by SPE's decoding code in Perf tool to calibrate a 'correct' timestamp. Based on your suggestions, I will use __sched_clock_offset to resolve the accuracy issue in patch v2. (I noticed Peter suggested to use a new API for wrapping clock_data structure, IIUC, __sched_clock_offset is more straightforward for this case). Please correct if I miss anything. Thank you for reviewing and suggestions! Thanks, Leo [1] https://lkml.org/lkml/2020/1/23/571
Re: [PATCH v4 5/5] media: platform: Add jpeg dec/enc feature
Hi Xia,
Finally found time to take a look again. Really sorry for the late
reply.
On Wed, Apr 22, 2020 at 03:00:07PM +0800, Xia Jiang wrote:
> On Tue, 2020-03-10 at 13:17 +0900, Tomasz Figa wrote:
> > Hi Xia,
> >
> > On Fri, Dec 6, 2019 at 6:59 PM Xia Jiang wrote:
> > >
> > > On Wed, 2019-10-23 at 18:39 +0800, Tomasz Figa wrote:
> > > > Hi Xia,
> > > >
> > > > On Thu, Oct 17, 2019 at 04:40:38PM +0800, Xia Jiang wrote:
> > > > > Add mtk jpeg encode v4l2 driver based on jpeg decode, because that
> > > > > jpeg
> > > > > decode and encode have great similarities with function operation.
> > > > >
> > > > > Signed-off-by: Xia Jiang
> > > > > ---
> > > > > v4: split mtk_jpeg_try_fmt_mplane() to two functions, one for encoder,
> > > > > one for decoder.
> > > > > split mtk_jpeg_set_default_params() to two functions, one for
> > > > > encoder, one for decoder.
> > > > > add cropping support for encoder in g/s_selection ioctls.
> > > > > change exif mode support by using V4L2_JPEG_ACTIVE_MARKER_APP1.
> > > > > change MTK_JPEG_MAX_WIDTH/MTK_JPEG_MAX_HEIGH from 8192 to 65535 by
> > > > > specification.
> > > > > move width shifting operation behind aligning operation in
> > > > > mtk_jpeg_try_enc_fmt_mplane() for bug fix.
> > > > > fix user abuseing data_offset issue for DMABUF in
> > > > > mtk_jpeg_set_enc_src().
> > > > > fix kbuild warings: change MTK_JPEG_MIN_HEIGHT/MTK_JPEG_MAX_HEIGHT
> > > > > and MTK_JPEG_MIN_WIDTH/MTK_JPEG_MAX_WIDTH from
> > > > > 'int' type to 'unsigned int' type.
> > > > > fix msleadingly indented of 'else'.
> > > > >
> > > > > v3: delete Change-Id.
> > > > > only test once handler->error after the last v4l2_ctrl_new_std().
> > > > > seperate changes of v4l2-ctrls.c and v4l2-controls.h to new patch.
> > > > >
> > > > > v2: fix compliance test fail, check created buffer size in driver.
> > > > > ---
> > > > > drivers/media/platform/mtk-jpeg/Makefile | 5 +-
> > > > > .../media/platform/mtk-jpeg/mtk_jpeg_core.c | 731
> > > > > +++---
> > > > > .../media/platform/mtk-jpeg/mtk_jpeg_core.h | 123 ++-
> > > > > .../media/platform/mtk-jpeg/mtk_jpeg_dec_hw.h | 7 +-
> > > > > .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c | 175 +
> > > > > .../media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h | 60 ++
> > > > > .../platform/mtk-jpeg/mtk_jpeg_enc_reg.h | 49 ++
> > > > > 7 files changed, 1004 insertions(+), 146 deletions(-)
> > > > > create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.c
> > > > > create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_hw.h
> > > > > create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_enc_reg.h
> > > > >
> > > >
> > > > First of all, thanks for the patch!
> > > >
> > > > Please check my comments below.
> > > >
> > > > My general feeling about this code is that the encoder hardware block is
> > > > completely orthogonal from the decoder block and there is very little
> > > > code
> > > > reuse from the original decoder driver.
> > > >
> > > > Moreover, a lot of existing code now needs if (decoder) { ... } else
> > > > {... }
> > > > segments, which complicates the code.
> > > >
> > > > Would it perhaps make sense to instead create a separate mtk-jpeg-enc
> > > > driver?
> > > >
> > > > It would also give us a fresh start in terms of code quality, as the
> > > > existing mtk-jpeg driver has a lot of quality issues unfortunately.
> > > > (Some
> > > > of my comments to this patch actually relate to the issues with the
> > > > original code, not introduced by this patch, but we need to fix them if
> > > > changing this driver already.)
> > > >
> > > Dear Tomasz,
> > >
> > > I haved fixed the driver by following your advice in general.
> > >
> > > Please check my reply below.
> >
> > Sorry, I missed this message originally. Replied below.
>
> Dear Tomasz,
>
> Thank you for your reply.I have changed the driver in the V8 version
> by following your good advice.
> >
> > [snip]
> > > > > + }
> > > > > + param->enc_w = q_data_src->w;
> > > > > + param->enc_h = q_data_src->h;
> > > > > +
> > > > > + if (jpeg_params->enc_quality >= 97)
> > > > > + param->enc_quality = JPEG_ENCODE_QUALITY_Q97;
> > > > > + else if (jpeg_params->enc_quality >= 95)
> > > > > + param->enc_quality = JPEG_ENCODE_QUALITY_Q95;
> > > >
> > > > I'm wondering if the application requests 96, it doesn't expect the
> > > > quality to
> > > > be _at_least_ 96.
> > > our jpeg enc hw do not support quality 96,only support 15 kinds of quant
> > > table listed here, so if the application requests 96,a nearest and
> > > highest quality will be given.
> > > >
> >
> > Just to clarify my comment, if I remember correctly, the JPEG standard
> > defines the 100 levels, so if the application requests level 96, but
> > the hardware provides only 95 and 97, the quality should be favored
> >
Re: [PATCH 4.9 00/80] 4.9.221-rc1 review
On 01/05/2020 14:20, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.221 release. > There are 80 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.221-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 24 tests: 24 pass, 0 fail Linux version: 4.9.221-rc1-gc0dc655ddaa6 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 4.14 000/117] 4.14.178-rc1 review
On 01/05/2020 14:20, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.178 release. > There are 117 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.178-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.14: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 24 tests: 24 pass, 0 fail Linux version: 4.14.178-rc1-gb24d32661fe1 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 4.19 00/46] 4.19.120-rc1 review
On 01/05/2020 14:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.120 release. > There are 46 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.120-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v4.19: 11 builds: 11 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 fail Linux version: 4.19.120-rc1-g81d4e31e1418 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 5.6 000/106] 5.6.9-rc1 review
On 01/05/2020 14:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.6.9 release. > There are 106 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.9-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.6.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v5.6: 13 builds: 13 pass, 0 fail 24 boots: 24 pass, 0 fail 40 tests: 40 pass, 0 fail Linux version: 5.6.9-rc1-g96c73ff08986 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH 5.4 00/83] 5.4.37-rc1 review
On 01/05/2020 14:22, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.4.37 release. > There are 83 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sun, 03 May 2020 13:12:02 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.37-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.4.y > and the diffstat can be found below. > > thanks, > > greg k-h All tests are passing for Tegra ... Test results for stable-v5.4: 13 builds: 13 pass, 0 fail 24 boots: 24 pass, 0 fail 40 tests: 40 pass, 0 fail Linux version: 5.4.37-rc1-gbecd7d89321d Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-, tegra30-cardhu-a04 Cheers Jon -- nvpublic
Re: [PATCH v2] perf: cs-etm: Update to build with latest opencsd version.
On Fri, May 01, 2020 at 03:36:15PM +0100, Mike Leach wrote: > OpenCSD version v0.14.0 adds in a new output element. This is represented > by a new value in the generic element type enum, which must be added to > the handling code in perf cs-etm-decoder to prevent build errors due to > build options on the perf project. > > This element is not currently used by the perf decoder. > > Perf build feature test updated to require a minimum of 0.14.0 > > Tested on Linux 5.7-rc3. > > Signed-off-by: Mike Leach Looks good to me, FWIW: Reviewed-by: Leo Yan > --- > tools/build/feature/test-libopencsd.c | 4 ++-- > tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 2 ++ > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/tools/build/feature/test-libopencsd.c > b/tools/build/feature/test-libopencsd.c > index 2b0e02c38870..1547bc2c0950 100644 > --- a/tools/build/feature/test-libopencsd.c > +++ b/tools/build/feature/test-libopencsd.c > @@ -4,9 +4,9 @@ > /* > * Check OpenCSD library version is sufficient to provide required features > */ > -#define OCSD_MIN_VER ((0 << 16) | (11 << 8) | (0)) > +#define OCSD_MIN_VER ((0 << 16) | (14 << 8) | (0)) > #if !defined(OCSD_VER_NUM) || (OCSD_VER_NUM < OCSD_MIN_VER) > -#error "OpenCSD >= 0.11.0 is required" > +#error "OpenCSD >= 0.14.0 is required" > #endif > > int main(void) > diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c > b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c > index cd92a99eb89d..cd007cc9c283 100644 > --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c > +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c > @@ -564,6 +564,8 @@ static ocsd_datapath_resp_t > cs_etm_decoder__gen_trace_elem_printer( > resp = cs_etm_decoder__set_tid(etmq, packet_queue, > elem, trace_chan_id); > break; > + /* Unused packet types */ > + case OCSD_GEN_TRC_ELEM_I_RANGE_NOPATH: > case OCSD_GEN_TRC_ELEM_ADDR_NACC: > case OCSD_GEN_TRC_ELEM_CYCLE_COUNT: > case OCSD_GEN_TRC_ELEM_ADDR_UNKNOWN: > -- > 2.17.1 > > ___ > CoreSight mailing list > coresi...@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/coresight
[PATCH v4 1/7] drm/bridge: ps8640: Get the EDID from eDP control
The PS8640 DSI-to-eDP bridge can retrieve the EDID, so implement the
.get_edid callback and set the flag to indicate the core to use it.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
Acked-by: Sam Ravnborg
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/parade-ps8640.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
b/drivers/gpu/drm/bridge/parade-ps8640.c
index 4b099196afeb..13755d278db6 100644
--- a/drivers/gpu/drm/bridge/parade-ps8640.c
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -242,8 +242,18 @@ static int ps8640_bridge_attach(struct drm_bridge *bridge,
return ret;
}
+static struct edid *ps8640_bridge_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
+
+ return drm_get_edid(connector,
+ ps_bridge->page[PAGE0_DP_CNTL]->adapter);
+}
+
static const struct drm_bridge_funcs ps8640_bridge_funcs = {
.attach = ps8640_bridge_attach,
+ .get_edid = ps8640_bridge_get_edid,
.post_disable = ps8640_post_disable,
.pre_enable = ps8640_pre_enable,
};
@@ -294,6 +304,8 @@ static int ps8640_probe(struct i2c_client *client)
ps_bridge->bridge.funcs = &ps8640_bridge_funcs;
ps_bridge->bridge.of_node = dev->of_node;
+ ps_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
+ ps_bridge->bridge.type = DRM_MODE_CONNECTOR_eDP;
ps_bridge->page[PAGE0_DP_CNTL] = client;
--
2.26.2
[PATCH v4 4/7] drm/mediatek: mtk_dsi: Convert to bridge driver
Convert mtk_dsi to a bridge driver with built-in encoder support for
compatibility with existing component drivers.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Sam Ravnborg
---
Changes in v4:
- Remove double call to drm_encoder_init(). (Chun-Kuang Hu)
- Cleanup the encoder in mtk_dsi_unbind(). (Chun-Kuang Hu)
Changes in v3:
- Add the bridge.type. (Laurent Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 108 +++--
1 file changed, 70 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 37b8d7ffd835..38cbdcb15fff 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -180,6 +180,7 @@ struct mtk_dsi {
struct device *dev;
struct mipi_dsi_host host;
struct drm_encoder encoder;
+ struct drm_bridge bridge;
struct drm_connector conn;
struct drm_panel *panel;
struct drm_bridge *next_bridge;
@@ -205,9 +206,9 @@ struct mtk_dsi {
const struct mtk_dsi_driver_data *driver_data;
};
-static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
+static inline struct mtk_dsi *bridge_to_dsi(struct drm_bridge *b)
{
- return container_of(e, struct mtk_dsi, encoder);
+ return container_of(b, struct mtk_dsi, bridge);
}
static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
@@ -796,32 +797,43 @@ static const struct drm_encoder_funcs
mtk_dsi_encoder_funcs = {
.destroy = mtk_dsi_encoder_destroy,
};
-static bool mtk_dsi_encoder_mode_fixup(struct drm_encoder *encoder,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode)
+static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
+static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
+
+static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
+enum drm_bridge_attach_flags flags)
{
- return true;
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ return mtk_dsi_create_conn_enc(bridge->dev, dsi);
+}
+
+static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
+{
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
+
+ mtk_dsi_destroy_conn_enc(dsi);
}
-static void mtk_dsi_encoder_mode_set(struct drm_encoder *encoder,
-struct drm_display_mode *mode,
-struct drm_display_mode *adjusted)
+static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
+ const struct drm_display_mode *mode,
+ const struct drm_display_mode *adjusted)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
drm_display_mode_to_videomode(adjusted, &dsi->vm);
}
-static void mtk_dsi_encoder_disable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_disable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_disable(dsi);
}
-static void mtk_dsi_encoder_enable(struct drm_encoder *encoder)
+static void mtk_dsi_bridge_enable(struct drm_bridge *bridge)
{
- struct mtk_dsi *dsi = encoder_to_dsi(encoder);
+ struct mtk_dsi *dsi = bridge_to_dsi(bridge);
mtk_output_dsi_enable(dsi);
}
@@ -833,11 +845,12 @@ static int mtk_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel, connector);
}
-static const struct drm_encoder_helper_funcs mtk_dsi_encoder_helper_funcs = {
- .mode_fixup = mtk_dsi_encoder_mode_fixup,
- .mode_set = mtk_dsi_encoder_mode_set,
- .disable = mtk_dsi_encoder_disable,
- .enable = mtk_dsi_encoder_enable,
+static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
+ .attach = mtk_dsi_bridge_attach,
+ .detach = mtk_dsi_bridge_detach,
+ .disable = mtk_dsi_bridge_disable,
+ .enable = mtk_dsi_bridge_enable,
+ .mode_set = mtk_dsi_bridge_mode_set,
};
static const struct drm_connector_funcs mtk_dsi_connector_funcs = {
@@ -888,20 +901,6 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
- if (ret) {
- DRM_ERROR("Failed to encoder init to drm\n");
- return ret;
- }
- drm_encoder_helper_add(&dsi->encoder, &mtk_dsi_encoder_helper_funcs);
-
- /*
-* Currently display data paths are statically assigned to a crtc each.
-* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
-*/
- dsi->encoder.possible_crtcs = 1;
-
/* I
[PATCH v4 0/7] Convert mtk-dsi to drm_bridge API and get EDID for ps8640 bridge
The PS8640 dsi-to-eDP bridge driver is using the panel bridge API, however, not all the components in the chain have been ported to the drm_bridge API. Actually, when a panel is attached the default panel's mode is used, but in some cases we can't get display up if mode getting from eDP control EDID is not chosen. This series address that problem, first implements the .get_edid() callback in the PS8640 driver (which is not used until the conversion is done) and then, converts the Mediatek DSI driver to use the drm_bridge API. As far as I know, we're the only users of the mediatek dsi driver in mainline, so should be safe to switch to the new chain of drm_bridge API unconditionally. The patches has been tested on a Acer Chromebook R13 (Elm) running a Chrome OS userspace and checking that the valid EDID mode reported by the bridge is selected. Enric Balletbo i Serra (7): drm/bridge: ps8640: Get the EDID from eDP control drm/bridge_connector: Set default status connected for eDP connectors drm/mediatek: mtk_dsi: Rename bridge to next_bridge drm/mediatek: mtk_dsi: Convert to bridge driver drm/mediatek: mtk_dsi: Use simple encoder drm/mediatek: mtk_dsi: Use the drm_panel_bridge API drm/mediatek: mtk_dsi: Create connector for bridges drivers/gpu/drm/bridge/parade-ps8640.c | 12 ++ drivers/gpu/drm/drm_bridge_connector.c | 1 + drivers/gpu/drm/mediatek/mtk_dsi.c | 277 - 3 files changed, 97 insertions(+), 193 deletions(-) -- 2.26.2
[PATCH v4 5/7] drm/mediatek: mtk_dsi: Use simple encoder
The mtk_dsi driver uses an empty implementation for its encoder. Replace
the code with the generic simple encoder.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
Acked-by: Sam Ravnborg
Reviewed-by: Chun-Kuang Hu
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 38cbdcb15fff..e02d16a086ac 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include "mtk_drm_ddp_comp.h"
@@ -788,15 +789,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
dsi->enabled = false;
}
-static void mtk_dsi_encoder_destroy(struct drm_encoder *encoder)
-{
- drm_encoder_cleanup(encoder);
-}
-
-static const struct drm_encoder_funcs mtk_dsi_encoder_funcs = {
- .destroy = mtk_dsi_encoder_destroy,
-};
-
static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
@@ -1126,8 +1118,8 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
{
int ret;
- ret = drm_encoder_init(drm, &dsi->encoder, &mtk_dsi_encoder_funcs,
- DRM_MODE_ENCODER_DSI, NULL);
+ ret = drm_simple_encoder_init(drm, &dsi->encoder,
+ DRM_MODE_ENCODER_DSI);
if (ret) {
DRM_ERROR("Failed to encoder init to drm\n");
return ret;
--
2.26.2
[PATCH v4 3/7] drm/mediatek: mtk_dsi: Rename bridge to next_bridge
This is really a cosmetic change just to make a bit more readable the
code after convert the driver to drm_bridge. The bridge variable name
will be used by the encoder drm_bridge, and the chained bridge will be
named next_bridge.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
Acked-by: Sam Ravnborg
---
Changes in v4: None
Changes in v3:
- Replace s/bridge/next bridge/ for comment. (Laurent Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index cfa45d6abd74..37b8d7ffd835 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,7 +182,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_connector conn;
struct drm_panel *panel;
- struct drm_bridge *bridge;
+ struct drm_bridge *next_bridge;
struct phy *phy;
void __iomem *regs;
@@ -902,9 +902,10 @@ static int mtk_dsi_create_conn_enc(struct drm_device *drm,
struct mtk_dsi *dsi)
*/
dsi->encoder.possible_crtcs = 1;
- /* If there's a bridge, attach to it and let it create the connector */
- if (dsi->bridge) {
- ret = drm_bridge_attach(&dsi->encoder, dsi->bridge, NULL, 0);
+ /* If there's a next bridge, attach to it and let it create the
connector */
+ if (dsi->next_bridge) {
+ ret = drm_bridge_attach(&dsi->encoder, dsi->next_bridge, NULL,
+ 0);
if (ret) {
DRM_ERROR("Failed to attach bridge to drm\n");
goto err_encoder_cleanup;
@@ -1185,7 +1186,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
}
ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
- &dsi->panel, &dsi->bridge);
+ &dsi->panel, &dsi->next_bridge);
if (ret)
goto err_unregister_host;
--
2.26.2
[PATCH v4 2/7] drm/bridge_connector: Set default status connected for eDP connectors
In an eDP application, HPD is not required and on most bridge chips useless. If HPD is not used, we need to set initial status as connected, otherwise the connector created by the drm_bridge_connector API remains in an unknown state. Signed-off-by: Enric Balletbo i Serra Reviewed-by: Laurent Pinchart Acked-by: Sam Ravnborg --- Changes in v4: None Changes in v3: None Changes in v2: None drivers/gpu/drm/drm_bridge_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c index c6994fe673f3..a58cbde59c34 100644 --- a/drivers/gpu/drm/drm_bridge_connector.c +++ b/drivers/gpu/drm/drm_bridge_connector.c @@ -187,6 +187,7 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force) case DRM_MODE_CONNECTOR_DPI: case DRM_MODE_CONNECTOR_LVDS: case DRM_MODE_CONNECTOR_DSI: + case DRM_MODE_CONNECTOR_eDP: status = connector_status_connected; break; default: -- 2.26.2
Re: [PATCH v3 4/6] blktrace: fix debugfs use after free
On Wed, Apr 29, 2020 at 02:57:26PM +0200, Greg KH wrote: > On Wed, Apr 29, 2020 at 12:21:52PM +, Luis Chamberlain wrote: > > On Wed, Apr 29, 2020 at 05:04:06AM -0700, Christoph Hellwig wrote: > > > On Wed, Apr 29, 2020 at 12:02:30PM +, Luis Chamberlain wrote: > > > > > Err, that function is static and has two callers. > > > > > > > > Yes but that is to make it easier to look for who is creating the > > > > debugfs_dir for either the request_queue or partition. I'll export > > > > blk_debugfs_root and we'll open code all this. > > > > > > No, please not. exported variables are usually a bad idea. Just > > > skip the somewhat pointless trivial static function. > > > > Alrighty. It has me thinking we might want to only export those symbols > > to a specific namespace. Thoughts, preferences? > > > > BLOCK_GENHD_PRIVATE ? > > That's a nice add-on issue after this is fixed. As Christoph and I > pointed out, you have _less_ code in the file if you remove the static > wrapper function. Do that now and then worry about symbol namespaces > please. So it turns out that in the old implementation, it was implicit that the request_queue directory was shared with the scsi drive. So, the q->debugfs_dir *will* be set, and as we have it here', we'd silently be overwriting the old q->debugfs_dir, as the queue is the same. To keep things working as it used to, with both, we just need to use a symlink here. With the old way, we'd *always* create the sg directory and re-use that, however since we can only have one blktrace per request_queue, it still had the same restriction, this was just implicit. Using a symlink will make this much more obvious and upkeep the old functionality. We'll need to only export one symbol. I'll roll this in. Luis
[PATCH v4 6/7] drm/mediatek: mtk_dsi: Use the drm_panel_bridge API
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Enric Balletbo i Serra
Reviewed-by: Laurent Pinchart
Acked-by: Sam Ravnborg
Reviewed-by: Chun-Kuang Hu
---
Changes in v4: None
Changes in v3:
- Use next_bridge field to store the panel bridge. (Laurent Pinchart)
- Add the bridge.type field. (Laurent Pinchart)
- This patch requires https://lkml.org/lkml/2020/4/16/2080 to work
properly.
Changes in v2:
- Do not set connector_type for panel here. (Sam Ravnborg)
drivers/gpu/drm/mediatek/mtk_dsi.c | 173 +++--
1 file changed, 14 insertions(+), 159 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index e02d16a086ac..4f3bd095c1ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -182,8 +182,6 @@ struct mtk_dsi {
struct mipi_dsi_host host;
struct drm_encoder encoder;
struct drm_bridge bridge;
- struct drm_connector conn;
- struct drm_panel *panel;
struct drm_bridge *next_bridge;
struct phy *phy;
@@ -212,11 +210,6 @@ static inline struct mtk_dsi *bridge_to_dsi(struct
drm_bridge *b)
return container_of(b, struct mtk_dsi, bridge);
}
-static inline struct mtk_dsi *connector_to_dsi(struct drm_connector *c)
-{
- return container_of(c, struct mtk_dsi, conn);
-}
-
static inline struct mtk_dsi *host_to_dsi(struct mipi_dsi_host *h)
{
return container_of(h, struct mtk_dsi, host);
@@ -682,16 +675,7 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_lane0_ulp_mode_leave(dsi);
mtk_dsi_clk_hs_mode(dsi, 0);
- if (dsi->panel) {
- if (drm_panel_prepare(dsi->panel)) {
- DRM_ERROR("failed to prepare the panel\n");
- goto err_disable_digital_clk;
- }
- }
-
return 0;
-err_disable_digital_clk:
- clk_disable_unprepare(dsi->digital_clk);
err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);
err_phy_power_off:
@@ -718,15 +702,7 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
*/
mtk_dsi_stop(dsi);
- if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
- if (dsi->panel) {
- if (drm_panel_unprepare(dsi->panel)) {
- DRM_ERROR("failed to unprepare the panel\n");
- return;
- }
- }
- }
-
+ mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500);
mtk_dsi_reset_engine(dsi);
mtk_dsi_lane0_ulp_mode_enter(dsi);
mtk_dsi_clk_ulp_mode_enter(dsi);
@@ -757,19 +733,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
mtk_dsi_start(dsi);
- if (dsi->panel) {
- if (drm_panel_enable(dsi->panel)) {
- DRM_ERROR("failed to enable the panel\n");
- goto err_dsi_power_off;
- }
- }
-
dsi->enabled = true;
-
- return;
-err_dsi_power_off:
- mtk_dsi_stop(dsi);
- mtk_dsi_poweroff(dsi);
}
static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
@@ -777,34 +741,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
if (!dsi->enabled)
return;
- if (dsi->panel) {
- if (drm_panel_disable(dsi->panel)) {
- DRM_ERROR("failed to disable the panel\n");
- return;
- }
- }
-
mtk_dsi_poweroff(dsi);
dsi->enabled = false;
}
-static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi
*dsi);
-static void mtk_dsi_destroy_conn_enc(struct mtk_dsi *dsi);
-
static int mtk_dsi_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
struct mtk_dsi *dsi = bridge_to_dsi(bridge);
- return mtk_dsi_create_conn_enc(bridge->dev, dsi);
-}
-
-static void mtk_dsi_bridge_detach(struct drm_bridge *bridge)
-{
- struct mtk_dsi *dsi = bridge_to_dsi(bridge);
-
- mtk_dsi_destroy_conn_enc(dsi);
+ /* Attach the panel or bridge to the dsi bridge */
+ return drm_bridge_attach(bridge->encoder, dsi->next_bridge,
+&dsi->bridge, flags);
}
static void mtk_dsi_bridge_mode_set(struct drm_bridge *bridge,
@@ -830,101 +779,13 @@ static void mtk_dsi_bridge_enable(struct drm_bridge
*bridge)
mtk_output_dsi_enable(dsi);
}
-static int mtk_dsi_connector_get_modes(struct drm_connector *connector)
-{
- struct mtk_dsi *dsi = connector_to_dsi(connector);
-
- return drm_panel_get_modes(dsi->panel, connector);
-}
-
static const struct drm_bridge_funcs mtk_dsi_bridge_funcs = {
Re: [PATCH 1/4] fs: Implement close-on-fork
On Fri, May 01, 2020 at 02:45:16PM +, Karstens, Nate wrote: > Others -- I will respond to feedback outside of implementation details in a > separate message. FWIW, I'm opposed to the entire feature. Improving the implementation will not change that.
[PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Signed-off-by: Enric Balletbo i Serra
Acked-by: Sam Ravnborg
---
Changes in v4: None
Changes in v3:
- Move the bridge.type line to the patch that adds drm_bridge support. (Laurent
Pinchart)
Changes in v2: None
drivers/gpu/drm/mediatek/mtk_dsi.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 4f3bd095c1ee..471fcafdf348 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -183,6 +184,7 @@ struct mtk_dsi {
struct drm_encoder encoder;
struct drm_bridge bridge;
struct drm_bridge *next_bridge;
+ struct drm_connector *connector;
struct phy *phy;
void __iomem *regs;
@@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm,
struct mtk_dsi *dsi)
*/
dsi->encoder.possible_crtcs = 1;
- ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0);
+ ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
if (ret)
goto err_cleanup_encoder;
+ dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
+ if (IS_ERR(dsi->connector)) {
+ DRM_ERROR("Unable to create bridge connector\n");
+ ret = PTR_ERR(dsi->connector);
+ goto err_cleanup_encoder;
+ }
+ drm_connector_attach_encoder(dsi->connector, &dsi->encoder);
+
return 0;
err_cleanup_encoder:
--
2.26.2
Re: [PATCH 4/4 v2] firmware: stratix10-svc: Slightly simplify code
Hi, On 4/29/20 1:52 AM, Christophe JAILLET wrote: Replace 'devm_kmalloc_array(... | __GFP_ZERO)' with the equivalent and shorter 'devm_kcalloc(...)'. It doesn't make much sense. Actually devm_kcalloc returns devm_kmalloc_array(.., flag | __GFP_ZERO). 'ctrl->genpool' can not be NULL, so axe a useless test in the remove function. Signed-off-by: Christophe JAILLET --- drivers/firmware/stratix10-svc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/firmware/stratix10-svc.c b/drivers/firmware/stratix10-svc.c index 739004398877..c228337cb0a1 100644 --- a/drivers/firmware/stratix10-svc.c +++ b/drivers/firmware/stratix10-svc.c @@ -1002,8 +1002,7 @@ static int stratix10_svc_drv_probe(struct platform_device *pdev) if (!controller) return -ENOMEM; - chans = devm_kmalloc_array(dev, SVC_NUM_CHANNEL, - sizeof(*chans), GFP_KERNEL | __GFP_ZERO); + chans = devm_kcalloc(dev, SVC_NUM_CHANNEL, sizeof(*chans), GFP_KERNEL); if (!chans) return -ENOMEM; @@ -1086,8 +1085,7 @@ static int stratix10_svc_drv_remove(struct platform_device *pdev) kthread_stop(ctrl->task); ctrl->task = NULL; } - if (ctrl->genpool) - gen_pool_destroy(ctrl->genpool); + gen_pool_destroy(ctrl->genpool); list_del(&ctrl->node); return 0; Regards, Richard
Re: [PATCH] PCI: dwc: Fix inner MSI IRQ domain registration
On 5/1/20, 7:39 AM, Marc Zyngier wrote: > On a system that uses the internal DWC MSI widget, I get this > warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: > > debugfs: File ':soc:pcie@fc00' in directory 'domains' already present! > > This is due to the fact that the DWC MSI code tries to register two > IRQ domains for the same firmware node, without telling the low > level code how to distinguish them (by setting a bus token). This > further confuses debugfs which tries to create corresponding > files for each domain. > > Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is > the closest thing we have as to "generic MSI". > > Signed-off-by: Marc Zyngier Acked-by: Jingoo Han > --- > drivers/pci/controller/dwc/pcie-designware-host.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c > b/drivers/pci/controller/dwc/pcie-designware-host.c > index 395feb8ca051..3c43311bb95c 100644 > --- a/drivers/pci/controller/dwc/pcie-designware-host.c > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c > @@ -264,6 +264,8 @@ int dw_pcie_allocate_domains(struct pcie_port *pp) > return -ENOMEM; > } > > + irq_domain_update_bus_token(pp->irq_domain, DOMAIN_BUS_NEXUS); > + > pp->msi_domain = pci_msi_create_irq_domain(fwnode, > &dw_pcie_msi_domain_info, > pp->irq_domain); > -- > 2.26.2
Re: [PATCH 5/5] arm/arm64: smccc: Add ARCH_SOC_ID support
On 30/04/2020 12:48, Sudeep Holla wrote:
+static int __init smccc_soc_init(void)
+{
+ struct device *dev;
+ int ret, soc_id_rev;
+ struct arm_smccc_res res;
+ static char soc_id_str[8], soc_id_rev_str[12];
+
+ if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2)
+ return 0;
+
+ ret = smccc_soc_id_support_check();
+ if (ret)
+ return ret;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, &res);
+
+ ret = smccc_map_error_codes(res.a0);
+ if (ret)
+ return ret;
+
+ soc_id_version = res.a0;
+
+ arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, &res);
+
+ ret = smccc_map_error_codes(res.a0);
+ if (ret)
+ return ret;
+
+ soc_id_rev = res.a0;
+
+ soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
+ if (!soc_dev_attr)
+ return -ENOMEM;
+
+ sprintf(soc_id_str, "0x%04x", IMP_DEF_SOC_ID(soc_id_version));
+ sprintf(soc_id_rev_str, "0x%08x", soc_id_rev);
+
+ soc_dev_attr->soc_id = soc_id_str;
+ soc_dev_attr->revision = soc_id_rev_str;
+
+ soc_dev = soc_device_register(soc_dev_attr);
+ if (IS_ERR(soc_dev)) {
+ ret = PTR_ERR(soc_dev);
+ goto free_soc;
+ }
+
+ dev = soc_device_to_device(soc_dev);
+
Just wondering, what about if the platform already had a SoC driver -
now it could have another one, such that we may have multiple sysfs soc
devices, right?
Thanks,
John
+ ret = devm_device_add_groups(dev, jep106_id_groups);
+ if (ret) {
+ dev_err(dev, "sysfs create failed: %d\n", ret);
+ goto unregister_soc;
+ }
+
+ pr_info("SMCCC SoC ID: %s Revision %s\n", soc_dev_attr->soc_id,
+ soc_dev_attr->revision);
+
+ return 0;
Re: [PATCH] arm64: perf_event: Fix time_offset for arch timer
On Fri, May 01, 2020 at 11:14:48PM +0800, Leo Yan wrote: > On Thu, Apr 30, 2020 at 05:18:15PM +0100, Will Deacon wrote: > > On Thu, Apr 30, 2020 at 06:04:36PM +0200, Peter Zijlstra wrote: > > > On Thu, Apr 30, 2020 at 04:29:23PM +0100, Marc Zyngier wrote: > > > > > > > I wonder if we could/should make __sched_clock_offset available even > > > > when > > > > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK isn't defined. It feels like it would > > > > help with this particular can or worm... > > > > > > Errrgh. __sched_clock_offset is only needed on x86 because we transition > > > from one clock device to another on boot. It really shouldn't exist on > > > anything sane. > > > > I think we still transition from jiffies on arm64, because we don't register > > with sched_clock until the timer driver probes. Marc, is that right? > > > > > Let me try and understand your particular problem better. > > > > I think the long and short of it is that userspace needs a way to convert > > the raw counter cycles into a ns value that can be compared against values > > coming out of sched_clock. To do this accurately, I think it needs the > > cycles value at the point when sched_clock was initialised. > > Will's understanding is exactly what I want to resolve in this patch. > > The background info is for the ARM SPE [1] decoding with perf tool, if > the timestamp is enabled, it uses the generic timer's counter as > timestamp source. SPE trace data only contains the raw counter cycles, > as Will mentioned, the perf tool needs to convert it to a coordinate > value with sched_clock. This is why this patch tries to calculate the > offset between the raw counter's ns value and sched_clock, eventually > this offset value will be used by SPE's decoding code in Perf tool to > calibrate a 'correct' timestamp. > > Based on your suggestions, I will use __sched_clock_offset to resolve > the accuracy issue in patch v2. (I noticed Peter suggested to use a > new API for wrapping clock_data structure, IIUC, __sched_clock_offset > is more straightforward for this case). > > Please correct if I miss anything. Thank you for reviewing and > suggestions! I don't think you can use __sched_clock_offset without selecting HAVE_UNSTABLE_SCHED_CLOCK, and we really don't want to do that just for this. So Peter's idea about exposing what we need is better, although you'll probably need to take care with the switch-over from jiffies. It needs some thought, but one possibility would be to introduce a new variant of sthe ched_clock_register() function that returns the cycle offset, and then we could fish that out of the timer driver. If we're crossing all the 'i's and dotting all the 't's then we'd want to disable the perf userpage if sched_clock changes clocksource too (a bit like we do for the vDSO). Will
Re: [PATCH RFC v2 01/11] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
On Wed, Apr 29, 2020 at 10:16:34PM +0200, Martin Blumenstingl wrote: > The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX > delay. Add a property with the known supported values so it can be > configured according to the board layout. > > Signed-off-by: Martin Blumenstingl Reviewed-by: Andrew Lunn Andrew
Re: [PATCH RFC v2 02/11] dt-bindings: net: dwmac-meson: Document the "timing-adjustment" clock
On Wed, Apr 29, 2020 at 10:16:35PM +0200, Martin Blumenstingl wrote: > The PRG_ETHERNET registers can add an RX delay in RGMII mode. This > requires an internal re-timing circuit whose input clock is called > "timing adjustment clock". Document this clock input so the clock can be > enabled as needed. > > Signed-off-by: Martin Blumenstingl Reviewed-by: Andrew Lunn Andrew
Re: [PATCH RFC v2 03/11] net: stmmac: dwmac-meson8b: use FIELD_PREP instead of open-coding it
On Wed, Apr 29, 2020 at 10:16:36PM +0200, Martin Blumenstingl wrote: > Use FIELD_PREP() to shift a value to the correct offset based on a > bitmask instead of open-coding the logic. > No functional changes. > > Signed-off-by: Martin Blumenstingl Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 2/2] lib kallsyms: parse using io api
On Fri, May 1, 2020 at 5:23 AM Jiri Olsa wrote:
>
> On Thu, Apr 30, 2020 at 12:35:57PM -0700, Ian Rogers wrote:
> > Perf record will call kallsyms__parse 4 times during startup and process
> > megabytes of data. This changes kallsyms__parse to use the io library
> > rather than fgets to improve performance of the user code by over 8%.
> >
> > Before:
> > Running 'internals/kallsyms-parse' benchmark:
> > Average kallsyms__parse took: 103.988 ms (+- 0.203 ms)
> > After:
> > Running 'internals/kallsyms-parse' benchmark:
> > Average kallsyms__parse took: 95.571 ms (+- 0.006 ms)
> >
> > For a workload like:
> > $ perf record /bin/true
> > Run under 'perf record -e cycles:u -g' the time goes from:
> > Before
> > 30.10% 1.67% perf perf[.] kallsyms__parse
> > After
> > 25.55%20.04% perf perf[.] kallsyms__parse
> > So a little under 5% of the start-up time is removed. A lot of what
> > remains is on the kernel side, but caching kallsyms within perf would
> > at least impact memory footprint.
>
> with your change I'm getting following warnings:
>
> $ sudo ./perf record -a
> Couldn't record kernel reference relocation symbol
> Symbol resolution may be skewed if relocation was used (e.g. kexec).
> Check /proc/kallsyms permission or run as root.
I'll investigate, sorry in advance for sending this out too early.
> >
> > Signed-off-by: Ian Rogers
> > ---
> > tools/lib/api/io.h | 3 ++
> > tools/lib/symbol/kallsyms.c | 81 +++--
> > 2 files changed, 44 insertions(+), 40 deletions(-)
> >
> > diff --git a/tools/lib/api/io.h b/tools/lib/api/io.h
> > index b7e55b5f8a4a..777c20f6b604 100644
> > --- a/tools/lib/api/io.h
> > +++ b/tools/lib/api/io.h
> > @@ -7,6 +7,9 @@
> > #ifndef __API_IO__
> > #define __API_IO__
> >
> > +#include
> > +#include
>
> was this missing?
Yes, they were getting picked up by a transitive #include in
synthesize-events.c, but given the call to read and use of size_t are
here it makes sense for the #includes to be here.
Thanks,
Ian
> jirka
>
> > +
> > struct io {
> > /* File descriptor being read/ */
> > int fd;
>
> SNIP
>
