[RFC v5 5/6] usb: gadget: udc: core: Introduce check_config to verify USB configuration
Some UDCs may have constraints on how many high bandwidth endpoints it can
support in a certain configuration. This API allows for the composite
driver to pass down the total number of endpoints to the UDC so it can verify
it has the required resources to support the configuration.
Signed-off-by: Wesley Cheng
---
drivers/usb/gadget/udc/core.c | 9 +
include/linux/usb/gadget.h| 2 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index c33ad8a333ad..e006d69dff9b 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -1001,6 +1001,15 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
}
EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)
+{
+ if (!gadget->ops->check_config)
+ return 0;
+
+ return gadget->ops->check_config(gadget, ep_map);
+}
+EXPORT_SYMBOL_GPL(usb_gadget_check_config);
+
/* - */
static void usb_gadget_state_work(struct work_struct *work)
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 52ce1f6b8f83..791ae5b352a1 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -326,6 +326,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+ int (*check_config)(struct usb_gadget *gadget, unsigned long
ep_map);
};
/**
@@ -575,6 +576,7 @@ int usb_gadget_connect(struct usb_gadget *gadget);
int usb_gadget_disconnect(struct usb_gadget *gadget);
int usb_gadget_deactivate(struct usb_gadget *gadget);
int usb_gadget_activate(struct usb_gadget *gadget);
+int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map);
#else
static inline int usb_gadget_frame_number(struct usb_gadget *gadget)
{ return 0; }
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[RFC v5 3/6] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize
Re-introduce the comment for the tx-fifo-resize setting for the DWC3 controller. This allows for vendors to control if they require the TX FIFO resizing logic on their HW, as the default FIFO size configurations may already be sufficient. Signed-off-by: Wesley Cheng Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/dwc3.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index d03edf9d3935..fba14d084072 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -103,7 +103,7 @@ Optional properties: 1-16 (DWC_usb31 programming guide section 1.2.3) to enable periodic ESS TX threshold. - - tx-fifo-resize: determines if the FIFO *has* to be reallocated. + - tx-fifo-resize: determines if the FIFO *has* to be reallocated. - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0 register, undefined length INCR burst type enable and INCRx type. When just one value, which means INCRX burst mode enabled. When -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[RFC v5 2/6] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
Enable the flexible TX FIFO resize logic on SM8150. Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.
Signed-off-by: Wesley Cheng
---
arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 7a0c5b419ff0..169ac4c8e298 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -717,6 +717,7 @@ usb_1_dwc3: dwc3@a60 {
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+ tx-fifo-resize;
phys = <_1_hsphy>, <_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[RFC v5 0/6] Re-introduce TX FIFO resize for larger EP bursting
Changes in V5: - Added check_config() logic, which is used to communicate the number of EPs used in a particular configuration. Based on this, the DWC3 gadget driver has the ability to know the maximum number of eps utilized in all configs. This helps reduce unnecessary allocation to unused eps, and will catch fifo allocation issues at bind() time. - Fixed variable declaration to single line per variable, and reverse xmas. - Created a helper for fifo clearing, which is used by ep0.c Changes in V4: - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos() - Removed WARN_ON(1) in case we run out of fifo space Changes in V3: - Removed "Reviewed-by" tags - Renamed series back to RFC - Modified logic to ensure that fifo_size is reset if we pass the minimum threshold. Tested with binding multiple FDs requesting 6 FIFOs. Changes in V2: - Modified TXFIFO resizing logic to ensure that each EP is reserved a FIFO. - Removed dev_dbg() prints and fixed typos from patches - Added some more description on the dt-bindings commit message Currently, there is no functionality to allow for resizing the TXFIFOs, and relying on the HW default setting for the TXFIFO depth. In most cases, the HW default is probably sufficient, but for USB compositions that contain multiple functions that require EP bursting, the default settings might not be enough. Also to note, the current SW will assign an EP to a function driver w/o checking to see if the TXFIFO size for that particular EP is large enough. (this is a problem if there are multiple HW defined values for the TXFIFO size) It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3 is required for an EP that supports bursting. Otherwise, there may be frequent occurences of bursts ending. For high bandwidth functions, such as data tethering (protocols that support data aggregation), mass storage, and media transfer protocol (over FFS), the bMaxBurst value can be large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB throughput. (which can be associated to system access latency, etc...) It allows for a more consistent burst of traffic, w/o any interruptions, as data is readily available in the FIFO. With testing done using the mass storage function driver, the results show that with a larger TXFIFO depth, the bandwidth increased significantly. Test Parameters: - Platform: Qualcomm SM8150 - bMaxBurst = 6 - USB req size = 256kB - Num of USB reqs = 16 - USB Speed = Super-Speed - Function Driver: Mass Storage (w/ ramdisk) - Test Application: CrystalDiskMark Results: TXFIFO Depth = 3 max packets Test Case | Data Size | AVG tput (in MB/s) --- Sequential|1 GB x | Read |9 loops| 193.60 | | 195.86 | | 184.77 | | 193.60 --- TXFIFO Depth = 6 max packets Test Case | Data Size | AVG tput (in MB/s) --- Sequential|1 GB x | Read |9 loops| 287.35 | | 304.94 | | 289.64 | | 293.61 --- Wesley Cheng (6): usb: dwc3: Resize TX FIFOs to meet EP bursting requirements arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic dt-bindings: usb: dwc3: Add entry for tx-fifo-resize usb: gadget: configfs: Check USB configuration before adding usb: gadget: udc: core: Introduce check_config to verify USB configuration usb: dwc3: gadget: Ensure enough TXFIFO space for USB configuration .../devicetree/bindings/usb/dwc3.txt | 2 +- arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 + drivers/usb/dwc3/core.c | 2 + drivers/usb/dwc3/core.h | 7 + drivers/usb/dwc3/ep0.c| 2 + drivers/usb/dwc3/gadget.c | 194 ++ drivers/usb/gadget/configfs.c | 22 ++ drivers/usb/gadget/udc/core.c | 9 + include/linux/usb/gadget.h| 2 + 9 files changed, 240 insertions(+), 1 deletion(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
[RFC v5 1/6] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
Some devices have USB compositions which may require multiple endpoints
that support EP bursting. HW defined TX FIFO sizes may not always be
sufficient for these compositions. By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth. With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.
Ensure that one TX FIFO is reserved for every IN endpoint. This allows for
the FIFO logic to prevent running out of FIFO space.
Signed-off-by: Wesley Cheng
---
drivers/usb/dwc3/core.c | 2 +
drivers/usb/dwc3/core.h | 6 ++
drivers/usb/dwc3/ep0.c| 2 +
drivers/usb/dwc3/gadget.c | 159 ++
4 files changed, 169 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 422aea24afcd..cf7815ed3861 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1307,6 +1307,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
_max_burst_prd);
+ dwc->needs_fifo_resize = device_property_read_bool(dev,
+ "tx-fifo-resize");
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 2f04b3e42bf1..e85c1ec70cc3 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1214,6 +1214,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+ unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1246,6 +1247,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
u16 imod_interval;
+ int last_fifo_depth;
+ int num_ep_resized;
};
#define INCRX_BURST_MODE 0
@@ -1459,6 +1462,7 @@ int dwc3_gadget_set_link_state(struct dwc3 *dwc, enum
dwc3_link_state state);
int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned cmd,
struct dwc3_gadget_ep_cmd_params *params);
int dwc3_send_gadget_generic_command(struct dwc3 *dwc, unsigned cmd, u32
param);
+void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc);
#else
static inline int dwc3_gadget_init(struct dwc3 *dwc)
{ return 0; }
@@ -1478,6 +1482,8 @@ static inline int dwc3_send_gadget_ep_cmd(struct dwc3_ep
*dep, unsigned cmd,
static inline int dwc3_send_gadget_generic_command(struct dwc3 *dwc,
int cmd, u32 param)
{ return 0; }
+static inline void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
+{ }
#endif
#if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 456aa87e8778..3ea1e051a8f1 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -611,6 +611,8 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct
usb_ctrlrequest *ctrl)
return -EINVAL;
case USB_STATE_ADDRESS:
+ dwc3_gadget_clear_tx_fifos(dwc);
+
ret = dwc3_ep0_delegate_req(dwc, ctrl);
/* if the cfg matches and the cfg is non zero */
if (cfg && (!ret || (ret == USB_GADGET_DELAYED_STATUS))) {
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index df8d89d6bdc9..53e5220f9893 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -613,6 +613,161 @@ static int dwc3_gadget_set_ep_config(struct dwc3_ep *dep,
unsigned int action)
static void dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force,
bool interrupt);
+static int dwc3_gadget_calc_tx_fifo_size(struct dwc3 *dwc, int mult)
+{
+ int max_packet = 1024;
+ int fifo_size;
+ int mdwidth;
+
+ mdwidth = DWC3_MDWIDTH(dwc->hwparams.hwparams0);
+ /* MDWIDTH is represented in bits, we need it in bytes */
+ mdwidth >>= 3;
+
+ fifo_size = mult * ((max_packet + mdwidth) / mdwidth) + 1;
+ return fifo_size;
+}
+
+void dwc3_gadget_clear_tx_fifos(struct dwc3 *dwc)
+{
+ struct dwc3_ep *dep;
+ int fifo_depth;
+ int size;
+ int num;
+
+ if (!dwc->needs_fifo_resize)
+ return;
+
+ /* Read ep0IN related TXFIFO size */
+ dep = dwc->eps[1];
+ size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
+ if (DWC3_IP_IS(DWC31))
+ fifo_depth = DWC31_GTXFIFOSIZ_TXFDEP(size);
+ else
+ fifo_depth = DWC3_GTXFIFOSIZ_TXFDEP(size);
+
+ dwc->last_fifo_depth = fifo_depth;
+ /* Clear
RE: [RFC] sched/topology: NUMA topology limitations
> Subject: RE: [RFC] sched/topology: NUMA topology limitations
>
> > Subject: [RFC] sched/topology: NUMA topology limitations
> >
> > (For those of you who already got this one: sorry! I messed up LKML and
> > Vincent's addresses)
> >
> > Hi,
> >
> > Some of you may have noticed me struggling to plug some topology holes in
> > [1]. While digging in there I realized there are some non-obvious
> > limitations
> > wrt supported NUMA topologies; IMO if we don't feel like they should be
> > "fixed", they should at the very least be documented somewhere.
> >
> > I should get to ramble about this at this year's (v)LPC during the scheduler
> > µconf, but this isn't really trivial so I figured an email wouldn't hurt. I
> > tried to
> > package it into reasonable segments - this is still a pretty big wall of
> > text, so
> > use of coffee/tea/beer is recommended.
> >
> > Spoiler alert: I don't have solutions for these yet.
> >
> > Diameter issue
> > ==
> >
> > Definition
> > ++
> >
> > Each unique NUMA distance gets an index in
> sched_domains_numa_distance[],
> > and as the big wall of text atop topology.c::build_balance_mask() mentions
> > this can be seen as an array of hops. i.e. in the following table:
> >
> > 0 1
> > 0: 10 20
> > 1: 20 10
> >
> > sched_domains_numa_distance = { 10, 20 };
> >
> > distance 10 is 0 hops (i.e. identity distance), distance 20 is 1 hop. This
> > isn't
> > strictly speaking always true, as e.g. two consecutive distance values could
> > represent the same number of hops (with one path slightly "longer" than the
> > other), but it makes explaining that mess a bit easier.
> >
> > I'm using 'diameter' in the NoC meaning of the term, i.e. the longest
> > shortest
> > path between any two nodes, in # of hops.
> >
> > Diameter <= 2
> > +
> >
> > AFAIU, one of the issues I'm encountering in [1] is that the scheduler
> topology
> > code cannot cope with a NUMA diameter > 2. I've looked into what's already
> > out there, but haven't found any (x86) machine that violates this rule.
> > Below
> > are some examples.
> >
> > AMD Epyc
> >
> >
> > node 0 1 2 3 4 5 6 7
> > 0: 10 16 16 16 32 32 32 32
> > 1: 16 10 16 16 32 32 32 32
> > 2: 16 16 10 16 32 32 32 32
> > 3: 16 16 16 10 32 32 32 32
> > 4: 32 32 32 32 10 16 16 16
> > 5: 32 32 32 32 16 10 16 16
> > 6: 32 32 32 32 16 16 10 16
> > 7: 32 32 32 32 16 16 16 10
> >
> > Here, diameter=2
> >
> > Opteron 6174
> >
> >
> > This is the 4-node one, which looks like this:
> >
> > node 0 1 2 3
> > 0: 10 20 20 20
> > 1: 20 10 20 20
> > 2: 20 20 10 20
> > 3: 20 20 20 10
> >
> > 0 - 3
> > | \ / |
> > | X |
> > | / \ |
> > 1 - 2
> >
> > Clearly this is diameter=1
> >
> > AMD Bulldozer
> > -
> >
> > I'm using the topology described in decade of wasted cores [2]; I'm not
> > going
> > to bother reproducing the distance table, the topology looks like:
> >
> >___
> > /_ \
> > | / \|
> > 0 - 4 - 5 - 1
> > | \ / | \ / | \ / |
> > | X | X | X |
> > | / \ | / \ | / \ |
> > 6 - 2 - 3 - 7
> > | \__/|
> > \___/
> >
> > Which is diameter=2 (assuming equal edge weights)
> >
> > Diameter > 2
> >
> >
> > I haven't found other NUMA systems out there with a diameter > 2 other
> than
> > the one I'm rambling about in [1]. Nevertheless, I think there are some
> > theoretical setups that aren't too insane (at least less than [1]).
> >
> > One of them is a 6-node mesh, which is diameter=3 and would look like:
> >
> > 0 - 5
> > | |
> > 1 - 4
> > | |
> > 2 - 3
> >
> > A more convoluted one would be a 12-node "spidergon"; it's a ring with an
> > even number of nodes N, each node is connected to both of its neighbours
> and
> > there is an interlink between node X and node (X + N/2) % N. I won't pretend
> I
> > can draw it in ASCII, but that again gives us a diameter of 3.
> >
> > Case study w/ QEMU
> > ++
> >
> > Setup
> > -
> >
> > The topology I'll describe below is a simplified version of the one in [1],
> > as it
> is
> > the smallest reproducer of the issue. Morten has been calling this a
> > "segmented bus".
> >
> >1 - 0
> >|
> >|
> >|
> >2 - 3
> >
> > node 0 1 2 3
> > 0: 10 20 30 40
> > 1: 20 10 20 30
> > 2: 30 20 10 20
> > 3: 40 30 20 10
> >
> > Diameter here is 3. I can recreate this with the following qemu
> > incantation:
> >
> > $ qemu-system-aarch64 -kernel Image -initrd rootfs.cpio -append \
> > 'console=ttyAMA0 earlycon=pl011,0x900
> > root=/dev/vda debug earlyprintk=serial sched_debug' \
> > -smp cores=4
RE: [RFC] sched/topology: NUMA topology limitations
> Subject: [RFC] sched/topology: NUMA topology limitations
>
> (For those of you who already got this one: sorry! I messed up LKML and
> Vincent's addresses)
>
> Hi,
>
> Some of you may have noticed me struggling to plug some topology holes in
> [1]. While digging in there I realized there are some non-obvious limitations
> wrt supported NUMA topologies; IMO if we don't feel like they should be
> "fixed", they should at the very least be documented somewhere.
>
> I should get to ramble about this at this year's (v)LPC during the scheduler
> µconf, but this isn't really trivial so I figured an email wouldn't hurt. I
> tried to
> package it into reasonable segments - this is still a pretty big wall of
> text, so
> use of coffee/tea/beer is recommended.
>
> Spoiler alert: I don't have solutions for these yet.
>
> Diameter issue
> ==
>
> Definition
> ++
>
> Each unique NUMA distance gets an index in sched_domains_numa_distance[],
> and as the big wall of text atop topology.c::build_balance_mask() mentions
> this can be seen as an array of hops. i.e. in the following table:
>
> 0 1
> 0: 10 20
> 1: 20 10
>
> sched_domains_numa_distance = { 10, 20 };
>
> distance 10 is 0 hops (i.e. identity distance), distance 20 is 1 hop. This
> isn't
> strictly speaking always true, as e.g. two consecutive distance values could
> represent the same number of hops (with one path slightly "longer" than the
> other), but it makes explaining that mess a bit easier.
>
> I'm using 'diameter' in the NoC meaning of the term, i.e. the longest shortest
> path between any two nodes, in # of hops.
>
> Diameter <= 2
> +
>
> AFAIU, one of the issues I'm encountering in [1] is that the scheduler
> topology
> code cannot cope with a NUMA diameter > 2. I've looked into what's already
> out there, but haven't found any (x86) machine that violates this rule. Below
> are some examples.
>
> AMD Epyc
>
>
> node 0 1 2 3 4 5 6 7
> 0: 10 16 16 16 32 32 32 32
> 1: 16 10 16 16 32 32 32 32
> 2: 16 16 10 16 32 32 32 32
> 3: 16 16 16 10 32 32 32 32
> 4: 32 32 32 32 10 16 16 16
> 5: 32 32 32 32 16 10 16 16
> 6: 32 32 32 32 16 16 10 16
> 7: 32 32 32 32 16 16 16 10
>
> Here, diameter=2
>
> Opteron 6174
>
>
> This is the 4-node one, which looks like this:
>
> node 0 1 2 3
> 0: 10 20 20 20
> 1: 20 10 20 20
> 2: 20 20 10 20
> 3: 20 20 20 10
>
> 0 - 3
> | \ / |
> | X |
> | / \ |
> 1 - 2
>
> Clearly this is diameter=1
>
> AMD Bulldozer
> -
>
> I'm using the topology described in decade of wasted cores [2]; I'm not going
> to bother reproducing the distance table, the topology looks like:
>
>___
> /_ \
> | / \|
> 0 - 4 - 5 - 1
> | \ / | \ / | \ / |
> | X | X | X |
> | / \ | / \ | / \ |
> 6 - 2 - 3 - 7
> | \__/|
> \___/
>
> Which is diameter=2 (assuming equal edge weights)
>
> Diameter > 2
>
>
> I haven't found other NUMA systems out there with a diameter > 2 other than
> the one I'm rambling about in [1]. Nevertheless, I think there are some
> theoretical setups that aren't too insane (at least less than [1]).
>
> One of them is a 6-node mesh, which is diameter=3 and would look like:
>
> 0 - 5
> | |
> 1 - 4
> | |
> 2 - 3
>
> A more convoluted one would be a 12-node "spidergon"; it's a ring with an
> even number of nodes N, each node is connected to both of its neighbours and
> there is an interlink between node X and node (X + N/2) % N. I won't pretend I
> can draw it in ASCII, but that again gives us a diameter of 3.
>
> Case study w/ QEMU
> ++
>
> Setup
> -
>
> The topology I'll describe below is a simplified version of the one in [1],
> as it is
> the smallest reproducer of the issue. Morten has been calling this a
> "segmented bus".
>
>1 - 0
>|
>|
>|
>2 - 3
>
> node 0 1 2 3
> 0: 10 20 30 40
> 1: 20 10 20 30
> 2: 30 20 10 20
> 3: 40 30 20 10
>
> Diameter here is 3. I can recreate this with the following qemu
> incantation:
>
> $ qemu-system-aarch64 -kernel Image -initrd rootfs.cpio -append \
> 'console=ttyAMA0 earlycon=pl011,0x900
> root=/dev/vda debug earlyprintk=serial sched_debug' \
> -smp cores=4 -nographic -m 512 -cpu cortex-a53
> -machine virt \
> -numa node,cpus=0,nodeid=0 -numa
> node,cpus=1,nodeid=1, \
> -numa node,cpus=2,nodeid=2, -numa
> node,cpus=3,nodeid=3, \
> -numa dist,src=0,dst=1,val=20, -numa
> dist,src=0,dst=2,val=30, \
> -numa dist,src=0,dst=3,val=40, -numa
>
[PATCH 2/3] ia64: remove unneeded header includes from
includes too many unneeded headers. This commit cuts off a lot of header includes. What we need to include are: - for DECLARE_PER_CPU(u64, ia64_mca_pal_base) - for NR_CPUS - for u8, u64, size_t, etc. - for KERNEL_STACK_SIZE The other header includes are actually unneeded. previously included 436 headers, and now it includes only 138. I confirmed is still self-contained. Signed-off-by: Masahiro Yamada --- arch/ia64/include/asm/mca.h | 9 +++-- arch/ia64/kernel/efi.c | 1 + arch/ia64/kernel/mca.c | 1 + 3 files changed, 5 insertions(+), 6 deletions(-) diff --git a/arch/ia64/include/asm/mca.h b/arch/ia64/include/asm/mca.h index c92b9c15962c..05805249296c 100644 --- a/arch/ia64/include/asm/mca.h +++ b/arch/ia64/include/asm/mca.h @@ -14,13 +14,10 @@ #if !defined(__ASSEMBLY__) -#include +#include +#include #include - -#include -#include -#include -#include +#include #define IA64_MCA_RENDEZ_TIMEOUT(20 * 1000) /* value in milliseconds - 20 seconds */ diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c index f932b25fb817..b6bb718ed1ff 100644 --- a/arch/ia64/kernel/efi.c +++ b/arch/ia64/kernel/efi.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c index 17151269d655..3911c561d2bb 100644 --- a/arch/ia64/kernel/mca.c +++ b/arch/ia64/kernel/mca.c @@ -96,6 +96,7 @@ #include #include #include +#include #include #include -- 2.25.1
[PATCH 0/3] ia64: clean-up header dependency and build process, fix build warning
Randy Dunlap reports the following warning with CONFIG_IA64_PALINFO=m: ../scripts/Makefile.build:68: 'arch/ia64/kernel/palinfo.ko' will not be built even though obj-m is specified. ../scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module Makefile. Use obj-y/m instead. This comes from the fact Kbuild descends into arch/ia64/kernel/ twice. First, to generate , Second, to build kernel and module objects. The warning is emitted in the first descend because it is not the intended usage. I looked into the code closely, and noticed arch/ia64/kernel/nr-irqs.c was not needed in the first place. It was separated out of arch/ia64/kernel/asm-offsets.c just because was including too many bogus headers. IA64 is not actively maintained, and there exists unneeded obsolete code. The first two patches are the outcome when I played with ARCH=ia64 builds, but not prerequisites for 3/3. Anyway I believe they are nice cleanups and folded in this patch set. 3/3 is the important one to fix the false positive warning, and it is a nice cleanup too. Masahiro Yamada (3): ia64: do not typedef struct pal_min_state_area_s ia64: remove unneeded header includes from ia64: remove generated/nr-irqs.h generation to fix build warning arch/ia64/Makefile | 6 -- arch/ia64/include/asm/irq.h| 4 +++- arch/ia64/include/asm/mca.h| 11 --- arch/ia64/include/asm/pal.h| 4 ++-- arch/ia64/include/asm/sal.h| 2 +- arch/ia64/kernel/Makefile | 5 - arch/ia64/kernel/asm-offsets.c | 18 +- arch/ia64/kernel/efi.c | 1 + arch/ia64/kernel/mca.c | 5 +++-- arch/ia64/kernel/mca_drv.c | 2 +- arch/ia64/kernel/nr-irqs.c | 22 -- 11 files changed, 24 insertions(+), 56 deletions(-) delete mode 100644 arch/ia64/kernel/nr-irqs.c -- 2.25.1
[PATCH 3/3] ia64: remove generated/nr-irqs.h generation to fix build warning
Randy reports the following warning when building ARCH=ia64 with
CONFIG_IA64_PALINFO=m:
../scripts/Makefile.build:68: 'arch/ia64/kernel/palinfo.ko' will not be built
even though obj-m is specified.
../scripts/Makefile.build:69: You cannot use subdir-y/m to visit a module
Makefile. Use obj-y/m instead.
This message is actually false-positive, and you can get palinfo.ko
correctly built. It is emitted in the archprepare stage, where Kbuild
descends into arch/ia64/kernel to generate include/generated/nr-irqs.h
instead of any kind of kernel objects.
arch/ia64/kernel/nr-irqs.c was introduced by commit 213060a4d699
("[IA64] pvops: paravirtualize NR_IRQS") to pre-calculate:
NR_IRQS = max(IA64_NATIVE_NR_IRQS, XEN_NR_IRQS, FOO_NR_IRQS...)
Since commit d52eefb47d4e ("ia64/xen: Remove Xen support for ia64"), this
union contains just one field, making NR_IRQS and IA64_NATIVE_NR_IRQS
always match.
So, the following hard-coding now works:
#define NR_IRQSIA64_NATIVE_NR_IRQS
If you need to re-introduce NR_IRQS = max(...) gimmick in the future,
please try to implement it in asm-offsets.c instead of a separate file.
It will be possible because the header inclusion has been consolidated
to make asm-offsets.c independent of .
Reported-by: Randy Dunlap
Signed-off-by: Masahiro Yamada
---
arch/ia64/Makefile | 6 --
arch/ia64/include/asm/irq.h | 4 +++-
arch/ia64/kernel/Makefile | 5 -
arch/ia64/kernel/nr-irqs.c | 22 --
4 files changed, 3 insertions(+), 34 deletions(-)
delete mode 100644 arch/ia64/kernel/nr-irqs.c
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index 2876a7df1b0a..3d54d411fcc4 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -87,9 +87,3 @@ define archhelp
echo ' install - Install compressed kernel image'
echo '* unwcheck - Check vmlinux for invalid unwind info'
endef
-
-archprepare: make_nr_irqs_h
-PHONY += make_nr_irqs_h
-
-make_nr_irqs_h:
- $(Q)$(MAKE) $(build)=arch/ia64/kernel include/generated/nr-irqs.h
diff --git a/arch/ia64/include/asm/irq.h b/arch/ia64/include/asm/irq.h
index 5acf52e90872..0eccf33dfe8b 100644
--- a/arch/ia64/include/asm/irq.h
+++ b/arch/ia64/include/asm/irq.h
@@ -14,7 +14,9 @@
#include
#include
-#include
+#include
+
+#define NR_IRQSIA64_NATIVE_NR_IRQS
static __inline__ int
irq_canonicalize (int irq)
diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile
index 1a8df6669eee..7c9354ee4b3e 100644
--- a/arch/ia64/kernel/Makefile
+++ b/arch/ia64/kernel/Makefile
@@ -48,8 +48,3 @@ CFLAGS_traps.o += -mfixed-range=f2-f5,f16-f31
# The gate DSO image is built using a special linker script.
include $(src)/Makefile.gate
-
-include/generated/nr-irqs.h: arch/$(SRCARCH)/kernel/nr-irqs.s FORCE
- $(call filechk,offsets,__ASM_NR_IRQS_H__)
-
-targets += nr-irqs.s
diff --git a/arch/ia64/kernel/nr-irqs.c b/arch/ia64/kernel/nr-irqs.c
deleted file mode 100644
index f2633b22d3be..
--- a/arch/ia64/kernel/nr-irqs.c
+++ /dev/null
@@ -1,22 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * calculate
- * NR_IRQS = max(IA64_NATIVE_NR_IRQS, XEN_NR_IRQS, FOO_NR_IRQS...)
- * depending on config.
- * This must be calculated before processing asm-offset.c.
- */
-
-#define ASM_OFFSETS_C 1
-
-#include
-#include
-#include
-
-void foo(void)
-{
- union paravirt_nr_irqs_max {
- char ia64_native_nr_irqs[IA64_NATIVE_NR_IRQS];
- };
-
- DEFINE(NR_IRQS, sizeof (union paravirt_nr_irqs_max));
-}
--
2.25.1
[PATCH 1/3] ia64: do not typedef struct pal_min_state_area_s
Documentation/process/coding-style.rst says:
Please don't use things like ``vps_t``.
It's a **mistake** to use typedef for structures and pointers.
This commit converts as follows:
struct pal_min_state_area_s -> struct pal_min_state_area
pal_min_state_area_t -> struct pal_min_state_area
My main motivation for this is to slim down the include directives
of in the next commit.
Currently, is required to include directly
or indirectly due to (pal_min_state_area_t *). Otherwise, it would
have no idea what pal_min_state_area_t is.
Replacing it with (struct pal_min_state_area *) will relax the header
dependency since it is enough to tell it is a pointer to a structure,
and to resolve the size of struct pal_min_state_area. It will make
independent of .
typedef's a lot of structures, but it is trivial to
convert the others in the same way.
Signed-off-by: Masahiro Yamada
---
arch/ia64/include/asm/mca.h| 2 +-
arch/ia64/include/asm/pal.h| 4 ++--
arch/ia64/include/asm/sal.h| 2 +-
arch/ia64/kernel/asm-offsets.c | 18 +-
arch/ia64/kernel/mca.c | 4 ++--
arch/ia64/kernel/mca_drv.c | 2 +-
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/ia64/include/asm/mca.h b/arch/ia64/include/asm/mca.h
index 726df17f1b51..c92b9c15962c 100644
--- a/arch/ia64/include/asm/mca.h
+++ b/arch/ia64/include/asm/mca.h
@@ -83,7 +83,7 @@ struct ia64_sal_os_state {
/* common */
unsigned long sal_ra; /* Return address in
SAL, physical */
unsigned long sal_gp; /* GP of the SAL -
physical */
- pal_min_state_area_t*pal_min_state; /* from R17. physical
in asm, virtual in C */
+ struct pal_min_state_area *pal_min_state; /* from R17. physical
in asm, virtual in C */
/* Previous values of IA64_KR(CURRENT) and IA64_KR(CURRENT_STACK).
* Note: if the MCA/INIT recovery code wants to resume to a new context
* then it must change these values to reflect the new kernel stack.
diff --git a/arch/ia64/include/asm/pal.h b/arch/ia64/include/asm/pal.h
index f9d2b3b2dfad..b1d87955e8cc 100644
--- a/arch/ia64/include/asm/pal.h
+++ b/arch/ia64/include/asm/pal.h
@@ -750,7 +750,7 @@ typedef union pal_mc_error_info_u {
* for PAL.
*/
-typedef struct pal_min_state_area_s {
+struct pal_min_state_area {
u64 pmsa_nat_bits; /* nat bits for saved GRs */
u64 pmsa_gr[15];/* GR1 - GR15 */
u64 pmsa_bank0_gr[16]; /* GR16 - GR31 */
@@ -766,7 +766,7 @@ typedef struct pal_min_state_area_s {
u64 pmsa_xfs; /* previous ifs*/
u64 pmsa_br1; /* branch register 1 */
u64 pmsa_reserved[70]; /* pal_min_state_area should total to
1KB */
-} pal_min_state_area_t;
+};
struct ia64_pal_retval {
diff --git a/arch/ia64/include/asm/sal.h b/arch/ia64/include/asm/sal.h
index 08f5b6aaed73..78f4f7b40435 100644
--- a/arch/ia64/include/asm/sal.h
+++ b/arch/ia64/include/asm/sal.h
@@ -385,7 +385,7 @@ typedef struct sal_processor_static_info {
fr : 1,
reserved: 58;
} valid;
- pal_min_state_area_t min_state_area;
+ struct pal_min_state_area min_state_area;
u64 br[8];
u64 cr[128];
u64 ar[128];
diff --git a/arch/ia64/kernel/asm-offsets.c b/arch/ia64/kernel/asm-offsets.c
index fb0deb8a4221..be3b90fef2e9 100644
--- a/arch/ia64/kernel/asm-offsets.c
+++ b/arch/ia64/kernel/asm-offsets.c
@@ -245,23 +245,23 @@ void foo(void)
BLANK();
DEFINE(IA64_PMSA_GR_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_gr));
+ offsetof(struct pal_min_state_area, pmsa_gr));
DEFINE(IA64_PMSA_BANK1_GR_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_bank1_gr));
+ offsetof(struct pal_min_state_area, pmsa_bank1_gr));
DEFINE(IA64_PMSA_PR_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_pr));
+ offsetof(struct pal_min_state_area, pmsa_pr));
DEFINE(IA64_PMSA_BR0_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_br0));
+ offsetof(struct pal_min_state_area, pmsa_br0));
DEFINE(IA64_PMSA_RSC_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_rsc));
+ offsetof(struct pal_min_state_area, pmsa_rsc));
DEFINE(IA64_PMSA_IIP_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_iip));
+ offsetof(struct pal_min_state_area, pmsa_iip));
DEFINE(IA64_PMSA_IPSR_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_ipsr));
+ offsetof(struct pal_min_state_area, pmsa_ipsr));
DEFINE(IA64_PMSA_IFS_OFFSET,
- offsetof (struct pal_min_state_area_s, pmsa_ifs));
+
Re: [PATCH v3 4/5] fpga manager: xilinx-spi: add error checking after gpiod_get_value()
Hi Luca,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v5.9-rc2]
[also build test WARNING on next-20200828]
[cannot apply to xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Luca-Ceresoli/fpga-manager-xilinx-spi-remove-stray-comment/20200829-040041
base:d012a7190fc1fd72ed48911e77ca97ba4521bccd
compiler: nds32le-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
cppcheck warnings: (new ones prefixed by >>)
>> drivers/fpga/xilinx-spi.c:183:10: warning: Uninitialized variable: expired
>> [uninitvar]
while (!expired) {
^
#
https://github.com/0day-ci/linux/commit/5ae295c0b82631de73665c58df85ec3ed8567a8e
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Luca-Ceresoli/fpga-manager-xilinx-spi-remove-stray-comment/20200829-040041
git checkout 5ae295c0b82631de73665c58df85ec3ed8567a8e
vim +183 drivers/fpga/xilinx-spi.c
061c97d13f1a69 Anatolij Gustschin 2017-03-23 168
061c97d13f1a69 Anatolij Gustschin 2017-03-23 169 static int
xilinx_spi_write_complete(struct fpga_manager *mgr,
061c97d13f1a69 Anatolij Gustschin 2017-03-23 170
struct fpga_image_info *info)
061c97d13f1a69 Anatolij Gustschin 2017-03-23 171 {
061c97d13f1a69 Anatolij Gustschin 2017-03-23 172 struct xilinx_spi_conf
*conf = mgr->priv;
629463d1acc532 Luca Ceresoli 2020-08-28 173 unsigned long timeout =
jiffies + usecs_to_jiffies(info->config_complete_timeout_us);
629463d1acc532 Luca Ceresoli 2020-08-28 174 bool expired;
629463d1acc532 Luca Ceresoli 2020-08-28 175 int done;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 176 int ret;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 177
629463d1acc532 Luca Ceresoli 2020-08-28 178 /*
629463d1acc532 Luca Ceresoli 2020-08-28 179* This loop is
carefully written such that if the driver is
629463d1acc532 Luca Ceresoli 2020-08-28 180* scheduled out for
more than 'timeout', we still check for DONE
629463d1acc532 Luca Ceresoli 2020-08-28 181* before giving up and
we apply 8 extra CCLK cycles in all cases.
629463d1acc532 Luca Ceresoli 2020-08-28 182*/
629463d1acc532 Luca Ceresoli 2020-08-28 @183 while (!expired) {
629463d1acc532 Luca Ceresoli 2020-08-28 184 expired =
time_after(jiffies, timeout);
061c97d13f1a69 Anatolij Gustschin 2017-03-23 185
629463d1acc532 Luca Ceresoli 2020-08-28 186 done =
get_done_gpio(mgr);
629463d1acc532 Luca Ceresoli 2020-08-28 187 if (done < 0)
629463d1acc532 Luca Ceresoli 2020-08-28 188 return
done;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 189
061c97d13f1a69 Anatolij Gustschin 2017-03-23 190 ret =
xilinx_spi_apply_cclk_cycles(conf);
061c97d13f1a69 Anatolij Gustschin 2017-03-23 191 if (ret)
061c97d13f1a69 Anatolij Gustschin 2017-03-23 192 return
ret;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 193
629463d1acc532 Luca Ceresoli 2020-08-28 194 if (done)
629463d1acc532 Luca Ceresoli 2020-08-28 195 return
0;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 196 }
061c97d13f1a69 Anatolij Gustschin 2017-03-23 197
70cac0e8c9ec83 Luca Ceresoli 2020-08-28 198 dev_err(>dev,
"Timeout after config data transfer\n");
061c97d13f1a69 Anatolij Gustschin 2017-03-23 199 return -ETIMEDOUT;
061c97d13f1a69 Anatolij Gustschin 2017-03-23 200 }
061c97d13f1a69 Anatolij Gustschin 2017-03-23 201
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: [PATCH v1 1/1] scsi: ufshcd: Allow zero value setting to Auto-Hibernate Timer
On 2020-08-28 18:05, Bao D. Nguyen wrote:
> static ssize_t auto_hibern8_show(struct device *dev,
>struct device_attribute *attr, char *buf)
> {
> + u32 ahit;
> struct ufs_hba *hba = dev_get_drvdata(dev);
Although not strictly required for SCSI code, how about following the "reverse
christmas tree" convention and adding "u32 ahit" below the "hba" declaration?
> if (!ufshcd_is_auto_hibern8_supported(hba))
> return -EOPNOTSUPP;
>
> - return snprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(hba->ahit));
> + pm_runtime_get_sync(hba->dev);
> + ufshcd_hold(hba, false);
> + ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
> + ufshcd_release(hba);
> + pm_runtime_put_sync(hba->dev);
> +
> + return scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
> }
Why the pm_runtime_get_sync()/pm_runtime_put_sync() and
ufshcd_hold()/ufshcd_release() calls? I don't think these are necessary here.
Thanks,
Bart.
[PATCH 1/1] samples/seccomp: eliminate two boring compile warnings in user-trap.c
samples/seccomp/user-trap.c is compiled with $(userccflags), and the
latter does not contain -fno-strict-aliasing, so the warnings reported as
below. Due to add "userccflags += -fno-strict-aliasin" will impact other
files, so use __attribute__((__may_alias__)) to suppress it exactly.
My gcc version is 5.5.0 20171010.
--
samples/seccomp/user-trap.c: In function ‘send_fd’:
samples/seccomp/user-trap.c:50:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
*((int *)CMSG_DATA(cmsg)) = fd;
^
samples/seccomp/user-trap.c: In function ‘recv_fd’:
samples/seccomp/user-trap.c:83:2: warning: dereferencing type-punned pointer
will break strict-aliasing rules [-Wstrict-aliasing]
return *((int *)CMSG_DATA(cmsg));
^
Signed-off-by: Zhen Lei
---
samples/seccomp/user-trap.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/samples/seccomp/user-trap.c b/samples/seccomp/user-trap.c
index 20291ec6489f31e..e36696b7f41517f 100644
--- a/samples/seccomp/user-trap.c
+++ b/samples/seccomp/user-trap.c
@@ -23,6 +23,8 @@
#define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
+typedef int __attribute__((__may_alias__)) __int_alias_t;
+
static int seccomp(unsigned int op, unsigned int flags, void *args)
{
errno = 0;
@@ -47,7 +49,7 @@ static int send_fd(int sock, int fd)
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
cmsg->cmsg_len = CMSG_LEN(sizeof(int));
- *((int *)CMSG_DATA(cmsg)) = fd;
+ *(__int_alias_t *)CMSG_DATA(cmsg) = fd;
msg.msg_controllen = cmsg->cmsg_len;
if (sendmsg(sock, , 0) < 0) {
@@ -80,7 +82,7 @@ static int recv_fd(int sock)
cmsg = CMSG_FIRSTHDR();
- return *((int *)CMSG_DATA(cmsg));
+ return *(__int_alias_t *)CMSG_DATA(cmsg);
}
static int user_trap_syscall(int nr, unsigned int flags)
--
1.8.3
Re: [RFC][PATCH 6/7] freelist: Lock less freelist
> I'm curious whether it is correct to just set the prev->refs to zero and > return > @prev? So that it can remove an unneeded "add()()" pair (although in > an unlikely branch) and __freelist_add() can be folded into freelist_add() > for tidier code. That is a very good question. I believe it would be correct, yes, and would certainly simplify the code. The reference count is zero, so nobody can increment it again, and REFS_ON_FREELIST is set (the should-be-on-freelist flag), so instead of adding it to the freelist to be removed later, it can be returned directly. > On Fri, Aug 28, 2020 at 04:46:52PM +0200, Oleg Nesterov wrote: > > 129 lines! And I spent more than 2 hours trying to understand these > > 129 lines ;) looks correct... Hahaha. Sorry about that. Some of the most mind-bending code I've ever written. :-) > > + /* > > + * Hmm, the add failed, but we can only try again when > > + * the refcount goes back to zero. > > + */ > > + if (atomic_fetch_add_release(REFS_ON_FREELIST - 1, > > >refs) == 1) > > + continue; > Do we really need _release ? Why can't atomic_fetch_add_relaxed() work? The release is to synchronize with the acquire in the compare-exchange of try_get. However, I think you're right, between the previous release-write to the refs and that point, there are no memory effects that need to be synchronized, and so it could be safely replaced with a relaxed operation. > Cosmetic, but why not atomic_fetch_dec() ? This is just one of my idiosyncrasies. I prefer exclusively using atomic add, I find it easier to read. Feel free to change them all to subs! Cameron > > > > Do we the barriers implied by _fetch_? Why can't atomic_sub(2, refs) work? > > I think we can, the original has std::memory_order_relaxed here. So I > should've used atomic_fetch_add_relaxed() but since we don't use the > return value, atomic_sub() would work just fine too. > > > > + /* > > > +* OK, the head must have changed on us, but we still need to > > > decrement > > > +* the refcount we increased. > > > +*/ > > > + refs = atomic_fetch_add(-1, >refs); > > > > Cosmetic, but why not atomic_fetch_dec() ? > > The original had that, I didn't want to risk more bugs by 'improving' > things. But yes, that can definitely become dec().
[PATCH] [v2] ext4: Fix error handling code in add_new_gdb
When ext4_journal_get_write_access() fails, we should
terminate the execution flow and release n_group_desc,
iloc.bh, dind and gdb_bh.
Signed-off-by: Dinghao Liu
---
Changelog:
v2: - Remove changes to ext4_handle_dirty_super()'s
error handling path.
---
fs/ext4/resize.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
index a50b51270ea9..71bf600e5b42 100644
--- a/fs/ext4/resize.c
+++ b/fs/ext4/resize.c
@@ -843,8 +843,10 @@ static int add_new_gdb(handle_t *handle, struct inode
*inode,
BUFFER_TRACE(dind, "get_write_access");
err = ext4_journal_get_write_access(handle, dind);
- if (unlikely(err))
+ if (unlikely(err)) {
ext4_std_error(sb, err);
+ goto errout;
+ }
/* ext4_reserve_inode_write() gets a reference on the iloc */
err = ext4_reserve_inode_write(handle, inode, );
--
2.17.1
Re: [PATCH 1/5] KVM: nVMX: Fix VMX controls MSRs setup when nested VMX enabled
On 8/29/2020 9:49 AM, Chenyi Qiang wrote:
On 8/29/2020 1:43 AM, Jim Mattson wrote:
On Fri, Aug 28, 2020 at 1:54 AM Chenyi Qiang
wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of nested VMX controls MSR.
Aren't these features added conditionally in
nested_vmx_entry_exit_ctls_update() and
nested_vmx_pmu_entry_exit_ctls_update()?
Yes, but I assume vmcs_config.nested should reflect the global
capability of VMX MSR. KVM supports these two controls, so should be
exposed here.
No. I prefer to say they are removed conditionally in
nested_vmx_entry_exit_ctls_update() and
nested_vmx_pmu_entry_exit_ctls_update().
Userspace calls vmx_get_msr_feature() to query what KVM supports for
these VMX MSR. In vmx_get_msr_feature(), it returns the value of
vmcs_config.nested. As KVM supports these two bits, we should advertise
them in vmcs_config.nested and report to userspace.
[PATCH 1/1] Fix silent audio output and corrupted input on MSI X570-A PRO
From: Dan Crawford
Following Christian Lachner's patch for Gigabyte X570-based motherboards,
also patch the MSI X570-A PRO motherboard; the ALC1220 codec requires the
same workaround for Clevo laptops to enforce the DAC/mixer connection
path. Set up a quirk entry for that.
I suspect most if all X570 motherboards will require similar patches.
Related buglink: https://bugzilla.kernel.org/show_bug.cgi?id=205275
Signed-off-by: Dan Crawford
---
sound/pci/hda/patch_realtek.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index a1fa983d2..a52d8640e 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -2474,6 +2474,7 @@ static const struct snd_pci_quirk alc882_fixup_tbl[] = {
SND_PCI_QUIRK(0x1462, 0x1275, "MSI-GL63", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1276, "MSI-GL73", ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x1293, "MSI-GP65", ALC1220_FIXUP_CLEVO_P950),
+ SND_PCI_QUIRK(0x1462, 0x9c37, "MSI X570-A PRO",
ALC1220_FIXUP_CLEVO_P950),
SND_PCI_QUIRK(0x1462, 0x7350, "MSI-7350", ALC889_FIXUP_CD),
SND_PCI_QUIRK(0x1462, 0xda57, "MSI Z270-Gaming",
ALC1220_FIXUP_GB_DUAL_CODECS),
SND_PCI_QUIRK_VENDOR(0x1462, "MSI", ALC882_FIXUP_GPIO3),
--
2.28.0
Re: [PATCH v4 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation
ChiYuan Huang 於 2020年8月29日 週六 上午8:32寫道：
>
> Rob Herring 於 2020年8月29日 週六 上午6:05寫道：
> >
> > On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > > From: ChiYuan Huang
> > >
> > > Add a devicetree binding documentation for the MT6360 Type-C driver.
> > >
> > > usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
> > >
> > > Signed-off-by: ChiYuan Huang
> > > ---
> > > .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73
> > > ++
> > > 1 file changed, 73 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > > b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > > new file mode 100644
> > > index ..9e8ab0d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > > @@ -0,0 +1,73 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
> > > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > > +
> > > +title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller
> > > DT bindings
> > > +
> > > +maintainers:
> > > + - ChiYuan Huang
> > > +
> > > +description: |
> > > + Mediatek MT6360 is a multi-functional device. It integrates charger,
> > > ADC, flash, RGB indicators,
> > > + regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery
> > > controller.
> > > + This document only describes MT6360 Type-C Port Switch and Power
> > > Delivery controller.
> > > +
> > > +properties:
> > > + compatible:
> > > +enum:
> > > + - mediatek,mt6360-tcpc
> > > +
> > > + interrupts-extended:
> >
> > Use 'interrupts'. The tooling will automatically support
> > 'interrupts-extended'.
> Okay.
> >
> > > +maxItems: 1
> > > +
> > > + interrupt-names:
> > > +items:
> > > + - const: PD_IRQB
> > > +
> > > +patternProperties:
> > > + "connector":
> > > +type: object
> > > +$ref: ../connector/usb-connector.yaml#
> > > +description:
> > > + Properties for usb c connector.
> > > +
> > > +additionalProperties: false
> > > +
> > > +required:
> > > + - compatible
> > > + - interrupts-extended
> > > + - interrupt-names
> > > +
> > > +examples:
> > > + - |
> > > +#include
> > > +#include
> > > +i2c0 {
> > > +#address-cells = <1>;
> > > +#size-cells = <0>;
> > > +
> > > +mt6360@34 {
> > > +compatible = "mediatek,mt6360";
> > > +reg = <0x34>;
> > > +
> > > +tcpc {
> > > +compatible = "mediatek,mt6360-tcpc";
> > > +interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
> > > +interrupt-names = "PD_IRQB";
> > > +
> > > +connector {
> >
> > Where's the data connections? The assumption of the binding is the USB
> > (2 and 3) connections come from the parent if there's no graph to the
> > USB controller(s).
> MT6360 is only a subpmic. TypeC part only handle the CC logic to support
> USBPD.
> For the usb connection like as usbhs/usbss, it need to be handled
> by/connect to application processor side.
> LIke as connector/usb-connector.yaml decribed, it specify the port
> property to bind USB HS/SS.
>
Do i need to add the ports into the connector node for example?
Like as hs/ss/aux, to make the user know to use 6360's tcpc?
I check the style in connector/usb-connect.yaml
Do I also need to replace two space instead of one tab in the binding example?
> >
> > > +compatible = "usb-c-connector";
> > > +label = "USB-C";
> > > +data-role = "dual";
> > > +power-role = "dual";
> > > +try-power-role = "sink";
> > > +source-pdos = > > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > > +sink-pdos = > > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > > +op-sink-microwatt = <1000>;
> > > +};
> > > +};
> > > +};
> > > +};
> > > +...
> > > --
> > > 2.7.4
> > >
Re: Re: [PATCH] ext4: Fix memleak in add_new_gdb
> On Thu 27-08-20 14:28:43, Dinghao Liu wrote:
> > When ext4_journal_get_write_access() fails, we should release
> > n_group_desc, iloc.bh, dind and gdb_bh to prevent memleak.
> > It's the same when ext4_handle_dirty_super() fails, but we
> > don't need to release dind here because it has been released
> > before.
> >
> > Signed-off-by: Dinghao Liu
>
> Thanks for the patch! Some comments below:
>
> > diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c
> > index a50b51270ea9..efc0a022ca8e 100644
> > --- a/fs/ext4/resize.c
> > +++ b/fs/ext4/resize.c
> > @@ -843,8 +843,10 @@ static int add_new_gdb(handle_t *handle, struct inode
> > *inode,
> >
> > BUFFER_TRACE(dind, "get_write_access");
> > err = ext4_journal_get_write_access(handle, dind);
> > - if (unlikely(err))
> > + if (unlikely(err)) {
> > ext4_std_error(sb, err);
> > + goto errout;
> > + }
>
> This hunk looks good.
>
> > @@ -899,13 +901,17 @@ static int add_new_gdb(handle_t *handle, struct inode
> > *inode,
> >
> > le16_add_cpu(>s_reserved_gdt_blocks, -1);
> > err = ext4_handle_dirty_super(handle, sb);
> > - if (err)
> > + if (err) {
> > ext4_std_error(sb, err);
> > + goto errsuper;
> > + }
> > +
> > return err;
> > errout:
> > + brelse(dind);
> > +errsuper:
>
> But this is definitely wrong. Look, n_group_desc and gdb_bh are already
> referenced from the superblock so you cannot free them, iloc.bh has been
> released in ext4_mark_iloc_dirty().
>
Thank you for your advice! It's clear to me and I will fix this soon.
Regards,
Dinghao
Re: [RFC][PATCH 7/7] kprobes: Replace rp->free_instance with freelist
On Fri, Aug 28, 2020 at 10:29 PM Cameron wrote: > I thought about this some more, and actually, it should be safe. Although I should note that it's important that the flags/refcount are not overwritten even after the node is taken off the freelist. Cameron
Re: [RFC][PATCH 7/7] kprobes: Replace rp->free_instance with freelist
On Fri, Aug 28, 2020 at 5:18 AM wrote: > So the freelist->refs thing is supposed to pin freelist->next for > concurrent usage, but if we instantly stick it on the > current->kretprobe_instances llist while it's still elevated, we'll > overwrite ->next, which would be bad. I thought about this some more, and actually, it should be safe. The next is not supposed to be changed while the node has non-zero ref-count, true, but this is only important while the node is in the freelist. If it's never added back to the freelist, then there is no problem (the overwritten next may be read but never used). But even if it is later re-added to the freelist, as long as the refcount is still above zero, the node won't actually be in the list right away, and again its next won't matter. When the refcount finally goes down to zero, it will be put on the list but its next will be blindly overwritten at that point. Cameron
Re: [PATCH] mtd: ck804xrom: fix missing pci device put in error paths
Hi Miquèl,
Thanks for your feedback.
I have just rechecked this function and find that "pdev" currently is
already put
inside ck804xrom_cleanup, so my previous patch is meaningless...
The current calling order is like:
window->pdev = pci_dev_get(pdev);
...
ck804xrom_cleanup(window)
->
pci_dev_put(window->pdev);
And sorry for bothering you.
Thanks,
James
On Thu, Aug 27, 2020 at 7:46 AM Miquel Raynal wrote:
>
> Hi James,
>
> James Bond wrote on Fri, 21 Aug 2020
> 02:05:36 -0500:
>
> > pci_dev_get increases the refcount of "pdev".
> > In the error paths, pci_dev_put should be called
> > to handle the "pdev" and decrease the corresponding refcount.
> >
> > Fixes: 90afffc8bd79 ("[MTD] [MAPS] Support for BIOS flash chips on the
> > nvidia ck804 southbridge")
> > Signed-off-by: James Bond
> > ---
> > drivers/mtd/maps/ck804xrom.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/mtd/maps/ck804xrom.c b/drivers/mtd/maps/ck804xrom.c
> > index 460494212f6a..16af8b5ee653 100644
> > --- a/drivers/mtd/maps/ck804xrom.c
> > +++ b/drivers/mtd/maps/ck804xrom.c
> > @@ -195,6 +195,7 @@ static int __init ck804xrom_init_one(struct pci_dev
> > *pdev,
> > if (!window->virt) {
> > printk(KERN_ERR MOD_NAME ": ioremap(%08lx, %08lx) failed\n",
> > window->phys, window->size);
> > + pci_dev_put(pdev);
> > goto out;
> > }
> >
> > @@ -222,6 +223,7 @@ static int __init ck804xrom_init_one(struct pci_dev
> > *pdev,
> >
> > if (!map) {
> > printk(KERN_ERR MOD_NAME ": kmalloc failed");
> > + pci_dev_put(pdev);
> > goto out;
> > }
> > memset(map, 0, sizeof(*map));
> > @@ -295,6 +297,7 @@ static int __init ck804xrom_init_one(struct pci_dev
> > *pdev,
> > if (mtd_device_register(map->mtd, NULL, 0)) {
> > map_destroy(map->mtd);
> > map->mtd = NULL;
> > + pci_dev_put(pdev);
> > goto out;
> > }
> >
>
> I suppose in these three cases, the window->maps list will be empty and
> you will end up returning -ENODEV and the bottom of the function? If
> yes, it woudl probably be better to move these pci_dev_put() calls to
> this location.
>
> Otherwise, it might bit interesting to clean up a little bit the error
> path and perhaps have a distinct success vs. failure path.
>
>
> Thanks,
> Miquèl
[PATCH] gpu/ipu-v3:reduce protected code area in ipu idmac get/put
This change will speed-up a bit these ipu_idmac_get &
ipu_idmac_put processing and there is no need to protect
kzalloc & kfree.
Signed-off-by: Bernard Zhao
---
drivers/gpu/ipu-v3/ipu-common.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index b3dae9ec1a38..8b3a57864c2e 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -267,29 +267,30 @@ EXPORT_SYMBOL_GPL(ipu_rot_mode_to_degrees);
struct ipuv3_channel *ipu_idmac_get(struct ipu_soc *ipu, unsigned num)
{
struct ipuv3_channel *channel;
+ struct ipuv3_channel *entry;
dev_dbg(ipu->dev, "%s %d\n", __func__, num);
if (num > 63)
return ERR_PTR(-ENODEV);
+ channel = kzalloc(sizeof(*channel), GFP_KERNEL);
+ if (!channel)
+ return ERR_PTR(-ENOMEM);
+
+ channel->num = num;
+ channel->ipu = ipu;
+
mutex_lock(>channel_lock);
- list_for_each_entry(channel, >channels, list) {
- if (channel->num == num) {
+ list_for_each_entry(entry, >channels, list) {
+ if (entry->num == num) {
+ kfree(channel);
channel = ERR_PTR(-EBUSY);
goto out;
}
}
- channel = kzalloc(sizeof(*channel), GFP_KERNEL);
- if (!channel) {
- channel = ERR_PTR(-ENOMEM);
- goto out;
- }
-
- channel->num = num;
- channel->ipu = ipu;
list_add(>list, >channels);
out:
@@ -308,9 +309,10 @@ void ipu_idmac_put(struct ipuv3_channel *channel)
mutex_lock(>channel_lock);
list_del(>list);
- kfree(channel);
mutex_unlock(>channel_lock);
+
+ kfree(channel);
}
EXPORT_SYMBOL_GPL(ipu_idmac_put);
--
2.28.0
Re: [PATCH v4 18/23] sched: Fix try_invoke_on_locked_down_task() semantics
On Fri, 28 Aug 2020 21:29:55 +0900
Masami Hiramatsu wrote:
> From: Peter Zijlstra
In the next version I will drop this since I will merge the kretprobe_holder
things into removing kretporbe hash patch.
However, this patch itself seems fixing a bug of commit 2beaf3280e57
("sched/core: Add function to sample state of locked-down task").
Peter, could you push this separately?
Thank you,
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/sched/core.c |9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 2d95dc3f4644..13b0db2d0be2 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3006,15 +3006,14 @@ try_to_wake_up(struct task_struct *p, unsigned int
> state, int wake_flags)
> */
> bool try_invoke_on_locked_down_task(struct task_struct *p, bool
> (*func)(struct task_struct *t, void *arg), void *arg)
> {
> - bool ret = false;
> struct rq_flags rf;
> + bool ret = false;
> struct rq *rq;
>
> - lockdep_assert_irqs_enabled();
> - raw_spin_lock_irq(>pi_lock);
> + raw_spin_lock_irqsave(>pi_lock, rf.flags);
> if (p->on_rq) {
> rq = __task_rq_lock(p, );
> - if (task_rq(p) == rq)
> + if (task_rq(p) == rq && rq->curr != p)
> ret = func(p, arg);
> rq_unlock(rq, );
> } else {
> @@ -3028,7 +3027,7 @@ bool try_invoke_on_locked_down_task(struct task_struct
> *p, bool (*func)(struct t
> ret = func(p, arg);
> }
> }
> - raw_spin_unlock_irq(>pi_lock);
> + raw_spin_unlock_irqrestore(>pi_lock, rf.flags);
> return ret;
> }
>
>
--
Masami Hiramatsu
[RESEND PATCH] vfs: add RWF_NOAPPEND flag for pwritev2
The pwrite function, originally defined by POSIX (thus the "p"), is
defined to ignore O_APPEND and write at the offset passed as its
argument. However, historically Linux honored O_APPEND if set and
ignored the offset. This cannot be changed due to stability policy,
but is documented in the man page as a bug.
Now that there's a pwritev2 syscall providing a superset of the pwrite
functionality that has a flags argument, the conforming behavior can
be offered to userspace via a new flag. Since pwritev2 checks flag
validity (in kiocb_set_rw_flags) and reports unknown ones with
EOPNOTSUPP, callers will not get wrong behavior on old kernels that
don't support the new flag; the error is reported and the caller can
decide how to handle it.
Signed-off-by: Rich Felker
---
include/linux/fs.h | 4
include/uapi/linux/fs.h | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index e0d909d35763..3a769a972f79 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3397,6 +3397,8 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki,
rwf_t flags)
{
if (unlikely(flags & ~RWF_SUPPORTED))
return -EOPNOTSUPP;
+ if (unlikely((flags & RWF_APPEND) && (flags & RWF_NOAPPEND)))
+ return -EINVAL;
if (flags & RWF_NOWAIT) {
if (!(ki->ki_filp->f_mode & FMODE_NOWAIT))
@@ -3411,6 +3413,8 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki,
rwf_t flags)
ki->ki_flags |= (IOCB_DSYNC | IOCB_SYNC);
if (flags & RWF_APPEND)
ki->ki_flags |= IOCB_APPEND;
+ if (flags & RWF_NOAPPEND)
+ ki->ki_flags &= ~IOCB_APPEND;
return 0;
}
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 379a612f8f1d..591357d9b3c9 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -299,8 +299,11 @@ typedef int __bitwise __kernel_rwf_t;
/* per-IO O_APPEND */
#define RWF_APPEND ((__force __kernel_rwf_t)0x0010)
+/* per-IO negation of O_APPEND */
+#define RWF_NOAPPEND ((__force __kernel_rwf_t)0x0020)
+
/* mask of flags supported by the kernel */
#define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\
-RWF_APPEND)
+RWF_APPEND | RWF_NOAPPEND)
#endif /* _UAPI_LINUX_FS_H */
--
2.21.0
[PATCH] seccomp: kill process instead of thread for unknown actions
Asynchronous termination of a thread outside of the userspace thread library's knowledge is an unsafe operation that leaves the process in an inconsistent, corrupt, and possibly unrecoverable state. In order to make new actions that may be added in the future safe on kernels not aware of them, change the default action from SECCOMP_RET_KILL_THREAD to SECCOMP_RET_KILL_PROCESS. Signed-off-by: Rich Felker --- This fundamental problem with SECCOMP_RET_KILL_THREAD, and that it should be considered unsafe and deprecated, was recently noted/fixed seccomp in the man page and its example. Here I've only changed the default action for new/unknown action codes. Ideally the behavior for strict seccomp mode would be changed too but I think that breaks stability policy; in any case it's less likely to be an issue since strict mode is hard or impossible to use reasonably in a multithreaded process. Unfortunately changing this now won't help older kernels where unknown new actions would still be handled unsafely, but at least it makes it so the problem will fade away over time. kernel/seccomp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/seccomp.c b/kernel/seccomp.c index d653d8426de9..ce1875fa6b39 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -910,10 +910,10 @@ static int __seccomp_filter(int this_syscall, const struct seccomp_data *sd, seccomp_init_siginfo(, this_syscall, data); do_coredump(); } - if (action == SECCOMP_RET_KILL_PROCESS) - do_group_exit(SIGSYS); - else + if (action == SECCOMP_RET_KILL_THREAD) do_exit(SIGSYS); + else + do_group_exit(SIGSYS); } unreachable(); -- 2.21.0
Re: [PATCH] crypto: cavium/nitrox: add an error message to explain the failure of pci_request_mem_regions
Hi Herbert, I just noticed a small potential issue about the calling sequence of pci_disable_device and dev_err. Do you think it will be better to call dev_err before we call pci_disable_device(pdev) , or the order here does not matter? On Fri, Aug 28, 2020 at 2:19 AM Herbert Xu wrote: > > On Thu, Aug 20, 2020 at 10:12:08PM -0500, George Acosta wrote: > > Provide an error message for users when pci_request_mem_regions failed. > > > > Signed-off-by: George Acosta > > --- > > drivers/crypto/cavium/nitrox/nitrox_main.c | 1 + > > 1 file changed, 1 insertion(+) > > Patch applied. Thanks. > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt Thanks, George
Re: [PATCH 1/5] KVM: nVMX: Fix VMX controls MSRs setup when nested VMX enabled
On 8/29/2020 1:43 AM, Jim Mattson wrote:
On Fri, Aug 28, 2020 at 1:54 AM Chenyi Qiang wrote:
KVM supports the nested VM_{EXIT, ENTRY}_LOAD_IA32_PERF_GLOBAL_CTRL and
VM_{ENTRY_LOAD, EXIT_CLEAR}_BNDCFGS, but they doesn't expose during
the setup of nested VMX controls MSR.
Aren't these features added conditionally in
nested_vmx_entry_exit_ctls_update() and
nested_vmx_pmu_entry_exit_ctls_update()?
Yes, but I assume vmcs_config.nested should reflect the global
capability of VMX MSR. KVM supports these two controls, so should be
exposed here.
Re: [PATCH v5 00/20] gpio: cdev: add uAPI v2
On Fri, Aug 28, 2020 at 04:37:19PM +0200, Linus Walleij wrote: > On Fri, Aug 28, 2020 at 12:47 AM Kent Gibson wrote: > > > The particular use case I am considering is one I had been asked about - > > changing a requested line from input with edge detection to output, and > > vice versa. Losing interrupts isn't really an issue for this use case - > > it is expected. Yet the current implementation requires a re-request. > > This is possible to do for in-kernel users, but I don't know if that makes > sense for userspace. It is for one-offs and prototyping after all, there > is no need (IMO) to make it overly convenient for users to implement > all kind of weirdness in userspace unless there is a very real use case. > Fair point - in fact it is the same one that made me reconsider why I was so concerned about potentially losing an edge event in a few rare corner cases. Another point for this change are that it actually simplifies the kernel code, as it takes as much code to detect and filter these cases as it does to include them in the normal flow. I had a play with it yesterday and the change removes two whole functions, gpio_v2_line_config_change_validate() and gpio_v2_line_config_has_edge_detection() at the expense of making debounce_update() a little more complicated. I'm happy to put together a v6 that incorporates those changes if there aren't any strenuous objections - we can always revert to v5. Or I could mail the couple of patches I've made and if they seem reasonable then I could merge them into this set? Cheers, Kent.
Re: INFO: task hung in usb_bulk_msg
On Fri, Aug 28, 2020 at 05:52:16AM -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:15bc20c6 Merge tag 'tty-5.9-rc3' of git://git.kernel.org/p..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1052a66990
> kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
> dashboard link: https://syzkaller.appspot.com/bug?extid=7a7613e5ba9ae7bd15f9
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=101c328e90
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=155eff4190
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+7a7613e5ba9ae7bd1...@syzkaller.appspotmail.com
>
> INFO: task syz-executor790:9958 blocked for more than 143 seconds.
> Not tainted 5.9.0-rc2-syzkaller #0
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor790 state:D stack:28240 pid: 9958 ppid: 6854
> flags:0x4004
> Call Trace:
> context_switch kernel/sched/core.c:3778 [inline]
> __schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
> schedule+0xd0/0x2a0 kernel/sched/core.c:4602
> schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1855
> do_wait_for_common kernel/sched/completion.c:85 [inline]
> __wait_for_common kernel/sched/completion.c:106 [inline]
> wait_for_common kernel/sched/completion.c:117 [inline]
> wait_for_completion_timeout+0x15e/0x270 kernel/sched/completion.c:157
> usb_start_wait_urb+0x144/0x2b0 drivers/usb/core/message.c:63
> usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:254
> do_proc_bulk+0x39b/0x710 drivers/usb/core/devio.c:1231
> proc_bulk drivers/usb/core/devio.c:1268 [inline]
> usbdev_do_ioctl drivers/usb/core/devio.c:2542 [inline]
> usbdev_ioctl+0x586/0x3360 drivers/usb/core/devio.c:2708
I'm confused about this bug report.
Here's the syz reproducer from the link listed above:
#
https://syzkaller.appspot.com/bug?id=bf172344c5f1d3487a4feff67c3dd30e08d5b635
# See https://goo.gl/kgGztJ for information about syzkaller reproducers.
#{"threaded":true,"repeat":true,"procs":6,"sandbox":"none","fault_call":-1,"netdev":true,"close_fds":true}
r0 = syz_open_dev$usbfs(&(0x7f40)='/dev/bus/usb/00#/00#\x00',
0x4071, 0x28081)
r1 = socket$inet6(0xa, 0x2, 0x0)
r2 = dup(r1)
ioctl$PERF_EVENT_IOC_ENABLE(r2, 0x8912, 0x400200)
socketpair$unix(0x1, 0x0, 0x0, &(0x7f00))
ioctl$USBDEVFS_CONTROL(r0, 0x8108551b, &(0x7f001140)={0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0})
ioctl$USBDEVFS_CLEAR_HALT(r0, 0xc0185502, &(0x7f00)={0x1, 0x1})
As far as I can see, the only USB ioctls used in this test are
USBDEVFS_CONTROL and USBDEVFS_CLEAR_HALT. Neither of those calls
do_proc_bulk() or usb_bulk_msg(), so how did those routines end up in
the stack trace?
In fact, do_proc_bulk() is called only for USBDEVFS_BULK. But the test
doesn't use that ioctl!
What's going on? Am I missing part of the test?
Alan Stern
Re: [PATCH v4 19/23] kprobes: Remove kretprobe hash
On Fri, 28 Aug 2020 22:29:12 +0200
Peter Zijlstra wrote:
> On Fri, Aug 28, 2020 at 07:32:11PM +, eddy...@trendmicro.com wrote:
> >
> > > -Original Message-
> > > From: Masami Hiramatsu
> > >
> > > @@ -1311,24 +1257,23 @@ void kprobe_busy_end(void)
> > > void kprobe_flush_task(struct task_struct *tk)
> > > {
> > > struct kretprobe_instance *ri;
> > > + struct llist_node *node;
> > >
> > > + /* Early boot, not yet initialized. */
> > > if (unlikely(!kprobes_initialized))
> > > return;
> > >
> > > kprobe_busy_begin();
> > >
> > > + node = current->kretprobe_instances.first;
> > > + current->kretprobe_instances.first = NULL;
> >
> > I think we are flushing tk instead of current here.
> > After fixing this to tk, the NULL pointer deference is gone!
>
Cool!!
> Ah, very good! I can indeed confirm that that cures things.
OK, I'll merge this too.
Thank you,
>
> ---
> Index: linux-2.6/kernel/kprobes.c
> ===
> --- linux-2.6.orig/kernel/kprobes.c
> +++ linux-2.6/kernel/kprobes.c
> @@ -1275,9 +1275,7 @@ void kprobe_flush_task(struct task_struc
>
> kprobe_busy_begin();
>
> - node = current->kretprobe_instances.first;
> - current->kretprobe_instances.first = NULL;
> -
> + node == __llist_del_all(>kretprobe_instances);
> while (node) {
> ri = container_of(node, struct kretprobe_instance, llist);
> node = node->next;
> @@ -1871,6 +1869,7 @@ unsigned long __kretprobe_trampoline_han
> struct llist_node *first, *node;
> struct kretprobe *rp;
>
> + /* Find all nodes for this frame. */
> first = node = current->kretprobe_instances.first;
> while (node) {
> ri = container_of(node, struct kretprobe_instance, llist);
> @@ -1900,7 +1899,7 @@ unsigned long __kretprobe_trampoline_han
> while (first) {
> ri = container_of(first, struct kretprobe_instance, llist);
> rp = get_kretprobe(ri);
> - node = first->next;
> + first = first->next;
>
> if (rp && rp->handler) {
> __this_cpu_write(current_kprobe, >kp);
> @@ -1910,8 +1909,6 @@ unsigned long __kretprobe_trampoline_han
> }
>
> recycle_rp_inst(ri);
> -
> - first = node;
> }
>
> return (unsigned long)correct_ret_addr;
> Index: linux-2.6/include/linux/llist.h
> ===
> --- linux-2.6.orig/include/linux/llist.h
> +++ linux-2.6/include/linux/llist.h
> @@ -237,6 +237,14 @@ static inline struct llist_node *llist_d
> return xchg(>first, NULL);
> }
>
> +static inline struct llist_node *__llist_del_all(struct llist_head *head)
> +{
> + struct llist_node *first = head->first;
> +
> + head->first = NULL;
> + return first;
> +}
> +
> extern struct llist_node *llist_del_first(struct llist_head *head);
>
> struct llist_node *llist_reverse_order(struct llist_node *head);
>
--
Masami Hiramatsu
[PATCH] Staging: rtl8723bs: os_dep: fixed some coding style issues
Fixed some coding style issues.
Signed-off-by: Ross Schmidt
---
drivers/staging/rtl8723bs/os_dep/sdio_intf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
index f1e2829a19a7..2b2f4505b98b 100644
--- a/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
+++ b/drivers/staging/rtl8723bs/os_dep/sdio_intf.c
@@ -121,6 +121,7 @@ extern unsigned int oob_irq;
static irqreturn_t gpio_hostwakeup_irq_thread(int irq, void *data)
{
struct adapter *padapter = data;
+
DBG_871X_LEVEL(_drv_always_, "gpio_hostwakeup_irq_thread\n");
/* Disable interrupt before calling handler */
/* disable_irq_nosync(oob_irq); */
@@ -131,6 +132,7 @@ static irqreturn_t gpio_hostwakeup_irq_thread(int irq, void
*data)
static u8 gpio_hostwakeup_alloc_irq(struct adapter *padapter)
{
int err;
+
if (oob_irq == 0) {
DBG_871X("oob_irq ZERO!\n");
return _FAIL;
--
2.26.2
Re: [RFC/RFT PATCH 3/6] arm64, numa: Move pcibus_to_node definition to generic numa code
On Fri, Aug 28, 2020 at 9:15 AM Bjorn Helgaas wrote:
>
> On Fri, Aug 28, 2020 at 10:48:30AM +0100, Jonathan Cameron wrote:
> > On Fri, 14 Aug 2020 14:47:22 -0700
> > Atish Patra wrote:
> >
> > > pcibus_to_node is used only when numa is enabled and does not depend
> > > on ISA. Thus, it can be moved the generic numa implementation.
> > >
> > > Signed-off-by: Atish Patra
> >
> > From a more general unification point of view, there seem to
> > be two ways architectures implement this.
> > Either
> >
> > bus->sysdata.node
> >
> > Or as here.
> > There are weird other options, but let us ignore those :)
> >
> > That is going to take a bit of unwinding should we
> > want to take this unification further and perhaps we want to think
> > about doing this in pci generic code rather than here?
> >
> > Perhaps this is one we are better keeping architecture specific for
> > now?
> >
> > +CC Bjorn and Linux-pci
> >
> >
> > > ---
> > > arch/arm64/kernel/pci.c | 10 --
> > > drivers/base/arch_numa.c | 11 +++
> > > 2 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > index 1006ed2d7c60..07c122946c11 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -54,16 +54,6 @@ int raw_pci_write(unsigned int domain, unsigned int
> > > bus,
> > > return b->ops->write(b, devfn, reg, len, val);
> > > }
> > >
> > > -#ifdef CONFIG_NUMA
> > > -
> > > -int pcibus_to_node(struct pci_bus *bus)
> > > -{
> > > - return dev_to_node(>dev);
> > > -}
> > > -EXPORT_SYMBOL(pcibus_to_node);
> > > -
> > > -#endif
> > > -
> > > #ifdef CONFIG_ACPI
> > >
> > > struct acpi_pci_generic_root_info {
> > > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > > index 83341c807240..4ab1b20a615d 100644
> > > --- a/drivers/base/arch_numa.c
> > > +++ b/drivers/base/arch_numa.c
> > > @@ -11,6 +11,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #ifdef CONFIG_ARM64
> > > @@ -60,6 +61,16 @@ EXPORT_SYMBOL(cpumask_of_node);
> > >
> > > #endif
> > >
> > > +#ifdef CONFIG_PCI
> > > +
> > > +int pcibus_to_node(struct pci_bus *bus)
> > > +{
> > > + return dev_to_node(>dev);
> > > +}
> > > +EXPORT_SYMBOL(pcibus_to_node);
> > > +
> > > +#endif
>
> I certainly agree that this should not be arch-specific, but I'm not
> really in favor of adding this PCI gunk in drivers/base.
>
> I think we can do better (eventually) by getting rid of
> pcibus_to_node() completely. It's not used very much except by
> cpumask_of_pcibus(), which itself is hardly used at all.
>
I am a bit confused here. A quick grep suggested that pcibus_to_node()
is also called from generic pci probe,
controller and few drivers(block, infiniband) as well. Maybe I am
missing something here ?
We can move the pcibus_to_node to arch specific code for now if that's
what is preferred.
> > > static void numa_update_cpu(unsigned int cpu, bool remove)
> > > {
> > > int nid = cpu_to_node(cpu);
> >
> >
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
Re: [PATCH] drm/i915/display: fix uninitialized variable
Just merged the first patch that fixed this issue, thanks anyways.
2034c2129bc4a91d471815d4dc7a2a69eaa5338d - drm/i915/display: Ensure that ret is
always initialized in icl_combo_phy_verify_state
On Tue, 2020-08-25 at 16:20 -0700, t...@redhat.com wrote:
> From: Tom Rix <
> t...@redhat.com
> >
>
> clang static analysis flags this error
>
> intel_combo_phy.c:268:7: warning: The left expression of the
> compound assignment is an uninitialized value.
> The computed value will also be garbage
> ret &= check_phy_reg(...
> ~~~ ^
>
> ret has no initial values, in icl_combo_phy_verify_state() ret is
> set by the next statment and then updated by similar &= logic.
>
> Because the check_phy_req() are only register reads, reorder the
> statements.
>
> Fixes: 239bef676d8e ("drm/i915/display: Implement new combo phy
> initialization step")
> Signed-off-by: Tom Rix <
> t...@redhat.com
> >
> ---
> drivers/gpu/drm/i915/display/intel_combo_phy.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 6968de4f3477..7622ef66c987 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -264,6 +264,8 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
> if (!icl_combo_phy_enabled(dev_priv, phy))
> return false;
>
> + ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> +
> if (INTEL_GEN(dev_priv) >= 12) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_TX_DW8_LN0(phy),
>ICL_PORT_TX_DW8_ODCC_CLK_SEL |
> @@ -276,8 +278,6 @@ static bool icl_combo_phy_verify_state(struct
> drm_i915_private *dev_priv,
>DCC_MODE_SELECT_CONTINUOSLY);
> }
>
> - ret = cnl_verify_procmon_ref_values(dev_priv, phy);
> -
> if (phy_is_master(dev_priv, phy)) {
> ret &= check_phy_reg(dev_priv, phy, ICL_PORT_COMP_DW8(phy),
>IREFGEN, IREFGEN);
>
Warning on Kernel 5.9.0-rc1 on PowerBook G4 (ppc32), bisected to a5c3b9ffb0f4
In kernel 5.9.0-rc1 on a PowerBook G4 (ppc32), several warnings of the following
type are logged:
[ cut here ]
WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x20/0x100
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 5.9.0-rc2 #2
NIP: c002add4 LR: c07dba40 CTR:
REGS: f1019d70 TRAP: 0700 Not tainted (5.9.0-rc2)
MSR: 00029032 CR: 22000888 XER:
GPR00: c07dba40 f1019e28 eeca3220 eef7ace0 4e999000 eef7d664 f1019e50
GPR08: 007c2315 0001 007c2315 f1019e48 22000888 c00054dc
GPR16: 2ef7d000 07c2 fff0 eef7b000 04e8
eef7d000
GPR24: eef7c5c0 007c2315 4e999000 c05ef548 eef7d664 c087cda8
007c2315
NIP [c002add4] set_pte_at+0x20/0x100
LR [c07dba40] debug_vm_pgtable+0x29c/0x654
Call Trace:
[f1019e28] [c002b4ac] pte_fragment_alloc+0x24/0xe4 (unreliable)
[f1019e48] [c07dba40] debug_vm_pgtable+0x29c/0x654
[f1019e98] [c0005160] do_one_initcall+0x70/0x158
[f1019ef8] [c07c352c] kernel_init_freeable+0x1f4/0x1f8
[f1019f28] [c00054f0] kernel_init+0x14/0xfc
[f1019f38] [c001516c] ret_from_kernel_thread+0x14/0x1c
Instruction dump:
57ff053e 39610010 7c63fa14 4800308c 9421ffe0 7c0802a6 8125 bfa10014
7cbd2b78 90010024 552907fe 83e6 <0f09> 3d20c089 83c91280 813e0018
---[ end trace 4ef67686e5133716 ]---
Although the warnings do no harm, I suspect that they should be fixed in case
some future modification turns the warning statements into BUGS.
The problem was bisected to commit a5c3b9ffb0f4 ("mm/debug_vm_pgtable: add tests
validating advanced arch page table helpers") by Anshuman Khandual
Thanks,
Larry
[PATCH v1 1/1] scsi: ufshcd: Allow zero value setting to Auto-Hibernate Timer
The zero value Auto-Hibernate Timer is a valid setting, and it
indicates the Auto-Hibernate feature being disabled. Correctly
support this setting. In addition, when this value is queried
from sysfs, read from the host controller's register and return
that value instead of using the RAM value.
Signed-off-by: Bao D. Nguyen
Signed-off-by: Asutosh Das
Signed-off-by: Can Guo
---
drivers/scsi/ufs/ufs-sysfs.c | 9 -
drivers/scsi/ufs/ufshcd.c| 2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 02d379f00..bdcd27f 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -146,12 +146,19 @@ static u32 ufshcd_us_to_ahit(unsigned int timer)
static ssize_t auto_hibern8_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
+ u32 ahit;
struct ufs_hba *hba = dev_get_drvdata(dev);
if (!ufshcd_is_auto_hibern8_supported(hba))
return -EOPNOTSUPP;
- return snprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(hba->ahit));
+ pm_runtime_get_sync(hba->dev);
+ ufshcd_hold(hba, false);
+ ahit = ufshcd_readl(hba, REG_AUTO_HIBERNATE_IDLE_TIMER);
+ ufshcd_release(hba);
+ pm_runtime_put_sync(hba->dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%d\n", ufshcd_ahit_to_us(ahit));
}
static ssize_t auto_hibern8_store(struct device *dev,
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 06e2439..ea5cc33 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3975,7 +3975,7 @@ void ufshcd_auto_hibern8_enable(struct ufs_hba *hba)
{
unsigned long flags;
- if (!ufshcd_is_auto_hibern8_supported(hba) || !hba->ahit)
+ if (!ufshcd_is_auto_hibern8_supported(hba))
return;
spin_lock_irqsave(hba->host->host_lock, flags);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH net-next v3 2/3] hinic: add support to query rq info
add debugfs node for querying rq info, for example:
cat /sys/kernel/debug/hinic/:15:00.0/RQs/0x0/rq_hw_pi
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
.../net/ethernet/huawei/hinic/hinic_debugfs.c | 66 +++
.../net/ethernet/huawei/hinic/hinic_debugfs.h | 8 +++
drivers/net/ethernet/huawei/hinic/hinic_dev.h | 2 +
.../net/ethernet/huawei/hinic/hinic_hw_io.c | 1 +
.../net/ethernet/huawei/hinic/hinic_hw_qp.h | 3 +
.../net/ethernet/huawei/hinic/hinic_main.c| 23 ++-
6 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
index 2a1050cb400e..d10d0a6d9f13 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
@@ -40,6 +40,36 @@ static u64 hinic_dbg_get_sq_info(struct hinic_dev *nic_dev,
struct hinic_sq *sq,
return 0;
}
+enum rq_dbg_info {
+ GLB_RQ_ID,
+ RQ_HW_PI,
+ RQ_SW_CI,
+ RQ_SW_PI,
+ RQ_MSIX_ENTRY,
+};
+
+static char *rq_fields[] = {"glb_rq_id", "rq_hw_pi", "rq_sw_ci", "rq_sw_pi",
"rq_msix_entry"};
+
+static u64 hinic_dbg_get_rq_info(struct hinic_dev *nic_dev, struct hinic_rq
*rq, int idx)
+{
+ struct hinic_wq *wq = rq->wq;
+
+ switch (idx) {
+ case GLB_RQ_ID:
+ return nic_dev->hwdev->func_to_io.global_qpn + rq->qid;
+ case RQ_HW_PI:
+ return be16_to_cpu(*(__be16 *)(rq->pi_virt_addr)) & wq->mask;
+ case RQ_SW_CI:
+ return atomic_read(>cons_idx) & wq->mask;
+ case RQ_SW_PI:
+ return atomic_read(>prod_idx) & wq->mask;
+ case RQ_MSIX_ENTRY:
+ return rq->msix_entry;
+ }
+
+ return 0;
+}
+
static ssize_t hinic_dbg_cmd_read(struct file *filp, char __user *buffer,
size_t count,
loff_t *ppos)
{
@@ -57,6 +87,10 @@ static ssize_t hinic_dbg_cmd_read(struct file *filp, char
__user *buffer, size_t
out = hinic_dbg_get_sq_info(dbg->dev, dbg->object, *desc);
break;
+ case HINIC_DBG_RQ_INFO:
+ out = hinic_dbg_get_rq_info(dbg->dev, dbg->object, *desc);
+ break;
+
default:
netif_warn(dbg->dev, drv, dbg->dev->netdev, "Invalid hinic
debug cmd: %d\n",
dbg->type);
@@ -128,6 +162,28 @@ void hinic_sq_debug_rem(struct hinic_sq *sq)
rem_dbg_files(sq->dbg);
}
+int hinic_rq_debug_add(struct hinic_dev *dev, u16 rq_id)
+{
+ struct hinic_rq *rq;
+ struct dentry *root;
+ char sub_dir[16];
+
+ rq = dev->rxqs[rq_id].rq;
+
+ sprintf(sub_dir, "0x%x", rq_id);
+
+ root = debugfs_create_dir(sub_dir, dev->rq_dbgfs);
+
+ return create_dbg_files(dev, HINIC_DBG_RQ_INFO, rq, root, >dbg,
rq_fields,
+ ARRAY_SIZE(rq_fields));
+}
+
+void hinic_rq_debug_rem(struct hinic_rq *rq)
+{
+ if (rq->dbg)
+ rem_dbg_files(rq->dbg);
+}
+
void hinic_sq_dbgfs_init(struct hinic_dev *nic_dev)
{
nic_dev->sq_dbgfs = debugfs_create_dir("SQs", nic_dev->dbgfs_root);
@@ -138,6 +194,16 @@ void hinic_sq_dbgfs_uninit(struct hinic_dev *nic_dev)
debugfs_remove_recursive(nic_dev->sq_dbgfs);
}
+void hinic_rq_dbgfs_init(struct hinic_dev *nic_dev)
+{
+ nic_dev->rq_dbgfs = debugfs_create_dir("RQs", nic_dev->dbgfs_root);
+}
+
+void hinic_rq_dbgfs_uninit(struct hinic_dev *nic_dev)
+{
+ debugfs_remove_recursive(nic_dev->rq_dbgfs);
+}
+
void hinic_dbg_init(struct hinic_dev *nic_dev)
{
nic_dev->dbgfs_root =
debugfs_create_dir(pci_name(nic_dev->hwdev->hwif->pdev),
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.h
b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.h
index 45fb3b40f487..186ca4a26919 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.h
@@ -12,10 +12,18 @@ int hinic_sq_debug_add(struct hinic_dev *dev, u16 sq_id);
void hinic_sq_debug_rem(struct hinic_sq *sq);
+int hinic_rq_debug_add(struct hinic_dev *dev, u16 rq_id);
+
+void hinic_rq_debug_rem(struct hinic_rq *rq);
+
void hinic_sq_dbgfs_init(struct hinic_dev *nic_dev);
void hinic_sq_dbgfs_uninit(struct hinic_dev *nic_dev);
+void hinic_rq_dbgfs_init(struct hinic_dev *nic_dev);
+
+void hinic_rq_dbgfs_uninit(struct hinic_dev *nic_dev);
+
void hinic_dbg_init(struct hinic_dev *nic_dev);
void hinic_dbg_uninit(struct hinic_dev *nic_dev);
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
index 95d9548014ac..0876a699d205 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
@@ -60,6 +60,7 @@ struct hinic_intr_coal_info {
enum hinic_dbg_type {
[PATCH net-next v3 1/3] hinic: add support to query sq info
add debugfs node for querying sq info, for example:
cat /sys/kernel/debug/hinic/:15:00.0/SQs/0x0/sq_pi
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
drivers/net/ethernet/huawei/hinic/Makefile| 3 +-
.../net/ethernet/huawei/hinic/hinic_debugfs.c | 162 ++
.../net/ethernet/huawei/hinic/hinic_debugfs.h | 27 +++
drivers/net/ethernet/huawei/hinic/hinic_dev.h | 15 ++
.../net/ethernet/huawei/hinic/hinic_hw_dev.c | 1 +
.../net/ethernet/huawei/hinic/hinic_hw_io.c | 1 +
.../net/ethernet/huawei/hinic/hinic_hw_io.h | 1 +
.../net/ethernet/huawei/hinic/hinic_hw_qp.h | 3 +
.../net/ethernet/huawei/hinic/hinic_main.c| 45 -
9 files changed, 254 insertions(+), 4 deletions(-)
create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_debugfs.h
diff --git a/drivers/net/ethernet/huawei/hinic/Makefile
b/drivers/net/ethernet/huawei/hinic/Makefile
index 67b59d0ba769..2f89119c9b69 100644
--- a/drivers/net/ethernet/huawei/hinic/Makefile
+++ b/drivers/net/ethernet/huawei/hinic/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_HINIC) += hinic.o
hinic-y := hinic_main.o hinic_tx.o hinic_rx.o hinic_port.o hinic_hw_dev.o \
hinic_hw_io.o hinic_hw_qp.o hinic_hw_cmdq.o hinic_hw_wq.o \
hinic_hw_mgmt.o hinic_hw_api_cmd.o hinic_hw_eqs.o hinic_hw_if.o \
- hinic_common.o hinic_ethtool.o hinic_devlink.o hinic_hw_mbox.o
hinic_sriov.o
+ hinic_common.o hinic_ethtool.o hinic_devlink.o hinic_hw_mbox.o \
+ hinic_sriov.o hinic_debugfs.o
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
new file mode 100644
index ..2a1050cb400e
--- /dev/null
+++ b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
@@ -0,0 +1,162 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/* Huawei HiNIC PCI Express Linux driver
+ * Copyright(c) 2017 Huawei Technologies Co., Ltd
+ */
+
+#include
+#include
+
+#include "hinic_debugfs.h"
+
+static struct dentry *hinic_dbgfs_root;
+
+enum sq_dbg_info {
+ GLB_SQ_ID,
+ SQ_PI,
+ SQ_CI,
+ SQ_FI,
+ SQ_MSIX_ENTRY,
+};
+
+static char *sq_fields[] = {"glb_sq_id", "sq_pi", "sq_ci", "sq_fi",
"sq_msix_entry"};
+
+static u64 hinic_dbg_get_sq_info(struct hinic_dev *nic_dev, struct hinic_sq
*sq, int idx)
+{
+ struct hinic_wq *wq = sq->wq;
+
+ switch (idx) {
+ case GLB_SQ_ID:
+ return nic_dev->hwdev->func_to_io.global_qpn + sq->qid;
+ case SQ_PI:
+ return atomic_read(>prod_idx) & wq->mask;
+ case SQ_CI:
+ return atomic_read(>cons_idx) & wq->mask;
+ case SQ_FI:
+ return be16_to_cpu(*(__be16 *)(sq->hw_ci_addr)) & wq->mask;
+ case SQ_MSIX_ENTRY:
+ return sq->msix_entry;
+ }
+
+ return 0;
+}
+
+static ssize_t hinic_dbg_cmd_read(struct file *filp, char __user *buffer,
size_t count,
+ loff_t *ppos)
+{
+ struct hinic_debug_priv *dbg;
+ char ret_buf[20];
+ int *desc;
+ u64 out;
+ int ret;
+
+ desc = filp->private_data;
+ dbg = container_of(desc, struct hinic_debug_priv, field_id[*desc]);
+
+ switch (dbg->type) {
+ case HINIC_DBG_SQ_INFO:
+ out = hinic_dbg_get_sq_info(dbg->dev, dbg->object, *desc);
+ break;
+
+ default:
+ netif_warn(dbg->dev, drv, dbg->dev->netdev, "Invalid hinic
debug cmd: %d\n",
+ dbg->type);
+ return -EINVAL;
+ }
+
+ ret = snprintf(ret_buf, sizeof(ret_buf), "0x%llx\n", out);
+
+ return simple_read_from_buffer(buffer, count, ppos, ret_buf, ret);
+}
+
+static const struct file_operations hinic_dbg_cmd_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .read = hinic_dbg_cmd_read,
+};
+
+static int create_dbg_files(struct hinic_dev *dev, enum hinic_dbg_type type,
void *data,
+ struct dentry *root, struct hinic_debug_priv **dbg,
char **field,
+ int nfile)
+{
+ struct hinic_debug_priv *tmp;
+ int i;
+
+ tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
+ if (!tmp)
+ return -ENOMEM;
+
+ tmp->dev = dev;
+ tmp->object = data;
+ tmp->type = type;
+ tmp->root = root;
+
+ for (i = 0; i < nfile; i++) {
+ tmp->field_id[i] = i;
+ debugfs_create_file(field[i], 0400, root, >field_id[i],
_dbg_cmd_fops);
+ }
+
+ *dbg = tmp;
+
+ return 0;
+}
+
+static void rem_dbg_files(struct hinic_debug_priv *dbg)
+{
+ debugfs_remove_recursive(dbg->root);
+ kfree(dbg);
+}
+
+int hinic_sq_debug_add(struct hinic_dev *dev, u16 sq_id)
+{
+ struct hinic_sq *sq;
+ struct dentry *root;
+
[PATCH net-next v3 3/3] hinic: add support to query function table
add debugfs node for querying function table, for example:
cat /sys/kernel/debug/hinic/:15:00.0/func_table/valid
Signed-off-by: Luo bin
---
V0~V1:
- remove command interfaces to the read only files
- split addition of each object into a separate patch
V1~V2:
- remove vlan_id and vlan_mode from the func_table_fields
V2~V3:
- remove rq_depth from the func_table_fields
.../net/ethernet/huawei/hinic/hinic_debugfs.c | 89 ++-
.../net/ethernet/huawei/hinic/hinic_debugfs.h | 79
drivers/net/ethernet/huawei/hinic/hinic_dev.h | 3 +
.../net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 +
.../net/ethernet/huawei/hinic/hinic_main.c| 15
5 files changed, 187 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
index d10d0a6d9f13..55a83137bb3c 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_debugfs.c
@@ -70,6 +70,60 @@ static u64 hinic_dbg_get_rq_info(struct hinic_dev *nic_dev,
struct hinic_rq *rq,
return 0;
}
+enum func_tbl_info {
+ VALID,
+ RX_MODE,
+ MTU,
+ QUEUE_NUM,
+};
+
+static char *func_table_fields[] = {"valid", "rx_mode", "mtu", "cfg_q_num"};
+
+static int hinic_dbg_get_func_table(struct hinic_dev *nic_dev, int idx)
+{
+ struct tag_sml_funcfg_tbl *funcfg_table_elem;
+ struct hinic_cmd_lt_rd *read_data;
+ u16 out_size = sizeof(*read_data);
+ int err;
+
+ read_data = kzalloc(sizeof(*read_data), GFP_KERNEL);
+ if (!read_data)
+ return ~0;
+
+ read_data->node = TBL_ID_FUNC_CFG_SM_NODE;
+ read_data->inst = TBL_ID_FUNC_CFG_SM_INST;
+ read_data->entry_size = HINIC_FUNCTION_CONFIGURE_TABLE_SIZE;
+ read_data->lt_index = HINIC_HWIF_FUNC_IDX(nic_dev->hwdev->hwif);
+ read_data->len = HINIC_FUNCTION_CONFIGURE_TABLE_SIZE;
+
+ err = hinic_port_msg_cmd(nic_dev->hwdev, HINIC_PORT_CMD_RD_LINE_TBL,
read_data,
+sizeof(*read_data), read_data, _size);
+ if (err || out_size != sizeof(*read_data) || read_data->status) {
+ netif_err(nic_dev, drv, nic_dev->netdev,
+ "Failed to get func table, err: %d, status: 0x%x, out
size: 0x%x\n",
+ err, read_data->status, out_size);
+ kfree(read_data);
+ return ~0;
+ }
+
+ funcfg_table_elem = (struct tag_sml_funcfg_tbl *)read_data->data;
+
+ switch (idx) {
+ case VALID:
+ return funcfg_table_elem->dw0.bs.valid;
+ case RX_MODE:
+ return funcfg_table_elem->dw0.bs.nic_rx_mode;
+ case MTU:
+ return funcfg_table_elem->dw1.bs.mtu;
+ case QUEUE_NUM:
+ return funcfg_table_elem->dw13.bs.cfg_q_num;
+ }
+
+ kfree(read_data);
+
+ return ~0;
+}
+
static ssize_t hinic_dbg_cmd_read(struct file *filp, char __user *buffer,
size_t count,
loff_t *ppos)
{
@@ -91,6 +145,10 @@ static ssize_t hinic_dbg_cmd_read(struct file *filp, char
__user *buffer, size_t
out = hinic_dbg_get_rq_info(dbg->dev, dbg->object, *desc);
break;
+ case HINIC_DBG_FUNC_TABLE:
+ out = hinic_dbg_get_func_table(dbg->dev, *desc);
+ break;
+
default:
netif_warn(dbg->dev, drv, dbg->dev->netdev, "Invalid hinic
debug cmd: %d\n",
dbg->type);
@@ -136,7 +194,9 @@ static int create_dbg_files(struct hinic_dev *dev, enum
hinic_dbg_type type, voi
static void rem_dbg_files(struct hinic_debug_priv *dbg)
{
- debugfs_remove_recursive(dbg->root);
+ if (dbg->type != HINIC_DBG_FUNC_TABLE)
+ debugfs_remove_recursive(dbg->root);
+
kfree(dbg);
}
@@ -184,6 +244,21 @@ void hinic_rq_debug_rem(struct hinic_rq *rq)
rem_dbg_files(rq->dbg);
}
+int hinic_func_table_debug_add(struct hinic_dev *dev)
+{
+ if (HINIC_IS_VF(dev->hwdev->hwif))
+ return 0;
+
+ return create_dbg_files(dev, HINIC_DBG_FUNC_TABLE, dev,
dev->func_tbl_dbgfs, >dbg,
+ func_table_fields,
ARRAY_SIZE(func_table_fields));
+}
+
+void hinic_func_table_debug_rem(struct hinic_dev *dev)
+{
+ if (!HINIC_IS_VF(dev->hwdev->hwif) && dev->dbg)
+ rem_dbg_files(dev->dbg);
+}
+
void hinic_sq_dbgfs_init(struct hinic_dev *nic_dev)
{
nic_dev->sq_dbgfs = debugfs_create_dir("SQs", nic_dev->dbgfs_root);
@@ -204,6 +279,18 @@ void hinic_rq_dbgfs_uninit(struct hinic_dev *nic_dev)
debugfs_remove_recursive(nic_dev->rq_dbgfs);
}
+void hinic_func_tbl_dbgfs_init(struct hinic_dev *nic_dev)
+{
+ if (!HINIC_IS_VF(nic_dev->hwdev->hwif))
+ nic_dev->func_tbl_dbgfs = debugfs_create_dir("func_table",
nic_dev->dbgfs_root);
+}
+
+void
[PATCH net-next v3 0/3] hinic: add debugfs support
add debugfs node for querying sq/rq info and function table Luo bin (3): hinic: add support to query sq info hinic: add support to query rq info hinic: add support to query function table drivers/net/ethernet/huawei/hinic/Makefile| 3 +- .../net/ethernet/huawei/hinic/hinic_debugfs.c | 315 ++ .../net/ethernet/huawei/hinic/hinic_debugfs.h | 114 +++ drivers/net/ethernet/huawei/hinic/hinic_dev.h | 20 ++ .../net/ethernet/huawei/hinic/hinic_hw_dev.c | 1 + .../net/ethernet/huawei/hinic/hinic_hw_dev.h | 2 + .../net/ethernet/huawei/hinic/hinic_hw_io.c | 2 + .../net/ethernet/huawei/hinic/hinic_hw_io.h | 1 + .../net/ethernet/huawei/hinic/hinic_hw_qp.h | 6 + .../net/ethernet/huawei/hinic/hinic_main.c| 83 - 10 files changed, 541 insertions(+), 6 deletions(-) create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_debugfs.c create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_debugfs.h -- 2.17.1
Re: [PATCH 3/4] sh: Add SECCOMP_FILTER
On Fri, Aug 28, 2020 at 01:03:00PM -0400, Rich Felker wrote: > On Fri, Aug 28, 2020 at 06:38:09PM +0200, John Paul Adrian Glaubitz wrote: > > Hi! > > > > On 8/28/20 6:30 PM, Rich Felker wrote: > > > I'm about to test a patch along these lines and will report what I > > > find. > > > > Let me know when you have something to test and I will test the patch as > > well, making sure we're not breaking seccomp again. > > If you have a seccomp test setup, please try the following patch. I'm > not sure if the end result is entirely correct, but I believe it's > at least much closer to correct than the code was before or after > adding SECCOMP_FILTER. > > > diff --git a/arch/sh/kernel/entry-common.S b/arch/sh/kernel/entry-common.S > index ad963104d22d..0560a8054215 100644 > --- a/arch/sh/kernel/entry-common.S > +++ b/arch/sh/kernel/entry-common.S > @@ -368,9 +368,6 @@ syscall_trace_entry: > mov.l 7f, r11 ! Call do_syscall_trace_enter which notifies > jsr @r11! superior (will chomp R[0-7]) >nop > - cmp/eq #-1, r0 > - bt syscall_exit > - mov.l r0, @(OFF_R0,r15) ! Save return value > ! Reload R0-R4 from kernel stack, where the > ! parent may have modified them using > ! ptrace(POKEUSR). (Note that R0-R2 are > @@ -382,7 +379,7 @@ syscall_trace_entry: > mov.l @(OFF_R5,r15), r5 > mov.l @(OFF_R6,r15), r6 > mov.l @(OFF_R7,r15), r7 ! arg3 > - mov.l @(OFF_R3,r15), r3 ! syscall_nr > + mov r0, r3 ! syscall_nr, possibly changed to -1 > ! > mov.l 6f, r10 ! Number of syscalls > cmp/hs r10, r3 > diff --git a/arch/sh/kernel/ptrace_32.c b/arch/sh/kernel/ptrace_32.c > index 25ccfbd02bfa..9e86cff041c7 100644 > --- a/arch/sh/kernel/ptrace_32.c > +++ b/arch/sh/kernel/ptrace_32.c > @@ -503,7 +503,7 @@ asmlinkage long do_syscall_trace_enter(struct pt_regs > *regs) > audit_syscall_entry(regs->regs[3], regs->regs[4], regs->regs[5], > regs->regs[6], regs->regs[7]); > > - return ret ?: regs->regs[0]; > + return ret ?: regs->regs[3]; > } > > asmlinkage void do_syscall_trace_leave(struct pt_regs *regs) This restored my ability to use strace, and I've written and tested a minimal strace-like hack using SECCOMP_RET_USER_NOTIF that works as expected on both j2 and qemu-system-sh4, so I think the above is correct. Rich
Re: [PATCH net-next v1 3/3] hinic: add support to query function table
On 2020/8/29 1:19, Jakub Kicinski wrote:
> On Fri, 28 Aug 2020 11:16:22 +0800 luobin (L) wrote:
>> On 2020/8/28 3:44, Jakub Kicinski wrote:
>>> On Thu, 27 Aug 2020 19:13:21 +0800 Luo bin wrote:
+ switch (idx) {
+ case VALID:
+ return funcfg_table_elem->dw0.bs.valid;
+ case RX_MODE:
+ return funcfg_table_elem->dw0.bs.nic_rx_mode;
+ case MTU:
+ return funcfg_table_elem->dw1.bs.mtu;
+ case VLAN_MODE:
+ return funcfg_table_elem->dw1.bs.vlan_mode;
+ case VLAN_ID:
+ return funcfg_table_elem->dw1.bs.vlan_id;
+ case RQ_DEPTH:
+ return funcfg_table_elem->dw13.bs.cfg_rq_depth;
+ case QUEUE_NUM:
+ return funcfg_table_elem->dw13.bs.cfg_q_num;
>>>
>>> The first two patches look fairly unobjectionable to me, but here the
>>> information does not seem that driver-specific. What's vlan_mode, and
>>> vlan_id in the context of PF? Why expose mtu, is it different than
>>> netdev mtu? What's valid? rq_depth?
>>> .
>>>
>> The vlan_mode and vlan_id in function table are provided for VF in QinQ
>> scenario
>> and they are useless for PF. Querying VF's function table is unsupported
>> now, so
>> there is no need to expose vlan_id and vlan mode and I'll remove them in my
>> next
>> patchset. The function table is saved in hw and we expose the mtu to ensure
>> the
>> mtu saved in hw is same with netdev mtu. The valid filed indicates whether
>> this
>> function is enabled or not and the hw can judge whether the RQ buffer in
>> host is
>> sufficient by comparing the values of rq depth, pi and ci.
>
> Queue depth is definitely something we can add to the ethtool API.
> You already expose raw producer and consumer indexes so the calculation
> can be done, anyway.
> .
>
Okay, I'll remove the queue depth as well. Thanks for your review.
Re: [RFC/RFT PATCH 2/6] arm64, numa: Change the numa init function name to be generic
On Fri, Aug 28, 2020 at 2:37 AM Jonathan Cameron
wrote:
>
> On Fri, 14 Aug 2020 14:47:21 -0700
> Atish Patra wrote:
>
> > As we are using generic numa implementation code, modify the init function
> > name to indicate that generic implementation.
> >
> > Signed-off-by: Atish Patra
> > ---
> > arch/arm64/mm/init.c | 4 ++--
> > drivers/base/arch_numa.c | 8 ++--
> > include/asm-generic/numa.h | 4 ++--
> > 3 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 481d22c32a2e..93b660229e1d 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -418,10 +418,10 @@ void __init bootmem_init(void)
> > max_pfn = max_low_pfn = max;
> > min_low_pfn = min;
> >
> > - arm64_numa_init();
> > + arch_numa_init();
> >
> > /*
> > - * must be done after arm64_numa_init() which calls numa_init() to
> > + * must be done after arch_numa_init() which calls numa_init() to
> >* initialize node_online_map that gets used in hugetlb_cma_reserve()
> >* while allocating required CMA size across online nodes.
> >*/
> > diff --git a/drivers/base/arch_numa.c b/drivers/base/arch_numa.c
> > index 73f8b49d485c..83341c807240 100644
> > --- a/drivers/base/arch_numa.c
> > +++ b/drivers/base/arch_numa.c
> > @@ -13,7 +13,9 @@
> > #include
> > #include
> >
> > +#ifdef CONFIG_ARM64
> > #include
> > +#endif
>
> This highlights an issue. We really don't want to define 'generic' arch
> code then match on individual architectures if at all possible.
>
I agree.
> I'm also not sure we need to.
>
> The arm64_acpi_numa_init() code is just a light wrapper around the
> standard acpi_init() call so should work fine on riscv (once ACPI
> support is ready).
>
> Can we pull that function into here
Sure. We can move the arm64_acpi_numa_init to here and rename it to
arch_acpi_numa_init.
We can keep arch_acpi_numa_init and the acpi.h included under CONFIG_ACPI_NUMA.
If RISC-V becomes ACPI ready one day, they always need to enable
CONFIG_ACPI_NUMA and reuse the generic functions.
> or perhaps a generic arch_numa_acpi.c?
>
There has not been much discussion about ACPI for RISC-V. So moving
the arm64 acpi code now to generic code would be premature
in my opinion. Currently, we don't even know how ACPI will look like
for RISC-V.
> There is probably a bit of a dance needed around acpi_disabled
> though as that can be defined in entirely different places
> depending on whether acpi is enabled or not.
> Possibly just adding an
>
> extern int acpi_disabled to include/linux/acpi.h when acpi is enabled
> will be sufficient (if ugly)?
>
We don't need to do that now unless we are moving arm64 ACPI code
implementation to generic code.
If ACPI is not enabled, it is already defined as a macro in
include/linux/acpi.h.
>
> > #include
> >
> > struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
> > @@ -445,16 +447,18 @@ static int __init dummy_numa_init(void)
> > }
> >
> > /**
> > - * arm64_numa_init() - Initialize NUMA
> > + * arch_numa_init() - Initialize NUMA
> > *
> > * Try each configured NUMA initialization method until one succeeds. The
> > * last fallback is dummy single node config encomapssing whole memory.
> > */
> > -void __init arm64_numa_init(void)
> > +void __init arch_numa_init(void)
> > {
> > if (!numa_off) {
> > +#ifdef CONFIG_ARM64
> > if (!acpi_disabled && !numa_init(arm64_acpi_numa_init))
> > return;
> > +#endif
> > if (acpi_disabled && !numa_init(of_numa_init))
> > return;
> > }
> > diff --git a/include/asm-generic/numa.h b/include/asm-generic/numa.h
> > index 0635c0724b7c..309eca8c0b5d 100644
> > --- a/include/asm-generic/numa.h
> > +++ b/include/asm-generic/numa.h
> > @@ -27,7 +27,7 @@ static inline const struct cpumask *cpumask_of_node(int
> > node)
> > }
> > #endif
> >
> > -void __init arm64_numa_init(void);
> > +void __init arch_numa_init(void);
> > int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > void __init numa_set_distance(int from, int to, int distance);
> > void __init numa_free_distance(void);
> > @@ -41,7 +41,7 @@ void numa_remove_cpu(unsigned int cpu);
> > static inline void numa_store_cpu_info(unsigned int cpu) { }
> > static inline void numa_add_cpu(unsigned int cpu) { }
> > static inline void numa_remove_cpu(unsigned int cpu) { }
> > -static inline void arm64_numa_init(void) { }
> > +static inline void arch_numa_init(void) { }
> > static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
> >
> > #endif /* CONFIG_NUMA */
>
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
--
Regards,
Atish
Re: [PATCH v4 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation
Rob Herring 於 2020年8月29日 週六 上午6:06寫道：
>
> On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add a devicetree binding documentation for the MT6360 Type-C driver.
> >
> > usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73
> > ++
> > 1 file changed, 73 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > new file mode 100644
> > index ..9e8ab0d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT
> > bindings
> > +
> > +maintainers:
> > + - ChiYuan Huang
> > +
> > +description: |
> > + Mediatek MT6360 is a multi-functional device. It integrates charger,
> > ADC, flash, RGB indicators,
> > + regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery
> > controller.
> > + This document only describes MT6360 Type-C Port Switch and Power
> > Delivery controller.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - mediatek,mt6360-tcpc
> > +
> > + interrupts-extended:
> > +maxItems: 1
> > +
> > + interrupt-names:
> > +items:
> > + - const: PD_IRQB
> > +
> > +patternProperties:
> > + "connector":
>
> Also, this is not a pattern, so should be under 'properties', and it
> doesn't need quotes.
Will be fixed in next patch.
>
> > +type: object
> > +$ref: ../connector/usb-connector.yaml#
> > +description:
> > + Properties for usb c connector.
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - interrupts-extended
> > + - interrupt-names
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +i2c0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +mt6360@34 {
> > +compatible = "mediatek,mt6360";
> > +reg = <0x34>;
> > +
> > +tcpc {
> > +compatible = "mediatek,mt6360-tcpc";
> > +interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
> > +interrupt-names = "PD_IRQB";
> > +
> > +connector {
> > +compatible = "usb-c-connector";
> > +label = "USB-C";
> > +data-role = "dual";
> > +power-role = "dual";
> > +try-power-role = "sink";
> > +source-pdos = > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > +sink-pdos = > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > +op-sink-microwatt = <1000>;
> > +};
> > +};
> > +};
> > +};
> > +...
> > --
> > 2.7.4
> >
Re: [PATCH v4 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation
Rob Herring 於 2020年8月29日 週六 上午6:05寫道：
>
> On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> > From: ChiYuan Huang
> >
> > Add a devicetree binding documentation for the MT6360 Type-C driver.
> >
> > usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
> >
> > Signed-off-by: ChiYuan Huang
> > ---
> > .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73
> > ++
> > 1 file changed, 73 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > new file mode 100644
> > index ..9e8ab0d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> > @@ -0,0 +1,73 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
> > +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> > +
> > +title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT
> > bindings
> > +
> > +maintainers:
> > + - ChiYuan Huang
> > +
> > +description: |
> > + Mediatek MT6360 is a multi-functional device. It integrates charger,
> > ADC, flash, RGB indicators,
> > + regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery
> > controller.
> > + This document only describes MT6360 Type-C Port Switch and Power
> > Delivery controller.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - mediatek,mt6360-tcpc
> > +
> > + interrupts-extended:
>
> Use 'interrupts'. The tooling will automatically support
> 'interrupts-extended'.
Okay.
>
> > +maxItems: 1
> > +
> > + interrupt-names:
> > +items:
> > + - const: PD_IRQB
> > +
> > +patternProperties:
> > + "connector":
> > +type: object
> > +$ref: ../connector/usb-connector.yaml#
> > +description:
> > + Properties for usb c connector.
> > +
> > +additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - interrupts-extended
> > + - interrupt-names
> > +
> > +examples:
> > + - |
> > +#include
> > +#include
> > +i2c0 {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +mt6360@34 {
> > +compatible = "mediatek,mt6360";
> > +reg = <0x34>;
> > +
> > +tcpc {
> > +compatible = "mediatek,mt6360-tcpc";
> > +interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
> > +interrupt-names = "PD_IRQB";
> > +
> > +connector {
>
> Where's the data connections? The assumption of the binding is the USB
> (2 and 3) connections come from the parent if there's no graph to the
> USB controller(s).
MT6360 is only a subpmic. TypeC part only handle the CC logic to support USBPD.
For the usb connection like as usbhs/usbss, it need to be handled
by/connect to application processor side.
LIke as connector/usb-connector.yaml decribed, it specify the port
property to bind USB HS/SS.
>
> > +compatible = "usb-c-connector";
> > +label = "USB-C";
> > +data-role = "dual";
> > +power-role = "dual";
> > +try-power-role = "sink";
> > +source-pdos = > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > +sink-pdos = > PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> > +op-sink-microwatt = <1000>;
> > +};
> > +};
> > +};
> > +};
> > +...
> > --
> > 2.7.4
> >
Re: [RFC/RFT PATCH 1/6] numa: Move numa implementation to common code
On Fri, Aug 28, 2020 at 2:24 AM Jonathan Cameron
wrote:
>
> On Fri, 14 Aug 2020 14:47:20 -0700
> Atish Patra wrote:
>
> > ARM64 numa implementation is generic enough that RISC-V can reuse that
> > implementation with very minor cosmetic changes. This will help both
> > ARM64 and RISC-V in terms of maintanace and feature improvement
> >
> > Move the numa implementation code to common directory so that both ISAs
> > can reuse this. This doesn't introduce any function changes for ARM64.
> >
> > Signed-off-by: Atish Patra
> Hi Atish,
>
> One trivial question inline. Otherwise subject to Anshuman's point about
> location, this looks fine to me.
>
> I'll run some sanity checks later.
>
> Jonathan
> > ---
> > arch/arm64/Kconfig| 1 +
> > arch/arm64/include/asm/numa.h | 45 +---
> > arch/arm64/mm/Makefile| 1 -
> > drivers/base/Kconfig | 6 +++
> > drivers/base/Makefile | 1 +
> > .../mm/numa.c => drivers/base/arch_numa.c | 0
> > include/asm-generic/numa.h| 51 +++
> > 7 files changed, 60 insertions(+), 45 deletions(-)
> > rename arch/arm64/mm/numa.c => drivers/base/arch_numa.c (100%)
> > create mode 100644 include/asm-generic/numa.h
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 6d232837cbee..955a0cf75b16 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -960,6 +960,7 @@ config HOTPLUG_CPU
> > # Common NUMA Features
> > config NUMA
> > bool "NUMA Memory Allocation and Scheduler Support"
> > + select GENERIC_ARCH_NUMA
> > select ACPI_NUMA if ACPI
> > select OF_NUMA
> > help
> > diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> > index 626ad01e83bf..8c8cf4297cc3 100644
> > --- a/arch/arm64/include/asm/numa.h
> > +++ b/arch/arm64/include/asm/numa.h
> > @@ -3,49 +3,6 @@
> > #define __ASM_NUMA_H
> >
> > #include
> > -
> > -#ifdef CONFIG_NUMA
> > -
> > -#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
> > -
> > -int __node_distance(int from, int to);
> > -#define node_distance(a, b) __node_distance(a, b)
> > -
> > -extern nodemask_t numa_nodes_parsed __initdata;
> > -
> > -extern bool numa_off;
> > -
> > -/* Mappings between node number and cpus on that node. */
> > -extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
> > -void numa_clear_node(unsigned int cpu);
> > -
> > -#ifdef CONFIG_DEBUG_PER_CPU_MAPS
> > -const struct cpumask *cpumask_of_node(int node);
> > -#else
> > -/* Returns a pointer to the cpumask of CPUs on Node 'node'. */
> > -static inline const struct cpumask *cpumask_of_node(int node)
> > -{
> > - return node_to_cpumask_map[node];
> > -}
> > -#endif
> > -
> > -void __init arm64_numa_init(void);
> > -int __init numa_add_memblk(int nodeid, u64 start, u64 end);
> > -void __init numa_set_distance(int from, int to, int distance);
> > -void __init numa_free_distance(void);
> > -void __init early_map_cpu_to_node(unsigned int cpu, int nid);
> > -void numa_store_cpu_info(unsigned int cpu);
> > -void numa_add_cpu(unsigned int cpu);
> > -void numa_remove_cpu(unsigned int cpu);
> > -
> > -#else/* CONFIG_NUMA */
> > -
> > -static inline void numa_store_cpu_info(unsigned int cpu) { }
> > -static inline void numa_add_cpu(unsigned int cpu) { }
> > -static inline void numa_remove_cpu(unsigned int cpu) { }
> > -static inline void arm64_numa_init(void) { }
> > -static inline void early_map_cpu_to_node(unsigned int cpu, int nid) { }
> > -
> > -#endif /* CONFIG_NUMA */
> > +#include
> >
> > #endif /* __ASM_NUMA_H */
> > diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> > index d91030f0ffee..928c308b044b 100644
> > --- a/arch/arm64/mm/Makefile
> > +++ b/arch/arm64/mm/Makefile
> > @@ -6,7 +6,6 @@ obj-y := dma-mapping.o extable.o
> > fault.o init.o \
> > obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> > obj-$(CONFIG_PTDUMP_CORE)+= dump.o
> > obj-$(CONFIG_PTDUMP_DEBUGFS) += ptdump_debugfs.o
> > -obj-$(CONFIG_NUMA) += numa.o
> > obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> > KASAN_SANITIZE_physaddr.o+= n
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> > index 8d7001712062..73c2151de194 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -210,4 +210,10 @@ config GENERIC_ARCH_TOPOLOGY
> > appropriate scaling, sysfs interface for reading capacity values at
> > runtime.
> >
> > +config GENERIC_ARCH_NUMA
> > + bool
> > + help
> > + Enable support for generic numa implementation. Currently, RISC-V
> > + and ARM64 uses it.
> > +
> > endmenu
> > diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> > index 157452080f3d..c3d02c644222 100644
> > --- a/drivers/base/Makefile
> > +++ b/drivers/base/Makefile
> > @@ -23,6 +23,7 @@ obj-$(CONFIG_PINCTRL) += pinctrl.o
> >
include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in '__msm_console_write' - unexpected unlock
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 005c53447a63cbce10de37406975a34d7bdc8704
commit: 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e tty: serial: msm_serial: Fix
lockup for sysrq and oops
date: 9 months ago
config: arm64-randconfig-s031-20200829 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-191-g10164920-dirty
git checkout 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
drivers/tty/serial/msm_serial.c:736:25: sparse: sparse: context imbalance in
'msm_handle_rx_dm' - unexpected unlock
drivers/tty/serial/msm_serial.c:802:28: sparse: sparse: context imbalance in
'msm_handle_rx' - unexpected unlock
drivers/tty/serial/msm_serial.c:1100:12: sparse: sparse: context imbalance
in 'msm_set_baud_rate' - unexpected unlock
drivers/tty/serial/msm_serial.c: note: in included file (through
arch/arm64/include/generated/asm/qspinlock.h,
arch/arm64/include/asm/spinlock.h, include/linux/spinlock.h, ...):
>> include/asm-generic/qspinlock.h:94:9: sparse: sparse: context imbalance in
>> '__msm_console_write' - unexpected unlock
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 0e4f7f920a5c6bfe5e851e989f27b35a0cc7fb7e
vim +/__msm_console_write +94 include/asm-generic/qspinlock.h
a33fda35e3a765 Waiman Long 2015-04-24 83
a33fda35e3a765 Waiman Long 2015-04-24 84 #ifndef queued_spin_unlock
a33fda35e3a765 Waiman Long 2015-04-24 85 /**
a33fda35e3a765 Waiman Long 2015-04-24 86 * queued_spin_unlock - release a
queued spinlock
a33fda35e3a765 Waiman Long 2015-04-24 87 * @lock : Pointer to queued
spinlock structure
a33fda35e3a765 Waiman Long 2015-04-24 88 */
a33fda35e3a765 Waiman Long 2015-04-24 89 static __always_inline void
queued_spin_unlock(struct qspinlock *lock)
a33fda35e3a765 Waiman Long 2015-04-24 90 {
a33fda35e3a765 Waiman Long 2015-04-24 91 /*
ca50e426f96c90 Pan Xinhui 2016-06-03 92* unlock() needs release
semantics:
a33fda35e3a765 Waiman Long 2015-04-24 93*/
626e5fbc143589 Will Deacon 2018-04-26 @94
smp_store_release(>locked, 0);
a33fda35e3a765 Waiman Long 2015-04-24 95 }
a33fda35e3a765 Waiman Long 2015-04-24 96 #endif
a33fda35e3a765 Waiman Long 2015-04-24 97
:: The code at line 94 was first introduced by commit
:: 626e5fbc14358901ddaa90ce510e0fbeab310432 locking/qspinlock: Use
smp_store_release() in queued_spin_unlock()
:: TO: Will Deacon
:: CC: Ingo Molnar
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH v36 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
On Thu, Aug 27, 2020 at 04:24:50PM +0300, Jarkko Sakkinen wrote: > > > + * @arg: userspace pointer to a struct sgx_enclave_create instance > > > + * > > > + * Allocate kernel data structures for a new enclave and execute ECREATE > > > after > > > + * verifying the correctness of the provided SECS. > > > + * > > > + * Note, enforcement of restricted and disallowed attributes is deferred > > > until > > > + * sgx_ioc_enclave_init(), only the architectural correctness of the > > > SECS is > > > + * checked by sgx_ioc_enclave_create(). > > > > From that same review: > > > > "Well, I don't see that checking. Where is it?" > > > > Ok, I'm going to stop here. Please go over v33's review and either > > address *all* feedback or incorporate it into your patches if you agree > > with it but do not silently ignore it. One of the things I very strongly > > detest is ignored review comments. OK, so sgx_validate_secs() is the validation of what the CPU requires from the contents of the SECS. That is mean by "architectural correctness". I spotted the glitch that makes this confusing. The change that the comment is related is https://lore.kernel.org/linux-sgx/20200716135303.276442-16-jarkko.sakki...@linux.intel.com/ This check in sgx_encl_init() should be relocated to this commit: /* Check that the required attributes have been authorized. */ if (encl->secs_attributes & ~encl->allowed_attributes) return -EACCES; It is the "enforcement of restricted and disallowed attributes" part. Does this make sense to you? > > -- > > Regards/Gruss, > > Boris. /Jarkko
Re: [PATCH v6 2/2] ASoC: qcom: sc7180: Add machine driver for sound card registration
+config SND_SOC_SC7180 + tristate "SoC Machine driver for SC7180 boards" + depends on SND_SOC_QCOM this depends is probably not necessary, the code is already in an if case. + select SND_SOC_QCOM_COMMON + select SND_SOC_LPASS_SC7180 + select SND_SOC_MAX98357A + select SND_SOC_RT5682 I haven't done any significant testing / review of your patch (I'm mostly sound-clueless), but I believe that the above needs to be "select SND_SOC_RT5682_I2C" atop the current top of the sound tree. When I fix that I can confirm that I see the rt5682 probe on sc7180-trogdor with Rob Clark's dts patch. Ack, no one should select SND_SOC_RT5682 directly in machine drivers. now that the code is split between I2C and SoundWire parts. There should probably be a depends on I2C as well?
[PATCH] microblaze: fix min_low_pfn/max_low_pfn build errors
Fix min_low_pfn/max_low_pfn build errors for arch/microblaze/: (e.g.) ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu_sink.ko] undefined! ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! ERROR: "min_low_pfn" [drivers/mmc/core/mmc_core.ko] undefined! ERROR: "min_low_pfn" [drivers/md/dm-crypt.ko] undefined! ERROR: "min_low_pfn" [drivers/net/wireless/ath/ath6kl/ath6kl_sdio.ko] undefined! ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! ERROR: "min_low_pfn" [crypto/asymmetric_keys/asym_tpm.ko] undefined! Mike had/has an alternate patch for Microblaze: https://lore.kernel.org/lkml/20200630111519.ga1951...@linux.ibm.com/ David suggested just exporting min_low_pfn & max_low_pfn in mm/memblock.c: https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: linux...@kvack.org Cc: Andrew Morton Cc: David Rientjes Cc: Mike Rapoport Cc: Michal Simek Cc: Michal Simek --- arch/microblaze/mm/init.c |3 +++ 1 file changed, 3 insertions(+) --- linux-next-20200825.orig/arch/microblaze/mm/init.c +++ linux-next-20200825/arch/microblaze/mm/init.c @@ -46,6 +46,9 @@ unsigned long memory_size; EXPORT_SYMBOL(memory_size); unsigned long lowmem_size; +EXPORT_SYMBOL(min_low_pfn); +EXPORT_SYMBOL(max_low_pfn); + #ifdef CONFIG_HIGHMEM pte_t *kmap_pte; EXPORT_SYMBOL(kmap_pte);
[PATCH] ia64: fix min_low_pfn/max_low_pfn build errors
Fix min_low_pfn/max_low_pfn build errors for arch/ia64/: (e.g.) ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined! ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined! ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined! ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! ERROR: "min_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] undefined! ERROR: "max_low_pfn" [security/keys/encrypted-keys/encrypted-keys.ko] undefined! ERROR: "min_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! ERROR: "max_low_pfn" [arch/ia64/kernel/mca_recovery.ko] undefined! David suggested just exporting min_low_pfn & max_low_pfn in mm/memblock.c: https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: linux...@kvack.org Cc: Andrew Morton Cc: David Rientjes Cc: Mike Rapoport Cc: Tony Luck Cc: Fenghua Yu Cc: linux-i...@vger.kernel.org --- arch/ia64/kernel/ia64_ksyms.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20200825.orig/arch/ia64/kernel/ia64_ksyms.c +++ linux-next-20200825/arch/ia64/kernel/ia64_ksyms.c @@ -3,7 +3,7 @@ * Architecture-specific kernel symbols */ -#ifdef CONFIG_VIRTUAL_MEM_MAP +#if defined(CONFIG_VIRTUAL_MEM_MAP) || defined(CONFIG_DISCONTIGMEM) #include #include #include
[PATCH] iio: sx9310: Prefer async probe
On one board I found that:
probe of 5-0028 returned 1 after 259547 usecs
There's no reason to block probe of all other devices on our probe.
Turn on async probe.
Signed-off-by: Douglas Anderson
---
NOTE: I haven't done any analysis of the driver to see _why_ it's so
slow, only that I have measured it to be slow. Someone could
certainly take the time to profile / optimize it, but in any case it
still won't hurt to be async.
This is a very safe flag to turn on since:
1. It's not like our probe order was defined by anything anyway. When
we probe is at the whim of when our i2c controller probes and that can
be any time.
2. If some other driver needs us then they have to handle the fact
that we might not have probed yet anyway.
3. There may be other drivers probing at the same time as us anyway
because _they_ used async probe.
While I won't say that it's impossible to tickle a bug by turning on
async probe, I would assert that in almost all cases the bug was
already there and needed to be fixed anyway.
ALSO NOTE: measurement / testing was done on the downstream Chrome OS
5.4 tree. I confirmed compiling on mainline.
drivers/iio/proximity/sx9310.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iio/proximity/sx9310.c b/drivers/iio/proximity/sx9310.c
index dc2e11b43431..444cafc53408 100644
--- a/drivers/iio/proximity/sx9310.c
+++ b/drivers/iio/proximity/sx9310.c
@@ -1054,6 +1054,7 @@ static struct i2c_driver sx9310_driver = {
.acpi_match_table = ACPI_PTR(sx9310_acpi_match),
.of_match_table = of_match_ptr(sx9310_of_match),
.pm = _pm_ops,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.probe = sx9310_probe,
.id_table = sx9310_id,
--
2.28.0.402.g5ffc5be6b7-goog
[ALTERNATE PATCH] memblock: fix min_low_pfn/max_low_pfn build errors
Export min_low_pfn & max_low_pfn in mm/memblock.c to fix build errors on arch/microblaze/ and arch/ia64/: (e.g.) ERROR: "max_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "min_low_pfn" [drivers/rpmsg/virtio_rpmsg_bus.ko] undefined! ERROR: "max_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined! ERROR: "min_low_pfn" [drivers/mtd/spi-nor/spi-nor.ko] undefined! ERROR: "min_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! ERROR: "max_low_pfn" [drivers/mtd/nand/raw/nand.ko] undefined! ERROR: "max_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined! ERROR: "min_low_pfn" [drivers/rapidio/devices/rio_mport_cdev.ko] undefined! ERROR: "min_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! ERROR: "max_low_pfn" [drivers/hwtracing/intel_th/intel_th_msu.ko] undefined! ERROR: "min_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: "max_low_pfn" [drivers/crypto/cavium/nitrox/n5pf.ko] undefined! ERROR: "max_low_pfn" [drivers/md/dm-integrity.ko] undefined! ERROR: "min_low_pfn" [drivers/md/dm-integrity.ko] undefined! ERROR: "max_low_pfn" [crypto/tcrypt.ko] undefined! ERROR: "min_low_pfn" [crypto/tcrypt.ko] undefined! In both arches, these variables are referenced in arch/$ARCH/include/asm/page.h. Mike had/has an alternate patch for Microblaze: https://lore.kernel.org/lkml/20200630111519.ga1951...@linux.ibm.com/ David suggested just exporting min_low_pfn & max_low_pfn in mm/memblock.c: https://lore.kernel.org/lkml/alpine.deb.2.22.394.2006291911220.1118...@chino.kir.corp.google.com/ Reported-by: kernel test robot Suggested-by: David Rientjes Signed-off-by: Randy Dunlap Cc: linux...@kvack.org Cc: Andrew Morton Cc: David Rientjes Cc: Mike Rapoport Cc: Michal Simek Cc: Michal Simek Cc: Tony Luck Cc: Fenghua Yu Cc: linux-i...@vger.kernel.org --- mm/memblock.c |2 ++ 1 file changed, 2 insertions(+) --- linux-next-20200825.orig/mm/memblock.c +++ linux-next-20200825/mm/memblock.c @@ -99,6 +99,8 @@ EXPORT_SYMBOL(contig_page_data); unsigned long max_low_pfn; unsigned long min_low_pfn; +EXPORT_SYMBOL(min_low_pfn); +EXPORT_SYMBOL(max_low_pfn); unsigned long max_pfn; unsigned long long max_possible_pfn;
[PATCH] spmi: prefix spmi bus device names with "spmi"
Change the format of spmi bus device names from:
-
Example: 0-01
to this:
spmi-
Example: spmi0-01
This helps to disambiguate SPMI device regmaps from I2C ones
at /sys/kernel/debug/regmap since I2C devices use a very
similar naming scheme: 0-.
Signed-off-by: David Collins
---
drivers/spmi/spmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spmi/spmi.c b/drivers/spmi/spmi.c
index c16b60f..ec94439 100644
--- a/drivers/spmi/spmi.c
+++ b/drivers/spmi/spmi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012-2015, 2020, The Linux Foundation. All rights reserved.
*/
#include
#include
@@ -62,7 +62,7 @@ int spmi_device_add(struct spmi_device *sdev)
struct spmi_controller *ctrl = sdev->ctrl;
int err;
- dev_set_name(>dev, "%d-%02x", ctrl->nr, sdev->usid);
+ dev_set_name(>dev, "spmi%d-%02x", ctrl->nr, sdev->usid);
err = device_add(>dev);
if (err < 0) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: linux-next: build failure after merge of the net-next tree
On 8/28/20 4:16 PM, Brian Vazquez wrote:
> On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap wrote:
>>
>> On 8/28/20 8:09 AM, Sven Joachim wrote:
>>> On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
>>>
I've been trying to reproduce it with your config but I didn't
succeed. I also looked at the file after the preprocessor and it
looked good:
ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
>>>
>>> However, in my configuration I have CONFIG_IPV6=m, and so
>>> fib6_rule_match is not available as a builtin. I think that's why ld is
>>> complaining about the undefined reference.
>>
>> Same here FWIW. CONFIG_IPV6=m.
>
> Oh I see,
> I tried this and it seems to work fine for me, does this also fix your
> problem? if so, I'll prepare the patch, and thanks for helping!
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index 51678a528f85..40dfd1f55899 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -16,7 +16,7 @@
> #include
> #include
>
> -#ifdef CONFIG_IPV6_MULTIPLE_TABLES
> +#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6)
Yes, that works for me.
You can add this to your patch:
Acked-by: Randy Dunlap # build-tested
thanks.
--
~Randy
Re: [GIT PULL] io_uring fixes for 5.9-rc3
The pull request you sent on Fri, 28 Aug 2020 14:03:22 -0600: > git://git.kernel.dk/linux-block.git tags/io_uring-5.9-2020-08-28 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/24148d8648e37f8c15bedddfa50d14a31a0582c5 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v36 12/24] x86/sgx: Add SGX_IOC_ENCLAVE_CREATE
On Thu, Aug 27, 2020 at 06:15:27PM +0200, Borislav Petkov wrote: > On Thu, Aug 27, 2020 at 04:24:36PM +0300, Jarkko Sakkinen wrote: > > I have not checked if this passes checkpatch.pl yet, but I would > > be surprised if that did not pass (obviously I'll check that). > > Right, when you're done with the patchset, just do > > checkpatch.pl -g ... > > on it before sending and you'll be good to go. Just remember to read the > suggestions checkpatch gives with turned on brain and sanity-check them > instead of blindly following them. > > > I'm sorry about that. This was not intentional. I'll revisit them by > > going through all your responses from here: > > > > https://patchwork.kernel.org/patch/11581715/ > > Actually this one: > > https://lkml.kernel.org/r/20200617220844.57423-12-jarkko.sakki...@linux.intel.com > > i.e., the v33 version. Ya, pasted wrong link, sorry :-) > > Also, make sure you go through the review comments of v34 and v35 in > case you haven't done so yet. I'll re-check them before I send a new version. > > v34 had the splitting of the big driver patch into multiple patches. > > > > During that process I've obviously failed to address these. > > Yeah, that can happen - I mean, this is not even close to being an easy > patchset so thanks for putting in the effort. I'd guess that this will get less painful given that the patches are now more reasonably sizeda after chopping the driver patch. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette /Jarkko
Re: [PATCH v36 22/24] selftests/x86: Add a selftest for SGX
On Thu, Aug 27, 2020 at 08:20:51AM -0700, Sean Christopherson wrote:
> On Thu, Aug 27, 2020 at 12:47:04AM -0400, Nathaniel McCallum wrote:
> > > +int main(int argc, char *argv[], char *envp[])
> > > +{
> > > + struct sgx_enclave_exception exception;
> > > + struct vdso_symtab symtab;
> > > + Elf64_Sym *eenter_sym;
> > > + uint64_t result = 0;
> > > + struct encl encl;
> > > + unsigned int i;
> > > + void *addr;
> > > +
> > > + if (!encl_load("test_encl.elf", ))
> > > + goto err;
> > > +
> > > + if (!encl_measure())
> > > + goto err;
> > > +
> > > + if (!encl_build())
> > > + goto err;
> > > +
> > > + /*
> > > +* An enclave consumer only must do this.
> > > +*/
> > > + for (i = 0; i < encl.nr_segments; i++) {
> > > + struct encl_segment *seg = _tbl[i];
> > > +
> > > + addr = mmap((void *)encl.encl_base + seg->offset,
> > > seg->size,
> > > + seg->prot, MAP_SHARED | MAP_FIXED, encl.fd,
> > > 0);
> >
> > My patch version is a bit behind (v32), but I suspect this still
> > applies. I discovered the following by accident.
> >
> > In the Enarx code base, this invocation succeeds:
> > mmap(0x2000, 0x1000, PROT_READ | PROT_WRITE, MAP_SHARED |
> > MAP_FIXED, sgxfd, 0)
> >
> > However, this one fails with -EINVAL:
> > mmap(0x2000, 0x1000, PROT_READ | PROT_WRITE,
> > MAP_SHARED_VALIDATE | MAP_FIXED, sgxfd, 0)
> >
> > From man mmap:
> >
> >MAP_SHARED_VALIDATE (since Linux 4.15)
> > This flag provides the same behavior as MAP_SHARED
> > except that MAP_SHARED mappings ignore unknown
> > flags in flags. By contrast, when creating a mapping
> > using MAP_SHARED_VALIDATE, the kernel veri‐
> > fies all passed flags are known and fails the
> > mapping with the error EOPNOTSUPP for unknown
> > flags. This mapping type is also required to be able to
> > use some mapping flags (e.g., MAP_SYNC).
> >
> > I can try again on a newer patch set tomorrow if need be. But the
> > documentation of mmap() doesn't match the behavior I'm seeing. A brief
> > look through the patch set didn't turn up anything obvious that could
> > be causing this.
>
> This is a bug in sgx_get_unmapped_area(). EPC must be mapped SHARED, and
> so MAP_PRIVATE is disallowed. The current check is:
>
> if (flags & MAP_PRIVATE)
> return -EINVAL;
>
> and the base "flags" are:
>
> #define MAP_SHARED 0x01/* Share changes */
> #define MAP_PRIVATE 0x02/* Changes are private */
> #define MAP_SHARED_VALIDATE 0x03/* share + validate extension flags
> */
>
> which causes the SGX check to interpret MAP_SHARED_VALIDATE as MAP_PRIVATE.
> The types are just that, types, not flag modifiers. So the SGX code needs
> to be:
>
> if ((flags & MAP_TYPE) == MAP_PRIVATE)
> return -EINVAL;
Updated, thanks.
/Jarkko
Re: [RFC PATCH v7 09/23] sched/fair: Fix forced idle sibling starvation corner case
On 8/28/20 5:25 PM, Peter Zijlstra wrote:
The only pupose of this loop seem to be to find if we have a forceidle;
surely we can avoid that by storing this during the pick.
The idea was to kick each cpu that was force idle. But now, thinking
about it, we just need to kick one as it will pick for all the siblings.
Will optimize this as you suggested.
static void task_tick_core(struct rq *rq)
{
if (sched_core_enabled(rq))
resched_forceidle_sibling(rq, >curr->se);
}
#else
static void task_tick_core(struct rq *rq) { }
+#endif
+
/*
* scheduler tick hitting a task of our scheduling class.
*
@@ -10654,6 +10688,11 @@ static void task_tick_fair(struct rq *rq, struct
task_struct *curr, int queued)
update_misfit_status(curr, rq);
update_overutilized_status(task_rq(curr));
+
+#ifdef CONFIG_SCHED_CORE
+ if (sched_core_enabled(rq))
+ resched_forceidle_sibling(rq, >se);
+#endif
Then you can ditch the #ifdef here
Makes sense, will do.
Thanks,
Vineeth
Re: [PATCH 4.19 1/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
On 8/28/20 4:15 PM, Sasha Levin wrote:
On Fri, Aug 28, 2020 at 03:25:11PM -0700, Sowjanya Komatineni wrote:
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
What does this line above represent?
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set incorrectly in above commit
when Tegra210 support was added.
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra210.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Acked-by: Adrian Hunter
Signed-off-by: Sowjanya Komatineni
[PATCH] ASoC: rt5682: Prefer async probe
The probe of rt5682 is pretty slow. A quick measurement shows that it
takes ~650 ms on at least one board. There's no reason to block all
other drivers waiting for this probe to finish. Set the flag to allow
other drivers to probe while we're probing.
Signed-off-by: Douglas Anderson
---
NOTE: I haven't done any analysis of the driver to see _why_ it's so
slow, only that I have measured it to be slow. Someone could
certainly take the time to profile / optimize it, but in any case it
still won't hurt to be async.
This is a very safe flag to turn on since:
1. It's not like our probe order was defined by anything anyway. When
we probe is at the whim of when our i2c controller probes and that can
be any time.
2. If some other driver needs us then they have to handle the fact
that we might not have probed yet anyway.
3. There may be other drivers probing at the same time as us anyway
because _they_ used async probe.
While I won't say that it's impossible to tickle a bug by turning on
async probe, I would assert that in almost all cases the bug was
already there and needed to be fixed anyway.
sound/soc/codecs/rt5682-i2c.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c
index 85aba311bdc8..6b4e0eb30c89 100644
--- a/sound/soc/codecs/rt5682-i2c.c
+++ b/sound/soc/codecs/rt5682-i2c.c
@@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = {
.name = "rt5682",
.of_match_table = rt5682_of_match,
.acpi_match_table = rt5682_acpi_match,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
},
.probe = rt5682_i2c_probe,
.shutdown = rt5682_i2c_shutdown,
--
2.28.0.402.g5ffc5be6b7-goog
Re: linux-next: build failure after merge of the net-next tree
On Fri, Aug 28, 2020 at 8:12 AM Randy Dunlap wrote:
>
> On 8/28/20 8:09 AM, Sven Joachim wrote:
> > On 2020-08-27 11:12 -0700, Brian Vazquez wrote:
> >
> >> I've been trying to reproduce it with your config but I didn't
> >> succeed. I also looked at the file after the preprocessor and it
> >> looked good:
> >>
> >> ret = ({ __builtin_expect(!!(ops->match == fib6_rule_match), 1) ?
> >> fib6_rule_match(rule, fl, flags) : ops->match(rule, fl, flags); })
> >
> > However, in my configuration I have CONFIG_IPV6=m, and so
> > fib6_rule_match is not available as a builtin. I think that's why ld is
> > complaining about the undefined reference.
>
> Same here FWIW. CONFIG_IPV6=m.
Oh I see,
I tried this and it seems to work fine for me, does this also fix your
problem? if so, I'll prepare the patch, and thanks for helping!
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 51678a528f85..40dfd1f55899 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -16,7 +16,7 @@
#include
#include
-#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+#if defined(CONFIG_IPV6_MULTIPLE_TABLES) && defined(CONFIG_IPV6)
>
>
> > Changing the configuration to CONFIG_IPV6=y helps, FWIW.
> >
> >> Note that fib4_rule_match doesn't appear as the
> >> CONFIG_IP_MULTIPLE_TABLES is not there.
> >>
> >> Could you share more details on how you're compiling it and what
> >> compiler you're using??
> >
> > Tried with both gcc 9 and gcc 10 under Debian unstable, binutils 2.35.
> > I usually use "make bindebpkg", but just running "make" is sufficient to
> > reproduce the problem, as it happens when linking vmlinux.
> >
> > Cheers,
> >Sven
> >
> >
> >> On Mon, Aug 24, 2020 at 1:08 AM Sven Joachim wrote:
> >>>
> >>> On 2020-08-22 08:16 +0200, Sven Joachim wrote:
> >>>
> On 2020-08-21 09:23 -0700, Brian Vazquez wrote:
>
> > Hi Sven,
> >
> > Sorry for the late reply, did you still see this after:
> > https://patchwork.ozlabs.org/project/netdev/patch/20200803131948.41736-1-yuehaib...@huawei.com/
> > ??
>
> That patch is apparently already in 5.9-rc1 as commit 80fbbb1672e7, so
> yes I'm still seeing it.
> >>>
> >>> Still present in 5.9-rc2 as of today, I have attached my .config for
> >>> reference. Note that I have CONFIG_IPV6_MULTIPLE_TABLES=y, but
> >>> CONFIG_IP_MULTIPLE_TABLES is not mentioned at all there.
> >>>
> >>> To build the kernel, I have now deselected IPV6_MULTIPLE_TABLES. Not
> >>> sure why this was enabled in my .config which has grown organically over
> >>> many years.
> >>>
> >>> Cheers,
> >>>Sven
> >>>
> >>>
> > On Mon, Aug 17, 2020 at 12:21 AM Sven Joachim wrote:
> >
> >> On 2020-07-29 21:27 +1000, Stephen Rothwell wrote:
> >>
> >>> Hi all,
> >>>
> >>> After merging the net-next tree, today's linux-next build (i386
> >> defconfig)
> >>> failed like this:
> >>>
> >>> x86_64-linux-gnu-ld: net/core/fib_rules.o: in function
> >> `fib_rules_lookup':
> >>> fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
> >>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to
> >> `fib6_rule_match'
> >>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to
> >> `fib6_rule_action'
> >>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to
> >> `fib6_rule_action'
> >>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to
> >> `fib6_rule_suppress'
> >>> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to
> >> `fib6_rule_suppress'
> >>
> >> FWIW, I saw these errors in 5.9-rc1 today, so the fix in commit
> >> 41d707b7332f ("fib: fix fib_rules_ops indirect calls wrappers") was
> >> apparently not sufficient.
> >>
> >> ,
> >> | $ grep IPV6 .config
> >> | CONFIG_IPV6=m
> >> | # CONFIG_IPV6_ROUTER_PREF is not set
> >> | # CONFIG_IPV6_OPTIMISTIC_DAD is not set
> >> | # CONFIG_IPV6_MIP6 is not set
> >> | # CONFIG_IPV6_ILA is not set
> >> | # CONFIG_IPV6_VTI is not set
> >> | CONFIG_IPV6_SIT=m
> >> | # CONFIG_IPV6_SIT_6RD is not set
> >> | CONFIG_IPV6_NDISC_NODETYPE=y
> >> | CONFIG_IPV6_TUNNEL=m
> >> | CONFIG_IPV6_MULTIPLE_TABLES=y
> >> | # CONFIG_IPV6_SUBTREES is not set
> >> | # CONFIG_IPV6_MROUTE is not set
> >> | # CONFIG_IPV6_SEG6_LWTUNNEL is not set
> >> | # CONFIG_IPV6_SEG6_HMAC is not set
> >> | # CONFIG_IPV6_RPL_LWTUNNEL is not set
> >> | # CONFIG_NF_SOCKET_IPV6 is not set
> >> | # CONFIG_NF_TPROXY_IPV6 is not set
> >> | # CONFIG_NF_DUP_IPV6 is not set
> >> | # CONFIG_NF_REJECT_IPV6 is not set
> >> | # CONFIG_NF_LOG_IPV6 is not set
> >> | CONFIG_NF_DEFRAG_IPV6=m
> >> `
> >>
> >>> Caused by commit
> >>>
> >>> b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
> >> fib_rules_ops")
> >>>
> >>> #
Re: [PATCH 4.19 1/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
On Fri, Aug 28, 2020 at 03:25:11PM -0700, Sowjanya Komatineni wrote:
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
What does this line above represent?
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra210.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Acked-by: Adrian Hunter
Signed-off-by: Sowjanya Komatineni
--
Thanks,
Sasha
Re: [PATCH v3] net: Use standardized (IANA) local port range
From: Stephen Hemminger Date: Fri, 28 Aug 2020 14:52:03 -0700 > Changing the default range impacts existing users. Since Linux has been doing > this for so long, I don't think just because a standards body decided to > reserve > some space is sufficient justification to do this. Agreed, there is no way we can change this after decades of precedence. We will definitely break things for people.
Re: [PATCH] of: of_match_node: Make stub an inline function to avoid W=1 warnings
On Fri, Aug 28, 2020 at 7:00 AM Andrew Lunn wrote: > > On Fri, Aug 28, 2020 at 04:19:39AM +0200, Andrew Lunn wrote: > > When building without CONFIG_OF and W=1, errors are given about unused > > arrays of match data, because of_match_node is stubbed as a macro. The > > compile does not see it takes parameters when not astub, so it > > generates warnings about unused variables. Replace the stub with an > > inline function to avoid these false warnings. > > Hi Rob > > So 0-day shows some people have worked around this with #ifdef > CONFIG_OF around the match table. > > I checked the object code for the file i'm interested in. The > optimiser has correctly throw away the match table and all code around > it with the inline stub. > > Which do you prefer? This patch and i remove the #ifdef, or the old > stub and if add #ifdef around the driver i'm getting warnings from? Use of_device_get_match_data instead of of_match_node. Rob
Re: [PATCH v6 2/2] ASoC: qcom: sc7180: Add machine driver for sound card registration
Hi, On Wed, Aug 26, 2020 at 4:05 AM Cheng-Yi Chiang wrote: > > +config SND_SOC_SC7180 > + tristate "SoC Machine driver for SC7180 boards" > + depends on SND_SOC_QCOM > + select SND_SOC_QCOM_COMMON > + select SND_SOC_LPASS_SC7180 > + select SND_SOC_MAX98357A > + select SND_SOC_RT5682 I haven't done any significant testing / review of your patch (I'm mostly sound-clueless), but I believe that the above needs to be "select SND_SOC_RT5682_I2C" atop the current top of the sound tree. When I fix that I can confirm that I see the rt5682 probe on sc7180-trogdor with Rob Clark's dts patch. -Doug
Re: [PATCH v10 03/16] s390/vfio-ap: manage link between queue struct and matrix mdev
On 8/25/20 6:25 AM, Cornelia Huck wrote:
On Fri, 21 Aug 2020 15:56:03 -0400
Tony Krowiak wrote:
Let's create links between each queue device bound to the vfio_ap device
driver and the matrix mdev to which the queue is assigned. The idea is to
facilitate efficient retrieval of the objects representing the queue
devices and matrix mdevs as well as to verify that a queue assigned to
a matrix mdev is bound to the driver.
The links will be created as follows:
* When the queue device is probed, if its APQN is assigned to a matrix
mdev, the structures representing the queue device and the matrix mdev
will be linked.
* When an adapter or domain is assigned to a matrix mdev, for each new
APQN assigned that references a queue device bound to the vfio_ap
device driver, the structures representing the queue device and the
matrix mdev will be linked.
The links will be removed as follows:
* When the queue device is removed, if its APQN is assigned to a matrix
mdev, the structures representing the queue device and the matrix mdev
will be unlinked.
* When an adapter or domain is unassigned from a matrix mdev, for each
APQN unassigned that references a queue device bound to the vfio_ap
device driver, the structures representing the queue device and the
matrix mdev will be unlinked.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 132 +-
drivers/s390/crypto/vfio_ap_private.h | 2 +
2 files changed, 129 insertions(+), 5 deletions(-)
(...)
@@ -548,6 +557,87 @@ static int vfio_ap_mdev_verify_no_sharing(struct
ap_matrix_mdev *matrix_mdev)
return 0;
}
+enum qlink_type {
I think this is less of a type, and more of an action, so
maybe call this 'qlink_action' (and the function parameter below
'action'?)
Sure, but what is this tag?
+ LINK_APID,
+ LINK_APQI,
+ UNLINK_APID,
+ UNLINK_APQI,
+};
+
+static void vfio_ap_mdev_link_queue(struct ap_matrix_mdev *matrix_mdev,
+ unsigned long apid, unsigned long apqi)
+{
+ struct vfio_ap_queue *q;
+
+ q = vfio_ap_get_queue(AP_MKQID(apid, apqi));
+ if (q) {
+ q->matrix_mdev = matrix_mdev;
+ hash_add(matrix_mdev->qtable,
+>mdev_qnode, q->apqn);
+ }
+}
+
+static void vfio_ap_mdev_unlink_queue(unsigned long apid, unsigned long apqi)
+{
+ struct vfio_ap_queue *q;
+
+ q = vfio_ap_get_queue(AP_MKQID(apid, apqi));
+ if (q) {
+ q->matrix_mdev = NULL;
+ hash_del(>mdev_qnode);
+ }
+}
+
+/**
+ * vfio_ap_mdev_link_queues
+ *
+ * @matrix_mdev: The matrix mdev to link.
+ * @type: The type of @qlink_id.
+ * @qlink_id: The APID or APQI of the queues to link.
+ *
+ * Sets or clears the links between the queues with the specified @qlink_id
+ * and the @matrix_mdev:
+ * @type == LINK_APID: Set the links between the @matrix_mdev and the
+ * queues with the specified @qlink_id (APID)
+ * @type == LINK_APQI: Set the links between the @matrix_mdev and the
+ * queues with the specified @qlink_id (APQI)
+ * @type == UNLINK_APID: Clear the links between the @matrix_mdev and the
+ * queues with the specified @qlink_id (APID)
+ * @type == UNLINK_APQI: Clear the links between the @matrix_mdev and the
+ * queues with the specified @qlink_id (APQI)
+ */
+static void vfio_ap_mdev_link_queues(struct ap_matrix_mdev *matrix_mdev,
+enum qlink_type type,
+unsigned long qlink_id)
+{
+ unsigned long id;
+
+ switch (type) {
+ case LINK_APID:
+ for_each_set_bit_inv(id, matrix_mdev->matrix.aqm,
+matrix_mdev->matrix.aqm_max + 1)
+ vfio_ap_mdev_link_queue(matrix_mdev, qlink_id, id);
+ break;
+ case UNLINK_APID:
+ for_each_set_bit_inv(id, matrix_mdev->matrix.aqm,
+matrix_mdev->matrix.aqm_max + 1)
+ vfio_ap_mdev_unlink_queue(qlink_id, id);
+ break;
+ case LINK_APQI:
+ for_each_set_bit_inv(id, matrix_mdev->matrix.apm,
+matrix_mdev->matrix.apm_max + 1)
+ vfio_ap_mdev_link_queue(matrix_mdev, id, qlink_id);
+ break;
+ case UNLINK_APQI:
+ for_each_set_bit_inv(id, matrix_mdev->matrix.apm,
+matrix_mdev->matrix.apm_max + 1)
+ vfio_ap_mdev_link_queue(matrix_mdev, id, qlink_id);
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ }
+}
+
(...)
I have not reviewed this deeply, but at a glance, it seems fine.
Re: linux-next: Tree for Aug 26
On Fri, Aug 28, 2020 at 09:24:19PM +0200, Anders Roxell wrote: > On Fri, 28 Aug 2020 at 15:29, Paul E. McKenney wrote: > > > > On Fri, Aug 28, 2020 at 09:37:17AM +0200, Anders Roxell wrote: > > > On Wed, 26 Aug 2020 at 21:39, Paul E. McKenney wrote: > > > > > > > > On Wed, Aug 26, 2020 at 08:19:01PM +0200, Anders Roxell wrote: > > > > > On Wed, 26 Aug 2020 at 08:33, Stephen Rothwell > > > > > wrote: > > > > > > > > [ . . . ] > > > > > > > > > I've built and run an arm64 allmodconfig kernel where I use the > > > > > defconfig as the base, I do this for testing purposes. > > > > > I can see the following call trace [1]: > > > > > > > > > > [ 2595.811453][T1] Running tests on all trace events: > > > > > [ 2595.860933][T1] Testing all events: > > > > > [ 4316.066072][T8] kworker/dying (8) used greatest stack depth: > > > > > 27056 bytes left > > > > > [ 8561.924871][C0] watchdog: BUG: soft lockup - CPU#0 stuck for > > > > > 22s! [migration/0:14] > > > > > [ 8561.934498][C0] Modules linked in: > > > > > [ 8561.942303][C0] irq event stamp: 4044 > > > > > [ 8561.949044][C0] hardirqs last enabled at (4043): > > > > > [] _raw_spin_unlock_irqrestore+0xac/0x138 > > > > > [ 8561.960848][C0] hardirqs last disabled at (4044): > > > > > [] __schedule+0xf8/0x7e0 > > > > > [ 8561.971418][C0] softirqs last enabled at (3698): > > > > > [] __do_softirq+0x524/0x5f8 > > > > > [ 8561.982191][C0] softirqs last disabled at (3689): > > > > > [] __irq_exit_rcu+0x128/0x1a0 > > > > > [ 8561.993068][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G > > > > >W 5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1 > > > > > [ 8562.005684][C0] Hardware name: linux,dummy-virt (DT) > > > > > [ 8562.013247][C0] pstate: 8045 (Nzcv daif +PAN -UAO BTYPE=--) > > > > > [ 8562.021657][C0] pc : arch_local_irq_enable+0x58/0x80 > > > > > [ 8562.029323][C0] lr : _raw_spin_unlock_irq+0x84/0xc0 > > > > > [ 8562.036739][C0] sp : 698efaa0 > > > > > [ 8562.042984][C0] x29: 698efaa0 x28: 6ad0f270 > > > > > [ 8562.053814][C0] x27: 6ad0f248 x26: 698d4718 > > > > > [ 8562.064687][C0] x25: 6ad0e798 x24: a000139e3a40 > > > > > [ 8562.075506][C0] x23: 0001 x22: a000154f5000 > > > > > [ 8562.086425][C0] x21: 6ad0e798 x20: 6ad0e780 > > > > > [ 8562.097255][C0] x19: a000126a905c x18: 14c0 > > > > > [ 8562.108071][C0] x17: 1500 x16: 1440 > > > > > [ 8562.118918][C0] x15: f1f1f1f1 x14: 003d0900 > > > > > [ 8562.129739][C0] x13: 3d09 x12: 8d31df41 > > > > > [ 8562.140544][C0] x11: 1fffed31df40 x10: 8d31df40 > > > > > [ 8562.151366][C0] x9 : dfffa000 x8 : 698efa07 > > > > > [ 8562.162247][C0] x7 : 0001 x6 : 72ce20c0 > > > > > [ 8562.173072][C0] x5 : 698d4040 x4 : dfffa000 > > > > > [ 8562.183954][C0] x3 : a0001040f904 x2 : 0007 > > > > > [ 8562.194811][C0] x1 : a0001408 x0 : 00e0 > > > > > [ 8562.205858][C0] Call trace: > > > > > [ 8562.211739][C0] arch_local_irq_enable+0x58/0x80 > > > > > [ 8562.219076][C0] _raw_spin_unlock_irq+0x84/0xc0 > > > > > [ 8562.226394][C0] __schedule+0x75c/0x7e0 > > > > > [ 8562.233074][C0] preempt_schedule_notrace+0x64/0xc0 > > > > > [ 8562.268210][C0] ftrace_ops_list_func+0x494/0x4e0 > > > > > [ 8562.275735][C0] ftrace_graph_call+0x0/0x4 > > > > > [ 8562.282647][C0] preempt_count_add+0xc/0x240 > > > > > [ 8562.289686][C0] schedule+0xe4/0x160 > > > > > [ 8562.296187][C0] smpboot_thread_fn+0x47c/0x540 > > > > > [ 8562.303377][C0] kthread+0x23c/0x260 > > > > > [ 8562.309906][C0] ret_from_fork+0x10/0x18 > > > > > [ 8562.316604][C0] Kernel panic - not syncing: softlockup: hung > > > > > tasks > > > > > [ 8562.325230][C0] CPU: 0 PID: 14 Comm: migration/0 Tainted: G > > > > >WL5.9.0-rc2-next-20200826-5-g24628bb4c0bf #1 > > > > > [ 8562.337861][C0] Hardware name: linux,dummy-virt (DT) > > > > > [ 8562.345374][C0] Call trace: > > > > > [ 8562.351228][C0] dump_backtrace+0x0/0x320 > > > > > [ 8562.358070][C0] show_stack+0x38/0x60 > > > > > [ 8562.364728][C0] dump_stack+0x1c0/0x280 > > > > > [ 8562.371447][C0] panic+0x32c/0x614 > > > > > [ 8562.377868][C0] watchdog_timer_fn+0x49c/0x560 > > > > > [ 8562.385076][C0] __run_hrtimer+0x1cc/0x360 > > > > > [ 8562.392021][C0] __hrtimer_run_queues+0x1a0/0x220 > > > > > [ 8562.399500][C0] hrtimer_interrupt+0x1f8/0x440 > > > > > [ 8562.406807][C0] arch_timer_handler_virt+0x68/0xa0 > > > > > [ 8562.414338][C0] handle_percpu_devid_irq+0x118/0x2a0 > > > > > [ 8562.421992][C0] __handle_domain_irq+0x150/0x1c0 > > > > > [ 8562.429315][C0] gic_handle_irq+0x98/0x120 > > > > > [
Re: [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
On Fri, 28 Aug 2020 18:54:50 -0400
Steven Rostedt wrote:
> On Fri, 28 Aug 2020 18:49:55 -0400
> Steven Rostedt wrote:
>
> > On Fri, 28 Aug 2020 15:53:06 +0800
> > Wen Gong wrote:
> >
> > > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> > > has upstream.
> > >
> > > how much size is the per cpu buffer?
> > > seems it is initilized in trace_buffered_event_enable,
> > > it is only 1 page size as below:
> > > void trace_buffered_event_enable(void)
> > > {
> > > ...
> > > for_each_tracing_cpu(cpu) {
> > > page = alloc_pages_node(cpu_to_node(cpu),
> > > GFP_KERNEL | __GFP_NORETRY, 0);
> > > If the size of buffer to trace is more than 1 page, such as 46680, then
> > > it trigger kernel crash/panic in my case while run trace-cmd.
> > > After debugging, the trace_file->flags in
> > > trace_event_buffer_lock_reserve is 0x40b while run trace-cmd, and it is
> > > 0x403 while collecting ftrace log.
> > >
> > > Is it have any operation to disable this patch dynamically?
> >
> > It shouldn't be disabled, this is a bug that needs to be fixed.
> >
> > Also, if an event is more than a page, it wont be saved in the ftrace
> > ring buffer, as events are limited by page size minus the headers.
> >
>
> Untested (not even compiled, as I'm now on PTO) but does this patch
> work for you?
>
> -- Steve
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index f40d850ebabc..3a9b4422e7fc 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -2598,7 +2598,7 @@ trace_event_buffer_lock_reserve(struct trace_buffer
> **current_rb,
> (entry = this_cpu_read(trace_buffered_event))) {
> /* Try to use the per cpu buffer first */
> val = this_cpu_inc_return(trace_buffered_event_cnt);
> - if (val == 1) {
> + if (val == 1 || (len > (PAGE_SIZE - 8))) {
That was suppose to be:
if (val == 1 && (len < (PAGE_SIZE - 8))) {
-- Steve
> trace_event_setup(entry, type, flags, pc);
> entry->array[0] = len;
> return entry;
Re: [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
On Fri, 28 Aug 2020 18:49:55 -0400
Steven Rostedt wrote:
> On Fri, 28 Aug 2020 15:53:06 +0800
> Wen Gong wrote:
>
> > this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> > has upstream.
> >
> > how much size is the per cpu buffer?
> > seems it is initilized in trace_buffered_event_enable,
> > it is only 1 page size as below:
> > void trace_buffered_event_enable(void)
> > {
> > ...
> > for_each_tracing_cpu(cpu) {
> > page = alloc_pages_node(cpu_to_node(cpu),
> > GFP_KERNEL | __GFP_NORETRY, 0);
> > If the size of buffer to trace is more than 1 page, such as 46680, then
> > it trigger kernel crash/panic in my case while run trace-cmd.
> > After debugging, the trace_file->flags in
> > trace_event_buffer_lock_reserve is 0x40b while run trace-cmd, and it is
> > 0x403 while collecting ftrace log.
> >
> > Is it have any operation to disable this patch dynamically?
>
> It shouldn't be disabled, this is a bug that needs to be fixed.
>
> Also, if an event is more than a page, it wont be saved in the ftrace
> ring buffer, as events are limited by page size minus the headers.
>
Untested (not even compiled, as I'm now on PTO) but does this patch
work for you?
-- Steve
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index f40d850ebabc..3a9b4422e7fc 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -2598,7 +2598,7 @@ trace_event_buffer_lock_reserve(struct trace_buffer
**current_rb,
(entry = this_cpu_read(trace_buffered_event))) {
/* Try to use the per cpu buffer first */
val = this_cpu_inc_return(trace_buffered_event_cnt);
- if (val == 1) {
+ if (val == 1 || (len > (PAGE_SIZE - 8))) {
trace_event_setup(entry, type, flags, pc);
entry->array[0] = len;
return entry;
[PATCH] sysfs: Add sysfs_emit to replace sprintf to PAGE_SIZE buffers.
sprintf does not know the PAGE_SIZE maximum of the temporary buffer
used for outputting sysfs content requests and it's possible to
overrun the buffer length.
Add a generic sysfs_emit mechanism that knows that the size of the
temporary buffer and ensures that no overrun is done.
Signed-off-by: Joe Perches
---
fs/sysfs/file.c | 30 ++
include/linux/sysfs.h | 8
2 files changed, 38 insertions(+)
diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..06a13bbd7080 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -707,3 +707,33 @@ int sysfs_change_owner(struct kobject *kobj, kuid_t kuid,
kgid_t kgid)
return 0;
}
EXPORT_SYMBOL_GPL(sysfs_change_owner);
+
+/**
+ * sysfs_emit - scnprintf equivalent, aware of PAGE_SIZE buffer.
+ * @buf: start of PAGE_SIZE buffer.
+ * @pos: current position in buffer
+ * (pos - buf) must always be < PAGE_SIZE
+ * @fmt: format
+ * @...: arguments to format
+ *
+ *
+ * Returns number of characters written at pos.
+ */
+int sysfs_emit(char *buf, char *pos, const char *fmt, ...)
+{
+ va_list args;
+ bool bad_pos = pos < buf;
+ bool bad_len = (pos - buf) >= PAGE_SIZE;
+ int len;
+
+ if (WARN(bad_pos || bad_len, "(pos < buf):%d (pos >= PAGE_SIZE):%d\n",
+bad_pos, bad_len))
+ return 0;
+
+ va_start(args, fmt);
+ len = vscnprintf(pos, PAGE_SIZE - (pos - buf), fmt, args);
+ va_end(args);
+
+ return len;
+}
+EXPORT_SYMBOL_GPL(sysfs_emit);
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..5a21d3d30016 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -329,6 +329,8 @@ int sysfs_groups_change_owner(struct kobject *kobj,
int sysfs_group_change_owner(struct kobject *kobj,
const struct attribute_group *groups, kuid_t kuid,
kgid_t kgid);
+__printf(3, 4)
+int sysfs_emit(char *buf, char *pos, const char *fmt, ...);
#else /* CONFIG_SYSFS */
@@ -576,6 +578,12 @@ static inline int sysfs_group_change_owner(struct kobject
*kobj,
return 0;
}
+__printf(3, 4)
+static inline int sysfs_emit(char *buf, char *pos, const char *fmt, ...)
+{
+ return 0;
+}
+
#endif /* CONFIG_SYSFS */
static inline int __must_check sysfs_create_file(struct kobject *kobj,
--
2.26.0
Re: [for-next][PATCH 2/2] tracing: Use temp buffer when filtering events
On Fri, 28 Aug 2020 15:53:06 +0800
Wen Gong wrote:
> this patch commit id is : 0fc1b09ff1ff404ddf753f5ffa5cd0adc8fdcdc9 which
> has upstream.
>
> how much size is the per cpu buffer?
> seems it is initilized in trace_buffered_event_enable,
> it is only 1 page size as below:
> void trace_buffered_event_enable(void)
> {
> ...
> for_each_tracing_cpu(cpu) {
> page = alloc_pages_node(cpu_to_node(cpu),
> GFP_KERNEL | __GFP_NORETRY, 0);
> If the size of buffer to trace is more than 1 page, such as 46680, then
> it trigger kernel crash/panic in my case while run trace-cmd.
> After debugging, the trace_file->flags in
> trace_event_buffer_lock_reserve is 0x40b while run trace-cmd, and it is
> 0x403 while collecting ftrace log.
>
> Is it have any operation to disable this patch dynamically?
It shouldn't be disabled, this is a bug that needs to be fixed.
Also, if an event is more than a page, it wont be saved in the ftrace
ring buffer, as events are limited by page size minus the headers.
-- Steve
Re: [PATCH v2] Documentation/x86: Add documentation for /proc/cpuinfo feature flags
Hi Boris, On Fri, 2020-08-28 at 20:42 +0200, Borislav Petkov wrote: > On Mon, Aug 24, 2020 at 11:04:12AM -0700, Kyung Min Park wrote: > > +If the expected flag does not appear in /proc/cpuinfo, things are > > murkier. > > +Users need to find out the reason why the flag is missing and find > > the way > > +how to enable it, which is not always easy. There are several > > factors that > > +can explain missing flags: the expected feature failed to enable, > > the feature > > +is missing in hardware, platform firmware did not enable it, the > > feature is > > +disabled at build or run time, an old kernel is in use, or the > > kernel does > > +not support the feature and thus has not enabled it. In general, > > /proc/cpuinfo > > +shows features which the kernel supports. > > + > > +For a full list of CPUID flags which the CPU supports, the users > > may use > > +tools like http://www.etallen.com/cpuid.html (which is not updated > > with > > +kernel releases) or other custom tools that read CPUID. > > I guess this should talk only about our own kcpuid tool since we > wanna > do that now, right? Should I mention the tool specifically although the tool is WIP? As you commented previously, should I use tools/arch/x86/tools/cpuid/cpuid as the future tool and its location? Or do you want it to be mentioned in the future tense without specifying the tool name and location? > > ... > > > +c: The kernel disabled support for it at compile-time. > > +-- > > +For example, if 5-level-paging is not enabled when building (i.e., > > +CONFIG_X86_5LEVEL is not selected) the flag "la57" will not show > > up [#f1]_. > > +Even though the feature will still be detected via CPUID, the > > kernel disables > > +it via cleared by setup_clear_cpu_cap(X86_FEATURE_LA57). > > "... disables it by clearing... " Sure, let me fix it. > > > +d: The feature is disabled at boot-time. > > + > > +A feature can be disabled either using a command-line parameter or > > because > > +it failed to be enabled. The command-line parameter clearcpuid= > > can be used > > +to disable features using the feature number as defined in > > +/arch/x86/include/asm/cpufeatures.h. For instance, User Mode > > Instruction > > +Protection can be disabled using clearcpuid=514. The number 514 is > > calculated > > +from #define X86_FEATURE_UMIP (16*32 + 2). > > + > > +In addition, there exists a variety of custom command-line > > parameters that > > +disable specific features. The list of parameters includes, but is > > not limited > > +to, no5lvl, nosmap, and nosmep. > > You already give the separate example for "no5lvl" below so use > something else > above, say, "nofsgsbase", for example. You're right. Let me change it. > > > 5-level paging can also be disabled using > > +"no5lvl". SMAP and SMEP are disabled with the aforementioned > > parameters, > > +respectively. > > + > > +e: The feature was known to be non-functional. > > +-- > > +The feature was known to be non-functional because a dependency > > was > > +missing at runtime. For example, AVX flags will not show up if > > XSAVE feature > > +is disabled since they depend on XSAVE feature. > > Another example would be: broken CPUs and them missing microcode > patches > and due to that the kernel deciding not to enable a feature. Thank you for the comment. I'll add that too. > > But yap, all in all looks like a good idea. I'll take the next > version > after you've fixed those nitpicks. > > Thx. Thanks Boris!
[PATCH v2] usb: dwc3: Stop active transfers before halting the controller
In the DWC3 databook, for a device initiated disconnect or bus reset, the
driver is required to send dependxfer commands for any pending transfers.
In addition, before the controller can move to the halted state, the SW
needs to acknowledge any pending events. If the controller is not halted
properly, there is a chance the controller will continue accessing stale or
freed TRBs and buffers.
Signed-off-by: Wesley Cheng
---
Changes in v2:
- Moved cleanup code to the pullup() API to differentiate between device
disconnect and hibernation.
- Added cleanup code to the bus reset case as well.
- Verified the move to pullup() did not reproduce the problen using the
same test sequence.
Verified fix by adding a check for ETIMEDOUT during the run stop call.
Shell script writing to the configfs UDC file to trigger disconnect and
connect. Batch script to have PC execute data transfers over adb (ie adb
push) After a few iterations, we'd run into a scenario where the
controller wasn't halted. With the following change, no failed halts after
many iterations.
---
drivers/usb/dwc3/ep0.c| 2 +-
drivers/usb/dwc3/gadget.c | 52 ++-
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 59f2e8c31bd1..456aa87e8778 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -197,7 +197,7 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct
usb_request *request,
int ret;
spin_lock_irqsave(>lock, flags);
- if (!dep->endpoint.desc) {
+ if (!dep->endpoint.desc || !dwc->pullups_connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
ret = -ESHUTDOWN;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 3ab6f118c508..df8d89d6bdc9 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1516,7 +1516,7 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep,
struct dwc3_request *req)
{
struct dwc3 *dwc = dep->dwc;
- if (!dep->endpoint.desc) {
+ if (!dep->endpoint.desc || !dwc->pullups_connected) {
dev_err(dwc->dev, "%s: can't queue to disabled endpoint\n",
dep->name);
return -ESHUTDOWN;
@@ -1926,6 +1926,24 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget
*g,
return 0;
}
+static void dwc3_stop_active_transfers(struct dwc3 *dwc)
+{
+ u32 epnum;
+
+ for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
+ struct dwc3_ep *dep;
+
+ dep = dwc->eps[epnum];
+ if (!dep)
+ continue;
+
+ if (!(dep->flags & DWC3_EP_ENABLED))
+ continue;
+
+ dwc3_remove_requests(dwc, dep);
+ }
+}
+
static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
{
u32 reg;
@@ -1994,9 +2012,39 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int
is_on)
}
}
+ /*
+* Synchronize and disable any further event handling while controller
+* is being enabled/disabled.
+*/
+ disable_irq(dwc->irq_gadget);
spin_lock_irqsave(>lock, flags);
+
+ /* Controller is not halted until pending events are acknowledged */
+ if (!is_on) {
+ u32 reg;
+
+ __dwc3_gadget_ep_disable(dwc->eps[0]);
+ __dwc3_gadget_ep_disable(dwc->eps[1]);
+
+ /*
+* The databook explicitly mentions for a device-initiated
+* disconnect sequence, the SW needs to ensure that it ends any
+* active transfers.
+*/
+ dwc3_stop_active_transfers(dwc);
+
+ reg = dwc3_readl(dwc->regs, DWC3_GEVNTCOUNT(0));
+ reg &= DWC3_GEVNTCOUNT_MASK;
+ if (reg > 0) {
+ dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), reg);
+ dwc->ev_buf->lpos = (dwc->ev_buf->lpos + reg) %
+ dwc->ev_buf->length;
+ }
+ }
+
ret = dwc3_gadget_run_stop(dwc, is_on, false);
spin_unlock_irqrestore(>lock, flags);
+ enable_irq(dwc->irq_gadget);
return ret;
}
@@ -3100,6 +3148,8 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
}
dwc3_reset_gadget(dwc);
+ /* Stop any active/pending transfers when receiving bus reset */
+ dwc3_stop_active_transfers(dwc);
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH v2 1/9] docs: Document IO Address Space ID (IOASID) APIs
Hi Jean, Thanks for the review! On Mon, 24 Aug 2020 12:32:39 +0200 Jean-Philippe Brucker wrote: > On Fri, Aug 21, 2020 at 09:35:10PM -0700, Jacob Pan wrote: > > IOASID is used to identify address spaces that can be targeted by > > device DMA. It is a system-wide resource that is essential to its > > many users. This document is an attempt to help developers from all > > vendors navigate the APIs. At this time, ARM SMMU and Intel’s > > Scalable IO Virtualization (SIOV) enabled platforms are the primary > > users of IOASID. Examples of how SIOV components interact with > > IOASID APIs are provided in that many APIs are driven by the > > requirements from SIOV. > > > > Signed-off-by: Liu Yi L > > Signed-off-by: Wu Hao > > Signed-off-by: Jacob Pan > > --- > > Documentation/ioasid.rst | 618 > > +++ 1 file changed, 618 > > insertions(+) create mode 100644 Documentation/ioasid.rst > > > > diff --git a/Documentation/ioasid.rst b/Documentation/ioasid.rst > > Thanks for writing this up. Should it go to > Documentation/driver-api/, or Documentation/driver-api/iommu/? I > think this also needs to Cc linux-...@vger.kernel.org and > cor...@lwn.net > Good point, I think Documentation/driver-api/ is good for now as there are no other IOMMU docs. Will CC Jon also. > > new file mode 100644 > > index ..b6a8cdc885ff > > --- /dev/null > > +++ b/Documentation/ioasid.rst > > @@ -0,0 +1,618 @@ > > +.. ioasid: > > + > > += > > +IO Address Space ID > > += > > + > > +IOASID is a generic name for PCIe Process Address ID (PASID) or ARM > > +SMMU sub-stream ID. An IOASID identifies an address space that > > DMA > > "SubstreamID" > > > +requests can target. > > + > > +The primary use cases for IOASID are Shared Virtual Address (SVA) > > and +IO Virtual Address (IOVA). However, the requirements for > > IOASID > > IOVA alone isn't a use case, maybe "multiple IOVA spaces per device"? > Yes, I meant guest IOVA for mdev which has "multiple IOVA spaces per device" based on aux domain. I will add this to the IOVA case description. "The primary use cases for IOASID are Shared Virtual Address (SVA) and multiple IOVA spaces per device. However, the requirements for IOASID management can vary among hardware architectures. For baremetal IOVA, IOASID #0 is used for DMA request without PASID. Even though some architectures such as VT-d also offers the flexibility of using any PASIDs for DMA request without PASID. PASID #0 is reserved and not allocated from any ioasid_set. Multiple IOVA spaces per device are mapped to auxiliary domains which can be used for mediated device assignment with and without a virtual IOMMU (vIOMMU). An IOASID is allocated for each auxiliary domain as default PASID. Without vIOMMU, default IOASID is used for DMA map/unmap APIs. With vIOMMU, default IOASID is used for guest IOVA where DMA request with PASID is required for the device. The reason is that there is only one PASID #0 per device, e.g. VT-d, RID_PASID is per PCI device. " > > +management can vary among hardware architectures. > > + > > +This document covers the generic features supported by IOASID > > +APIs. Vendor-specific use cases are also illustrated with Intel's > > VT-d +based platforms as the first example. > > + > > +.. contents:: :local: > > + > > +Glossary > > + > > +PASID - Process Address Space ID > > + > > +IOASID - IO Address Space ID (generic term for PCIe PASID and > > +sub-stream ID in SMMU) > > "SubstreamID" > will fix. > > + > > +SVA/SVM - Shared Virtual Addressing/Memory > > + > > +ENQCMD - New Intel X86 ISA for efficient workqueue submission [1] > > Maybe drop the "New", to keep the documentation perennial. It might be > good to add internal links here to the specifications URLs at the > bottom. > Good idea > > + > > +DSA - Intel Data Streaming Accelerator [2] > > + > > +VDCM - Virtual device composition module [3] > > + > > +SIOV - Intel Scalable IO Virtualization > > + > > + > > +Key Concepts > > + > > + > > +IOASID Set > > +--- > > +An IOASID set is a group of IOASIDs allocated from the system-wide > > +IOASID pool. An IOASID set is created and can be identified by a > > +token of u64. Refer to IOASID set APIs for more details. > > Identified either by an u64 or an mm_struct, right? Maybe just drop > the second sentence if it's detailed in the IOASID set section below. > Sounds good. > > + > > +IOASID set is particularly useful for guest SVA where each guest > > could +have its own IOASID set for security and efficiency reasons. > > + > > +IOASID Set Private ID (SPID) > > + > > +SPIDs are introduced as IOASIDs within its set. Each SPID maps to a > > +system-wide IOASID but the namespace of SPID is within its IOASID > > +set. > > The intro isn't super clear. Perhaps this is simpler: > "Each IOASID set has a private
Re: [PATCH v3 1/3] dt-bindings: media: atmel: csi2dc: add bindings for microchip csi2dc
On Wed, 26 Aug 2020 09:51:40 +0300, Eugen Hristev wrote: > Add bindings documentation for Microchip CSI2 Demultiplexer controller. > > CSI2DC is a demultiplexer from Synopsys IDI interface specification to > parallel interface connection or direct memory access. > > Signed-off-by: Eugen Hristev > --- > Changes in v3: > - Removed some text from description, as it was explained in the schema > - fixed other things as per Rob's review > - moved some text inside the schema, like the clock description > > Changes in v2: > - fixed warnings reported by dt_binding_check > > .../bindings/media/microchip,csi2dc.yaml | 174 ++ > 1 file changed, 174 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/media/microchip,csi2dc.yaml > Reviewed-by: Rob Herring
INFO: task can't die in wait_on_page_bit_common
Hello,
syzbot found the following issue on:
HEAD commit:d8be0e12 Add linux-next specific files for 20200824
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12fa85ee90
kernel config: https://syzkaller.appspot.com/x/.config?x=9ef0a5f95935d447
dashboard link: https://syzkaller.appspot.com/bug?extid=17675037466844188253
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16f9051990
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=153d3f5e90
The issue was bisected to:
commit 2da22da573481cc4837e246d0eee4d518b3f715e
Author: Mike Christie
Date: Tue Aug 13 16:39:52 2019 +
nbd: fix zero cmd timeout handling v2
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=15af02de90
final oops: https://syzkaller.appspot.com/x/report.txt?x=17af02de90
console output: https://syzkaller.appspot.com/x/log.txt?x=13af02de90
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+17675037466844188...@syzkaller.appspotmail.com
Fixes: 2da22da57348 ("nbd: fix zero cmd timeout handling v2")
INFO: task syz-executor066:6866 can't die for more than 143 seconds.
task:syz-executor066 state:D stack:28568 pid: 6866 ppid: 6855 flags:0x0004
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
io_schedule+0xb5/0x120 kernel/sched/core.c:6296
wait_on_page_bit_common+0x52c/0xca0 mm/filemap.c:1193
wait_on_page_bit mm/filemap.c:1218 [inline]
wait_on_page_locked include/linux/pagemap.h:611 [inline]
do_read_cache_page+0x257/0x1390 mm/filemap.c:2917
read_mapping_page include/linux/pagemap.h:437 [inline]
read_part_sector+0xf6/0x5af block/partitions/core.c:770
adfspart_check_ICS+0x9d/0xc90 block/partitions/acorn.c:360
check_partition block/partitions/core.c:140 [inline]
blk_add_partitions+0x445/0xe00 block/partitions/core.c:698
bdev_disk_changed+0x1ea/0x370 fs/block_dev.c:1416
__blkdev_get+0xee4/0x1aa0 fs/block_dev.c:1559
blkdev_get fs/block_dev.c:1639 [inline]
blkdev_open+0x227/0x300 fs/block_dev.c:1753
do_dentry_open+0x4b9/0x11b0 fs/open.c:817
do_open fs/namei.c:3251 [inline]
path_openat+0x1b9a/0x2730 fs/namei.c:3368
do_filp_open+0x17e/0x3c0 fs/namei.c:3395
do_sys_openat2+0x16d/0x420 fs/open.c:1168
do_sys_open fs/open.c:1184 [inline]
__do_sys_open fs/open.c:1192 [inline]
__se_sys_open fs/open.c:1188 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1188
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x405811
Code: Bad RIP value.
RSP: 002b:7f3442d94980 EFLAGS: 0293 ORIG_RAX: 0002
RAX: ffda RBX: RCX: 00405811
RDX: RSI: RDI: 7f3442d94990
RBP: 6667 R08: 000f R09: 7f3442d95700
R10: 7f3442d959d0 R11: 0293 R12: 006dbc4c
R13: 7fffc941905f R14: 7f3442d959c0 R15: 20c49ba5e353f7cf
INFO: task syz-executor066:6866 blocked for more than 143 seconds.
Not tainted 5.9.0-rc2-next-20200824-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor066 state:D stack:28568 pid: 6866 ppid: 6855 flags:0x0004
Call Trace:
context_switch kernel/sched/core.c:3778 [inline]
__schedule+0x8e5/0x21e0 kernel/sched/core.c:4527
schedule+0xd0/0x2a0 kernel/sched/core.c:4602
io_schedule+0xb5/0x120 kernel/sched/core.c:6296
wait_on_page_bit_common+0x52c/0xca0 mm/filemap.c:1193
wait_on_page_bit mm/filemap.c:1218 [inline]
wait_on_page_locked include/linux/pagemap.h:611 [inline]
do_read_cache_page+0x257/0x1390 mm/filemap.c:2917
read_mapping_page include/linux/pagemap.h:437 [inline]
read_part_sector+0xf6/0x5af block/partitions/core.c:770
adfspart_check_ICS+0x9d/0xc90 block/partitions/acorn.c:360
check_partition block/partitions/core.c:140 [inline]
blk_add_partitions+0x445/0xe00 block/partitions/core.c:698
bdev_disk_changed+0x1ea/0x370 fs/block_dev.c:1416
__blkdev_get+0xee4/0x1aa0 fs/block_dev.c:1559
blkdev_get fs/block_dev.c:1639 [inline]
blkdev_open+0x227/0x300 fs/block_dev.c:1753
do_dentry_open+0x4b9/0x11b0 fs/open.c:817
do_open fs/namei.c:3251 [inline]
path_openat+0x1b9a/0x2730 fs/namei.c:3368
do_filp_open+0x17e/0x3c0 fs/namei.c:3395
do_sys_openat2+0x16d/0x420 fs/open.c:1168
do_sys_open fs/open.c:1184 [inline]
__do_sys_open fs/open.c:1192 [inline]
__se_sys_open fs/open.c:1188 [inline]
__x64_sys_open+0x119/0x1c0 fs/open.c:1188
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x405811
Code: Bad RIP value.
RSP: 002b:7f3442d94980 EFLAGS: 0293 ORIG_RAX: 0002
RAX: ffda RBX: RCX: 00405811
RDX: RSI: RDI: 7f3442d94990
RBP: 6667
Re: [PATCH v3 17/19] dt-bindings: serial: fsl-lpuart: Fix compatible matching
On Tue, 25 Aug 2020 21:35:34 +0200, Krzysztof Kozlowski wrote:
> The i.MX 8QXP DTSes use two compatibles so update the binding to fix
> dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
> compatible: ['fsl,imx8qxp-lpuart', 'fsl,imx7ulp-lpuart'] is too long
> From schema: Documentation/devicetree/bindings/serial/fsl-lpuart.yaml
>
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml: serial@5a06:
> compatible: Additional items are not allowed ('fsl,imx7ulp-lpuart' was
> unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v2:
> 1. Remove moved compatibles.
>
> Changes since v1:
> 1. New patch.
> ---
> .../devicetree/bindings/serial/fsl-lpuart.yaml | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring
Re: [PATCH v3 13/19] dt-bindings: nvmem: imx-ocotp: Update i.MX 8M compatibles
On Tue, 25 Aug 2020 21:35:30 +0200, Krzysztof Kozlowski wrote:
> DTSes with new i.MX 8M SoCs use two compatibles so update the binding to
> fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
> compatible:1: 'syscon' was expected
> From schema: Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
> compatible: ['fsl,imx8mn-ocotp', 'fsl,imx8mm-ocotp', 'syscon'] is too long
>
> arch/arm64/boot/dts/freescale/imx8mn-evk.dt.yaml: efuse@3035:
> compatible: Additional items are not allowed ('syscon' was unexpected)
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Changes since v2:
> 1. Remove moved compatibles.
> ---
> .../devicetree/bindings/nvmem/imx-ocotp.yaml | 38 +++
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
Reviewed-by: Rob Herring
[PATCH 4.19 1/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the
beginning of Tegra210 support in the driver.
Tegra210 SDMMC hardware by default uses timeout clock (TMCLK)
instead of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra210.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Acked-by: Adrian Hunter
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 27bdf6d..731956e 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -423,7 +423,6 @@ static const struct sdhci_tegra_soc_data soc_data_tegra124
= {
static const struct sdhci_pltfm_data sdhci_tegra210_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
--
2.7.4
[PATCH 4.19 5/7] arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes
commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register and uses it by default.
So, this clock should be kept enabled by the SDMMC driver.
Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index b762227..821dc5f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -232,8 +232,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0340 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC1>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC1>;
reset-names = "sdhci";
status = "disabled";
@@ -243,8 +244,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0342 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC2>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC2>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC2>;
reset-names = "sdhci";
status = "disabled";
@@ -254,8 +256,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0344 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC3>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC3>;
reset-names = "sdhci";
status = "disabled";
@@ -265,8 +268,9 @@
compatible = "nvidia,tegra186-sdhci";
reg = <0x0 0x0346 0x0 0x1>;
interrupts = ;
- clocks = < TEGRA186_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = < TEGRA186_CLK_SDMMC4>,
+< TEGRA186_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA186_RESET_SDMMC4>;
reset-names = "sdhci";
status = "disabled";
--
2.7.4
[PATCH 4.19 6/7] arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes
commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should be kept enabled by SDMMC driver.
Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 9fc14bb..8a319c2 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -213,8 +213,9 @@
compatible = "nvidia,tegra194-sdhci",
"nvidia,tegra186-sdhci";
reg = <0x0340 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC1>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
status = "disabled";
@@ -224,8 +225,9 @@
compatible = "nvidia,tegra194-sdhci",
"nvidia,tegra186-sdhci";
reg = <0x0344 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC3>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
status = "disabled";
@@ -235,8 +237,9 @@
compatible = "nvidia,tegra194-sdhci",
"nvidia,tegra186-sdhci";
reg = <0x0346 0x1>;
interrupts = ;
- clocks = < TEGRA194_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = < TEGRA194_CLK_SDMMC4>,
+< TEGRA194_CLK_SDMMC_LEGACY_TM>;
+ clock-names = "sdhci", "tmclk";
resets = < TEGRA194_RESET_SDMMC4>;
reset-names = "sdhci";
status = "disabled";
--
2.7.4
[PATCH 4.19 7/7] sdhci: tegra: Add missing TMCLK for data timeout
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later has a separate sdmmc_legacy_tm (TMCLK) used by Tegra
SDMMC hawdware for data timeout to achive better timeout than using
SDCLK and using TMCLK is recommended.
USE_TMCLK_FOR_DATA_TIMEOUT bit in Tegra SDMMC register
SDHCI_TEGRA_VENDOR_SYS_SW_CTRL can be used to choose either TMCLK or
SDCLK for data timeout.
Default USE_TMCLK_FOR_DATA_TIMEOUT bit is set to 1 and TMCLK is used
for data timeout by Tegra SDMMC hardware and having TMCLK not enabled
is not recommended.
So, this patch adds quirk NVQUIRK_HAS_TMCLK for SoC having separate
timeout clock and keeps TMCLK enabled all the time.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Acked-by: Adrian Hunter
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 48 ++
1 file changed, 48 insertions(+)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 5a7c032..ff3340c 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -56,6 +56,12 @@
#define NVQUIRK_ENABLE_DDR50 BIT(5)
#define NVQUIRK_HAS_PADCALIB BIT(6)
+/*
+ * NVQUIRK_HAS_TMCLK is for SoC's having separate timeout clock for Tegra
+ * SDMMC hardware data timeout.
+ */
+#define NVQUIRK_HAS_TMCLK BIT(10)
+
struct sdhci_tegra_soc_data {
const struct sdhci_pltfm_data *pdata;
u32 nvquirks;
@@ -64,6 +70,7 @@ struct sdhci_tegra_soc_data {
struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
struct gpio_desc *power_gpio;
+ struct clk *tmclk;
bool ddr_signaling;
bool pad_calib_required;
@@ -433,6 +440,7 @@ static const struct sdhci_pltfm_data sdhci_tegra210_pdata =
{
static const struct sdhci_tegra_soc_data soc_data_tegra210 = {
.pdata = _tegra210_pdata,
+ .nvquirks = NVQUIRK_HAS_TMCLK,
};
static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
@@ -455,6 +463,7 @@ static const struct sdhci_pltfm_data sdhci_tegra186_pdata =
{
static const struct sdhci_tegra_soc_data soc_data_tegra186 = {
.pdata = _tegra186_pdata,
+ .nvquirks = NVQUIRK_HAS_TMCLK,
};
static const struct of_device_id sdhci_tegra_dt_match[] = {
@@ -510,6 +519,43 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
goto err_power_req;
}
+ /*
+* Some Tegra SoC's has a separate SDMMC_LEGACY_TM clock used for
+* host data timeout clock and SW can choose TMCLK or SDCLK for
+* hardware data timeout through the bit USE_TMCLK_FOR_DATA_TIMEOUT
+* of the register SDHCI_TEGRA_VENDOR_SYS_SW_CTRL.
+*
+* USE_TMCLK_FOR_DATA_TIMEOUT bit default is set to 1 and SDMMC uses
+* 12Mhz TMCLK which is advertised in host capability register.
+* With TMCLK of 12Mhz provides maximum data timeout period that can
+* be achieved is 11s better than using SDCLK for data timeout.
+*
+* So, TMCLK is set to 12Mhz and kept enabled all the time on SoC's
+* supporting separate TMCLK.
+*/
+
+ if (soc_data->nvquirks & NVQUIRK_HAS_TMCLK) {
+ clk = devm_clk_get(>dev, "tmclk");
+ if (IS_ERR(clk)) {
+ rc = PTR_ERR(clk);
+ if (rc == -EPROBE_DEFER)
+ goto err_power_req;
+
+ dev_warn(>dev, "failed to get tmclk: %d\n", rc);
+ clk = NULL;
+ }
+
+ clk_set_rate(clk, 1200);
+ rc = clk_prepare_enable(clk);
+ if (rc) {
+ dev_err(>dev,
+ "failed to enable tmclk: %d\n", rc);
+ goto err_power_req;
+ }
+
+ tegra_host->tmclk = clk;
+ }
+
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
dev_err(mmc_dev(host->mmc), "clk err\n");
@@ -550,6 +596,7 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
err_rst_get:
clk_disable_unprepare(pltfm_host->clk);
err_clk_get:
+ clk_disable_unprepare(tegra_host->tmclk);
err_power_req:
err_parse_dt:
sdhci_pltfm_free(pdev);
@@ -567,6 +614,7 @@ static int sdhci_tegra_remove(struct platform_device *pdev)
reset_control_assert(tegra_host->rst);
usleep_range(2000, 4000);
clk_disable_unprepare(pltfm_host->clk);
+ clk_disable_unprepare(tegra_host->tmclk);
sdhci_pltfm_free(pdev);
--
2.7.4
[PATCH 4.19 4/7] arm64: tegra: Add missing timeout clock to Tegra210 SDMMC
commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and
this clock is not enabled currently which is not recommended.
Tegra SDMMC advertises 12Mhz as timeout clock frequency in host
capability register.
So, this clock should be kept enabled by SDMMC driver.
Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Signed-off-by: Sowjanya Komatineni
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index 6597c08..64a0cb5 100644
--- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
@@ -1020,44 +1020,48 @@
};
sdhci@700b {
- compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+ compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC1>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC1>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 14>;
reset-names = "sdhci";
status = "disabled";
};
sdhci@700b0200 {
- compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+ compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0200 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC2>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC2>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 9>;
reset-names = "sdhci";
status = "disabled";
};
sdhci@700b0400 {
- compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+ compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0400 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC3>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC3>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 69>;
reset-names = "sdhci";
status = "disabled";
};
sdhci@700b0600 {
- compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci";
+ compatible = "nvidia,tegra210-sdhci";
reg = <0x0 0x700b0600 0x0 0x200>;
interrupts = ;
- clocks = <_car TEGRA210_CLK_SDMMC4>;
- clock-names = "sdhci";
+ clocks = <_car TEGRA210_CLK_SDMMC4>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
resets = <_car 15>;
reset-names = "sdhci";
status = "disabled";
--
2.7.4
[PATCH 4.19 0/7] Fix timeout clock used by hardware data timeout
Tegra210/Tegra186/Tegra194 has incorrectly enabled SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK from the beginning of their support. Tegra210 and later SDMMC hardware default uses sdmmc_legacy_tm (TMCLK) all the time for hardware data timeout instead of SDCLK and this TMCLK need to be kept enabled by Tegra sdmmc driver. This series includes manual backport patches to fix this for stable kernel #4.19 Sowjanya Komatineni (7): sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186 dt-bindings: mmc: tegra: Add tmclk for Tegra210 and Tegra186 arm64: tegra: Add missing timeout clock to Tegra210 SDMMC arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes sdhci: tegra: Add missing TMCLK for data timeout .../bindings/mmc/nvidia,tegra20-sdhci.txt | 23 +- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 + arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 28 ++-- drivers/mmc/host/sdhci-tegra.c | 50 +- 5 files changed, 106 insertions(+), 30 deletions(-) -- 2.7.4
[PATCH 4.19 3/7] dt-bindings: mmc: tegra: Add tmclk for Tegra210 and Tegra186
commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
timeout.
So, this patch adds "tmclk" to Tegra sdhci clock property in the
device tree binding.
Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
Cc: stable # 4.19
Reviewed-by: Jon Hunter
Signed-off-by: Sowjanya Komatineni
---
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 23 --
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
index 9bce578..a5f1fae 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
@@ -14,8 +14,15 @@ Required properties:
- "nvidia,tegra124-sdhci": for Tegra124 and Tegra132
- "nvidia,tegra210-sdhci": for Tegra210
- "nvidia,tegra186-sdhci": for Tegra186
-- clocks : Must contain one entry, for the module clock.
- See ../clocks/clock-bindings.txt for details.
+- clocks: For Tegra210 and Tegra186 must contain two entries.
+ One for the module clock and one for the timeout clock.
+ For all other Tegra devices, must contain a single entry for
+ the module clock. See ../clocks/clock-bindings.txt for details.
+- clock-names: For Tegra210 and Tegra186 must contain the strings 'sdhci'
+ and 'tmclk' to represent the module and the timeout clocks,
+ respectively.
+ For all other Tegra devices must contain the string 'sdhci'
+ to represent the module clock.
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
@@ -38,3 +45,15 @@ sdhci@c8000200 {
power-gpios = < 155 0>; /* gpio PT3 */
bus-width = <8>;
};
+
+sdhci@700b {
+ compatible = "nvidia,tegra210-sdhci";
+ reg = <0x0 0x700b 0x0 0x200>;
+ interrupts = ;
+ clocks = <_car TEGRA210_CLK_SDMMC1>,
+<_car TEGRA210_CLK_SDMMC_LEGACY>;
+ clock-names = "sdhci", "tmclk";
+ resets = <_car 14>;
+ reset-names = "sdhci";
+ status = "disabled";
+};
--
2.7.4
[PATCH 4.19 2/7] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186
commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the
beginning of its support in driver.
Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead
of SDCLK and this quirk should not be set.
So, this patch remove this quirk for Tegra186.
Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support")
Cc: stable # 4.19
Tested-by: Jon Hunter
Reviewed-by: Jon Hunter
Acked-by: Adrian Hunter
Signed-off-by: Sowjanya Komatineni
---
drivers/mmc/host/sdhci-tegra.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 731956e..5a7c032 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -437,7 +437,6 @@ static const struct sdhci_tegra_soc_data soc_data_tegra210
= {
static const struct sdhci_pltfm_data sdhci_tegra186_pdata = {
.quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
- SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
SDHCI_QUIRK_SINGLE_POWER_WRITE |
SDHCI_QUIRK_NO_HISPD_BIT |
SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
--
2.7.4
Re: [PATCH mmc-next v3 1/2] dt-bindings: mmc: add alias example
On Tue, Aug 25, 2020 at 03:44:40PM +0200, Matthias Schiffer wrote:
> As for I2C and SPI, it now is possible to reserve a fixed index for
> mmc/mmcblk devices.
>
> Signed-off-by: Matthias Schiffer
> ---
>
> v3: new patch
>
> Documentation/devicetree/bindings/mmc/mmc-controller.yaml | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> index b96da0c7f819..22ed4a36c65d 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> @@ -367,6 +367,14 @@ examples:
> };
>
>- |
> +/*
> + * Optionally define an alias to reserve a fixed index for the
> + * mmc and mmcblk devices
> + */
> +aliases {
> +mmc0 =
> +};
This will break if we improve schemas because this node is actually
/example-1/aliases.
So please drop. If you want, I'd really like to have a defined set (i.e.
a schema) of alias names. This would require deleting a bunch on some
platforms that just made up a bunch of them.
> +
> mmc3: mmc@1c12000 {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.17.1
>
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On Fri, Aug 28, 2020 at 06:02:25PM -0400, Vineeth Pillai wrote: [...] > > Can we please split out this hotplug 'fix' into a separate patch with a > > coherent changelog. > Sorry about this. I had posted this as separate patches in v6 list, > but merged it for v7. Will split it and have details about the fix in > next iteration. Thanks Vineeth. Peter, also the "v6+" series (which were some addons on v6) detail the individual hotplug changes squashed into this patch: https://lore.kernel.org/lkml/20200815031908.1015049-9-j...@joelfernandes.org/ https://lore.kernel.org/lkml/20200815031908.1015049-11-j...@joelfernandes.org/ https://lore.kernel.org/lkml/20200815031908.1015049-12-j...@joelfernandes.org/ https://lore.kernel.org/lkml/20200815031908.1015049-13-j...@joelfernandes.org/ Agreed we can split the patches for the next series, however for final upstream merge, I suggest we fix hotplug issues in this patch itself so that we don't break bisectability. thanks, - Joel
linux-next: Fixes tag needs some work in the kbuild-current tree
Hi all,
Commit
ffaab3f87589 ("Documentation/llvm: Improve formatting of commands, variables,
and arguments")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpNJZWaTdQaG.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 2/2] DT: leds: Add an optional property named 'shutdown-gpios'
On Tue, 25 Aug 2020 16:22:06 +0800, Grant Feng wrote: > The chip enters hardware shutdown when the SDB pin is pulled low. > The chip releases hardware shutdown when the SDB pin is pulled high. > > Signed-off-by: Grant Feng > --- > Documentation/devicetree/bindings/leds/leds-is31fl319x.txt | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH] arc: fix memory initialization for systems with two memory banks
Hi Mike,
On 8/28/20 9:39 AM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Rework if memory map initialization broke initialization of ARC systems
> with two memory banks. Before these changes, memblock was not aware of
> nodes configuration and the memory map was always allocated from the
> "lowmem" bank. After the addition of node information to memblock, the core
> mm attempts to allocate the memory map for the "highmem" bank from its
> node. The access to this memory using __va() fails because it can be only
> accessed using kmap.
>
> Anther problem that was uncovered is that {min,max}_high_pfn are calculated
> from u64 high_mem_start variable which prevents truncation to 32-bit
> physical address and the PFN values are above the node and zone boundaries.
Not sure if I quite follow this part. We should not be relying on truncation:
the
pfn should be derived off of zone addresses ?
> Use phys_addr_t type for high_mem_start and high_mem_size to ensure
> correspondence between PFNs and highmem zone boundaries and reserve the
> entire highmem bank until mem_init() to avoid accesses to it before highmem
> is enabled.
>
> Fixes: 51930df5801e ("mm: free_area_init: allow defining max_zone_pfn in
> descend ing order")
> Signed-off-by: Mike Rapoport
Thx for the fix. I verified that a 2 mem bank system with HIGHMEM enabled now
works again.
And I've also added a couple of lines to changelog to describe how to test such
a
config.
| To test this:
| 1. Enable HIGHMEM in ARC config
| 2. Enable 2 memory banks in haps_hs.dts (uncomment the 2nd bank)
> ---
> arch/arc/mm/init.c | 27 ---
> 1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arc/mm/init.c b/arch/arc/mm/init.c
> index f886ac69d8ad..3a35b82a718e 100644
> --- a/arch/arc/mm/init.c
> +++ b/arch/arc/mm/init.c
> @@ -26,8 +26,8 @@ static unsigned long low_mem_sz;
>
> #ifdef CONFIG_HIGHMEM
> static unsigned long min_high_pfn, max_high_pfn;
> -static u64 high_mem_start;
> -static u64 high_mem_sz;
> +static phys_addr_t high_mem_start;
> +static phys_addr_t high_mem_sz;
> #endif
>
> #ifdef CONFIG_DISCONTIGMEM
> @@ -69,6 +69,7 @@ void __init early_init_dt_add_memory_arch(u64 base, u64
> size)
> high_mem_sz = size;
> in_use = 1;
> memblock_add_node(base, size, 1);
> + memblock_reserve(base, size);
> #endif
> }
>
> @@ -157,7 +158,7 @@ void __init setup_arch_memory(void)
> min_high_pfn = PFN_DOWN(high_mem_start);
> max_high_pfn = PFN_DOWN(high_mem_start + high_mem_sz);
>
> - max_zone_pfn[ZONE_HIGHMEM] = max_high_pfn;
> + max_zone_pfn[ZONE_HIGHMEM] = min_low_pfn;
>
> high_memory = (void *)(min_high_pfn << PAGE_SHIFT);
> kmap_init();
> @@ -166,22 +167,26 @@ void __init setup_arch_memory(void)
> free_area_init(max_zone_pfn);
> }
>
> -/*
> - * mem_init - initializes memory
> - *
> - * Frees up bootmem
> - * Calculates and displays memory available/used
> - */
> -void __init mem_init(void)
> +static void __init highmem_init(void)
> {
> #ifdef CONFIG_HIGHMEM
> unsigned long tmp;
>
> - reset_all_zones_managed_pages();
> + memblock_free(high_mem_start, high_mem_sz);
> for (tmp = min_high_pfn; tmp < max_high_pfn; tmp++)
> free_highmem_page(pfn_to_page(tmp));
> #endif
> +}
>
> +/*
> + * mem_init - initializes memory
> + *
> + * Frees up bootmem
> + * Calculates and displays memory available/used
> + */
> +void __init mem_init(void)
> +{
> memblock_free_all();
> + highmem_init();
> mem_init_print_info(NULL);
> }
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On 8/28/20 4:55 PM, Peter Zijlstra wrote: On Fri, Aug 28, 2020 at 03:51:09PM -0400, Julien Desfossez wrote: + if (is_idle_task(rq_i->core_pick) && rq_i->nr_running) + rq_i->core_forceidle = true; Did you mean: rq_i->core_pick == rq_i->idle ? is_idle_task() will also match idle-injection threads, which I'm not sure we want here. Thanks for catching this. You are right, we should be checking for rq_i->idle. There are couple other places where we use is_idle_task. Will go through them and verify if we need to fix there as well. Thanks, Vineeth
Re: [PATCH v4 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation
On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add a devicetree binding documentation for the MT6360 Type-C driver.
>
> usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
>
> Signed-off-by: ChiYuan Huang
> ---
> .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73
> ++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> new file mode 100644
> index ..9e8ab0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT
> bindings
> +
> +maintainers:
> + - ChiYuan Huang
> +
> +description: |
> + Mediatek MT6360 is a multi-functional device. It integrates charger, ADC,
> flash, RGB indicators,
> + regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery
> controller.
> + This document only describes MT6360 Type-C Port Switch and Power Delivery
> controller.
> +
> +properties:
> + compatible:
> +enum:
> + - mediatek,mt6360-tcpc
> +
> + interrupts-extended:
> +maxItems: 1
> +
> + interrupt-names:
> +items:
> + - const: PD_IRQB
> +
> +patternProperties:
> + "connector":
Also, this is not a pattern, so should be under 'properties', and it
doesn't need quotes.
> +type: object
> +$ref: ../connector/usb-connector.yaml#
> +description:
> + Properties for usb c connector.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - interrupts-extended
> + - interrupt-names
> +
> +examples:
> + - |
> +#include
> +#include
> +i2c0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +mt6360@34 {
> +compatible = "mediatek,mt6360";
> +reg = <0x34>;
> +
> +tcpc {
> +compatible = "mediatek,mt6360-tcpc";
> +interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-names = "PD_IRQB";
> +
> +connector {
> +compatible = "usb-c-connector";
> +label = "USB-C";
> +data-role = "dual";
> +power-role = "dual";
> +try-power-role = "sink";
> +source-pdos = PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> +sink-pdos = PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> +op-sink-microwatt = <1000>;
> +};
> +};
> +};
> +};
> +...
> --
> 2.7.4
>
Re: [PATCH v2] platform: cros_ec: Reduce ligthbar get version command
[-iio list][+kernel list]
On Tue, Aug 25, 2020 at 5:29 PM Gwendal Grignou wrote:
>
> By default, the lightbar commands are set to the
> biggest lightbar command and response. That length is greater than 128
> bytes and may not work on all machines.
> But all EC are probed for lightbar by sending a get version request.
> Set that request size precisely.
>
> Before the command would be:
> cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 194, insize:
> 128, result: 0
> Afer:
> cros_ec_cmd: version: 0, command: EC_CMD_LIGHTBAR_CMD, outsize: 1, insize: 8,
> result: 0
>
> Signed-off-by: Gwendal Grignou
> ---
> Changes since v1:
> - Remove BUG and TEST fields.
>
> drivers/platform/chrome/cros_ec_lightbar.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
> b/drivers/platform/chrome/cros_ec_lightbar.c
> index b59180bff5a3e..ef61298c30bdd 100644
> --- a/drivers/platform/chrome/cros_ec_lightbar.c
> +++ b/drivers/platform/chrome/cros_ec_lightbar.c
> @@ -116,6 +116,8 @@ static int get_lightbar_version(struct cros_ec_dev *ec,
>
> param = (struct ec_params_lightbar *)msg->data;
> param->cmd = LIGHTBAR_CMD_VERSION;
> + msg->outsize = sizeof(param->cmd);
> + msg->result = sizeof(resp->version);
> ret = cros_ec_cmd_xfer_status(ec->ec_dev, msg);
> if (ret < 0) {
> ret = 0;
> --
> 2.28.0.297.g1956fa8f8d-goog
>
Re: [PATCH v4 2/2] usb typec: mt6360: Add MT6360 Type-C DT binding documentation
On Fri, Aug 28, 2020 at 06:30:36PM +0800, cy_huang wrote:
> From: ChiYuan Huang
>
> Add a devicetree binding documentation for the MT6360 Type-C driver.
>
> usb typec: mt6360: Rename DT binding doument from mt6360 to mt636x
>
> Signed-off-by: ChiYuan Huang
> ---
> .../bindings/usb/mediatek,mt6360-tcpc.yaml | 73
> ++
> 1 file changed, 73 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> new file mode 100644
> index ..9e8ab0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/mediatek,mt6360-tcpc.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/usb/mediatek,mt6360-tcpc.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Mediatek MT6360 Type-C Port Switch and Power Delivery controller DT
> bindings
> +
> +maintainers:
> + - ChiYuan Huang
> +
> +description: |
> + Mediatek MT6360 is a multi-functional device. It integrates charger, ADC,
> flash, RGB indicators,
> + regulators (BUCKs/LDOs), and TypeC Port Switch with Power Delivery
> controller.
> + This document only describes MT6360 Type-C Port Switch and Power Delivery
> controller.
> +
> +properties:
> + compatible:
> +enum:
> + - mediatek,mt6360-tcpc
> +
> + interrupts-extended:
Use 'interrupts'. The tooling will automatically support
'interrupts-extended'.
> +maxItems: 1
> +
> + interrupt-names:
> +items:
> + - const: PD_IRQB
> +
> +patternProperties:
> + "connector":
> +type: object
> +$ref: ../connector/usb-connector.yaml#
> +description:
> + Properties for usb c connector.
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - interrupts-extended
> + - interrupt-names
> +
> +examples:
> + - |
> +#include
> +#include
> +i2c0 {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +mt6360@34 {
> +compatible = "mediatek,mt6360";
> +reg = <0x34>;
> +
> +tcpc {
> +compatible = "mediatek,mt6360-tcpc";
> +interrupts-extended = < 3 IRQ_TYPE_LEVEL_LOW>;
> +interrupt-names = "PD_IRQB";
> +
> +connector {
Where's the data connections? The assumption of the binding is the USB
(2 and 3) connections come from the parent if there's no graph to the
USB controller(s).
> +compatible = "usb-c-connector";
> +label = "USB-C";
> +data-role = "dual";
> +power-role = "dual";
> +try-power-role = "sink";
> +source-pdos = PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> +sink-pdos = PDO_FIXED_DUAL_ROLE | PDO_FIXED_DATA_SWAP)>;
> +op-sink-microwatt = <1000>;
> +};
> +};
> +};
> +};
> +...
> --
> 2.7.4
>
Re: [RFC PATCH v7 08/23] sched: Add core wide task selection and scheduling.
On 8/28/20 4:51 PM, Peter Zijlstra wrote: cpumask_weigt() is fairly expensive, esp. for something that should 'never' happen. What exactly is the race here? We'll update the cpu_smt_mask() fairly early in secondary bringup, but where does it become a problem? The moment the new thread starts scheduling it'll block on the common rq->lock and then it'll cycle task_seq and do a new pick. So where do things go side-ways? During hotplug stress test, we have noticed that while a sibling is in pick_next_task, another sibling can go offline or come online. What we have observed is smt_mask get updated underneath us even if we hold the lock. From reading the code, looks like we don't hold the rq lock when the mask is updated. This extra logic was to take care of that. Can we please split out this hotplug 'fix' into a separate patch with a coherent changelog. Sorry about this. I had posted this as separate patches in v6 list, but merged it for v7. Will split it and have details about the fix in next iteration. Thanks, Vineeth
Re: [PATCH v4] dt-bindings: nvmem: Add syscon to Vybrid OCOTP driver
On Mon, 24 Aug 2020 20:04:06 -0700, Chris Healy wrote:
> From: Chris Healy
>
> Add syscon compatibility with Vybrid OCOTP driver binding. This is
> required to access the UID.
>
> Fixes: 623069946952 ("nvmem: Add DT binding documentation for Vybrid
> OCOTP driver")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Chris Healy
> ---
> Changes in v4:
> - Point to the appropriate commit for the Fixes: line
> - Update the Required Properties to add the "syscon" compatible
> ---
> Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Acked-by: Rob Herring
Re: [PATCH v4 2/4] dt-bindings: arm: fsl: Add binding for Variscite Symphony board with VAR-SOM-MX8MM
On Mon, 24 Aug 2020 21:18:17 +0200, Krzysztof Kozlowski wrote: > Add a binding for the Variscite Symphony evaluation kit board with > VAR-SOM-MX8MM System on Module. > > Signed-off-by: Krzysztof Kozlowski > > --- > > Changes since v1: > 1. None > --- > Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Acked-by: Rob Herring
