Re: usb: dwc3: gadget: Change runtime pm function for DWC3 runtime suspend
Hello!
On 15.02.2021 5:38, Daehwan Jung wrote:
It seems pm_runtime_put calls runtime_idle callback not runtime_suspend
callback.
It's better to use pm_runtime_put_sync_suspend to allow DWC3 runtime suspend.
Signed-off-by: Daehwan Jung
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index aebcf8e..4a4b93b 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2229,7 +2229,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int
is_on)
*/
ret = pm_runtime_get_sync(dwc->dev);
if (!ret || ret < 0) {
BTW, this can be shortened to (ret <= 0)...
- pm_runtime_put(dwc->dev);
+ pm_runtime_put_sync_suspend(dwc->dev);
return 0;
}
MBR, Sergei
[PATCH v7 2/3] scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM
By design, SCMI performance domains define the granularity of
performance controls, they do not describe any underlying hardware
dependencies (although they may match in many cases).
It is therefore possible to have some platforms where hardware may have
the ability to control CPU performance at different granularity and choose
to describe fine-grained performance control through SCMI.
In such situations, the energy model would be provided with inaccurate
information based on controls, while it still needs to know the
performance boundaries.
To restore correct functionality, retrieve information of CPUs under the
same performance domain from operating-points-v2 in DT, and pass it on to
EM.
Reviewed-by: Ionela Voinescu
Tested-by: Ionela Voinescu
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 72 --
1 file changed, 52 insertions(+), 20 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 34bf2eb8d465..fc9866511f01 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -126,6 +126,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
struct scmi_data *priv;
struct cpufreq_frequency_table *freq_table;
struct em_data_callback em_cb = EM_DATA_CB(scmi_get_cpu_power);
+ cpumask_var_t opp_shared_cpus;
bool power_scale_mw;
cpu_dev = get_cpu_device(policy->cpu);
@@ -134,32 +135,62 @@ static int scmi_cpufreq_init(struct cpufreq_policy
*policy)
return -ENODEV;
}
- ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
- if (ret) {
- dev_warn(cpu_dev, "failed to add opps to the device\n");
- return ret;
- }
+ if (!zalloc_cpumask_var(_shared_cpus, GFP_KERNEL))
+ ret = -ENOMEM;
+ /* Obtain CPUs that share SCMI performance controls */
ret = scmi_get_sharing_cpus(cpu_dev, policy->cpus);
if (ret) {
dev_warn(cpu_dev, "failed to get sharing cpumask\n");
- return ret;
+ goto out_free_cpumask;
}
- ret = dev_pm_opp_set_sharing_cpus(cpu_dev, policy->cpus);
- if (ret) {
- dev_err(cpu_dev, "%s: failed to mark OPPs as shared: %d\n",
- __func__, ret);
- return ret;
+ /*
+* Obtain CPUs that share performance levels.
+* The OPP 'sharing cpus' info may come from DT through an empty opp
+* table and opp-shared.
+*/
+ ret = dev_pm_opp_of_get_sharing_cpus(cpu_dev, opp_shared_cpus);
+ if (ret || !cpumask_weight(opp_shared_cpus)) {
+ /*
+* Either opp-table is not set or no opp-shared was found.
+* Use the CPU mask from SCMI to designate CPUs sharing an OPP
+* table.
+*/
+ cpumask_copy(opp_shared_cpus, policy->cpus);
}
+ /*
+* Add OPPs only on those CPUs for which we haven't already done so.
+*/
nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
if (nr_opp <= 0) {
- dev_err(cpu_dev, "%s: No OPPs for this device: %d\n",
- __func__, ret);
-
- ret = -ENODEV;
- goto out_free_priv;
+ ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
+ if (ret) {
+ dev_warn(cpu_dev, "failed to add opps to the device\n");
+ goto out_free_cpumask;
+ }
+
+ nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
+ if (nr_opp <= 0) {
+ dev_err(cpu_dev, "%s: No OPPs for this device: %d\n",
+ __func__, ret);
+
+ ret = -ENODEV;
+ goto out_free_opp;
+ }
+
+ ret = dev_pm_opp_set_sharing_cpus(cpu_dev, opp_shared_cpus);
+ if (ret) {
+ dev_err(cpu_dev, "%s: failed to mark OPPs as shared:
%d\n",
+ __func__, ret);
+
+ goto out_free_opp;
+ }
+
+ power_scale_mw = handle->perf_ops->power_scale_mw_get(handle);
+ em_dev_register_perf_domain(cpu_dev, nr_opp, _cb,
+ opp_shared_cpus, power_scale_mw);
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
@@ -192,17 +223,18 @@ static int scmi_cpufreq_init(struct cpufreq_policy
*policy)
policy->fast_switch_possible =
handle->perf_ops->fast_switch_possible(handle, cpu_dev);
- power_scale_mw = handle->perf_ops->power_scale_mw_get(handle);
- em_dev_register_perf_domain(cpu_dev, nr_opp, _cb, policy->cpus,
- power_scale_mw);
-
+ free_cpumask_var(opp_shared_cpus);
return 0;
[PATCH v7 3/3] cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev
From: Sudeep Holla
Add "arm,vexpress" to cpufreq-dt-platdev blacklist since the actual
scaling is handled by the firmware cpufreq drivers(scpi, scmi and
vexpress-spc).
Signed-off-by: Sudeep Holla
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index bd2db0188cbb..91e6a0c10dbf 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -103,6 +103,8 @@ static const struct of_device_id whitelist[] __initconst = {
static const struct of_device_id blacklist[] __initconst = {
{ .compatible = "allwinner,sun50i-h6", },
+ { .compatible = "arm,vexpress", },
+
{ .compatible = "calxeda,highbank", },
{ .compatible = "calxeda,ecx-2000", },
--
2.27.0
[PATCH v7 1/3] scmi-cpufreq: Remove deferred probe
The current implementation of the scmi_cpufreq_init() function returns
-EPROBE_DEFER when the OPP table is not populated. In practice the
cpufreq core cannot handle this error code.
Therefore, fix the return value and clarify the error message.
Reviewed-by: Ionela Voinescu
Signed-off-by: Nicola Mazzucato
---
drivers/cpufreq/scmi-cpufreq.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 491a0a24fb1e..34bf2eb8d465 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -155,9 +155,11 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
if (nr_opp <= 0) {
- dev_dbg(cpu_dev, "OPP table is not ready, deferring probe\n");
- ret = -EPROBE_DEFER;
- goto out_free_opp;
+ dev_err(cpu_dev, "%s: No OPPs for this device: %d\n",
+ __func__, ret);
+
+ ret = -ENODEV;
+ goto out_free_priv;
}
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
--
2.27.0
[PATCH v7 0/3] CPUFreq: Add support for opp-sharing cpus
Hi Viresh, In this V7 posting I have reworked the CPUFreq scmi driver in a different way as suggested in v6. Essentially I believe it is more efficient to keep the support for opp-shared in the _init() stage, rather than moving everything to _probe(), storing whatever is required and reuse it only once in _init(). The reasons for this are: - scmi-cpufreq has no init cases that would require a deferred probe. - therefore, moving the all the cpus initialisation to probe, whilst possible, will result in a waste of memory, since we need to store cpumask and freq_table only for them to be reused just once later on at init. - it does not appear to be functional justification for moving the init code to probe, which results in unnecessary overhead for both coding and review. - this change is much smaller and only one patch required (1 file changed, 52 insertions, 20 deletions) compared to a version where we first move init code to _probe and later add support for opp-v2 (2 patches, 1 file changed, 194+34 insertions, 44+9 deletions, version with a linked list). - this v7 implementation is much easier to maintain. Many thanks, Nicola [v7] * Bring back common stuff for CPUs from _init stage to _probe * Remove patch "scmi-cpufreq: Move CPU initialisation to probe" This v7 is based on Linux 5.11-rc6 [v6] * Remove deferred probe, not occurring * Move common stuff for CPUs from _init stage to _probe This V6 is rebased on next-20210111 [v5] * Rework documentation of opp-shared within OPP node * Register EM only for the first CPU within cpumask in driver * Add check for nr_opp in driver before registering EM * Add comments on both dev_pm_opp_get_opp_count in driver * Remove redundant ret=0 in driver This v5 is rebased on top of: next-20201208 + Lukasz Luba's patches [1] [v4] * Remove unconditional set of opp_table->shared_opp to exclusive * Add implementation for scmi-cpufreq * Change subject These patches are on top of: next-20201201 + Lukasz Luba's patches (waiting for Rafael) [1] [v3] * Remove proposal for new 'cpu-performance-dependencies' as we instead can reuse the opp table. * Update documentation for devicetree/bindings/opp * Minor changes within opp to support empty opp table * Rework the RFC by adding a second proposal [v2] * Fix errors when running make dt_binding_check * Improve commit message description for the dt-binding * Add RFC for implementation in cpufreq-core and one of its drivers. Nicola Mazzucato (2): scmi-cpufreq: Remove deferred probe scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM Sudeep Holla (1): cpufreq: blacklist Arm Vexpress platforms in cpufreq-dt-platdev drivers/cpufreq/cpufreq-dt-platdev.c | 2 + drivers/cpufreq/scmi-cpufreq.c | 70 +--- 2 files changed, 54 insertions(+), 18 deletions(-) -- 2.27.0
Re: [PATCH 2/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
Hi, Thanks for your review. On Mon, Feb 15, 2021 at 08:07:21AM +0200, Leon Romanovsky wrote: > On Mon, Feb 15, 2021 at 02:06:53PM +0900, Nobuhiro Iwamatsu wrote: > > Add dwmac-visconti to the stmmac driver in Toshiba Visconti ARM SoCs. > > This patch contains only the basic function of the device. There is no > > clock control, PM, etc. yet. These will be added in the future. > > > > Signed-off-by: Nobuhiro Iwamatsu > > --- > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 + > > drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + > > .../ethernet/stmicro/stmmac/dwmac-visconti.c | 285 ++ > > 3 files changed, 294 insertions(+) > > create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig > > b/drivers/net/ethernet/stmicro/stmmac/Kconfig > > index 53f14c5a9e02..55ba67a550b9 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig > > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig > > @@ -219,6 +219,14 @@ config DWMAC_INTEL_PLAT > > This selects the Intel platform specific glue layer support for > > the stmmac device driver. This driver is used for the Intel Keem Bay > > SoC. > > + > > +config DWMAC_VISCONTI > > + bool "Toshiba Visconti DWMAC support" > > + def_bool y > Sorry, I sent the wrong patchset that didn't fix this point out. > I asked it before, but never received an answer. I have received your point out and have sent an email with the content to remove this line. But it may not have arrived yet... > Why did you use "def_bool y" and not "default y"? Isn't it supposed to be > "depends on STMMAC_ETH"? And probably it shouldn't be set as a default as "y". > The reason why "def_bool y" was set is that the wrong fix was left when debugging. Also, I don't think it is necessary to set "default y". This is also incorrect because it says "bool" Toshiba Visconti DWMAC support "". I change it to trustate in the new patch. And this driver is enabled when STMMAC_PLATFORM was Y. And STMMAC_PLATFORM depends on STMMAC_ETH. So I understand that STMMAC_ETH does not need to be dependents. Is this understanding wrong? > Thanks > Best regards, Nobuhiro
[PATCH] mtd: parsers: ofpart: fix building as module
From: Rafał Miłecki
This fixes:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse" [drivers/mtd/parsers/ofpart.ko]
undefined!
Reported-by: Stephen Rothwell
Fixes: 09cf6ee6d21c ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
Signed-off-by: Rafał Miłecki
---
drivers/mtd/parsers/Makefile | 2 +-
drivers/mtd/parsers/bcm4908-partitions.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 01972a5edc5c..bf58a5221730 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -4,7 +4,7 @@ obj-$(CONFIG_MTD_BCM47XX_PARTS) += bcm47xxpart.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_CMDLINE_PARTS)+= cmdlinepart.o
obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
-obj-$(CONFIG_MTD_OF_PARTS) += bcm4908-partitions.o
+ofpart-objs:= bcm4908-partitions.o
obj-$(CONFIG_MTD_PARSER_IMAGETAG) += parser_imagetag.o
obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
obj-$(CONFIG_MTD_PARSER_TRX) += parser_trx.o
diff --git a/drivers/mtd/parsers/bcm4908-partitions.c
b/drivers/mtd/parsers/bcm4908-partitions.c
index 40eb3b3801c3..ac69a2169763 100644
--- a/drivers/mtd/parsers/bcm4908-partitions.c
+++ b/drivers/mtd/parsers/bcm4908-partitions.c
@@ -62,3 +62,5 @@ int bcm4908_partitions_post_parse(struct mtd_info *mtd,
struct mtd_partition *pa
return 0;
}
+
+MODULE_LICENSE("GPL");
--
2.26.2
[PATCH net-next RFC v3] net: hdlc_x25: Queue outgoing LAPB frames
When sending packets, we will first hand over the (L3) packets to the
LAPB module. The LAPB module will then hand over the corresponding LAPB
(L2) frames back to us for us to transmit.
The LAPB module can also emit LAPB (L2) frames at any time, even without
an (L3) packet currently being sent on the device. This happens when the
LAPB module tries to send (L3) packets queued up in its internal queue,
or when the LAPB module decides to send some (L2) control frame.
This means we need to have a queue for these outgoing LAPB (L2) frames,
otherwise frames can be dropped if sent when the hardware driver is
already busy in transmitting. The queue needs to be controlled by
the hardware driver's netif_stop_queue and netif_wake_queue calls.
Therefore, we need to use the device's qdisc TX queue for this purpose.
However, currently outgoing LAPB (L2) frames are not queued.
On the other hand, outgoing (L3) packets (before they are handed over
to the LAPB module) don't need to be queued, because the LAPB module
already has an internal queue for them, and is able to queue new outgoing
(L3) packets at any time. However, currently outgoing (L3) packets are
being queued in the device's qdisc TX queue, which is controlled by
the hardware driver's netif_stop_queue and netif_wake_queue calls.
This is unnecessary and meaningless.
To fix these issues, we can split the HDLC device into two devices -
a virtual X.25 device and the actual HDLC device, use the virtual X.25
device to send (L3) packets and then use the actual HDLC device to
queue LAPB (L2) frames. The outgoing (L2) LAPB queue will be controlled
by the hardware driver's netif_stop_queue and netif_wake_queue calls,
while outgoing (L3) packets will not be affected by these calls.
Cc: Martin Schiller
Signed-off-by: Xie He
---
Change from RFC v2:
Simplified the commit message.
Dropped the x25_open fix which is already merged into net-next now.
Use HDLC_MAX_MTU as the mtu of the X.25 virtual device.
Add an explanation to the documentation about the X.25 virtual device.
Change from RFC v1:
Properly initialize state(hdlc)->x25_dev and state(hdlc)->x25_dev_lock.
---
Documentation/networking/generic-hdlc.rst | 3 +
drivers/net/wan/hdlc_x25.c| 153 ++
2 files changed, 130 insertions(+), 26 deletions(-)
diff --git a/Documentation/networking/generic-hdlc.rst
b/Documentation/networking/generic-hdlc.rst
index 1c3bb5cb98d4..55f6b0ab45be 100644
--- a/Documentation/networking/generic-hdlc.rst
+++ b/Documentation/networking/generic-hdlc.rst
@@ -59,6 +59,9 @@ or::
In Frame Relay mode, ifconfig master hdlc device up (without assigning
any IP address to it) before using pvc devices.
+In X.25 mode, ifconfig the hdlc device up, then a virtual X.25 device
+would appear for use.
+
Setting interface:
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 4aaa6388b9ee..b0541f1bfb4e 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,13 @@
struct x25_state {
x25_hdlc_proto settings;
+ struct net_device *x25_dev;
+ spinlock_t x25_dev_lock; /* Protects the x25_dev pointer */
+};
+
+/* Pointed to by netdev_priv(x25_dev) */
+struct x25_device {
+ struct net_device *hdlc_dev;
};
static int x25_ioctl(struct net_device *dev, struct ifreq *ifr);
@@ -32,6 +39,11 @@ static struct x25_state *state(hdlc_device *hdlc)
return hdlc->state;
}
+static struct x25_device *dev_to_x25(struct net_device *dev)
+{
+ return netdev_priv(dev);
+}
+
/* These functions are callbacks called by LAPB layer */
static void x25_connect_disconnect(struct net_device *dev, int reason, int
code)
@@ -89,15 +101,10 @@ static int x25_data_indication(struct net_device *dev,
struct sk_buff *skb)
static void x25_data_transmit(struct net_device *dev, struct sk_buff *skb)
{
- hdlc_device *hdlc = dev_to_hdlc(dev);
-
+ skb->dev = dev_to_x25(dev)->hdlc_dev;
+ skb->protocol = htons(ETH_P_HDLC);
skb_reset_network_header(skb);
- skb->protocol = hdlc_type_trans(skb, dev);
-
- if (dev_nit_active(dev))
- dev_queue_xmit_nit(skb, dev);
-
- hdlc->xmit(skb, dev); /* Ignore return value :-( */
+ dev_queue_xmit(skb);
}
@@ -163,7 +170,8 @@ static int x25_open(struct net_device *dev)
.data_indication = x25_data_indication,
.data_transmit = x25_data_transmit,
};
- hdlc_device *hdlc = dev_to_hdlc(dev);
+ struct net_device *hdlc_dev = dev_to_x25(dev)->hdlc_dev;
+ hdlc_device *hdlc = dev_to_hdlc(hdlc_dev);
struct lapb_parms_struct params;
int result;
@@ -195,9 +203,98 @@ static int x25_open(struct net_device *dev)
-static void x25_close(struct net_device *dev)
+static int x25_close(struct net_device *dev)
{
lapb_unregister(dev);
+ return 0;
+}
+
+static const struct net_device_ops hdlc_x25_netdev_ops = {
+ .ndo_open =
Re: [PATCH 0/5] iio: kfifo: define a devm_iio_kfifo_buffer_setup helper
On Sun, Feb 14, 2021 at 5:06 PM Jonathan Cameron wrote:
>
> On Sun, 14 Feb 2021 16:33:08 +0200
> Alexandru Ardelean wrote:
>
> > This is a re-spin of an older set [1]:
> >
> > https://patchwork.kernel.org/project/linux-iio/patch/20200401125936.6398-1-alexandru.ardel...@analog.com/
> >
> > Patch 'iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free()' is
> > already be present in a fixes-togreg path. It did not make it yet
> > downstream in the iio-togreg path.
> >
> > Following [1], where there was a suggestion to name this
> > 'devm_iio_device_attach_new_kfifo_buffer()', I took another look and
> > devm_iio_kfifo_buffer_setup() made more sense, since there is already a
> > '{devm_}iio_triggered_buffer_setup()' helper.
> >
> > This reduces the usage of the iio_device_attach_buffer() helper to a
> > more manage-able state.
> > This is related to comment:
> >
> > https://lore.kernel.org/linux-iio/CA+U=Dsp5hxd9=rNbigUMFALBpPVBqDZDRq_Pe69ggKak7p46=w...@mail.gmail.com/T/#u
> This definitely reduces where we need to handle errors from
> iio_device_attach_buffer() which
> is good. I guess we need a rebase of one or the other series though to make
> this all fit together.
>
> >
> > This should have gone before the multibuffer patch-set, but I was still
> > waiting on patch 'iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free()'
> > to make it downstream in iio-togreg.
>
> Oops. I've been a touch slow sending things onwards recently.
>
> >
> > Regarding patch 'iio: kfifo: un-export devm_iio_kfifo_allocate() function'
> > I would have also wanted to un-export iio_kfifo_allocate() &
> > iio_kfifo_free(), but that still needs a bit of work to cleanup the IIO
> > dummy buffer.
>
> Yup. The lack of having a parent is a bit of pain. We just need to fake one
> I guess however silly that seems.
>
> Mind you, I'd also like to see this go over to the triggered_buffer stuff
> if possible.
Not sure what should go over the triggered_buffer stuff.
I would have happily done more cleanup there as well, but I'm trying
to defer some things to a later point.
Mostly to avoid blocking myself with too many overlapping patch-sets.
>
>
> > Related to patchset:
> >
> > https://lore.kernel.org/linux-iio/20201203095005.72252-1-alexandru.ardel...@analog.com/
> >
> > The IIO dummy driver seems to be one of those blockers in cleaning up
> > some IIO API.
> >
>
> Jonathan
>
> > Alexandru Ardelean (5):
> > iio: adc: ti_am335x_adc: remove omitted iio_kfifo_free()
> > iio: kfifo: add devm_iio_kfifo_buffer_setup() helper
> > iio: make use of devm_iio_kfifo_buffer_setup() helper
> > iio: accel: sca3000: use devm_iio_kfifo_buffer_setup() helper
> > iio: kfifo: un-export devm_iio_kfifo_allocate() function
> >
> > .../driver-api/driver-model/devres.rst| 2 +-
> > drivers/iio/accel/sca3000.c | 19 ++---
> > drivers/iio/accel/ssp_accel_sensor.c | 14 +++
> > drivers/iio/adc/ina2xx-adc.c | 14 +++
> > drivers/iio/adc/ti_am335x_adc.c | 24 +++
> > drivers/iio/buffer/kfifo_buf.c| 42 ++-
> > .../cros_ec_sensors/cros_ec_sensors_core.c| 13 +++---
> > drivers/iio/gyro/ssp_gyro_sensor.c| 14 +++
> > drivers/iio/health/max30100.c | 16 ---
> > drivers/iio/health/max30102.c | 16 ---
> > .../iio/imu/inv_icm42600/inv_icm42600_accel.c | 14 +++
> > .../iio/imu/inv_icm42600/inv_icm42600_gyro.c | 13 +++---
> > .../iio/imu/st_lsm6dsx/st_lsm6dsx_buffer.c| 15 +++
> > drivers/iio/light/acpi-als.c | 12 +++---
> > drivers/iio/light/apds9960.c | 16 ---
> > .../staging/iio/impedance-analyzer/ad5933.c | 23 ++
> > include/linux/iio/kfifo_buf.h | 7 +++-
> > 17 files changed, 125 insertions(+), 149 deletions(-)
> >
>
Re: [RFC PATCH 1/7] drivers: base: Add resource managed version of delayed work init
On Sat, 2021-02-13 at 16:59 +0100, Hans de Goede wrote:
> Hi,
>
> On 2/13/21 4:27 PM, Guenter Roeck wrote:
> > On 2/13/21 7:03 AM, Hans de Goede wrote:
> > [ ... ]
> > > I think something like this should work:
> > >
> > > static int devm_delayed_work_autocancel(struct device *dev,
> > > struct delayed_work *w,
> > > void (*worker)(struct
> > > work_struct *work)) {
> > > INIT_DELAYED_WORK(w, worker);
> > > return devm_add_action(dev, (void (*action)(void
> > > *))cancel_delayed_work_sync, w);
> > > }
> > >
> > > I'm not sure about the cast, that may need something like this
> > > instead:
> > >
> > > typedef void (*devm_action_func)(void *);
> > >
> > > static int devm_delayed_work_autocancel(struct device *dev,
> > > struct delayed_work *w,
> > > void (*worker)(struct
> > > work_struct *work)) {
> > > INIT_DELAYED_WORK(w, worker);
> > > return devm_add_action(dev,
> > > (devm_action_func)cancel_delayed_work_sync, w);
> >
> > Unfortunately, you can not type cast function pointers in C. It is
> > against the C ABI.
> > I am sure it is done in a few places in the kernel anyway, but
> > those are wrong.
>
> I see, bummer.
I think using devm_add_action() is still a good idea.
>
> If we add a devm_clk_prepare_enable() helper that should probably be
> added
> to drivers/clk/clk-devres.c and not to drivers/base/devres.c .
>
> I also still wonder if we cannot find a better place for this new
> devm_delayed_work_autocancel() helper but nothing comes to mind.
I don't like the idea of including device.h from workqueue.h - and I
think this would be necessary if we added
devm_delayed_work_autocancel() as inline in workqueue.h, right?
I also see strong objection towards the devm managed clean-ups.
How about adding some devm-helpers.c in drivers/base - where we could
collect devm-based helpers - and which could be enabled by own CONFIG -
and left out by those who dislike it?
I know I wrote that the devm_delayed_work_autocancel() does probably
not warrant own file - but if you can foresee devm_work_autocancel()
and few other generally useful helpers - then we would have a place for
those. The devm stuff should in my opinion live under drivers/.
Best Regards
Matti Vaittinen
Re: [PATCH] bus: mhi: core: Fix check for syserr at power_up
On Fri, 12 Feb 2021 at 22:27, Jeffrey Hugo wrote:
>
> The check to see if we have reset the device after detecting syserr at
> power_up is inverted. wait_for_event_timeout() returns 0 on failure,
> and a positive value on success. The check is looking for non-zero
> as a failure, which is likely to incorrectly cause a device init failure
> if syserr was detected at power_up. Fix this.
>
> Fixes: e18d4e9fa79b ("bus: mhi: core: Handle syserr during power_up")
> Signed-off-by: Jeffrey Hugo
Reviewed-by: Loic Poulain
> ---
> drivers/bus/mhi/core/pm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/mhi/core/pm.c b/drivers/bus/mhi/core/pm.c
> index 681960c..36ab7aa 100644
> --- a/drivers/bus/mhi/core/pm.c
> +++ b/drivers/bus/mhi/core/pm.c
> @@ -1092,7 +1092,7 @@ int mhi_async_power_up(struct mhi_controller *mhi_cntrl)
>) ||
> !val,
> msecs_to_jiffies(mhi_cntrl->timeout_ms));
> - if (ret) {
> + if (!ret) {
> ret = -EIO;
> dev_info(dev, "Failed to reset MHI due to syserr
> state\n");
> goto error_bhi_offset;
> --
> Qualcomm Technologies, Inc. is a member of the
> Code Aurora Forum, a Linux Foundation Collaborative Project.
>
Re: [PATCH] bus: mhi: core: Use current ee in intvec handler for syserr
On Sat, 13 Feb 2021 at 01:41, Jeffrey Hugo wrote:
>
> The intvec handler stores the caches ee in a local variable for use in
> processing the intvec. When determining if a syserr is a fatal error or
> not, the intvec handler is using the cached version, when it should be
> using the current ee read from the device. Currently, the device could
> be in the PBL ee as the result of a fatal error, but the cached ee might
> be AMSS, which would cause the intvec handler to incorrectly signal a
> non-fatal syserr.
>
> Fixes: 3000f85b8f47 ("bus: mhi: core: Add support for basic PM operations")
> Signed-off-by: Jeffrey Hugo
So in that function, 'ee' should be 'previous_ee', right?
Reviewed-by: Loic Poulain
Re: [PATCH] cpufreq: schedutil: Don't use the limits_changed flag any more
On Mon, 15 Feb 2021 12:00:08 +0530
Viresh Kumar wrote:
> On 14-02-21, 11:44, Yue Hu wrote:
> > On Fri, 12 Feb 2021 17:14:03 +0100
> > "Rafael J. Wysocki" wrote:
> > > This may be running in parallel with sugov_update_next_freq() on a
> > > different CPU, so the latter may clear need_freq_update right
> > > after it has been set here unless I'm overlooking something.
> >
> > Whether this logic is also happening for limits_changed in
> > sugo_should_update_freq() or not?
>
> It is but it shouldn't have any side effects as we calculate the next
> frequency after cleaning the limits_changed flag. Your patch would
> have been fine, but it is not anymore because of commit 23a881852f3e
> ("cpufreq: schedutil: Don't skip freq update if need_freq_update is
> set").
>
> It made a considerable change after which your patch adds a bug. With
> 23a881852f3e, need_freq_update is updated/cleared after the next
> frequency is calculated, while earlier it was cleared before it. And
> so even with the race condition taking place, there were no issues.
>
Okay, clear.
Re: [PATCH v21 00/10] NTFS read-write driver GPL implementation by Paragon Software
The bug can be reproduced easily with following step:
find mountpoint -exec ls -d {} + 1>/dev/null
2021-02-14 2:00 GMT+07.00, Hanabishi Recca :
> On Sat, Feb 13, 2021 at 2:27 AM Oleksandr Natalenko
> wrote:
>
>> Hanabishi, babam (both in Cc), here [2] you've reported some issues with
>> accessing some files and with hidden attributes. You may reply to this
>> email of mine with detailed description of your issues, and maybe
>> developers will answer you.
>
> There is strange files access issue since v18 update. Some random
> files on partition became inaccessible, can't be read or even deleted.
> For example:
>
> # ls -la
> ls: cannot access 'NlsStrings.js': No such file or directory
> total 176
> drwxrwxrwx 1 root root 4096 Oct 20 10:41 .
> drwxrwxrwx 1 root root 12288 Oct 20 10:42 ..
> -rwxrwxrwx 1 root root 8230 Oct 19 17:02 Layer.js < this file is ok
> -? ? ???? NlsStrings.js < this file is
> inaccessible
> ...
>
> To reproduce the issue try to mount a NTFS partition with deep
> structure and large files amout. Then run on it some recursive file
> command, e.g. 'du -sh', it will list all access errors.
> Can't say what exactly causes it. Filesystem itself is not damaged,
> when mounting it via ntfs-3g, ntfs3 <18 or in Windows it works
> normally. The files is not damaged and chkdsk report no errors.
>
--
Sorry, my English is bad.
Re: [PATCH net-next RFC v2] net: hdlc_x25: Queue outgoing LAPB frames
On Sun, Feb 14, 2021 at 10:27 PM Martin Schiller wrote: > > At first glance, the patch looks quite reasonable. The only thing I > noticed right away is that you also included the changes of your patch > "Return meaningful error code in x25_open". Thanks! It was because this patch was sent before that fix got merged into "net-next". I will drop that part now. I will also make the MTU of the virtual X.25 device be HDLC_MAX_MTU (instead of HDLC_MAX_MTU - 2), because I see other HDLC Protocol Drivers seem to also use this value as MTU (without subtracting the header length). > I hope to get back to the office this week and test it. Thanks!
Re: [RFC PATCH 1/7] drivers: base: Add resource managed version of delayed work init
On Sat, 2021-02-13 at 14:18 +0100, Hans de Goede wrote: > Hi, > > On 2/13/21 1:16 PM, Greg Kroah-Hartman wrote: > > On Sat, Feb 13, 2021 at 01:58:44PM +0200, Matti Vaittinen wrote: > > > +/** > > > + * devm_delayed_work_autocancel - Resource-managed work > > > allocation > > > + * @dev: Device which lifetime work is bound to > > > + * @pdata: work to be cancelled when device exits > > > + * > > > + * Initialize work which is automatically cancelled when device > > > exits. > > > > There is no such thing in the driver model as "when device exits". > > Please use the proper terminology as I do not understand what you > > think > > this is doing here... > > I agree that this needs better wording I always talk about driver- > unbinding > because sysfs has /sys/bus/*/drivers/*/bind and > /sys/bus/*/drivers/*/unbind > attributes. But I see that the relevant driver-core functions all > call it > driver detaching, so lets be consistent and use that here too. //Snip > > > @@ -249,6 +250,10 @@ void __iomem *devm_of_iomap(struct device > > > *dev, > > > struct device_node *node, int index, > > > resource_size_t *size); > > > > > > +/* delayed work which is cancelled when driver exits */ > > > > Not when the "driver exits". > > Right this should be detached not exits. > Thanks guys. I am poor with the terminology so I do appreciate your help in getting this right. I can change this for the v2. > > There is two different lifespans here (well 3). Code and > > data*2. Don't > > confuse them as that will just cause lots of problems. > > > > The move toward more and more "devm" functions is not the way to go > > as > > they just more and more make things easier to get wrong. > > > > APIs should be impossible to get wrong, this one is going to be > > almost > > impossible to get right. > > I have to disagree here devm generally makes it easier to get things > right, > it is when some devm functions are missing and devm and non devm > resources > are mixed that things get tricky. Thanks for the discussion. I hope we can come to some conclusion here. Unsurprisingly I agree with Hans here. I did after all send this patch series :) I guess I am mostly just repeating what he said. As Hans pointed out, when all calls are 'undone' by devm the order of 'undoing' is highly likely to be correct as the unwinding is done in reverse order to initializations. I think it is sane to assume in most case things are initiated in order where operations which depend on something are done last - and when 'unwinding' things those are 'undone' first. My 'gut feeling' for probe / remove related errors is that the most usual errors I've seen have been: a) Tear-down completely forgotten b) Tear-down forgotten at error path c) Wrong order of initiating things (IRQ requested prior resource initialization) d) Wrong order of cleann-up at remove. a) and b) class errors have been the most common ones I've seen. They can be completely avoided when devm is used. c) is there no matter if we use devm or not. d) is mostly avoided when only devm is used - mixing devm and manual operations make this more likely as Hans pointed out. As long as we have some devm operations we should help avoid mixing devm and manual clean-up. Best Regards Matti Vaittinen
Re: [PATCH v2 3/8] xen/events: avoid handling the same event on two cpus at the same time
On 14.02.21 22:34, Julien Grall wrote:
Hi Juergen,
On 11/02/2021 10:16, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
drivers/xen/events/events_base.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/xen/events/events_base.c
b/drivers/xen/events/events_base.c
index e157e7506830..f7e22330dcef 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -102,6 +102,7 @@ struct irq_info {
#define EVT_MASK_REASON_EXPLICIT 0x01
#define EVT_MASK_REASON_TEMPORARY 0x02
#define EVT_MASK_REASON_EOI_PENDING 0x04
+ u8 is_active; /* Is event just being handled? */
unsigned irq;
evtchn_port_t evtchn; /* event channel */
unsigned short cpu; /* cpu bound */
@@ -622,6 +623,7 @@ static void xen_irq_lateeoi_locked(struct irq_info
*info, bool spurious)
}
info->eoi_time = 0;
+ smp_store_release(>is_active, 0);
do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
@@ -809,13 +811,15 @@ static void pirq_query_unmask(int irq)
static void eoi_pirq(struct irq_data *data)
{
- evtchn_port_t evtchn = evtchn_from_irq(data->irq);
+ struct irq_info *info = info_for_irq(data->irq);
+ evtchn_port_t evtchn = info ? info->evtchn : 0;
struct physdev_eoi eoi = { .irq = pirq_from_irq(data->irq) };
int rc = 0;
if (!VALID_EVTCHN(evtchn))
return;
+ smp_store_release(>is_active, 0);
Would you mind to explain why you are using the release semantics?
It is basically releasing a lock. So release semantics seem to be
appropriate.
It is also not clear to me if there are any expected ordering between
clearing is_active and clearing the pending bit.
No, I don't think there is a specific ordering required. is_active is
just guarding against two simultaneous IRQ handler calls for the same
event being active. Clearing the pending bit is not part of the guarded
section.
clear_evtchn(evtchn);
The 2 lines here seems to be a common pattern in this patch. So I would
suggest to create a new helper.
Okay.
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH] cpufreq: schedutil: Don't use the limits_changed flag any more
On 14-02-21, 11:44, Yue Hu wrote:
> On Fri, 12 Feb 2021 17:14:03 +0100
> "Rafael J. Wysocki" wrote:
> > This may be running in parallel with sugov_update_next_freq() on a
> > different CPU, so the latter may clear need_freq_update right after it
> > has been set here unless I'm overlooking something.
>
> Whether this logic is also happening for limits_changed in
> sugo_should_update_freq() or not?
It is but it shouldn't have any side effects as we calculate the next
frequency after cleaning the limits_changed flag. Your patch would
have been fine, but it is not anymore because of commit 23a881852f3e
("cpufreq: schedutil: Don't skip freq update if need_freq_update is
set").
It made a considerable change after which your patch adds a bug. With
23a881852f3e, need_freq_update is updated/cleared after the next
frequency is calculated, while earlier it was cleared before it. And
so even with the race condition taking place, there were no issues.
--
viresh
Re: [PATCH net-next RFC v2] net: hdlc_x25: Queue outgoing LAPB frames
On 2021-02-10 18:35, Xie He wrote:
When sending packets, we will first hand over the (L3) packets to the
LAPB module, then the LAPB module will hand over the corresponding LAPB
(L2) frames back to us for us to transmit.
The LAPB module can also emit LAPB (L2) frames at any time without an
(L3) packet currently being sent, when it is trying to send (L3)
packets
queued up in its internal queue, or when it decides to send some (L2)
control frame.
This means we need have a queue for these outgoing LAPB (L2) frames to
avoid congestion. This queue needs to be controlled by the hardware
drivers' netif_stop_queue and netif_wake_queue calls. So we need to use
a qdisc TX queue for this purpose.
On the other hand, the outgoing (L3) packets don't need to be queued,
because the LAPB module already has an internal queue for them.
However, currently the outgoing LAPB (L2) frames are not queued. This
can cause frames to be dropped by hardware drivers when they are busy.
At the same time the (L3) packets are being queued and controlled by
hardware drivers' netif_stop_queue and netif_wake_queue calls. This is
unnecessary and meaningless.
To solve this problem, we can split the HDLC device into two devices:
a virtual X.25 device and an actual HDLC device, using the virtual
X.25 device to send (L3) packets and using the actual HDLC device to
queue LAPB (L2) frames. The outgoing LAPB queue will be controlled by
hardware drivers' netif_stop_queue and netif_wake_queue calls, while
outgoing (L3) packets will not be affected by these calls.
At first glance, the patch looks quite reasonable. The only thing I
noticed right away is that you also included the changes of your patch
"Return meaningful error code in x25_open".
I hope to get back to the office this week and test it.
Cc: Martin Schiller
Signed-off-by: Xie He
---
Change from RFC v1:
Properly initialize state(hdlc)->x25_dev and state(hdlc)->x25_dev_lock.
---
drivers/net/wan/hdlc_x25.c | 158 ++---
1 file changed, 129 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index bb164805804e..2a7b3c3d0c05 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,13 @@
struct x25_state {
x25_hdlc_proto settings;
+ struct net_device *x25_dev;
+ spinlock_t x25_dev_lock; /* Protects the x25_dev pointer */
+};
+
+/* Pointed to by netdev_priv(x25_dev) */
+struct x25_device {
+ struct net_device *hdlc_dev;
};
static int x25_ioctl(struct net_device *dev, struct ifreq *ifr);
@@ -32,6 +39,11 @@ static struct x25_state *state(hdlc_device *hdlc)
return hdlc->state;
}
+static struct x25_device *dev_to_x25(struct net_device *dev)
+{
+ return netdev_priv(dev);
+}
+
/* These functions are callbacks called by LAPB layer */
static void x25_connect_disconnect(struct net_device *dev, int
reason, int code)
@@ -89,15 +101,10 @@ static int x25_data_indication(struct net_device
*dev, struct sk_buff *skb)
static void x25_data_transmit(struct net_device *dev, struct sk_buff
*skb)
{
- hdlc_device *hdlc = dev_to_hdlc(dev);
-
+ skb->dev = dev_to_x25(dev)->hdlc_dev;
+ skb->protocol = htons(ETH_P_HDLC);
skb_reset_network_header(skb);
- skb->protocol = hdlc_type_trans(skb, dev);
-
- if (dev_nit_active(dev))
- dev_queue_xmit_nit(skb, dev);
-
- hdlc->xmit(skb, dev); /* Ignore return value :-( */
+ dev_queue_xmit(skb);
}
@@ -163,17 +170,18 @@ static int x25_open(struct net_device *dev)
.data_indication = x25_data_indication,
.data_transmit = x25_data_transmit,
};
- hdlc_device *hdlc = dev_to_hdlc(dev);
+ struct net_device *hdlc_dev = dev_to_x25(dev)->hdlc_dev;
+ hdlc_device *hdlc = dev_to_hdlc(hdlc_dev);
struct lapb_parms_struct params;
int result;
result = lapb_register(dev, );
if (result != LAPB_OK)
- return result;
+ return -ENOMEM;
result = lapb_getparms(dev, );
if (result != LAPB_OK)
- return result;
+ return -EINVAL;
if (state(hdlc)->settings.dce)
params.mode = params.mode | LAPB_DCE;
@@ -188,16 +196,104 @@ static int x25_open(struct net_device *dev)
result = lapb_setparms(dev, );
if (result != LAPB_OK)
- return result;
+ return -EINVAL;
return 0;
}
-static void x25_close(struct net_device *dev)
+static int x25_close(struct net_device *dev)
{
lapb_unregister(dev);
+ return 0;
+}
+
+static const struct net_device_ops hdlc_x25_netdev_ops = {
+ .ndo_open = x25_open,
+ .ndo_stop = x25_close,
+ .ndo_start_xmit = x25_xmit,
+};
+
+static void x25_setup_virtual_dev(struct net_device *dev)
+{
+ dev->netdev_ops = _x25_netdev_ops;
+ dev->type=
Re: [PATCH] perf test: Fix unaligned access in sample parsing test
On 14/02/21 11:16 am, Namhyung Kim wrote:
> The ubsan reported the following error. It was because sample's raw
> data missed u32 padding at the end. So it broke the alignment of the
> array after it.
>
> The raw data contains an u32 size prefix so the data size should have
> an u32 padding after 8-byte aligned data.
>
> 27: Sample parsing :util/synthetic-events.c:1539:4:
> runtime error: store to misaligned address 0x6216b9bc for type
> '__u64' (aka 'unsigned long long'), which requires 8 byte alignment
> 0x6216b9bc: note: pointer points here
> 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff ff ff ff ff
> ^
> #0 0x561532a9fc96 in perf_event__synthesize_sample
> util/synthetic-events.c:1539:13
> #1 0x5615327f4a4f in do_test tests/sample-parsing.c:284:8
> #2 0x5615327f3f50 in test__sample_parsing tests/sample-parsing.c:381:9
> #3 0x56153279d3a1 in run_test tests/builtin-test.c:424:9
> #4 0x56153279c836 in test_and_print tests/builtin-test.c:454:9
> #5 0x56153279b7eb in __cmd_test tests/builtin-test.c:675:4
> #6 0x56153279abf0 in cmd_test tests/builtin-test.c:821:9
> #7 0x56153264e796 in run_builtin perf.c:312:11
> #8 0x56153264cf03 in handle_internal_command perf.c:364:8
> #9 0x56153264e47d in run_argv perf.c:408:2
> #10 0x56153264c9a9 in main perf.c:538:3
> #11 0x7f137ab6fbbc in __libc_start_main (/lib64/libc.so.6+0x38bbc)
> #12 0x561532596828 in _start ...
>
> SUMMARY: UndefinedBehaviorSanitizer: misaligned-pointer-use
> util/synthetic-events.c:1539:4 in
>
> Fixes: 045f8cd8542d ("perf tests: Add a sample parsing test")
> Cc: Adrian Hunter
> Signed-off-by: Namhyung Kim
Acked-by: Adrian Hunter
> ---
> tools/perf/tests/sample-parsing.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/perf/tests/sample-parsing.c
> b/tools/perf/tests/sample-parsing.c
> index f506eabfc269..0dbe3aa99853 100644
> --- a/tools/perf/tests/sample-parsing.c
> +++ b/tools/perf/tests/sample-parsing.c
> @@ -202,7 +202,7 @@ static int do_test(u64 sample_type, u64 sample_regs, u64
> read_format)
> .data = {1, -1ULL, 211, 212, 213},
> };
> u64 regs[64];
> - const u64 raw_data[] = {0x123456780a0b0c0dULL, 0x1102030405060708ULL};
> + const u32 raw_data[] = {0x12345678, 0x0a0b0c0d, 0x11020304, 0x05060708,
> 0 };
> const u64 data[] = {0x2211443366558877ULL, 0, 0xaabbccddeeff4321ULL};
> const u64 aux_data[] = {0xa55a, 0, 0xeeddee, 0x0282028202820282};
> struct perf_sample sample = {
>
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 2:40 PM Luis Henriques wrote:
>
> Greg KH writes:
>
> > On Fri, Feb 12, 2021 at 12:05:14PM +, Luis Henriques wrote:
> >> Greg KH writes:
> >>
> >> > On Fri, Feb 12, 2021 at 10:22:16AM +0200, Amir Goldstein wrote:
> >> >> On Fri, Feb 12, 2021 at 9:49 AM Greg KH
> >> >> wrote:
> >> >> >
> >> >> > On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> >> >> > > Filesystems such as procfs and sysfs generate their content at
> >> >> > > runtime. This implies the file sizes do not usually match the
> >> >> > > amount of data that can be read from the file, and that seeking
> >> >> > > may not work as intended.
> >> >> > >
> >> >> > > This will be useful to disallow copy_file_range with input files
> >> >> > > from such filesystems.
> >> >> > >
> >> >> > > Signed-off-by: Nicolas Boichat
> >> >> > > ---
> >> >> > > I first thought of adding a new field to struct file_operations,
> >> >> > > but that doesn't quite scale as every single file creation
> >> >> > > operation would need to be modified.
> >> >> >
> >> >> > Even so, you missed a load of filesystems in the kernel with this
> >> >> > patch
> >> >> > series, what makes the ones you did mark here different from the
> >> >> > "internal" filesystems that you did not?
> >> >> >
> >> >> > This feels wrong, why is userspace suddenly breaking? What changed in
> >> >> > the kernel that caused this? Procfs has been around for a _very_ long
> >> >> > time :)
> >> >>
> >> >> That would be because of (v5.3):
> >> >>
> >> >> 5dae222a5ff0 vfs: allow copy_file_range to copy across devices
> >> >>
> >> >> The intention of this change (series) was to allow server side copy
> >> >> for nfs and cifs via copy_file_range().
> >> >> This is mostly work by Dave Chinner that I picked up following requests
> >> >> from the NFS folks.
> >> >>
> >> >> But the above change also includes this generic change:
> >> >>
> >> >> - /* this could be relaxed once a method supports cross-fs copies
> >> >> */
> >> >> - if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> >> >> - return -EXDEV;
> >> >> -
> >> >>
> >> >> The change of behavior was documented in the commit message.
> >> >> It was also documented in:
> >> >>
> >> >> 88e75e2c5 copy_file_range.2: Kernel v5.3 updates
> >> >>
> >> >> I think our rationale for the generic change was:
> >> >> "Why not? What could go wrong? (TM)"
> >> >> I am not sure if any workload really gained something from this
> >> >> kernel cross-fs CFR.
> >> >
> >> > Why not put that check back?
> >> >
> >> >> In retrospect, I think it would have been safer to allow cross-fs CFR
> >> >> only to the filesystems that implement ->{copy,remap}_file_range()...
> >> >
> >> > Why not make this change? That seems easier and should fix this for
> >> > everyone, right?
> >> >
> >> >> Our option now are:
> >> >> - Restore the cross-fs restriction into generic_copy_file_range()
> >> >
> >> > Yes.
> >> >
> >>
> >> Restoring this restriction will actually change the current cephfs CFR
> >> behaviour. Since that commit we have allowed doing remote copies between
> >> different filesystems within the same ceph cluster. See commit
> >> 6fd4e6348352 ("ceph: allow object copies across different filesystems in
> >> the same cluster").
> >>
> >> Although I'm not aware of any current users for this scenario, the
> >> performance impact can actually be huge as it's the difference between
> >> asking the OSDs for copying a file and doing a full read+write on the
> >> client side.
> >
> > Regression in performance is ok if it fixes a regression for things that
> > used to work just fine in the past :)
> >
> > First rule, make it work.
>
> Sure, I just wanted to point out that *maybe* there are other options than
> simply reverting that commit :-)
>
> Something like the patch below (completely untested!) should revert to the
> old behaviour in filesystems that don't implement the CFR syscall.
>
> Cheers,
> --
> Luis
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 75f764b43418..bf5dccc43cc9 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1406,8 +1406,11 @@ static ssize_t do_copy_file_range(struct file
> *file_in, loff_t pos_in,
>file_out, pos_out,
>len, flags);
>
> - return generic_copy_file_range(file_in, pos_in, file_out, pos_out,
> len,
> - flags);
> + if (file_inode(file_in)->i_sb != file_inode(file_out)->i_sb)
> + return -EXDEV;
> + else
> + generic_copy_file_range(file_in, pos_in, file_out, pos_out,
> len,
> + flags);
> }
>
Which kernel is this patch based on?
At this point, I am with Dave and Darrick on not falling back to
generic_copy_file_range() at all.
We do not have proof of any workload that benefits from it and the
above patch
Re: [PATCH 2/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
On Mon, Feb 15, 2021 at 02:06:53PM +0900, Nobuhiro Iwamatsu wrote: > Add dwmac-visconti to the stmmac driver in Toshiba Visconti ARM SoCs. > This patch contains only the basic function of the device. There is no > clock control, PM, etc. yet. These will be added in the future. > > Signed-off-by: Nobuhiro Iwamatsu > --- > drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 + > drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + > .../ethernet/stmicro/stmmac/dwmac-visconti.c | 285 ++ > 3 files changed, 294 insertions(+) > create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c > > diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig > b/drivers/net/ethernet/stmicro/stmmac/Kconfig > index 53f14c5a9e02..55ba67a550b9 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig > @@ -219,6 +219,14 @@ config DWMAC_INTEL_PLAT > This selects the Intel platform specific glue layer support for > the stmmac device driver. This driver is used for the Intel Keem Bay > SoC. > + > +config DWMAC_VISCONTI > + bool "Toshiba Visconti DWMAC support" > + def_bool y I asked it before, but never received an answer. Why did you use "def_bool y" and not "default y"? Isn't it supposed to be "depends on STMMAC_ETH"? And probably it shouldn't be set as a default as "y". Thanks
Re: [net-next PATCH v5 13/15] phylink: introduce phylink_fwnode_phy_connect()
On Mon, Feb 08, 2021 at 03:31:11PM +, Russell King - ARM Linux admin wrote:
> On Mon, Feb 08, 2021 at 08:42:42PM +0530, Calvin Johnson wrote:
> > +int phylink_fwnode_phy_connect(struct phylink *pl,
> > + struct fwnode_handle *fwnode,
> > + u32 flags)
> > +{
> > + struct fwnode_handle *phy_fwnode;
> > + struct phy_device *phy_dev;
> > + int ret;
> > +
> > + if (is_of_node(fwnode)) {
> > + /* Fixed links and 802.3z are handled without needing a PHY */
> > + if (pl->cfg_link_an_mode == MLO_AN_FIXED ||
> > + (pl->cfg_link_an_mode == MLO_AN_INBAND &&
> > +phy_interface_mode_is_8023z(pl->link_interface)))
> > + return 0;
>
> This difference between ACPI and DT really needs to be described in the
> commit description.
>
> For example, why is it acceptable to have a PHY in fixed-link mode if
> we're using ACPI, and not DT?
>
> If we look at the phylink code, accepting a PHY when in fixed-link mode
> is basically not supported... so why should ACPI allow this?
DT and ACPI should handle fixed-link in similar manner. I'll remove the OF
check.
Thanks
Calvin
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Mon, Feb 15, 2021 at 3:27 AM Nicolas Boichat wrote: > > On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor wrote: > > > > On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner wrote: > > > > > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote: > > > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote: > > > > > > > > > If you can't tell from userspace that a file has data in it other > > > > > than by calling read() on it, then you can't use cfr on it. > > > > > > > > I don't know how to do that, Dave. :) > > > > > > If stat returns a non-zero size, then userspace knows it has at > > > least that much data in it, whether it be zeros or previously > > > written data. cfr will copy that data. The special zero length > > > regular pipe files fail this simple "how much data is there to copy > > > in this file" check... > > > > This suggests that if the Go standard library sees that > > copy_file_range reads zero bytes, we should assume that it failed, and > > should use the fallback path as though copy_file_range returned > > EOPNOTSUPP or EINVAL. This will cause an extra system call for an > > empty file, but as long as copy_file_range does not return an error > > for cases that it does not support we are going to need an extra > > system call anyhow. > > > > Does that seem like a possible mitigation? That is, are there cases > > where copy_file_range will fail to do a correct copy, and will return > > success, and will not return zero? > > I'm a bit worried about the sysfs files that report a 4096 bytes file > size, for 2 reasons: > - I'm not sure if the content _can_ actually be longer (I couldn't > find a counterexample) > - If you're unlucky enough to have a partial write in the output > filesystem, you'll get a non-zero return value and probably corrupted > content. > First of all, I am in favor of fixing the regression in the kernel caused by the change of behavior in v5.3. Having said that, I don't think it is a good idea to use ANY tool to copy a zero size pseudo file. rsync doesn't copy any data either if you try to use it to copy tracing into a temp file. I think it is perfectly sane for any tool to check file size before trying to read/copy. w.r.t. short write/short read, did you consider using the off_in/off_out arguments? I *think* current kernel CFR should be safe to use as long as the tool: 1. Checks file size before copy 2. Does not try to copy a range beyond EOF 3. Pass off_in/off_out args and verify that off_in/off_out advances as expected Thanks, Amir.
Re: [net-next PATCH v5 13/15] phylink: introduce phylink_fwnode_phy_connect()
Re: [PATCH] docs: reporting-issues.rst: explain how to decode stack traces
Hi! Many thx for looking into this, much appreciated! Am 14.02.21 um 17:00 schrieb Qais Yousef: > On 02/10/21 06:48, Thorsten Leemhuis wrote: > >> - * If the failure includes a stack dump, like an Oops does, consider >> decoding >> - it to find the offending line of code. >> + * If your failure involves a 'panic', 'oops', or 'warning', consider >> decoding > or 'BUG'? There are similar other places below that could benefit from this > addition too. Good point. In fact there are other places in the document where this is needed as well. Will address those in another patch. >> + the kernel log to find the line of code that trigger the error. >> >> * If your problem is a regression, try to narrow down when the issue was >> introduced as much as possible. >> @@ -869,6 +869,15 @@ pick up the configuration of your current kernel and >> then tries to adjust it >> somewhat for your system. That does not make the resulting kernel any >> better, >> but quicker to compile. >> >> +Note: If you are dealing with a kernel panic, oops, or warning, please make >> +sure to enable CONFIG_KALLSYMS when configuring your kernel. Additionally, > > s/make sure/try/ I did that, but ignored... > s/kernel./kernel if you can./ ...this. Yes, you have a point with... > Less demanding wording in case the user doesn't have the capability to rebuild > or deploy such a kernel where the problem happens. Maybe you can tweak it more > if you like too :-) ...that, but that section in the document is about building your own kernel, so I'd say we don't have to be that careful here. >> +enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_INFO, too; the latter is the >> +relevant one of those two, but can only be reached if you enable the >> former. Be >> +aware CONFIG_DEBUG_INFO increases the storage space required to build a >> kernel >> +by quite a bit. But that's worth it, as these options will allow you later >> to >> +pinpoint the exact line of code that triggers your issue. The section >> 'Decode >> +failure messages' below explains this in more detail. > > I think worth mentioning too that the user should keep a log of the problem > when first encountered and then attempt the above. Just in case the problem is > not reproducible easily so the info is not lost. > > Maybe something like below: > > ''' > Always keep a record of the issue encountered in case it is hard to reproduce. > Sending undecoded report is better than not sending a report at all. > ''' Very good point, added. >> +your kernel. If you did so, consider to decode the information from the >> +kernel's log. That will make it a lot easier to understand what lead to the >> +'panic', 'oops', or 'warning', which increases the chances enormously that >> +someone can provide a fix. > I suggest removing the word enormously. It helps, but it all depends on the > particular circumstances. Sometimes it does, others it doesn't. Done. > This looks good to me in general. With the above minor nits fixed, feel free > to > add my > Reviewed-by: Qais Yousef Great, thx, will do! Ciao, Thorsten
Re: [PATCH] arm64: mm: correct the start of physical address in linear map
Hello Pavel,
On 2/13/21 6:53 AM, Pavel Tatashin wrote:
> Memory hotplug may fail on systems with CONFIG_RANDOMIZE_BASE because the
> linear map range is not checked correctly.
>
> The start physical address that linear map covers can be actually at the
> end of the range because of randmomization. Check that and if so reduce it
> to 0.
Looking at the code, this seems possible if memstart_addr which is a signed
value becomes large (after falling below 0) during arm64_memblock_init().
>
> This can be verified on QEMU with setting kaslr-seed to ~0ul:
>
> memstart_offset_seed = 0x
> START: __pa(_PAGE_OFFSET(vabits_actual)) = 9000c000
> END: __pa(PAGE_END - 1) = 1000bfff
>
> Signed-off-by: Pavel Tatashin
> Fixes: 58284a901b42 ("arm64/mm: Validate hotplug range before creating linear
> mapping")
> ---
> arch/arm64/mm/mmu.c | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ae0c3d023824..6057ecaea897 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1444,14 +1444,25 @@ static void __remove_pgd_mapping(pgd_t *pgdir,
> unsigned long start, u64 size)
>
> static bool inside_linear_region(u64 start, u64 size)
> {
> + u64 start_linear_pa = __pa(_PAGE_OFFSET(vabits_actual));
> + u64 end_linear_pa = __pa(PAGE_END - 1);
> +
> + /*
> + * Check for a wrap, it is possible because of randomized linear mapping
> + * the start physical address is actually bigger than the end physical
> + * address. In this case set start to zero because [0, end_linear_pa]
> + * range must still be able to cover all addressable physical addresses.
> + */
If this is possible only with randomized linear mapping, could you please
add IS_ENABLED(CONFIG_RANDOMIZED_BASE) during the switch over. Wondering
if WARN_ON(start_linear_pa > end_linear_pa) should be added otherwise i.e
when linear mapping randomization is not enabled.
> + if (start_linear_pa > end_linear_pa)
> + start_linear_pa = 0;
This looks okay but will double check and give it some more testing.
> +
> /*
>* Linear mapping region is the range [PAGE_OFFSET..(PAGE_END - 1)]
>* accommodating both its ends but excluding PAGE_END. Max physical
>* range which can be mapped inside this linear mapping range, must
>* also be derived from its end points.
>*/
> - return start >= __pa(_PAGE_OFFSET(vabits_actual)) &&
> -(start + size - 1) <= __pa(PAGE_END - 1);
> + return start >= start_linear_pa && (start + size - 1) <= end_linear_pa;
> }
>
> int arch_add_memory(int nid, u64 start, u64 size,
>
- Anshuman
Re: [PATCH] docs: reporting-issues.rst: explain how to decode stack traces
Am 11.02.21 um 18:07 schrieb Randy Dunlap: > Just a couple of small nits (or one that is repeated): :-D > On 2/9/21 9:48 PM, Thorsten Leemhuis wrote: >> >> - * If the failure includes a stack dump, like an Oops does, consider >> decoding >> - it to find the offending line of code. >> + * If your failure involves a 'panic', 'oops', or 'warning', consider >> decoding >> + the kernel log to find the line of code that trigger the error. >triggered > […] > or it could be "code that triggers"... (just not "trigger"). Ahh, yes, you're right of course. Went with the former, many thx for taking a look and pointing it out! Ciao, Thorsten
Re: [PATCH v2] soc: mediatek: cmdq: add address shift in jump
On Thu, Jan 7, 2021 at 7:48 PM Yongqiang Niu wrote:
>
> On Wed, 2020-12-23 at 16:34 +0800, Yongqiang Niu wrote:
> > Add address shift when compose jump instruction
> > to compatible with 35bit format.
> >
> > Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform")
> >
> > Signed-off-by: Yongqiang Niu
> > Reviewed-by: Nicolas Boichat
> > ---
> > drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > index 5665b6e..75378e3 100644
> > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > @@ -168,7 +168,8 @@ static void cmdq_task_insert_into_thread(struct
> > cmdq_task *task)
> > dma_sync_single_for_cpu(dev, prev_task->pa_base,
> > prev_task->pkt->cmd_buf_size, DMA_TO_DEVICE);
> > prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
> > - (u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
> > + (u64)CMDQ_JUMP_BY_PA << 32 |
> > + (task->pa_base >> task->cmdq->shift_pa);
> > dma_sync_single_for_device(dev, prev_task->pa_base,
> > prev_task->pkt->cmd_buf_size,
> > DMA_TO_DEVICE);
> >
>
> hi jassi
>
> please confirm is there any question about this patch.
> if not, please apply this into next version, tks
>
I can't locate this patch in my inbox. And I can't fwd it from lkml to
myself. Please resend.
thnks.
[PATCH 4/4] arm: dts: visconti: Add DT support for Toshiba Visconti5 ethernet controller
Add the ethernet controller node in Toshiba Visconti5 SoC-specific DT file.
And enable this node in TMPV7708 RM main board's board-specific DT file.
Signed-off-by: Nobuhiro Iwamatsu
---
.../boot/dts/toshiba/tmpv7708-rm-mbrc.dts | 18 +
arch/arm64/boot/dts/toshiba/tmpv7708.dtsi | 25 +++
2 files changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
index ed0bf7f13f54..48fa8776e36f 100644
--- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
@@ -41,3 +41,21 @@ {
clocks = <_clk>;
clock-names = "apb_pclk";
};
+
+ {
+ status = "okay";
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ clocks = <>, <>;
+ clock-names = "stmmaceth", "phy_ref_clk";
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy0: ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ reg = <0x1>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
index 242f25f4e12a..3366786699fc 100644
--- a/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708.dtsi
@@ -134,6 +134,20 @@ uart_clk: uart-clk {
#clock-cells = <0>;
};
+ clk125mhz: clk125mhz {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ #clock-cells = <0>;
+ clock-output-names = "clk125mhz";
+ };
+
+ clk300mhz: clk300mhz {
+ compatible = "fixed-clock";
+ clock-frequency = <3>;
+ #clock-cells = <0>;
+ clock-output-names = "clk300mhz";
+ };
+
soc {
#address-cells = <2>;
#size-cells = <2>;
@@ -384,6 +398,17 @@ spi6: spi@28146000 {
#size-cells = <0>;
status = "disabled";
};
+
+ piether: ethernet@2800 {
+ compatible = "toshiba,visconti-dwmac",
"snps,dwmac-4.20a";
+ reg = <0 0x2800 0 0x1>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ snps,txpbl = <4>;
+ snps,rxpbl = <4>;
+ snps,tso;
+ status = "disabled";
+ };
};
};
--
2.30.0.rc2
[PATCH v3 0/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
Hi, This series is the ethernet driver for Toshiba's ARM SoC, Visconti[0]. This provides DT binding documentation, device driver, MAINTAINER files, and updates to DT files. Best regards, Nobuhiro [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recognition-processors-visconti.htmli Updates: dt-bindings: net: Add DT bindings for Toshiba Visconti TMPV7700 SoC v2 -> v3: Change to the correct dwmac version. Remove description of reg property. Update examples, drop dma-coherent, add snps,tso, fix phy-mode. v1 -> v2: No update. net: stmmac: Add Toshiba Visconti SoCs glue driver v2 -> v3: Remove code that is no longer needed by using compatible string. Drop def_bool y in Kconfig v1 -> v2: Use reverse christmas tree ordering for local variable declarations. MAINTAINERS: Add entries for Toshiba Visconti ethernet controller v2 -> v3: No update. v1 -> v2: No update. arm: dts: visconti: Add DT support for Toshiba Visconti5 ethernet controller v2 -> v3: Add "snps,dwmac-4.20a" as compatible string. Add snps,tso. v1 -> v2: No update. Nobuhiro Iwamatsu (4): dt-bindings: net: Add DT bindings for Toshiba Visconti TMPV7700 SoC net: stmmac: Add Toshiba Visconti SoCs glue driver MAINTAINERS: Add entries for Toshiba Visconti ethernet controller arm: dts: visconti: Add DT support for Toshiba Visconti5 ethernet controller .../bindings/net/toshiba,visconti-dwmac.yaml | 85 ++ MAINTAINERS | 2 + .../boot/dts/toshiba/tmpv7708-rm-mbrc.dts | 18 ++ arch/arm64/boot/dts/toshiba/tmpv7708.dtsi | 25 ++ drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 + drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + .../ethernet/stmicro/stmmac/dwmac-visconti.c | 285 ++ 7 files changed, 424 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c -- 2.30.0.rc2
[PATCH 1/4] dt-bindings: net: Add DT bindings for Toshiba Visconti TMPV7700 SoC
Add device tree bindings for ethernet controller of Toshiba Visconti
TMPV7700 SoC series.
Signed-off-by: Nobuhiro Iwamatsu
---
.../bindings/net/toshiba,visconti-dwmac.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
new file mode 100644
index ..59724d18e6f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml
@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/net/toshiba,visconti-dwmac.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Toshiba Visconti DWMAC Ethernet controller
+
+maintainers:
+ - Nobuhiro Iwamatsu
+
+select:
+ properties:
+compatible:
+ contains:
+enum:
+ - toshiba,visconti-dwmac
+ required:
+- compatible
+
+allOf:
+ - $ref: "snps,dwmac.yaml#"
+
+properties:
+ compatible:
+oneOf:
+ - items:
+ - enum:
+ - toshiba,visconti-dwmac
+ - const: snps,dwmac-4.20a
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: main clock
+ - description: PHY reference clock
+
+ clock-names:
+items:
+ - const: stmmaceth
+ - const: phy_ref_clk
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+soc {
+#address-cells = <2>;
+#size-cells = <2>;
+
+piether: ethernet@2800 {
+compatible = "toshiba,visconti-dwmac", "snps,dwmac-4.20a";
+reg = <0 0x2800 0 0x1>;
+interrupts = ;
+interrupt-names = "macirq";
+clocks = <>, <>;
+clock-names = "stmmaceth", "phy_ref_clk";
+snps,txpbl = <4>;
+snps,rxpbl = <4>;
+snps,tso;
+phy-mode = "rgmii-id";
+phy-handle = <>;
+
+mdio0 {
+#address-cells = <0x1>;
+#size-cells = <0x0>;
+compatible = "snps,dwmac-mdio";
+
+phy0: ethernet-phy@1 {
+device_type = "ethernet-phy";
+reg = <0x1>;
+};
+};
+};
+};
--
2.30.0.rc2
[PATCH 2/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
Add dwmac-visconti to the stmmac driver in Toshiba Visconti ARM SoCs.
This patch contains only the basic function of the device. There is no
clock control, PM, etc. yet. These will be added in the future.
Signed-off-by: Nobuhiro Iwamatsu
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../ethernet/stmicro/stmmac/dwmac-visconti.c | 285 ++
3 files changed, 294 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig
b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 53f14c5a9e02..55ba67a550b9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -219,6 +219,14 @@ config DWMAC_INTEL_PLAT
This selects the Intel platform specific glue layer support for
the stmmac device driver. This driver is used for the Intel Keem Bay
SoC.
+
+config DWMAC_VISCONTI
+ bool "Toshiba Visconti DWMAC support"
+ def_bool y
+ depends on OF && COMMON_CLK && (ARCH_VISCONTI || COMPILE_TEST)
+ help
+ Support for ethernet controller on Visconti SoCs.
+
endif
config DWMAC_INTEL
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 24e6145d4eae..366740ab9c5a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_DWMAC_DWC_QOS_ETH) += dwmac-dwc-qos-eth.o
obj-$(CONFIG_DWMAC_INTEL_PLAT) += dwmac-intel-plat.o
obj-$(CONFIG_DWMAC_GENERIC)+= dwmac-generic.o
obj-$(CONFIG_DWMAC_IMX8) += dwmac-imx.o
+obj-$(CONFIG_DWMAC_VISCONTI) += dwmac-visconti.o
stmmac-platform-objs:= stmmac_platform.o
dwmac-altr-socfpga-objs := altr_tse_pcs.o dwmac-socfpga.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
new file mode 100644
index ..b7a0c57dfbfb
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Toshiba Visconti Ethernet Support
+ *
+ * (C) Copyright 2020 TOSHIBA CORPORATION
+ * (C) Copyright 2020 Toshiba Electronic Devices & Storage Corporation
+ */
+
+#include
+#include
+#include
+#include
+
+#include "stmmac_platform.h"
+#include "dwmac4.h"
+
+#define REG_ETHER_CONTROL 0x52D4
+#define ETHER_ETH_CONTROL_RESET BIT(17)
+
+#define REG_ETHER_CLOCK_SEL0x52D0
+#define ETHER_CLK_SEL_TX_CLK_EN BIT(0)
+#define ETHER_CLK_SEL_RX_CLK_EN BIT(1)
+#define ETHER_CLK_SEL_RMII_CLK_EN BIT(2)
+#define ETHER_CLK_SEL_RMII_CLK_RST BIT(3)
+#define ETHER_CLK_SEL_DIV_SEL_2 BIT(4)
+#define ETHER_CLK_SEL_DIV_SEL_20 BIT(0)
+#define ETHER_CLK_SEL_FREQ_SEL_125M(BIT(9) | BIT(8))
+#define ETHER_CLK_SEL_FREQ_SEL_50M BIT(9)
+#define ETHER_CLK_SEL_FREQ_SEL_25M BIT(8)
+#define ETHER_CLK_SEL_FREQ_SEL_2P5MBIT(0)
+#define ETHER_CLK_SEL_TX_CLK_EXT_SEL_IN BIT(0)
+#define ETHER_CLK_SEL_TX_CLK_EXT_SEL_TXC BIT(10)
+#define ETHER_CLK_SEL_TX_CLK_EXT_SEL_DIV BIT(11)
+#define ETHER_CLK_SEL_RX_CLK_EXT_SEL_IN BIT(0)
+#define ETHER_CLK_SEL_RX_CLK_EXT_SEL_RXC BIT(12)
+#define ETHER_CLK_SEL_RX_CLK_EXT_SEL_DIV BIT(13)
+#define ETHER_CLK_SEL_TX_CLK_O_TX_I BIT(0)
+#define ETHER_CLK_SEL_TX_CLK_O_RMII_I BIT(14)
+#define ETHER_CLK_SEL_TX_O_E_N_IN BIT(15)
+#define ETHER_CLK_SEL_RMII_CLK_SEL_IN BIT(0)
+#define ETHER_CLK_SEL_RMII_CLK_SEL_RX_C BIT(16)
+
+#define ETHER_CLK_SEL_RX_TX_CLK_EN (ETHER_CLK_SEL_RX_CLK_EN |
ETHER_CLK_SEL_TX_CLK_EN)
+
+#define ETHER_CONFIG_INTF_MII 0
+#define ETHER_CONFIG_INTF_RGMII BIT(0)
+#define ETHER_CONFIG_INTF_RMII BIT(2)
+
+struct visconti_eth {
+ void __iomem *reg;
+ u32 phy_intf_sel;
+ struct clk *phy_ref_clk;
+ spinlock_t lock; /* lock to protect register update */
+};
+
+static void visconti_eth_fix_mac_speed(void *priv, unsigned int speed)
+{
+ struct visconti_eth *dwmac = priv;
+ unsigned int val, clk_sel_val;
+ unsigned long flags;
+
+ spin_lock_irqsave(>lock, flags);
+
+ /* adjust link */
+ val = readl(dwmac->reg + MAC_CTRL_REG);
+ val &= ~(GMAC_CONFIG_PS | GMAC_CONFIG_FES);
+
+ switch (speed) {
+ case SPEED_1000:
+ if (dwmac->phy_intf_sel == ETHER_CONFIG_INTF_RGMII)
+ clk_sel_val = ETHER_CLK_SEL_FREQ_SEL_125M;
+ break;
+ case SPEED_100:
+ if (dwmac->phy_intf_sel == ETHER_CONFIG_INTF_RGMII)
+ clk_sel_val = ETHER_CLK_SEL_FREQ_SEL_25M;
+ if (dwmac->phy_intf_sel == ETHER_CONFIG_INTF_RMII)
+ clk_sel_val = ETHER_CLK_SEL_DIV_SEL_2;
+ val |= GMAC_CONFIG_PS | GMAC_CONFIG_FES;
+ break;
+ case SPEED_10:
+ if (dwmac->phy_intf_sel == ETHER_CONFIG_INTF_RGMII)
+
[PATCH 3/4] MAINTAINERS: Add entries for Toshiba Visconti ethernet controller
Add entries for Toshiba Visconti ethernet controller binding and driver. Signed-off-by: Nobuhiro Iwamatsu --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index cbf4b94f89d4..6be4bdaabf32 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2641,8 +2641,10 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported T: git git://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti.git F: Documentation/devicetree/bindings/arm/toshiba.yaml +F: Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml F: Documentation/devicetree/bindings/pinctrl/toshiba,tmpv7700-pinctrl.yaml F: arch/arm64/boot/dts/toshiba/ +F: drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c F: drivers/pinctrl/visconti/ N: visconti -- 2.30.0.rc2
[GIT PULL] Remove oprofile and dcookies for v5.12
Hi Linus, The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837: Linux 5.11-rc3 (2021-01-10 14:34:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/linux.git tags/oprofile-removal-5.12 for you to fetch changes up to be65de6b03aa638c46ea51e9d11a92e4914d8103: fs: Remove dcookies support (2021-01-29 10:06:46 +0530) Remove oprofile and dcookies support The "oprofile" user-space tools don't use the kernel OPROFILE support any more, and haven't in a long time. User-space has been converted to the perf interfaces. The dcookies stuff is only used by the oprofile code. Now that oprofile's support is getting removed from the kernel, there is no need for dcookies as well. Remove kernel's old oprofile and dcookies support. Viresh Kumar (18): arch: alpha: Remove CONFIG_OPROFILE support arch: arm: Remove CONFIG_OPROFILE support arch: arc: Remove CONFIG_OPROFILE support arch: hexagon: Don't select HAVE_OPROFILE arch: ia64: Remove CONFIG_OPROFILE support arch: ia64: Remove rest of perfmon support arch: microblaze: Remove CONFIG_OPROFILE support arch: mips: Remove CONFIG_OPROFILE support arch: parisc: Remove CONFIG_OPROFILE support arch: powerpc: Stop building and using oprofile arch: powerpc: Remove oprofile arch: s390: Remove CONFIG_OPROFILE support arch: sh: Remove CONFIG_OPROFILE support arch: sparc: Remove CONFIG_OPROFILE support arch: x86: Remove CONFIG_OPROFILE support arch: xtensa: Remove CONFIG_OPROFILE support drivers: Remove CONFIG_OPROFILE support fs: Remove dcookies support Documentation/RCU/NMI-RCU.rst |3 +- Documentation/admin-guide/kernel-parameters.txt| 14 - Documentation/kbuild/makefiles.rst |1 - Documentation/process/magic-number.rst |1 - .../translations/it_IT/process/magic-number.rst|1 - .../translations/zh_CN/process/magic-number.rst|1 - MAINTAINERS| 11 - arch/Kconfig | 32 - arch/alpha/Kconfig |1 - arch/alpha/Makefile|1 - arch/alpha/oprofile/Makefile | 20 - arch/alpha/oprofile/common.c | 189 --- arch/alpha/oprofile/op_impl.h | 55 - arch/alpha/oprofile/op_model_ev4.c | 114 -- arch/alpha/oprofile/op_model_ev5.c | 209 --- arch/alpha/oprofile/op_model_ev6.c | 101 -- arch/alpha/oprofile/op_model_ev67.c| 261 --- arch/arc/Kconfig |1 - arch/arc/Makefile |2 - arch/arc/oprofile/Makefile | 10 - arch/arc/oprofile/common.c | 23 - arch/arm/Kconfig |1 - arch/arm/Makefile |2 - arch/arm/configs/bcm2835_defconfig |1 - arch/arm/configs/cns3420vb_defconfig |1 - arch/arm/configs/corgi_defconfig |1 - arch/arm/configs/imx_v4_v5_defconfig |1 - arch/arm/configs/keystone_defconfig|1 - arch/arm/configs/multi_v5_defconfig|1 - arch/arm/configs/mv78xx0_defconfig |1 - arch/arm/configs/mvebu_v5_defconfig|1 - arch/arm/configs/omap1_defconfig |1 - arch/arm/configs/omap2plus_defconfig |1 - arch/arm/configs/orion5x_defconfig |1 - arch/arm/configs/pxa_defconfig |1 - arch/arm/configs/qcom_defconfig|1 - arch/arm/configs/socfpga_defconfig |1 - arch/arm/configs/spitz_defconfig |1 - arch/arm/configs/vexpress_defconfig|1 - arch/arm/oprofile/Makefile | 14 - arch/arm/oprofile/common.c | 132 -- arch/hexagon/Kconfig |1 - arch/ia64/Kconfig |1 - arch/ia64/Makefile |1 - arch/ia64/configs/bigsur_defconfig |1 - arch/ia64/include/asm/hw_irq.h |1 - arch/ia64/include/asm/perfmon.h| 111 -- arch/ia64/include/uapi/asm/perfmon.h | 178 -- arch/ia64/include/uapi/asm/perfmon_default_smpl.h | 84 - arch/ia64/kernel/palinfo.c | 41 - arch/ia64/kernel/perfmon_default_smpl.c| 297 arch/ia64/kernel/perfmon_generic.h
Re: [PATCH v6 03/34] mailbox: vpu-ipc-mailbox: Add support for Intel VPU IPC mailbox
On Fri, Feb 12, 2021 at 4:23 PM wrote: > > From: Daniele Alessandrelli > > Add mailbox controller enabling inter-processor communication (IPC) > between the CPU (aka, the Application Processor - AP) and the VPU on > Intel Movidius SoCs like Keem Bay. > > The controller uses HW FIFOs to enable such communication. Specifically, > there are two FIFOs, one for the CPU and one for VPU. Each FIFO can hold > 128 entries (messages) of 32-bit each (but only 26 bits are actually > usable, since the 6 least-significant bits are reserved for the overflow > detection mechanism, more info below). > > When the Linux kernel on the AP needs to send messages to the VPU > firmware, it writes them to the VPU FIFO; similarly, when the VPU > firmware needs to send messages to the AP, it writes them to the CPU > FIFO. > > It's important to note that the AP is not the only one that can write to > the VPU FIFO: other components within the SoC can write to it too. Each > of these components (including the AP) has a unique 6-bit processor ID > associated to it. The VPU HW FIFO expects the last 6 bits of each 32-bit > FIFO entry to contain the processor ID of the sender. > > Therefore, sending a message from the AP to the VPU works as follows: > > 1. The message must be a 32-bit value with the last 6-bit set to 0 (in >practice, the message is meant to be a 32-bit address value, aligned >to 64 bytes; but this is not really relevant for this mailbox >controller). > > 2. The AP adds its processor ID to the 32-bit message being sent: >M = m | AP_ProcID > > 3. The sender writes the message (M) to the TIM_IPC_FIFO register of the >VPU FIFO. > > 4. The HW atomically checks if the FIFO is full and if not it writes it >to the actual FIFO; if the FIFO is full, the HW reads the ProcID >from M and then sets the corresponding bit of TIM_IPC_FIFO_OF_FLAG0, >to signal that the write failed, because the FIFO was full. > > 5. The AP reads the TIM_IPC_FIFO_OF_FLAG0 register and checks if the >bit corresponding to its ProcID has been set (in order to know if the >TX succeeded or failed); if the bit is set, the AP clears it. > > Note: as briefly mentioned above, the 32-bit value is meant to be a 32- > bit physical address (64-byte aligned). This address points to a > predefined struct (i.e., the IPC packet) in shared memory. However, > since this struct is not HW dependent (it's just the struct the VPU > firmware expects and in theory it could change if a different VPU FW is > used), it's not defined here, but in the Keem Bay IPC driver, which is > the mailbox client for this controller. > > The AP is notified of pending messages in the CPU FIFO by means of the > 'FIFO-not-empty' interrupt, which is generated by the CPU FIFO while not > empty. This interrupt is cleared automatically once all messages have > been read from the FIFO (i.e., the FIFO has been emptied). > > The hardware doesn't provide an TX done IRQ (i.e., an IRQ that allows > the VPU firmware to notify the AP that the message put into the VPU FIFO > has been received); however the AP can ensure that the message has been > successfully put into the VPU FIFO (and therefore transmitted) by > checking the VPU FIFO status register (TIM_IPC_FIFO_OF_FLAG0) to ensure > that writing the message didn't cause the FIFO to overflow (as described > above). > I don't remember the last time I saw such a detailed explanation! Thanks. > Therefore, the mailbox controller is configured as capable of tx_done > IRQs and a tasklet is used to simulate the tx_done IRQ. The tasklet is > activated by send_data() right after the message has been put into the > VPU FIFO and the VPU FIFO status registers has been checked. If an > overflow is reported by the status register, the tasklet passes -EBUSY > to mbox_chan_txdone(), to notify the mailbox client of the failed TX. > > The client should therefore register a tx_done() callback to properly > handle failed transmissions. > > Note: the 'txdone_poll' mechanism cannot be used because it doesn't > provide a way to report a failed transmission. > IIUIC, maybe the solution is simpler What if we set txdone_poll. Always return success in send_data(). And check if we overflew the fifo in last_tx_done(). If we did overflow, try to rewrite the data and check again. Return true, if not overflew this time, otherwise return false so that mailbox api can ask us to try again in next last_tx_done(). This way we can do away with the tasklet and, more importantly, avoid send_data() failures and retries on clients' part. Cheers!
Re: [PATCH v2 2/4] net: stmmac: Add Toshiba Visconti SoCs glue driver
Hi, On Sun, Feb 14, 2021 at 08:23:25AM +0200, Leon Romanovsky wrote: > On Fri, Feb 12, 2021 at 11:58:04AM +0900, Nobuhiro Iwamatsu wrote: > > Add dwmac-visconti to the stmmac driver in Toshiba Visconti ARM SoCs. > > This patch contains only the basic function of the device. There is no > > clock control, PM, etc. yet. These will be added in the future. > > > > Signed-off-by: Nobuhiro Iwamatsu > > --- > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 8 + > > drivers/net/ethernet/stmicro/stmmac/Makefile | 1 + > > .../ethernet/stmicro/stmmac/dwmac-visconti.c | 288 ++ > > 3 files changed, 297 insertions(+) > > create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-visconti.c > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig > > b/drivers/net/ethernet/stmicro/stmmac/Kconfig > > index 53f14c5a9e02..55ba67a550b9 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig > > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig > > @@ -219,6 +219,14 @@ config DWMAC_INTEL_PLAT > > This selects the Intel platform specific glue layer support for > > the stmmac device driver. This driver is used for the Intel Keem Bay > > SoC. > > + > > +config DWMAC_VISCONTI > > + bool "Toshiba Visconti DWMAC support" > > + def_bool y > > Doesn't it need to be "default y"? > Indeed. I will remove this. Thanks. Best regards, Nobuhiro
[GIT PULL] hwmon updates for v5.12
Hi Linus, Please pull hwmon updates for Linux v5.12 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-v5.12 Thanks, Guenter -- The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31: Linux 5.11-rc4 (2021-01-17 16:37:05 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git tags/hwmon-for-v5.12 for you to fetch changes up to 6ab3332cc692ad04dfa30c92d3391aea8b971ef2: MAINTAINERS: Add entry for Texas Instruments TPS23861 PoE PSE (2021-02-12 07:02:55 -0800) hwmon updates for v5.12 - New drivers Texas Instruments TPS23861 driver AHT10 Temperature and Humidity Sensor Driver - Support for new chips/variants to existing drivers Add AMD family 19h model 30h x86 match to amd_energy driver Add Zen3 Ryzen Desktop CPUs support to k10temp driver Add support for MAX16508 to max16601 driver Support revision "B" of max31785 Add support for ASRock boards to nct6683 driver - Driver removals (abx500) Decomission abx500 driver Various other minor fixes and improvements. Blaž Hrastnik (1): hwmon: (nct6683) Support ASRock boards Dan Carpenter (1): hwmon: (aht10) Unlock on error in aht10_read_values() Eddie James (2): hwmon: (pmbus) Add a PMBUS_NO_CAPABILITY platform data flag hwmon: (pmbus/ibm-cffps) Set the PMBUS_NO_CAPABILITY flag Erik Rosen (2): hwmon: (pmbus) Clear sensor data after chip write hwmon: (pmbus/lm25066) Remove unnecessary pmbus_clear_cache function call Gabriel Craciunescu (1): hwmon: (k10temp) Zen3 Ryzen Desktop CPUs support Guenter Roeck (3): hwmon: (abx500) Decomission abx500 driver hwmon: (pmbus/max16601) Determine and use number of populated phases hwmon: (pmbus/max16601) Add support for MAX16508 Jiapeng Zhong (2): hwmon: (applesmc) Assign boolean values to a bool variable hwmon: (pmbus) Simplify the calculation of variables Johannes Cornelis Draaijer (datdenkikniet) (1): hwmon: Add AHT10 Temperature and Humidity Sensor Driver Matthew Barth (1): hwmon: (pmbus/max31785) Support revision "B" Mauro Carvalho Chehab (1): hwmon: (ina2) update ti,ina2xx.yaml reference in documentation Naveen Krishna Chatradhi (1): hwmon: (amd_energy) Add AMD family 19h model 30h x86 match Paul Barker (2): hwmon: (pwm-fan) Store tach data separately hwmon: (pwm-fan) Support multiple fan tachometers Robert Marko (3): dt-bindings: hwmon: Add TI TPS23861 bindings hwmon: add Texas Instruments TPS23861 driver MAINTAINERS: Add entry for Texas Instruments TPS23861 PoE PSE Thomas Hebb (1): hwmon: (dell-smm) Add XPS 15 L502X to fan control blacklist Tian Tao (5): hwmon: (w83627ehf) Switch to using the new API kobj_to_dev() hwmon: (gpio-fan) Switch to using the new API kobj_to_dev() hwmon: (max6650) Switch to using the new API kobj_to_dev() hwmon: (aspeed-pwm-tacho) Switch to using the new API kobj_to_dev() hwmon: (da9052) Switch to using the new API kobj_to_dev() Tom Rix (1): hwmon: (smsc47m1) Remove 'h' from printk format specifier Uwe Kleine-König (1): hwmon: (pwm-fan) stop using legacy PWM functions and some cleanups Zheng Yongjun (1): hwmon: (pc87360) convert comma to semicolon .../devicetree/bindings/hwmon/ti,tps23861.yaml | 51 ++ Documentation/hwmon/ab8500.rst | 26 - Documentation/hwmon/abx500.rst | 32 -- Documentation/hwmon/aht10.rst | 46 ++ Documentation/hwmon/ina2xx.rst | 2 +- Documentation/hwmon/index.rst | 4 +- Documentation/hwmon/max16601.rst | 197 +++ Documentation/hwmon/nct6683.rst| 1 + Documentation/hwmon/tps23861.rst | 41 ++ MAINTAINERS| 9 + drivers/hwmon/Kconfig | 34 +- drivers/hwmon/Makefile | 3 +- drivers/hwmon/ab8500.c | 224 drivers/hwmon/abx500.c | 487 - drivers/hwmon/abx500.h | 69 --- drivers/hwmon/aht10.c | 348 drivers/hwmon/amd_energy.c | 1 + drivers/hwmon/applesmc.c | 2 +- drivers/hwmon/aspeed-pwm-tacho.c | 4 +- drivers/hwmon/da9052-hwmon.c | 2 +- drivers/hwmon/dell-smm-hwmon.c | 7 + drivers/hwmon/gpio-fan.c | 2 +- drivers/hwmon/k10temp.c| 3 +- drivers/hwmon/max6650.c|
Re: Droid 4 charging
Hi, * Pavel Machek [210206 13:14]: > Hi! > > (I'm using Leste 5.10 kernel here). > > When battery is full, green light is off and 0.00A being drawn from > USB. > > But that means that phone is now powered from battery, discharging > it... And soon charging starts again. (Pretty much immediately, for me) > > That's bad ... right? It wears the battery out. Well maintenance charging at 4.2V sure is better for the battery than what android is doing charging it at 4.31V contantly.. > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A > is drawn from USB, and battery is not discharged: > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > input_current_limit > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now > 0 Hmm so have you measured that setting the current limit to 0 actually draws something from the USB? I recall clearing the ichrgr bits stops the vbus draw completely, but I could be wrong. > Is that a better way to handle full battery? We could experiment with switching over to usb power when the battery is full. Looking at the docs for mc1378 it might be possible that setting CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the battery is full disables charging but still keep drawing power from the usb. I'd assume the current limit still needs to be nonzero there too? Totally untested.. And switching back to battery power on usb disconnect will potentially only give us very little time based on the different line length for vbus and ground pins compared to data pins on the usb connector.. And uvos had some concerns about the battery capacity putting it back online, so adding him to Cc also. Maybe just clearing ichrgr does all this already though and is enough. It should be measured on the vbus line. And then we still need to restart the charger at some point, but that could happen based on much longer timeouts that what we currently have. Regards, Tony
Re: [PATCH net-next v2 3/3] net: phy: broadcom: Allow BCM54210E to configure APD
On 2/13/2021 2:42 AM, Vladimir Oltean wrote:
> On Fri, Feb 12, 2021 at 07:46:32PM -0800, Florian Fainelli wrote:
>> BCM54210E/BCM50212E has been verified to work correctly with the
>> auto-power down configuration done by bcm54xx_adjust_rxrefclk(), add it
>> to the list of PHYs working.
>>
>> While we are at it, provide an appropriate name for the bit we are
>> changing which disables the RXC and TXC during auto-power down when
>> there is no energy on the cable.
>>
>> Signed-off-by: Florian Fainelli
>> ---
>
> Reviewed-by: Vladimir Oltean
>
>> drivers/net/phy/broadcom.c | 8 +---
>> include/linux/brcmphy.h| 2 +-
>> 2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
>> index 3ce266ab521b..91fbd26c809e 100644
>> --- a/drivers/net/phy/broadcom.c
>> +++ b/drivers/net/phy/broadcom.c
>> @@ -193,6 +193,7 @@ static void bcm54xx_adjust_rxrefclk(struct phy_device
>> *phydev)
>> if (BRCM_PHY_MODEL(phydev) != PHY_ID_BCM57780 &&
>> BRCM_PHY_MODEL(phydev) != PHY_ID_BCM50610 &&
>> BRCM_PHY_MODEL(phydev) != PHY_ID_BCM50610M &&
>> +BRCM_PHY_MODEL(phydev) != PHY_ID_BCM54210E &&
>> BRCM_PHY_MODEL(phydev) != PHY_ID_BCM54810 &&
>> BRCM_PHY_MODEL(phydev) != PHY_ID_BCM54811)
>> return;
>> @@ -227,9 +228,10 @@ static void bcm54xx_adjust_rxrefclk(struct phy_device
>> *phydev)
>> val |= BCM54XX_SHD_SCR3_DLLAPD_DIS;
>>
>> if (phydev->dev_flags & PHY_BRCM_DIS_TXCRXC_NOENRGY) {
>> -if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 ||
>> -BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54811)
>> -val |= BCM54810_SHD_SCR3_TRDDAPD;
>> +if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E ||
>> +BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 ||
>> +BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54210E)
>> +val |= BCM54XX_SHD_SCR3_RXCTXC_DIS;
>> else
>> val |= BCM54XX_SHD_SCR3_TRDDAPD;
>> }
>> diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
>> index 844dcfe789a2..16597d3fa011 100644
>> --- a/include/linux/brcmphy.h
>> +++ b/include/linux/brcmphy.h
>> @@ -193,6 +193,7 @@
>> #define BCM54XX_SHD_SCR3_DEF_CLK1250x0001
>> #define BCM54XX_SHD_SCR3_DLLAPD_DIS0x0002
>> #define BCM54XX_SHD_SCR3_TRDDAPD 0x0004
>> +#define BCM54XX_SHD_SCR3_RXCTXC_DIS0x0100
>
> Curiously enough, my BCM5464R datasheet does say:
>
> The TXC and RXC outputs can be disabled during auto-power down by setting the
> “1000BASE-T/100BASE-TX/10BASE-T
> Spare Control 3 Register (Address 1Ch, Shadow Value 00101),” bit 8 =1.
>
> but when I go to the definition of the register, bit 8 is hidden. Odd.
>
> How can I ensure that the auto power down feature is doing something?
I am trying to confirm what the expected power levels should be from the
54210E product engineer so I can give you an estimate of what you should
see with and without while measure the PHY's regulators.
--
Florian
[PATCH 2/2] exfat: add support FITRIM ioctl
add FITRIM ioctl to support trimming mounted filesystem
Signed-off-by: Hyeongseok Kim
---
fs/exfat/balloc.c | 89 +
fs/exfat/exfat_fs.h | 1 +
fs/exfat/file.c | 33 +
3 files changed, 123 insertions(+)
diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c
index 761c79c3a4ba..edd0f6912e8e 100644
--- a/fs/exfat/balloc.c
+++ b/fs/exfat/balloc.c
@@ -273,3 +273,92 @@ int exfat_count_used_clusters(struct super_block *sb,
unsigned int *ret_count)
*ret_count = count;
return 0;
}
+
+int exfat_trim_fs(struct inode *inode, struct fstrim_range *range)
+{
+ struct super_block *sb = inode->i_sb;
+ struct exfat_sb_info *sbi = EXFAT_SB(sb);
+ u64 clu_start, clu_end, trim_minlen, trimmed_total = 0;
+ unsigned int trim_begin, trim_end, count;
+ unsigned int next_free_clu;
+ int err = 0;
+
+ clu_start = max_t(u64, range->start >> sbi->cluster_size_bits,
+ EXFAT_FIRST_CLUSTER);
+ clu_end = clu_start + (range->len >> sbi->cluster_size_bits) - 1;
+ trim_minlen = range->minlen >> sbi->cluster_size_bits;
+
+ if (clu_start >= sbi->num_clusters || range->len < sbi->cluster_size)
+ return -EINVAL;
+
+ if (clu_end >= sbi->num_clusters)
+ clu_end = sbi->num_clusters - 1;
+
+ mutex_lock(_SB(inode->i_sb)->s_lock);
+
+ trim_begin = trim_end = exfat_find_free_bitmap(sb, clu_start);
+ if (trim_begin == EXFAT_EOF_CLUSTER)
+ goto unlock;
+
+ next_free_clu = exfat_find_free_bitmap(sb, trim_end + 1);
+ if (next_free_clu == EXFAT_EOF_CLUSTER)
+ goto unlock;
+
+ do {
+ if (next_free_clu == trim_end + 1)
+ /* extend trim range for continuous free cluster */
+ trim_end++;
+ else {
+ /* trim current range if it's larger than trim_minlen */
+ count = trim_end - trim_begin + 1;
+ if (count >= trim_minlen) {
+ err = sb_issue_discard(sb,
+ exfat_cluster_to_sector(sbi,
trim_begin),
+ count * sbi->sect_per_clus, GFP_NOFS,
0);
+ if (err && err != -EOPNOTSUPP)
+ goto unlock;
+ if (!err)
+ trimmed_total += count;
+ }
+
+ /* set next start point of the free hole */
+ trim_begin = trim_end = next_free_clu;
+ }
+
+ if (next_free_clu >= clu_end)
+ break;
+
+ if (fatal_signal_pending(current)) {
+ err = -ERESTARTSYS;
+ goto unlock;
+ }
+
+ if (need_resched()) {
+ mutex_unlock(_SB(inode->i_sb)->s_lock);
+ cond_resched();
+ mutex_lock(_SB(inode->i_sb)->s_lock);
+ }
+
+ next_free_clu = exfat_find_free_bitmap(sb, next_free_clu + 1);
+
+ } while (next_free_clu != EXFAT_EOF_CLUSTER &&
+ next_free_clu > trim_end);
+
+ /* try to trim remainder */
+ count = trim_end - trim_begin + 1;
+ if (count >= trim_minlen) {
+ err = sb_issue_discard(sb, exfat_cluster_to_sector(sbi,
trim_begin),
+ count * sbi->sect_per_clus, GFP_NOFS, 0);
+ if (err && err != -EOPNOTSUPP)
+ goto unlock;
+
+ if (!err)
+ trimmed_total += count;
+ }
+
+unlock:
+ mutex_unlock(_SB(inode->i_sb)->s_lock);
+ range->len = trimmed_total << sbi->cluster_size_bits;
+
+ return err;
+}
diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index a183021ae31d..e050aea0b639 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -411,6 +411,7 @@ int exfat_set_bitmap(struct inode *inode, unsigned int clu);
void exfat_clear_bitmap(struct inode *inode, unsigned int clu, bool sync);
unsigned int exfat_find_free_bitmap(struct super_block *sb, unsigned int clu);
int exfat_count_used_clusters(struct super_block *sb, unsigned int *ret_count);
+int exfat_trim_fs(struct inode *inode, struct fstrim_range *range);
/* file.c */
extern const struct file_operations exfat_file_operations;
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 679828e7be07..61a64a4d4e6a 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -351,7 +351,40 @@ int exfat_setattr(struct dentry *dentry, struct iattr
*attr)
long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
+ struct inode *inode = file_inode(filp);
+ struct super_block *sb = inode->i_sb;
+
switch (cmd) {
+ case
[PATCH 1/2] exfat: add initial ioctl function
Initialize empty ioctl function
Signed-off-by: Hyeongseok Kim
---
fs/exfat/dir.c | 5 +
fs/exfat/exfat_fs.h | 3 +++
fs/exfat/file.c | 21 +
3 files changed, 29 insertions(+)
diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
index 916797077aad..e1d5536de948 100644
--- a/fs/exfat/dir.c
+++ b/fs/exfat/dir.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
@@ -306,6 +307,10 @@ const struct file_operations exfat_dir_operations = {
.llseek = generic_file_llseek,
.read = generic_read_dir,
.iterate= exfat_iterate,
+ .unlocked_ioctl = exfat_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = exfat_compat_ioctl,
+#endif
.fsync = exfat_file_fsync,
};
diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
index 764bc645241e..a183021ae31d 100644
--- a/fs/exfat/exfat_fs.h
+++ b/fs/exfat/exfat_fs.h
@@ -420,6 +420,9 @@ int exfat_setattr(struct dentry *dentry, struct iattr
*attr);
int exfat_getattr(const struct path *path, struct kstat *stat,
unsigned int request_mask, unsigned int query_flags);
int exfat_file_fsync(struct file *file, loff_t start, loff_t end, int
datasync);
+long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
+long exfat_compat_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg);
/* namei.c */
extern const struct dentry_operations exfat_dentry_ops;
diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index a92478eabfa4..679828e7be07 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -348,6 +349,22 @@ int exfat_setattr(struct dentry *dentry, struct iattr
*attr)
return error;
}
+long exfat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+ switch (cmd) {
+ default:
+ return -ENOTTY;
+ }
+}
+
+#ifdef CONFIG_COMPAT
+long exfat_compat_ioctl(struct file *filp, unsigned int cmd,
+ unsigned long arg)
+{
+ return exfat_ioctl(filp, cmd, (unsigned long)compat_ptr(arg));
+}
+#endif
+
int exfat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
{
struct inode *inode = filp->f_mapping->host;
@@ -368,6 +385,10 @@ const struct file_operations exfat_file_operations = {
.llseek = generic_file_llseek,
.read_iter = generic_file_read_iter,
.write_iter = generic_file_write_iter,
+ .unlocked_ioctl = exfat_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = exfat_compat_ioctl,
+#endif
.mmap = generic_file_mmap,
.fsync = exfat_file_fsync,
.splice_read= generic_file_splice_read,
--
2.27.0.83.g0313f36
Re: [PATCH v2] block: recalculate segment count for multi-segment discards correctly
On Thu, Feb 11, 2021 at 10:48 PM David Jeffery wrote:
>
> When a stacked block device inserts a request into another block device
> using blk_insert_cloned_request, the request's nr_phys_segments field gets
> recalculated by a call to blk_recalc_rq_segments in
> blk_cloned_rq_check_limits. But blk_recalc_rq_segments does not know how to
> handle multi-segment discards. For disk types which can handle
> multi-segment discards like nvme, this results in discard requests which
> claim a single segment when it should report several, triggering a warning
> in nvme and causing nvme to fail the discard from the invalid state.
>
> WARNING: CPU: 5 PID: 191 at drivers/nvme/host/core.c:700
> nvme_setup_discard+0x170/0x1e0 [nvme_core]
> ...
> nvme_setup_cmd+0x217/0x270 [nvme_core]
> nvme_loop_queue_rq+0x51/0x1b0 [nvme_loop]
> __blk_mq_try_issue_directly+0xe7/0x1b0
> blk_mq_request_issue_directly+0x41/0x70
> ? blk_account_io_start+0x40/0x50
> dm_mq_queue_rq+0x200/0x3e0
> blk_mq_dispatch_rq_list+0x10a/0x7d0
> ? __sbitmap_queue_get+0x25/0x90
> ? elv_rb_del+0x1f/0x30
> ? deadline_remove_request+0x55/0xb0
> ? dd_dispatch_request+0x181/0x210
> __blk_mq_do_dispatch_sched+0x144/0x290
> ? bio_attempt_discard_merge+0x134/0x1f0
> __blk_mq_sched_dispatch_requests+0x129/0x180
> blk_mq_sched_dispatch_requests+0x30/0x60
> __blk_mq_run_hw_queue+0x47/0xe0
> __blk_mq_delay_run_hw_queue+0x15b/0x170
> blk_mq_sched_insert_requests+0x68/0xe0
> blk_mq_flush_plug_list+0xf0/0x170
> blk_finish_plug+0x36/0x50
> xlog_cil_committed+0x19f/0x290 [xfs]
> xlog_cil_process_committed+0x57/0x80 [xfs]
> xlog_state_do_callback+0x1e0/0x2a0 [xfs]
> xlog_ioend_work+0x2f/0x80 [xfs]
> process_one_work+0x1b6/0x350
> worker_thread+0x53/0x3e0
> ? process_one_work+0x350/0x350
> kthread+0x11b/0x140
> ? __kthread_bind_mask+0x60/0x60
> ret_from_fork+0x22/0x30
>
> This patch fixes blk_recalc_rq_segments to be aware of devices which can
> have multi-segment discards. It calculates the correct discard segment
> count by counting the number of bio as each discard bio is considered its
> own segment.
>
> Fixes: 1e739730c5b9 ("block: optionally merge discontiguous discard bios into
> a single request")
> Signed-off-by: David Jeffery
> Reviewed-by: Ming Lei
> Reviewed-by: Laurence Oberman
>
> ---
> V2 explicitly returns 1 instead of falling through in the no-multi case and
> handles REQ_OP_SECURE_ERASE like REQ_OP_DISCARD.
>
> block/blk-merge.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 808768f6b174..756473295f19 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -383,6 +383,14 @@ unsigned int blk_recalc_rq_segments(struct request *rq)
> switch (bio_op(rq->bio)) {
> case REQ_OP_DISCARD:
> case REQ_OP_SECURE_ERASE:
> + if (queue_max_discard_segments(rq->q) > 1) {
> + struct bio *bio = rq->bio;
> +
> + for_each_bio(bio)
> + nr_phys_segs++;
> + return nr_phys_segs;
> + }
> + return 1;
> case REQ_OP_WRITE_ZEROES:
> return 0;
> case REQ_OP_WRITE_SAME:
>
Hello Jens,
Any chance to merge this patch which fixes one regression caused
by commit 1e739730c5b9?
--
Ming Lei
Re: [PATCH 0/2] block: avoid to drop & re-add partitions if partitions aren't changed
On Fri, Feb 05, 2021 at 10:17:06AM +0800, Ming Lei wrote: > Hi Guys, > > The two patches changes block ioctl(BLKRRPART) for avoiding drop & > re-add partitions if partitions state isn't changed. The current > behavior confuses userspace because partitions can disappear anytime > when ioctl(BLKRRPART). > > Ming Lei (2): > block: move partitions check code into single helper > block: avoid to drop & re-add partitions if partitions aren't changed > > block/genhd.c| 2 + > block/partitions/check.h | 2 + > block/partitions/core.c | 101 --- > fs/block_dev.c | 28 +-- > include/linux/genhd.h| 4 ++ > 5 files changed, 118 insertions(+), 19 deletions(-) > > Cc: Ewan D. Milne > -- > 2.29.2 > Hello, Ping... -- Ming
linux-next: manual merge of the ftrace tree with Linus' tree
Hi all,
Today's linux-next merge of the ftrace tree got a conflict in:
kernel/trace/trace.c
between commit:
b220c049d519 ("tracing: Check length before giving out the filter buffer")
from Linus' tree and commit:
36590c50b2d0 ("tracing: Merge irqflags + preempt counter.")
from the ftrace tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc kernel/trace/trace.c
index b5815a022ecc,b79bcacdd6f9..
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@@ -2745,8 -2739,8 +2739,8 @@@ trace_event_buffer_lock_reserve(struct
(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 ((len < (PAGE_SIZE - sizeof(*entry))) && val == 1) {
- trace_event_setup(entry, type, flags, pc);
+ trace_event_setup(entry, type, trace_ctx);
entry->array[0] = len;
return entry;
}
pgpVyZZrf3k7a.pgp
Description: OpenPGP digital signature
[PATCH] regulator: mt6315: Return REGULATOR_MODE_INVALID for invalid mode
-EINVAL is not a valid return value for .of_map_mode, return REGULATOR_MODE_INVALID instead. Signed-off-by: Axel Lin --- drivers/regulator/mt6315-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/mt6315-regulator.c b/drivers/regulator/mt6315-regulator.c index d49a1534d8e9..fc7654624dd6 100644 --- a/drivers/regulator/mt6315-regulator.c +++ b/drivers/regulator/mt6315-regulator.c @@ -69,7 +69,7 @@ static unsigned int mt6315_map_mode(u32 mode) case MT6315_BUCK_MODE_LP: return REGULATOR_MODE_IDLE; default: - return -EINVAL; + return REGULATOR_MODE_INVALID; } } -- 2.25.1
KONTAKTIEREN SIE DEN BANKDIREKTOR.
CONTATE URGENTEMENTE O DIRETOR DO BANCO ORA..docx Description: MS-Word 2007 document
Re: [PATCH v2 2/2] of: property: Add fw_devlink support for interrupts
On 2/14/21 1:12 PM, Saravana Kannan wrote: [ ... ] > Can you please give me the following details: > * The DTS file for the board (not the SoC). I don't have it, sorry. The devicetree file is generated by qemu. Is there a way to extract it from a running system ? > * A boot log with the logs enabled in device_links_check_suppliers() > and device_link_add() > There is not much to be seen, except this: [ 14.084606][ T11] pci 0005:01:00.0: probe deferral - wait for supplier interrupt-controller@0 repeated three times. Guenter
Re: [PATCH] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
Hi Don,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on a2ea4e1d9091cd8bc69f1c42c15bedc38618f04c]
url:
https://github.com/0day-ci/linux/commits/Don-Bollinger/eeprom-optoe-driver-to-read-write-SFP-QSFP-CMIS-EEPROMS/20210215-083817
base: a2ea4e1d9091cd8bc69f1c42c15bedc38618f04c
config: sparc64-randconfig-p002-20210215 (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/9089aa757bfb70c473ca54face762582908bdd28
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Don-Bollinger/eeprom-optoe-driver-to-read-write-SFP-QSFP-CMIS-EEPROMS/20210215-083817
git checkout 9089aa757bfb70c473ca54face762582908bdd28
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=sparc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/misc/eeprom/optoe.c:615:16: warning: no previous prototype for
>> 'optoe_make_regmap' [-Wmissing-prototypes]
615 | struct regmap *optoe_make_regmap(struct i2c_client *client)
|^
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for COMPAT_BINFMT_ELF
Depends on COMPAT && BINFMT_ELF
Selected by
- COMPAT && SPARC64
vim +/optoe_make_regmap +615 drivers/misc/eeprom/optoe.c
605
606
607 /*
608 * optoe_make_regmap creates the regmap for the client.
609 * IMPORTANT: Don't call the regmap read/write calls directly
610 * for these devices. These devices are paged, and you have to
611 * set the page register before accessing the data in that page.
612 * Use the nvmem interfaces, those read/write calls use this
613 * driver to manage pages correctly.
614 */
> 615 struct regmap *optoe_make_regmap(struct i2c_client *client)
616 {
617 struct regmap_config regmap_config = { };
618 struct regmap *regmap;
619
620 /* setup a minimal regmap - 8 bits, 8 bit addresses */
621 regmap_config.val_bits = 8;
622 regmap_config.reg_bits = 8;
623
624 /* I'll handle the locking */
625 regmap_config.disable_locking = true;
626 regmap = devm_regmap_init_i2c(client, _config);
627 return regmap;
628 }
629
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
usb: dwc3: gadget: Change runtime pm function for DWC3 runtime suspend
It seems pm_runtime_put calls runtime_idle callback not runtime_suspend
callback.
It's better to use pm_runtime_put_sync_suspend to allow DWC3 runtime suspend.
Signed-off-by: Daehwan Jung
---
drivers/usb/dwc3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index aebcf8e..4a4b93b 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2229,7 +2229,7 @@ static int dwc3_gadget_pullup(struct usb_gadget *g, int
is_on)
*/
ret = pm_runtime_get_sync(dwc->dev);
if (!ret || ret < 0) {
- pm_runtime_put(dwc->dev);
+ pm_runtime_put_sync_suspend(dwc->dev);
return 0;
}
--
2.7.4
[GIT PULL] Crypto Update for 5.12
Hi Linus: API: - Restrict crypto_cipher to internal API users only. Algorithms: - Add x86 aesni acceleration for cts. - Improve x86 aesni acceleration for xts. - Remove x86 acceleration of some uncommon algorithms. - Remove RIPE-MD, Tiger and Salsa20. - Remove tnepres. - Add ARM acceleration for BLAKE2s and BLAKE2b. Drivers: - Add Keem Bay OCS HCU driver. - Add Marvell OcteonTX2 CPT PF driver. - Remove PicoXcell driver. - Remove mediatek driver. The following changes since commit 0aa171e9b267ce7c52d3a3df7bc9c1fc0203dec5: crypto: ecdh - avoid buffer overflow in ecdh_set_secret() (2021-01-03 08:35:35 +1100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus for you to fetch changes up to 0de9dc80625b0ca1cb9730c5ed1c5a8cab538369: hwrng: timeriomem - Use device-managed registration API (2021-02-10 17:56:01 +1100) Adam Guerin (3): crypto: qat - fix potential spectre issue crypto: qat - change format string and cast ring size crypto: qat - reduce size of mapped region Ard Biesheuvel (60): crypto: aesni - implement support for cts(cbc(aes)) crypto: tcrypt - avoid signed overflow in byte count chcr_ktls: use AES library for single use cipher crypto: remove cipher routines from public crypto API crypto: arm64/aes-ce - really hide slower algos when faster ones are enabled crypto: arm64/aes-ctr - improve tail handling crypto: x86/aes-ni-xts - use direct calls to and 4-way stride crypto: x86/aes-ni-xts - rewrite and drop indirections via glue helper crypto: aesni - prevent misaligned buffers on the stack crypto: aesni - drop unused asm prototypes crypto: aesni - clean up mapping of associated data crypto: aesni - refactor scatterlist processing crypto: aesni - replace function pointers with static branches crypto: x86/camellia - switch to XTS template crypto: x86/cast6 - switch to XTS template crypto: x86/serpent- switch to XTS template crypto: x86/twofish - switch to XTS template crypto: x86/glue-helper - drop XTS helper routines crypto: x86/camellia - drop CTR mode implementation crypto: x86/serpent - drop CTR mode implementation crypto: x86/cast5 - drop CTR mode implementation crypto: x86/cast6 - drop CTR mode implementation crypto: x86/twofish - drop CTR mode implementation crypto: x86/glue-helper - drop CTR helper routines crypto: x86/des - drop CTR mode implementation crypto: x86/blowfish - drop CTR mode implementation crypto: x86 - add some helper macros for ECB and CBC modes crypto: x86/camellia - drop dependency on glue helper crypto: x86/serpent - drop dependency on glue helper crypto: x86/cast5 - drop dependency on glue helper crypto: x86/cast6 - drop dependency on glue helper crypto: x86/twofish - drop dependency on glue helper crypto: x86 - remove glue helper module crypto: x86 - use local headers for x86 specific shared declarations crypto - shash: reduce minimum alignment of shash_desc structure crypto: arm64/sha - add missing module aliases crypto: aesni - replace CTR function pointer with static call crypto: aesni - release FPU during skcipher walk API calls crypto: rmd128 - remove RIPE-MD 128 hash algorithm crypto: rmd256 - remove RIPE-MD 256 hash algorithm crypto: rmd320 - remove RIPE-MD 320 hash algorithm crypto: tgr192 - remove Tiger 128/160/192 hash algorithms crypto: salsa20 - remove Salsa20 stream cipher algorithm arm64: assembler: add cond_yield macro crypto: michael_mic - fix broken misalignment handling crypto: serpent - get rid of obsolete tnepres variant crypto: serpent - use unaligned accessors instead of alignmask crypto: blowfish - use unaligned accessors instead of alignmask crypto: camellia - use unaligned accessors instead of alignmask crypto: cast5 - use unaligned accessors instead of alignmask crypto: cast6 - use unaligned accessors instead of alignmask crypto: fcrypt - drop unneeded alignmask crypto: twofish - use unaligned accessors instead of alignmask crypto: arm64/sha1-ce - simplify NEON yield crypto: arm64/sha2-ce - simplify NEON yield crypto: arm64/sha3-ce - simplify NEON yield crypto: arm64/sha512-ce - simplify NEON yield crypto: arm64/aes-neonbs - remove NEON yield calls crypto: arm64/aes-ce-mac - simplify NEON yield crypto: arm64/crc-t10dif - move NEON yield to C code Arnd Bergmann (1): crypto: octeontx2 - fix -Wpointer-bool-conversion warning Bhaskar Chowdhury (2): crypto: marvell/cesa - Fix a spelling s/fautly/faultly/ in comment crypto: xor - Fix typo of optimization Christophe JAILLET (1): hwrng: ingenic - Fix a
Re: [PATCH] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
Hi Don,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on a2ea4e1d9091cd8bc69f1c42c15bedc38618f04c]
url:
https://github.com/0day-ci/linux/commits/Don-Bollinger/eeprom-optoe-driver-to-read-write-SFP-QSFP-CMIS-EEPROMS/20210215-083817
base: a2ea4e1d9091cd8bc69f1c42c15bedc38618f04c
config: riscv-randconfig-r001-20210215 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
#
https://github.com/0day-ci/linux/commit/9089aa757bfb70c473ca54face762582908bdd28
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Don-Bollinger/eeprom-optoe-driver-to-read-write-SFP-QSFP-CMIS-EEPROMS/20210215-083817
git checkout 9089aa757bfb70c473ca54face762582908bdd28
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/misc/eeprom/optoe.c:615:16: warning: no previous prototype for
>> function 'optoe_make_regmap' [-Wmissing-prototypes]
struct regmap *optoe_make_regmap(struct i2c_client *client)
^
drivers/misc/eeprom/optoe.c:615:1: note: declare 'static' if the function is
not intended to be used outside of this translation unit
struct regmap *optoe_make_regmap(struct i2c_client *client)
^
static
1 warning generated.
vim +/optoe_make_regmap +615 drivers/misc/eeprom/optoe.c
605
606
607 /*
608 * optoe_make_regmap creates the regmap for the client.
609 * IMPORTANT: Don't call the regmap read/write calls directly
610 * for these devices. These devices are paged, and you have to
611 * set the page register before accessing the data in that page.
612 * Use the nvmem interfaces, those read/write calls use this
613 * driver to manage pages correctly.
614 */
> 615 struct regmap *optoe_make_regmap(struct i2c_client *client)
616 {
617 struct regmap_config regmap_config = { };
618 struct regmap *regmap;
619
620 /* setup a minimal regmap - 8 bits, 8 bit addresses */
621 regmap_config.val_bits = 8;
622 regmap_config.reg_bits = 8;
623
624 /* I'll handle the locking */
625 regmap_config.disable_locking = true;
626 regmap = devm_regmap_init_i2c(client, _config);
627 return regmap;
628 }
629
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] mmc: core: Reduce code duplication to mmc_spi_send_{csd|cid}
From: Yue Hu
mmc_spi_send_{csd|cid} have similar function body. Let's remove the
duplicated part to simplify the code, just add opcode to distinguish
them in changed mmc_spi_send_cxd().
Signed-off-by: Yue Hu
---
drivers/mmc/core/mmc_ops.c | 39 +--
1 file changed, 9 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c
index 265d95e..f413474 100644
--- a/drivers/mmc/core/mmc_ops.c
+++ b/drivers/mmc/core/mmc_ops.c
@@ -296,61 +296,40 @@ int mmc_set_relative_addr(struct mmc_card *card)
return 0;
}
-static int mmc_spi_send_csd(struct mmc_host *host, u32 *csd)
+static int mmc_spi_send_cxd(struct mmc_host *host, u32 *cxd, u32 opcode)
{
int ret, i;
- __be32 *csd_tmp;
+ __be32 *cxd_tmp;
- csd_tmp = kzalloc(16, GFP_KERNEL);
- if (!csd_tmp)
+ cxd_tmp = kzalloc(16, GFP_KERNEL);
+ if (!cxd_tmp)
return -ENOMEM;
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CSD, csd_tmp, 16);
+ ret = mmc_send_cxd_data(NULL, host, opcode, cxd_tmp, 16);
if (ret)
goto err;
for (i = 0; i < 4; i++)
- csd[i] = be32_to_cpu(csd_tmp[i]);
+ cxd[i] = be32_to_cpu(cxd_tmp[i]);
err:
- kfree(csd_tmp);
+ kfree(cxd_tmp);
return ret;
}
int mmc_send_csd(struct mmc_card *card, u32 *csd)
{
if (mmc_host_is_spi(card->host))
- return mmc_spi_send_csd(card->host, csd);
+ return mmc_spi_send_cxd(card->host, csd, MMC_SEND_CSD);
return mmc_send_cxd_native(card->host, card->rca << 16, csd,
MMC_SEND_CSD);
}
-static int mmc_spi_send_cid(struct mmc_host *host, u32 *cid)
-{
- int ret, i;
- __be32 *cid_tmp;
-
- cid_tmp = kzalloc(16, GFP_KERNEL);
- if (!cid_tmp)
- return -ENOMEM;
-
- ret = mmc_send_cxd_data(NULL, host, MMC_SEND_CID, cid_tmp, 16);
- if (ret)
- goto err;
-
- for (i = 0; i < 4; i++)
- cid[i] = be32_to_cpu(cid_tmp[i]);
-
-err:
- kfree(cid_tmp);
- return ret;
-}
-
int mmc_send_cid(struct mmc_host *host, u32 *cid)
{
if (mmc_host_is_spi(host))
- return mmc_spi_send_cid(host, cid);
+ return mmc_spi_send_cxd(host, cid, MMC_SEND_CID);
return mmc_send_cxd_native(host, 0, cid, MMC_ALL_SEND_CID);
}
--
1.9.1
Re: [PATCH] fs: configfs: Fix sentence with a better word in the file symlink.c
On 15:37 Sun 14 Feb 2021, Al Viro wrote: On Fri, Feb 05, 2021 at 06:02:35PM +0530, Bhaskar Chowdhury wrote: s/fucking/wonderful/ NAK. For one thing, your crusade (pardon the obscenity) is idiotic. For another, in this particular case your attempt of improvement changes the meaning to nearly opposite. "Magic" here is no compliment - read the comment and try to understand what it says. As expected Al, you are spot on. I will improve, honestly. You haven't read my other mail ...it should be lying somewhere in you inbox...that contain enough clue. :) Thanks, man! signature.asc Description: PGP signature
linux-next: build failure after merge of the mtd tree
Hi all,
After merging the mtd tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
ERROR: modpost: missing MODULE_LICENSE() in
drivers/mtd/parsers/bcm4908-partitions.o
ERROR: modpost: "bcm4908_partitions_post_parse" [drivers/mtd/parsers/ofpart.ko]
undefined!
Caused by commit
09cf6ee6d21c ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
I have used the mtd tree from next-20210212 for today.
--
Cheers,
Stephen Rothwell
pgpVeW81UGTiF.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Mon, Feb 15, 2021 at 9:12 AM Ian Lance Taylor wrote: > > On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner wrote: > > > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote: > > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote: > > > > > > > If you can't tell from userspace that a file has data in it other > > > > than by calling read() on it, then you can't use cfr on it. > > > > > > I don't know how to do that, Dave. :) > > > > If stat returns a non-zero size, then userspace knows it has at > > least that much data in it, whether it be zeros or previously > > written data. cfr will copy that data. The special zero length > > regular pipe files fail this simple "how much data is there to copy > > in this file" check... > > This suggests that if the Go standard library sees that > copy_file_range reads zero bytes, we should assume that it failed, and > should use the fallback path as though copy_file_range returned > EOPNOTSUPP or EINVAL. This will cause an extra system call for an > empty file, but as long as copy_file_range does not return an error > for cases that it does not support we are going to need an extra > system call anyhow. > > Does that seem like a possible mitigation? That is, are there cases > where copy_file_range will fail to do a correct copy, and will return > success, and will not return zero? I'm a bit worried about the sysfs files that report a 4096 bytes file size, for 2 reasons: - I'm not sure if the content _can_ actually be longer (I couldn't find a counterexample) - If you're unlucky enough to have a partial write in the output filesystem, you'll get a non-zero return value and probably corrupted content. > > Ian
Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
On 2/12/21 5:54 AM, Enrico Weigelt, metux IT consult wrote: > On 12.02.21 10:58, Linus Walleij wrote: > > Hi, > >> I think Intel people often take the stance that the ACPI DSDT (or whatever) >> needs to be fixed. > > It should, actually board/firmware vendors should think more carefully > and do it right in the first place. But reality is different. And > firmware upgrade often is anything but easy (as soon as we leave the > field of average Joh Doe's home PC) > >> If the usecase is to explicitly work around deployed firmware that cannot >> and will not be upgraded/fixed by describing the hardware using DT >> instead, based on just the DMI ID then we should spell that out >> explicitly. > > Okay, maybe I should have stated this more clearly. > > OTOH, the scope is also a little bit greater: certain external cards > that don't need much special handling for the card itself, just > enumerate devices (and connections between them) using existing drivers. > > That's a pretty common scenario in industrial backplane systems, where > we have lots of different (even application specific) cards, usually > composed of standard chips, that can be identified by some ID, but > cannot describe themselves. We have to write lots of specific drivers > for them, usually just for instantiating existing drivers. (we rarely > see such code going towards mainline). > > A similar case (mainlined) seems to be the RCAR display unit - they're > using dt overlays that are built into the driver and applied by it > based on the detected DU at runtime. RCAR seems to be a pure DT The RCAR use of overlays that are built into the driver are a known pattern that is explicitly not to be repeated. The driver has been granted a grandfathered in status, thus an exception as long as needed. -Frank > platform, so that's an obvious move. APU2/3/4 is ACPI based, so I went > in a different direction - but I'm now investigating how to make DT > overlays work on an ACPI platform (eg. needs some initial nodes, ...) > In case that's successful, I'll rework my RFC to use overlays, and > it will become much smaller (my oftree core changes then won't be > necessary anymore). > >> It feels a bit like fixing a problem using a different hardware description >> just because we can. Look in drivers/gpio/gpiolib-acpi.c >> table gpiolib_acpi_quirks[]. It's just an example how this is fixed using >> fine granular ACPI-specific mechanisms at several places in the kernel >> instead of just tossing out the whole description and redoing it in >> device tree. > > I'm quite reluctant to put everything in there. Theoretically, for apu > case, I could prevent enumerating the incomplete gpios there, but the > actual driver setup still remains (certainly don't wanna put that into > such a global place). But the original problem of having to write so > much code for just instantiating generic drivers remains. And > distributing knowledge of certain devices over several places doesn't > feel like a good idea to me. > > > --mtx >
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Sun, Feb 14, 2021 at 4:38 PM Dave Chinner wrote: > > On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote: > > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote: > > > > > If you can't tell from userspace that a file has data in it other > > > than by calling read() on it, then you can't use cfr on it. > > > > I don't know how to do that, Dave. :) > > If stat returns a non-zero size, then userspace knows it has at > least that much data in it, whether it be zeros or previously > written data. cfr will copy that data. The special zero length > regular pipe files fail this simple "how much data is there to copy > in this file" check... This suggests that if the Go standard library sees that copy_file_range reads zero bytes, we should assume that it failed, and should use the fallback path as though copy_file_range returned EOPNOTSUPP or EINVAL. This will cause an extra system call for an empty file, but as long as copy_file_range does not return an error for cases that it does not support we are going to need an extra system call anyhow. Does that seem like a possible mitigation? That is, are there cases where copy_file_range will fail to do a correct copy, and will return success, and will not return zero? Ian
Re: RFC: oftree based setup of composite board devices
On 2/8/21 5:48 PM, Rob Herring wrote: > +Johan H > > On Mon, Feb 8, 2021 at 4:22 PM Enrico Weigelt, metux IT consult > wrote: >> >> Hello folks, >> >> here's an RFC for using compiled-in dtb's for initializing board devices >> that can't be probed via bus'es or firmware. I've just been monitoring this thread for several days, hoping that the discussion would make things more clear for me. Disclaimer: I know essentially nothing about ACPI, please excuse improper naming and misunderstandings on my part. Why not compile in ACPI data (tables?) instead of devicetree description? > > I'm not convinced compiled in is the mechanism we want. > >> Use cases are boards with non-oftree firmware (ACPI, etc) where certain >> platform devices can't be directly enumerated via firmware. Traditionally >> we had to write board specific drivers that check for board identification >> (DMI strings, etc), then initialize the actual devices and their links >> (eg. gpio<->leds/buttons, ...). Often this can be expressed just by DT. > > This is something I've wanted to see for a while. There's use cases > for DT based systems too. The example I'd like to see supported are > USB serial adapters with downstream serdev, GPIO, I2C, SPI, etc. Then > plug more than one of those in. My understanding from the past is that the experts (those who understand both devicetree and ACPI) regard trying to mix devicetree and ACPI in a single running Linux kernel image is insanity, or at least likely to be confusing, difficult, and problematic. >From the devicetree side, I expect nightmares for me if devicetree and ACPI are mixed in a single running kernel image. > >> This patch queue does a bunch of preparations in oftree code, so we can >> support multiple fully independent DT's (not using DT overlays). And then >> adds a generic driver parses compiled-in fdt blobs, checks for mathing >> DMI strings and initializes the devices. As an example, the last patch >> adds an alternative implementation for the PC engines APU2/3/4 board >> family based on device tree. > > I think there's a couple of approaches we could take. Either support > multiple root nodes as you have done or keep a single root and add > child nodes to them. I think the latter would be less invasive. In the > non-DT cases, we'd just always create an empty skeleton DT. A 3rd > variation on a DT system is we could want to create parent nodes if > they don't exist to attach this DT to so we have a full hierarchy. > > I'm not saying which one we should do, just laying out some of the options. > Multiple root nodes and disjoint trees both seem problematic. Existing subsystems and drivers expect a single cohesive tree. Changing that architecture looks to me to be a painful exercise. >> The approach can be easily be extended to other kinds of composite devices, >> eg. PCI cards or USB dongles. >> >> >> Yet some drawbacks of the current implementation: >> >> * individual FDT's can't be modularized yet (IMHO, we don't have DMI-based >>modprobing anyways) > > I think we need to use either firmware loading or udev mechanisms to > load the FDTs. > >> * can't reconfigure or attach to devices outside the individual DT's >>(eg. probed by PCI, etc) > > Not sure I follow. > > Rob >
Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library
On Sun, Feb 14, 2021 at 4:23 PM David Howells wrote:
>
> Anyway, I have posted my fscache modernisation patches multiple times for
> public review, I have tried to involve the wider community in aspects of the
> development on public mailing lists and I have been including the maintainers
> in to/cc.
So then add those links and the cc's to the commit logs, so that I can
*see* them.
I'm done with this discussion.
If I see a pull request from you, I DO NOT WANT TO HAVE TO HAVE A
WEEK-LONG EMAIL THREAD ABOUT HOW I CANNOT SEE THAT IT HAS EVER SEEN
ANY REVIEW.
So if all I see is "Signed-off-by:" from you, I will promptly throw
that pull request into the garbage, because it's just not worth my
time to try to have to get you kicking and screaming to show that
others have been involved.
Can you not understand that?
When I get that pull request, I need to see that yes, this has been
reviewed, people have been involved, and yes, it's been in linux-next.
I want to see "reviewed-by" and "tested-by", I want to see "cc", and I
want to see links to submission threads with discussion showing that
others actually were involved.
I do *not* want to see just a single signed-off-by line from you, and
then have to ask for "has anybody else actually seen this and reviewed
it".
Look, here's an entirely unrelated example from a single fairly recent
trivial one-liner memory leak fix:
Fixes: 87c715dcde63 ("scsi: scsi_debug: Add per_host_store option")
Link: https://lore.kernel.org/r/20210208111734.34034-1-mlomb...@redhat.com
Acked-by: Douglas Gilbert
Signed-off-by: Maurizio Lombardi
Signed-off-by: Martin K. Petersen
that's from a quite a trivial commit. Yes, it's trivial, but it could
still be wrong, of course. And if somebody ever reports that it causes
problems despite how simple it was, look at what I have: I have three
people to contact, and I have a pointer to the actual original
submission of the patch.
Do we have that for all our commits? No. But it's also not at all
unusual any more, and in fact many commits have even more, with
testing etc.
And yes, sometimes the test results and acks come back later after
you've already pushed the changes out etc, and no, it's generally not
worth rebasing for that - maybe others have now started to rely on
whatever public branch you have. Which is why the "Link:" is useful,
so that if things come in later, the discussion can still be found.
But quite often, you shouldn't have pushed out some final branch
before you've gotten at least *some* positive response from people, so
I do kind of expect some "Acked-by" etc in the commit itself.
THAT is what you need to aim for.
And yes, I'm picking on you. Because we've had this problem before.
I've complained when you've sent me pull requests that don't even
build, that you in fact had been told by linux-next didn't build, and
you still sent them to me.
And as a result, I've asked for more involvement from other people before.
So now I'm clarifying that requirement - I absolutely need to see
that it has actually seen testing, that it has seen other people being
involved, and that it isn't just you throwing spaghetti at the wall to
see what sticks.
And I'm not going to do that for every pull request. I want to see
that data *in* the pull request itself.
Linus
Re: Linux 5.11
On 14:45 Sun 14 Feb 2021, Linus Torvalds wrote: Nothing unexpected or particularly scary happened this week, so here we are - with 5.11 tagged and pushed out. In fact, it's a smaller-than-average set of commits from rc7 to final, which makes me happy. And I already have several pull requests lined up for tomorrow, so we're all set for the merge window to start. But in the meantime - and yes, I know it's Valentine's Day here in the US - maybe give this release a good testing before you go back and play with development kernels. All right? Because I'm sure your SO will understand. Here we go ... :) bhaskar@OpenSuse_06:22:58_Mon Feb 15:~> rc-kernel-pull-build-boot.sh We have new RC kernel remote: Enumerating objects: 6, done. remote: Counting objects: 100% (6/6), done. remote: Compressing objects: 100% (4/4), done. remote: Total 4 (delta 2), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (4/4), 868 bytes | 289.00 KiB/s, done. From https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux 28a173387388..f40ddce88593 master -> origin/master * [new tag] v5.11 -> v5.11 Updating 28a173387388..f40ddce88593 Fast-forward Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) We are fine ..pls proceed.. ~Bhaskar signature.asc Description: PGP signature
[PATCH 2/2] arch: syscalls: remove $(srctree)/ prefix from syscall tables
The 'syscall' variables are not directly used in the commands. Remove the $(srctree)/ prefix because we can rely on VPATH. Signed-off-by: Masahiro Yamada --- arch/alpha/kernel/syscalls/Makefile | 2 +- arch/arm/tools/Makefile | 2 +- arch/ia64/kernel/syscalls/Makefile | 2 +- arch/m68k/kernel/syscalls/Makefile | 2 +- arch/microblaze/kernel/syscalls/Makefile | 2 +- arch/mips/kernel/syscalls/Makefile | 6 +++--- arch/parisc/kernel/syscalls/Makefile | 2 +- arch/powerpc/kernel/syscalls/Makefile| 2 +- arch/sh/kernel/syscalls/Makefile | 2 +- arch/sparc/kernel/syscalls/Makefile | 2 +- arch/x86/entry/syscalls/Makefile | 4 ++-- arch/xtensa/kernel/syscalls/Makefile | 2 +- 12 files changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/alpha/kernel/syscalls/Makefile b/arch/alpha/kernel/syscalls/Makefile index 1c42d2d2926d..285aaba832d9 100644 --- a/arch/alpha/kernel/syscalls/Makefile +++ b/arch/alpha/kernel/syscalls/Makefile @@ -5,7 +5,7 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/arm/tools/Makefile b/arch/arm/tools/Makefile index 27d8beb7c941..3654f979851b 100644 --- a/arch/arm/tools/Makefile +++ b/arch/arm/tools/Makefile @@ -11,7 +11,7 @@ uapi := $(gen)/uapi/asm syshdr := $(srctree)/$(src)/syscallhdr.sh sysnr := $(srctree)/$(src)/syscallnr.sh systbl := $(srctree)/$(src)/syscalltbl.sh -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl gen-y := $(gen)/calls-oabi.S gen-y += $(gen)/calls-eabi.S diff --git a/arch/ia64/kernel/syscalls/Makefile b/arch/ia64/kernel/syscalls/Makefile index b9bfd186295f..bf4bda0f63eb 100644 --- a/arch/ia64/kernel/syscalls/Makefile +++ b/arch/ia64/kernel/syscalls/Makefile @@ -5,7 +5,7 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/m68k/kernel/syscalls/Makefile b/arch/m68k/kernel/syscalls/Makefile index 1c42d2d2926d..285aaba832d9 100644 --- a/arch/m68k/kernel/syscalls/Makefile +++ b/arch/m68k/kernel/syscalls/Makefile @@ -5,7 +5,7 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/microblaze/kernel/syscalls/Makefile b/arch/microblaze/kernel/syscalls/Makefile index 1c42d2d2926d..285aaba832d9 100644 --- a/arch/microblaze/kernel/syscalls/Makefile +++ b/arch/microblaze/kernel/syscalls/Makefile @@ -5,7 +5,7 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/mips/kernel/syscalls/Makefile b/arch/mips/kernel/syscalls/Makefile index f15842bda464..ed22b711ccb7 100644 --- a/arch/mips/kernel/syscalls/Makefile +++ b/arch/mips/kernel/syscalls/Makefile @@ -5,9 +5,9 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscalln32 := $(srctree)/$(src)/syscall_n32.tbl -syscalln64 := $(srctree)/$(src)/syscall_n64.tbl -syscallo32 := $(srctree)/$(src)/syscall_o32.tbl +syscalln32 := $(src)/syscall_n32.tbl +syscalln64 := $(src)/syscall_n64.tbl +syscallo32 := $(src)/syscall_o32.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh sysnr := $(srctree)/$(src)/syscallnr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/parisc/kernel/syscalls/Makefile b/arch/parisc/kernel/syscalls/Makefile index 556fe30a6c8f..283f64407b07 100644 --- a/arch/parisc/kernel/syscalls/Makefile +++ b/arch/parisc/kernel/syscalls/Makefile @@ -5,7 +5,7 @@ uapi := arch/$(SRCARCH)/include/generated/uapi/asm _dummy := $(shell [ -d '$(uapi)' ] || mkdir -p '$(uapi)') \ $(shell [ -d '$(kapi)' ] || mkdir -p '$(kapi)') -syscall := $(srctree)/$(src)/syscall.tbl +syscall := $(src)/syscall.tbl syshdr := $(srctree)/$(src)/syscallhdr.sh systbl := $(srctree)/$(src)/syscalltbl.sh diff --git a/arch/powerpc/kernel/syscalls/Makefile
[PATCH 1/2] arch: syscalls: add missing FORCE and fix 'targets' to make if_changed work
The rules in these Makefiles cannot detect the command line change because the prerequisite 'FORCE' is missing. Adding 'FORCE' will result in the headers being rebuilt every time because the 'targets' additions are also wrong; the file paths in 'targets' must be relative to the current Makefile. Fix all of them so the if_changed rules work correctly. Signed-off-by: Masahiro Yamada Acked-by: Geert Uytterhoeven --- arch/alpha/kernel/syscalls/Makefile | 11 +- arch/ia64/kernel/syscalls/Makefile | 11 +- arch/m68k/kernel/syscalls/Makefile | 11 +- arch/microblaze/kernel/syscalls/Makefile | 11 +- arch/mips/kernel/syscalls/Makefile | 27 arch/parisc/kernel/syscalls/Makefile | 17 --- arch/powerpc/kernel/syscalls/Makefile| 19 + arch/sh/kernel/syscalls/Makefile | 11 +- arch/sparc/kernel/syscalls/Makefile | 17 --- arch/x86/entry/syscalls/Makefile | 23 ++-- arch/xtensa/kernel/syscalls/Makefile | 11 +- 11 files changed, 90 insertions(+), 79 deletions(-) diff --git a/arch/alpha/kernel/syscalls/Makefile b/arch/alpha/kernel/syscalls/Makefile index 659faefdcb1d..1c42d2d2926d 100644 --- a/arch/alpha/kernel/syscalls/Makefile +++ b/arch/alpha/kernel/syscalls/Makefile @@ -21,18 +21,19 @@ quiet_cmd_systbl = SYSTBL $@ '$(systbl_abi_$(basetarget))'\ '$(systbl_offset_$(basetarget))' -$(uapi)/unistd_32.h: $(syscall) $(syshdr) +$(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE $(call if_changed,syshdr) -$(kapi)/syscall_table.h: $(syscall) $(systbl) +$(kapi)/syscall_table.h: $(syscall) $(systbl) FORCE $(call if_changed,systbl) uapisyshdr-y += unistd_32.h kapisyshdr-y += syscall_table.h -targets+= $(uapisyshdr-y) $(kapisyshdr-y) +uapisyshdr-y := $(addprefix $(uapi)/, $(uapisyshdr-y)) +kapisyshdr-y := $(addprefix $(kapi)/, $(kapisyshdr-y)) +targets+= $(addprefix ../../../../, $(uapisyshdr-y) $(kapisyshdr-y)) PHONY += all -all: $(addprefix $(uapi)/,$(uapisyshdr-y)) -all: $(addprefix $(kapi)/,$(kapisyshdr-y)) +all: $(uapisyshdr-y) $(kapisyshdr-y) @: diff --git a/arch/ia64/kernel/syscalls/Makefile b/arch/ia64/kernel/syscalls/Makefile index 813a58cba39c..b9bfd186295f 100644 --- a/arch/ia64/kernel/syscalls/Makefile +++ b/arch/ia64/kernel/syscalls/Makefile @@ -22,19 +22,20 @@ quiet_cmd_systbl = SYSTBL $@ '$(systbl_offset_$(basetarget))' syshdr_offset_unistd_64 := __NR_Linux -$(uapi)/unistd_64.h: $(syscall) $(syshdr) +$(uapi)/unistd_64.h: $(syscall) $(syshdr) FORCE $(call if_changed,syshdr) systbl_offset_syscall_table := 1024 -$(kapi)/syscall_table.h: $(syscall) $(systbl) +$(kapi)/syscall_table.h: $(syscall) $(systbl) FORCE $(call if_changed,systbl) uapisyshdr-y += unistd_64.h kapisyshdr-y += syscall_table.h -targets+= $(uapisyshdr-y) $(kapisyshdr-y) +uapisyshdr-y := $(addprefix $(uapi)/, $(uapisyshdr-y)) +kapisyshdr-y := $(addprefix $(kapi)/, $(kapisyshdr-y)) +targets+= $(addprefix ../../../../, $(uapisyshdr-y) $(kapisyshdr-y)) PHONY += all -all: $(addprefix $(uapi)/,$(uapisyshdr-y)) -all: $(addprefix $(kapi)/,$(kapisyshdr-y)) +all: $(uapisyshdr-y) $(kapisyshdr-y) @: diff --git a/arch/m68k/kernel/syscalls/Makefile b/arch/m68k/kernel/syscalls/Makefile index 659faefdcb1d..1c42d2d2926d 100644 --- a/arch/m68k/kernel/syscalls/Makefile +++ b/arch/m68k/kernel/syscalls/Makefile @@ -21,18 +21,19 @@ quiet_cmd_systbl = SYSTBL $@ '$(systbl_abi_$(basetarget))'\ '$(systbl_offset_$(basetarget))' -$(uapi)/unistd_32.h: $(syscall) $(syshdr) +$(uapi)/unistd_32.h: $(syscall) $(syshdr) FORCE $(call if_changed,syshdr) -$(kapi)/syscall_table.h: $(syscall) $(systbl) +$(kapi)/syscall_table.h: $(syscall) $(systbl) FORCE $(call if_changed,systbl) uapisyshdr-y += unistd_32.h kapisyshdr-y += syscall_table.h -targets+= $(uapisyshdr-y) $(kapisyshdr-y) +uapisyshdr-y := $(addprefix $(uapi)/, $(uapisyshdr-y)) +kapisyshdr-y := $(addprefix $(kapi)/, $(kapisyshdr-y)) +targets+= $(addprefix ../../../../, $(uapisyshdr-y) $(kapisyshdr-y)) PHONY += all -all: $(addprefix $(uapi)/,$(uapisyshdr-y)) -all: $(addprefix $(kapi)/,$(kapisyshdr-y)) +all: $(uapisyshdr-y) $(kapisyshdr-y) @: diff --git a/arch/microblaze/kernel/syscalls/Makefile b/arch/microblaze/kernel/syscalls/Makefile index 659faefdcb1d..1c42d2d2926d 100644 --- a/arch/microblaze/kernel/syscalls/Makefile +++ b/arch/microblaze/kernel/syscalls/Makefile @@ -21,18 +21,19 @@ quiet_cmd_systbl = SYSTBL $@ '$(systbl_abi_$(basetarget))'\ '$(systbl_offset_$(basetarget))' -$(uapi)/unistd_32.h:
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got conflicts in:
drivers/net/ethernet/mellanox/mlx5/core/en_main.c
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
between commit:
e4484d9df500 ("net/mlx5e: Enable striding RQ for Connect-X IPsec capable
devices")
from the net tree and commits:
224169d2a32b ("net/mlx5e: IPsec, Remove unnecessary config flag usage")
70038b73e40e ("net/mlx5e: Add listener to trap event")
214baf22870c ("net/mlx5e: Support HTB offload")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index a2e0b548bf57,d3534b657b98..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@@ -65,7 -65,8 +65,9 @@@
#include "en/devlink.h"
#include "lib/mlx5.h"
#include "en/ptp.h"
+#include "fpga/ipsec.h"
+ #include "qos.h"
+ #include "en/trap.h"
bool mlx5e_check_fragmented_striding_rq_cap(struct mlx5_core_dev *mdev)
{
@@@ -2069,10 -2106,8 +2107,8 @@@ static void mlx5e_build_rq_frags_info(s
u32 buf_size = 0;
int i;
- #ifdef CONFIG_MLX5_EN_IPSEC
- if (MLX5_IPSEC_DEV(mdev))
+ if (mlx5_fpga_is_ipsec_device(mdev))
byte_count += MLX5E_METADATA_ETHER_LEN;
- #endif
if (mlx5e_rx_is_linear_skb(params, xsk)) {
int frag_stride;
diff --cc drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 4864deed9dc9,4de5a97ceac6..
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@@ -1794,12 -1786,10 +1786,10 @@@ int mlx5e_rq_set_handlers(struct mlx5e_
rq->dealloc_wqe = mlx5e_dealloc_rx_mpwqe;
rq->handle_rx_cqe =
priv->profile->rx_handlers->handle_rx_cqe_mpwqe;
- #ifdef CONFIG_MLX5_EN_IPSEC
- if (MLX5_IPSEC_DEV(mdev)) {
- netdev_err(netdev, "MPWQE RQ with IPSec offload not
supported\n");
+ if (mlx5_fpga_is_ipsec_device(mdev)) {
+ netdev_err(netdev, "MPWQE RQ with Innova IPSec offload
not supported\n");
return -EINVAL;
}
- #endif
if (!rq->handle_rx_cqe) {
netdev_err(netdev, "RX handler of MPWQE RQ is not
set\n");
return -EINVAL;
pgpu3GCjH27Mp.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
tools/testing/selftests/net/forwarding/tc_flower.sh
between commit:
d2126838050c ("flow_dissector: fix TTL and TOS dissection on IPv4 fragments")
from the net tree and commits:
203ee5cd7235 ("selftests: tc: Add basic mpls_* matching support for
tc-flower")
c09bfd9a5df9 ("selftests: tc: Add generic mpls matching support for
tc-flower")
from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/net/forwarding/tc_flower.sh
index b11d8e6b5bc1,a554838666c4..
--- a/tools/testing/selftests/net/forwarding/tc_flower.sh
+++ b/tools/testing/selftests/net/forwarding/tc_flower.sh
@@@ -3,7 -3,9 +3,9 @@@
ALL_TESTS="match_dst_mac_test match_src_mac_test match_dst_ip_test \
match_src_ip_test match_ip_flags_test match_pcp_test match_vlan_test \
- match_ip_tos_test match_indev_test match_ip_ttl_test"
+ match_ip_tos_test match_indev_test match_mpls_label_test \
+ match_mpls_tc_test match_mpls_bos_test match_mpls_ttl_test \
- match_mpls_lse_test"
++ match_mpls_lse_test match_ip_ttl_test"
NUM_NETIFS=2
source tc_common.sh
source lib.sh
pgpmMuGAaTuc2.pgp
Description: OpenPGP digital signature
linux-next: build warning after merge of the pm tree
Hi all,
After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
In file included from drivers/gpu/drm/gma500/mdfld_output.c:28:
arch/x86/include/asm/intel_scu_ipc.h:23:12: warning: 'struct module' declared
inside parameter list will not be visible outside of this definition or
declaration
23 | struct module *owner);
|^~
arch/x86/include/asm/intel_scu_ipc.h:33:17: warning: 'struct module' declared
inside parameter list will not be visible outside of this definition or
declaration
33 | struct module *owner);
| ^~
Introduced by commit
bfc838f8598e ("drm/gma500: Convert to use new SCU IPC API")
OK, these will go away when the drm-misc tree removes this file in commit
e1da811218d2 ("drm/gma500: Remove Medfield support")
So, if you don't want to see these warnings in Linus' build testing,
you need to make sure that the drm-misc tree is merged before the pm
tree (or the drivers-x86 tree). Or you need to include module.h in
mdfld_output.c before intel_scu_ipc.h (or in intel_scu_ipc.h itself).
--
Cheers,
Stephen Rothwell
pgp30b690u5z0.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 03:54:48PM -0800, Darrick J. Wong wrote: > On Sat, Feb 13, 2021 at 10:27:26AM +1100, Dave Chinner wrote: > > On Fri, Feb 12, 2021 at 03:07:39PM -0800, Ian Lance Taylor wrote: > > > On Fri, Feb 12, 2021 at 3:03 PM Dave Chinner wrote: > > > > > > > > On Fri, Feb 12, 2021 at 04:45:41PM +0100, Greg KH wrote: > > > > > On Fri, Feb 12, 2021 at 07:33:57AM -0800, Ian Lance Taylor wrote: > > > > > > On Fri, Feb 12, 2021 at 12:38 AM Greg KH > > > > > > wrote: > > > > > > > > > > > > > > Why are people trying to use copy_file_range on simple /proc and > > > > > > > /sys > > > > > > > files in the first place? They can not seek (well most can not), > > > > > > > so > > > > > > > that feels like a "oh look, a new syscall, let's use it > > > > > > > everywhere!" > > > > > > > problem that userspace should not do. > > > > > > > > > > > > This may have been covered elsewhere, but it's not that people are > > > > > > saying "let's use copy_file_range on files in /proc." It's that the > > > > > > Go language standard library provides an interface to operating > > > > > > system > > > > > > files. When Go code uses the standard library function io.Copy to > > > > > > copy the contents of one open file to another open file, then on > > > > > > Linux > > > > > > kernels 5.3 and greater the Go standard library will use the > > > > > > copy_file_range system call. That seems to be exactly what > > > > > > copy_file_range is intended for. Unfortunately it appears that when > > > > > > people writing Go code open a file in /proc and use io.Copy the > > > > > > contents to another open file, copy_file_range does nothing and > > > > > > reports success. There isn't anything on the copy_file_range man > > > > > > page > > > > > > explaining this limitation, and there isn't any documented way to > > > > > > know > > > > > > that the Go standard library should not use copy_file_range on > > > > > > certain > > > > > > files. > > > > > > > > > > But, is this a bug in the kernel in that the syscall being made is not > > > > > working properly, or a bug in that Go decided to do this for all types > > > > > of files not knowing that some types of files can not handle this? > > > > > > > > > > If the kernel has always worked this way, I would say that Go is doing > > > > > the wrong thing here. If the kernel used to work properly, and then > > > > > changed, then it's a regression on the kernel side. > > > > > > > > > > So which is it? > > > > > > > > Both Al Viro and myself have said "copy file range is not a generic > > > > method for copying data between two file descriptors". It is a > > > > targetted solution for *regular files only* on filesystems that store > > > > persistent data and can accelerate the data copy in some way (e.g. > > > > clone, server side offload, hardware offlead, etc). It is not > > > > intended as a copy mechanism for copying data from one random file > > > > descriptor to another. > > > > > > > > The use of it as a general file copy mechanism in the Go system > > > > library is incorrect and wrong. It is a userspace bug. Userspace > > > > has done the wrong thing, userspace needs to be fixed. > > > > > > OK, we'll take it out. > > > > > > I'll just make one last plea that I think that copy_file_range could > > > be much more useful if there were some way that a program could know > > > whether it would work or not. > > Well... we could always implement a CFR_DRYRUN flag that would run > through all the parameter validation and return 0 just before actually > starting any real copying logic. But that wouldn't itself solve the > problem that there are very old virtual filesystems in Linux that have > zero-length regular files that behave like a pipe. > > > If you can't tell from userspace that a file has data in it other > > than by calling read() on it, then you can't use cfr on it. > > I don't know how to do that, Dave. :) If stat returns a non-zero size, then userspace knows it has at least that much data in it, whether it be zeros or previously written data. cfr will copy that data. The special zero length regular pipe files fail this simple "how much data is there to copy in this file" check... > Frankly I'm with the Go developers on this -- one should detect c_f_r by > calling it and if it errors out then fall back to the usual userspace > buffer copy strategy. > > That still means we need to fix the kernel WRT these weird old > filesystems. One of... And that is the whole problem here, not that cfr is failing. cfr is behaving correctly and consistently as the filesystem is telling the kernel there is no data in the file (i.e. size = 0). > 1. Get rid of the generic fallback completely, since splice only copies > 64k at a time and ... yay? I guess it at least passes generic/521 and > generic/522 these days. I've had a few people ask me for cfr to not fall back to a manual copy because they only want it to do something if it can accelerate the copy to
Re: [EXT] Re: [PATCH v12 net-next 12/15] net: mvpp2: add BM protection underrun feature support
> > Does this even need to be configurable? What is the cost of turning it on? > > How does having less pools affect the system? Does average latency go up? > > When would i consider an underrun actually a good thing? > > > > Maybe it should just be hard coded on? Or we should try to detect when > > underruns are happening a lot, and dynamically turn it on for a while? > > > The cost of this change is that the number of pools reduced from 16 to 8. > The current driver uses only 4pools, but some future features like QoS can > use over 4 pools. So you are saying, there is currently no cost for turning it on. So it seems like you should just turn it on, and forget the module parameter. When QoS features are added which require more than 8 pools you can then address the issue of if this should be configurable. Andrew
[PATCH] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS
optoe is an i2c based driver that supports read/write access to all
the pages (tables) of MSA standard SFP and similar devices (conforming
to the SFF-8472 spec), MSA standard QSFP and similar devices (conforming
to the SFF-8636 spec) and CMIS and similar devices (conforming to the
Common Management Interface Specfication).
These devices provide identification, operational status and control
registers via an EEPROM model. These devices support one or 3 fixed pages
(128 bytes) of data, and one page that is selected via a page register on
the first fixed page. Thus the driver's main task is to map these pages
onto a simple linear address space for user space management applications.
See the driver code for a detailed layout.
Several variants and predecessors of this driver exist outside the kernel
tree. Some of them don't support pages at all, only accessing the first
256 bytes of EEPROM. None of them handle all three specifications, none
of them support pages beyond page 3. This is a problem since critical
monitoring data on CMIS devices is on page 0x11. Some of them don't
support pages at all, only accessing the first 256 bytes of data. optoe
supports the full architected 256 page address space of these devices.
optoe is currently in production on multiple platforms running SONiC
(Microsoft's Software for Open Networking in the Cloud) and ONL (Open
Network Linux). They have requested that optoe be submitted upstream.
The EEPROM data is accessible to user space and kernel consumers via the
nvmem interface.
optoe devices can be configured via device tree or the 'new_device'
paradigm.
See Documentation/misc-devices/optoe.rst for details on configuring
optoe and accessing the EEPROM.
Signed-off-by: Don Bollinger
---
Documentation/devicetree/bindings/eeprom/optoe.txt | 26 +
Documentation/misc-devices/optoe.rst | 127 +++
drivers/misc/eeprom/Kconfig| 24 +
drivers/misc/eeprom/Makefile | 1 +
drivers/misc/eeprom/optoe.c| 931 +
5 files changed, 1109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/eeprom/optoe.txt
create mode 100644 Documentation/misc-devices/optoe.rst
create mode 100644 drivers/misc/eeprom/optoe.c
diff --git a/Documentation/devicetree/bindings/eeprom/optoe.txt
b/Documentation/devicetree/bindings/eeprom/optoe.txt
new file mode 100644
index ..3a8c350cf2f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/optoe.txt
@@ -0,0 +1,26 @@
+EEPROMs on SFP/QSFP/CMIS optoelectronic modules using SFF-8472, SFF-8676,
+CMIS (Common Management Interface Spec) devices.
+
+Required properties:
+- compatible: shall be one of :
+ 'optoe,optoe1' - for QSFP class devices, adhering to SFF-8636
+ 'optoe,optoe2' - for SFP class devices, adhering to SFF-8472
+ 'optoe,optoe3' - for CMIS devices (newer QSFP class devices)
+- reg: 0x50 The only valid value is 0x50, as all three standards specify that
+ the device is at i2c address 0x50. (optoe allocates an i2c dummy to access
+ the data at i2c address 0x51.)
+
+Optional property:
+- port_name: can be set to any string up to 19 characters. Note that the
+ actual mapping between i2c busses and network ports is platform dependent
+ and varies widely. The 'port_name' property provides a way to associate
+ specific network ports with their associated hardware ports.
+
+Example:
+ #address-cells = <1>;
+ #size-cells = <0>;
+ optoe@50 {
+ compatible = "optoe,optoe2";
+ reg = <0x50>;
+ port_name = "port1";
+ };
diff --git a/Documentation/misc-devices/optoe.rst
b/Documentation/misc-devices/optoe.rst
new file mode 100644
index ..2ffce09f18bb
--- /dev/null
+++ b/Documentation/misc-devices/optoe.rst
@@ -0,0 +1,127 @@
+
+optoe - EEPROMs on SFP/QSFP/CMIS optoelectronic modules
+
+
+Author: Don Bollinger (d...@thebollingers.org)
+
+Description:
+
+
+Optoe is an i2c based driver that supports read/write access to all
+the pages (tables) of MSA standard SFP and similar devices (conforming
+to the SFF-8472 spec), MSA standard QSFP and similar devices (conforming
+to the SFF-8436 or SFF-8636 spec) and CMIS devices (conforming to the
+Common Management Interface Specification).
+
+i2c based optoelectronic transceivers (SPF, QSFP, etc) provide identification,
+operational status, and control registers via an EEPROM model. Unlike the
+EEPROMs that at24 supports, these devices access data beyond byte 256 via
+a page select register, which must be managed by the driver. optoe
+represents the EEPROM as a linear address space, managing the page register
+as needed. On QSFP and CMIS devices, the first 256 bytes are page 0, followed
+by 128 byte pages 1-128. On SFP devices, the first 256 bytes
Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library
Linus Torvalds wrote: > But no, it's not a replacement for actual code review after the fact. > > If you think email has too long latency for review, and can't use > public mailing lists and cc the people who are maintainers, then I > simply don't want your patches. I think we were talking at cross-purposes by the term "development" here. I was referring to the discussion of how the implementation should be done and working closely with colleagues - both inside and outside Red Hat - to get things working, not specifically the public review side of things. It's just that I don't have a complete record of the how-to-implement-it, the how-to-get-various-bits-working-together and the why-is-it-not-working? discussions. Anyway, I have posted my fscache modernisation patches multiple times for public review, I have tried to involve the wider community in aspects of the development on public mailing lists and I have been including the maintainers in to/cc. I've posted the more full patchset for public review a number of times: 4th May 2020: https://lore.kernel.org/linux-fsdevel/158861203563.340223.7585359869938129395.st...@warthog.procyon.org.uk/ 13th Jul (split into three subsets): https://lore.kernel.org/linux-fsdevel/159465766378.1376105.11619976251039287525.st...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/159465784033.1376674.18106463693989811037.st...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/159465821598.1377938.2046362270225008168.st...@warthog.procyon.org.uk/ 20th Nov: https://lore.kernel.org/linux-fsdevel/160588455242.3465195.3214733858273019178.st...@warthog.procyon.org.uk/ I then cut it down and posted that publically a couple of times: 20th Jan: https://lore.kernel.org/linux-fsdevel/161118128472.1232039.11746799833066425131.st...@warthog.procyon.org.uk/ 25th Jan: https://lore.kernel.org/linux-fsdevel/161161025063.2537118.2009249444682241405.st...@warthog.procyon.org.uk/ I let you know what was coming here: https://lore.kernel.org/linux-fsdevel/447452.1596109...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/2522190.1612544...@warthog.procyon.org.uk/ to try and find out whether you were going to have any objections to the design in advance, rather than at the last minute. I've apprised people of what I was up to: https://lore.kernel.org/lkml/24942.1573667...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/2758811.1610621...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/1441311.1598547...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/160655.1611012...@warthog.procyon.org.uk/ Asked for consultation on parts of what I wanted to do: https://lore.kernel.org/linux-fsdevel/3326.1579019...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/4467.1579020...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/3577430.1579705...@warthog.procyon.org.uk/ Asked someone who is actually using fscache in production to test the rewrite: https://listman.redhat.com/archives/linux-cachefs/2020-December/msg0.html I've posted partial patches to try and help 9p and cifs along: https://lore.kernel.org/linux-fsdevel/1514086.1605697...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-cifs/1794123.1605713...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/241017.1612263...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-cifs/270998.1612265...@warthog.procyon.org.uk/ (Jeff has been handling Ceph and Dave NFS). Proposed conference topics related to this: https://lore.kernel.org/linux-fsdevel/9608.1575900...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/14196.1575902...@warthog.procyon.org.uk/ https://lore.kernel.org/linux-fsdevel/364531.1579265...@warthog.procyon.org.uk/ though the lockdown put paid to that:-( Willy has discussed it too: https://lore.kernel.org/linux-fsdevel/20200826193116.gu17...@casper.infradead.org/ David
Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface
On Sun, Feb 14, 2021 at 11:50:12PM +, Al Viro wrote: > check that len is reasonable > p = kmalloc(offsetof(struct foo, string[len]), GFP_KERNEL); > copy_from_user(p, user_object, len); offsetof(struct foo, string[len]), that is
drivers/net/bonding/bond_main.c:4877:3: warning: 'strncpy' specified bound 16 equals destination size
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 358feceebbf68f33c44c6650d14455389e65282d
commit: 8d58f222e85f01da0c0e1fc1e77986c86de889e2 ubsan: disable UBSAN_ALIGNMENT
under COMPILE_TEST
date: 9 months ago
config: s390-randconfig-r014-20210215 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8d58f222e85f01da0c0e1fc1e77986c86de889e2
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 8d58f222e85f01da0c0e1fc1e77986c86de889e2
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
|^~~~
include/net/sch_generic.h:868:2: note: in expansion of macro 'this_cpu_inc'
868 | this_cpu_inc(sch->cpu_qstats->qlen);
| ^~~~
include/net/sch_generic.h: In function 'qdisc_qstats_cpu_qlen_dec':
arch/s390/include/asm/percpu.h:74:21: warning: comparison is always true due
to limited range of data type [-Wtype-limits]
74 | ((szcast)val__ > -129) && ((szcast)val__ < 128)) { \
| ^
arch/s390/include/asm/percpu.h:91:34: note: in expansion of macro
'arch_this_cpu_add'
91 | #define this_cpu_add_8(pcp, val) arch_this_cpu_add(pcp, val, "laag",
"agsi", long)
| ^
include/linux/percpu-defs.h:380:11: note: in expansion of macro
'this_cpu_add_8'
380 | case 8: stem##8(variable, __VA_ARGS__);break; \
| ^~~~
include/linux/percpu-defs.h:509:33: note: in expansion of macro
'__pcpu_size_call'
509 | #define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp,
val)
| ^~~~
include/linux/percpu-defs.h:519:33: note: in expansion of macro
'this_cpu_add'
519 | #define this_cpu_sub(pcp, val) this_cpu_add(pcp,
-(typeof(pcp))(val))
| ^~~~
include/linux/percpu-defs.h:521:28: note: in expansion of macro
'this_cpu_sub'
521 | #define this_cpu_dec(pcp) this_cpu_sub(pcp, 1)
|^~~~
include/net/sch_generic.h:873:2: note: in expansion of macro 'this_cpu_dec'
873 | this_cpu_dec(sch->cpu_qstats->qlen);
| ^~~~
include/net/sch_generic.h: In function 'qdisc_qstats_cpu_requeues_inc':
arch/s390/include/asm/percpu.h:74:21: warning: comparison is always true due
to limited range of data type [-Wtype-limits]
74 | ((szcast)val__ > -129) && ((szcast)val__ < 128)) { \
| ^
arch/s390/include/asm/percpu.h:91:34: note: in expansion of macro
'arch_this_cpu_add'
91 | #define this_cpu_add_8(pcp, val) arch_this_cpu_add(pcp, val, "laag",
"agsi", long)
| ^
include/linux/percpu-defs.h:380:11: note: in expansion of macro
'this_cpu_add_8'
380 | case 8: stem##8(variable, __VA_ARGS__);break; \
| ^~~~
include/linux/percpu-defs.h:509:33: note: in expansion of macro
'__pcpu_size_call'
509 | #define this_cpu_add(pcp, val) __pcpu_size_call(this_cpu_add_, pcp,
val)
| ^~~~
include/linux/percpu-defs.h:520:28: note: in expansion of macro
'this_cpu_add'
520 | #define this_cpu_inc(pcp) this_cpu_add(pcp, 1)
|^~~~
include/net/sch_generic.h:878:2: note: in expansion of macro 'this_cpu_inc'
878 | this_cpu_inc(sch->cpu_qstats->requeues);
| ^~~~
include/net/sch_generic.h: In function 'qdisc_qstats_cpu_drop':
arch/s390/include/asm/percpu.h:74:21: warning: comparison is always true due
to limited range of data type [-Wtype-limits]
74 | ((szcast)val__ > -129) && ((szcast)val__ < 128)) { \
| ^
arch/s390/include/asm/percpu.h:91:34: note: in expansion of macro
'arch_this_cpu_add'
91 | #define this_cpu_add_8(pcp, val) arch_this_cpu_add(pcp, val, "laag",
"agsi", long)
| ^
include/linux/percpu-defs.h:380:11: note: in expansion of macro
'this_cpu_add_8'
380 | case 8: stem##8(variable, __VA_ARGS__);break; \
| ^~~~
include/linux/percpu-defs.h:509:33: note: in expansion of macro
'__pcpu_size_call'
509 | #define
Re: [PATCH net-next 1/2] net: mvneta: Remove per-cpu queue mapping for Armada 3700
> According to Errata #23 "The per-CPU GbE interrupt is limited to Core
> 0", we can't use the per-cpu interrupt mechanism on the Armada 3700
> familly.
>
> This is correctly checked for RSS configuration, but the initial queue
> mapping is still done by having the queues spread across all the CPUs in
> the system, both in the init path and in the cpu_hotplug path.
Hello Maxime!
This patch looks like a bug fix for Armada 3700 SoC. What about marking
this commit with Fixes line? E.g.:
Fixes: 2636ac3cc2b4 ("net: mvneta: Add network support for Armada 3700 SoC")
Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface
On Sun, Feb 14, 2021 at 03:14:56PM -0800, Ben Widawsky wrote:
> On 21-02-14 16:30:09, Al Viro wrote:
> > On Tue, Feb 09, 2021 at 04:02:55PM -0800, Ben Widawsky wrote:
> >
> > > +static int handle_mailbox_cmd_from_user(struct cxl_memdev *cxlmd,
> > > + const struct cxl_mem_command *cmd,
> > > + u64 in_payload, u64 out_payload,
> > > + struct cxl_send_command __user *s)
> > > +{
> > > + struct cxl_mem *cxlm = cxlmd->cxlm;
> > > + struct device *dev = >dev;
> > > + struct mbox_cmd mbox_cmd = {
> > > + .opcode = cmd->opcode,
> > > + .size_in = cmd->info.size_in,
> > > + };
> > > + s32 user_size_out;
> > > + int rc;
> > > +
> > > + if (get_user(user_size_out, >out.size))
> > > + return -EFAULT;
> >
> > You have already copied it in. Never reread stuff from userland - it *can*
> > change under you.
>
> As it turns out, this is some leftover logic which doesn't need to exist at
> all,
> and I'm happy to change it. Thanks for reviewing.
>
> I wasn't familiar with this restriction though. For my edification could you
> explain how that could happen? Also, is this something that should go in the
> kdocs, because I don't see anything about this restriction there.
Er... You do realize that if two processes share memory, one can bloody well
modify it while another is in the middle of syscall, right? Always could -
even mmap(2) with MAP_SHARED is sufficient, same as shmat(2), or the wholesale
sharing between POSIX threads, etc.
And even on UP with no preemption you could bloody well have a structure that
spans a page boundary, with the next page being mmapped and currently not
present in memory. Then copy_from_user() would've copied the beginning, hit
a page fault, try to read the next page from something slow and lose CPU.
Letting the second process run and modify the already copied part.
It has been possible since at least mid-80s, well before Linux. Anything in
user memory can change under you, right in the middle of syscall. Always
could. And there had been very real bugs along the lines of data being
read twice, once for safety check, once for actual work. Something like
get_user(len, _object->len);
check that len is reasonable
p = kmalloc(offsetof(struct foo, string[len]), GFP_KERNEL);
copy_from_user(p, user_object, len);
work with the copy, assuming that first p->len bytes of p->string[]
are safe to use, find out that p->len is much greater than len since
the userland data has changed between two fetches
Some of those had been exploitable from the very beginning, some had become
such on innocious-looking changes.
For the sake of your sanity it's better to avoid such landmines. In some
cases it's OK to read the data twice (e.g. in something like select(2)), but
those cases are rare and seeing something of that sort is generally a big
red flag on review. In almost all cases it's best avoided.
[PATCH v1] atm: idt77252: fix build broken on amd64
idt77252 is broken and wont load on amd64 systems
modprobe idt77252 shows the following
idt77252_init: skb->cb is too small (48 < 56)
Add packed attribute to struct idt77252_skb_prv and struct atm_skb_data
so that the total size can be <= sizeof(skb->cb)
Also convert runtime size check to buildtime size check in
idt77252_init()
Signed-off-by: Tong Zhang
---
drivers/atm/idt77252.c | 11 +--
drivers/atm/idt77252.h | 2 +-
include/linux/atmdev.h | 2 +-
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
index 5f0472c18bcb..0c13cac903de 100644
--- a/drivers/atm/idt77252.c
+++ b/drivers/atm/idt77252.c
@@ -3743,16 +3743,7 @@ static int __init idt77252_init(void)
struct sk_buff *skb;
printk("%s: at %p\n", __func__, idt77252_init);
-
- if (sizeof(skb->cb) < sizeof(struct atm_skb_data) +
- sizeof(struct idt77252_skb_prv)) {
- printk(KERN_ERR "%s: skb->cb is too small (%lu < %lu)\n",
- __func__, (unsigned long) sizeof(skb->cb),
- (unsigned long) sizeof(struct atm_skb_data) +
- sizeof(struct idt77252_skb_prv));
- return -EIO;
- }
-
+ BUILD_BUG_ON(sizeof(skb->cb) < sizeof(struct idt77252_skb_prv) +
sizeof(struct atm_skb_data));
return pci_register_driver(_driver);
}
diff --git a/drivers/atm/idt77252.h b/drivers/atm/idt77252.h
index 9339197d701c..b059d31364dd 100644
--- a/drivers/atm/idt77252.h
+++ b/drivers/atm/idt77252.h
@@ -789,7 +789,7 @@ struct idt77252_skb_prv {
struct scqe tbd;/* Transmit Buffer Descriptor */
dma_addr_t paddr; /* DMA handle */
u32 pool; /* sb_pool handle */
-};
+} __packed;
#define IDT77252_PRV_TBD(skb) \
(((struct idt77252_skb_prv *)(ATM_SKB(skb)+1))->tbd)
diff --git a/include/linux/atmdev.h b/include/linux/atmdev.h
index d7493016cd46..60cd25c0461b 100644
--- a/include/linux/atmdev.h
+++ b/include/linux/atmdev.h
@@ -207,7 +207,7 @@ struct atm_skb_data {
struct atm_vcc *vcc; /* ATM VCC */
unsigned long atm_options;/* ATM layer options */
unsigned intacct_truesize; /* truesize accounted to vcc */
-};
+} __packed;
#define VCC_HTABLE_SIZE 32
--
2.25.1
Re: linux-next: manual merge of the xfs tree with the pidfd tree
On Mon, Feb 15, 2021 at 09:41:31AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 8 Feb 2021 10:33:48 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the xfs tree got a conflict in:
> >
> > fs/xfs/xfs_ioctl.c
> >
> > between commit:
> >
> > f736d93d76d3 ("xfs: support idmapped mounts")
> >
> > from the pidfd tree and commit:
> >
> > 7317a03df703 ("xfs: refactor inode ownership change
> > transaction/inode/quota allocation idiom")
> >
> > from the xfs tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
Oops, sorry, this email fell off my radar. Your fixup looks good to me;
thanks for the reminder.
--D
> >
> > diff --cc fs/xfs/xfs_ioctl.c
> > index 3d4c7ca080fb,248083ea0276..
> > --- a/fs/xfs/xfs_ioctl.c
> > +++ b/fs/xfs/xfs_ioctl.c
> > @@@ -1280,9 -1275,9 +1280,10 @@@ xfs_ioctl_setattr_prepare_dax
> >*/
> > static struct xfs_trans *
> > xfs_ioctl_setattr_get_trans(
> > - struct file *file)
> > - struct xfs_inode*ip,
> > ++ struct file *file,
> > + struct xfs_dquot*pdqp)
> > {
> > + struct xfs_inode*ip = XFS_I(file_inode(file));
> > struct xfs_mount*mp = ip->i_mount;
> > struct xfs_trans*tp;
> > int error = -EROFS;
> > @@@ -1470,9 -1461,9 +1469,9 @@@ xfs_ioctl_setattr
> >
> > xfs_ioctl_setattr_prepare_dax(ip, fa);
> >
> > - tp = xfs_ioctl_setattr_get_trans(file);
> > - tp = xfs_ioctl_setattr_get_trans(ip, pdqp);
> > ++ tp = xfs_ioctl_setattr_get_trans(file, pdqp);
> > if (IS_ERR(tp)) {
> > - code = PTR_ERR(tp);
> > + error = PTR_ERR(tp);
> > goto error_free_dquots;
> > }
> >
> > @@@ -1615,7 -1599,7 +1606,7 @@@ xfs_ioc_setxflags
> >
> > xfs_ioctl_setattr_prepare_dax(ip, );
> >
> > - tp = xfs_ioctl_setattr_get_trans(filp);
> > - tp = xfs_ioctl_setattr_get_trans(ip, NULL);
> > ++ tp = xfs_ioctl_setattr_get_trans(filp, NULL);
> > if (IS_ERR(tp)) {
> > error = PTR_ERR(tp);
> > goto out_drop_write;
>
> With the merge window about to open, this is a reminder that this
> conflict still exists.
>
> --
> Cheers,
> Stephen Rothwell
[PATCH v2 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge
Lontium Lt8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
MAINTAINERS | 1 +
drivers/gpu/drm/bridge/Kconfig | 14 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/lontium-lt8912.c | 719
4 files changed, 735 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f010b485aa7c..8b3d64b689c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10444,6 +10444,7 @@ LONTIUM LT8912 MIPI TO HDMI BRIDGE
M: Adrien Grassein
S: Maintained
F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
+F: drivers/gpu/drm/bridge/lontium-lt8912.c
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e4110d6ca7b3..5b36d4b86e3c 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -48,6 +48,20 @@ config DRM_DISPLAY_CONNECTOR
on ARM-based platforms. Saying Y here when this driver is not needed
will not cause any issue.
+config DRM_LONTIUM_LT8912
+ tristate "Lontium LT8912 DSI/HDMI bridge"
+ depends on OF
+ select DRM_PANEL_BRIDGE
+ select DRM_KMS_HELPER
+ select REGMAP_I2C
+ help
+ Driver for Lontium LT8912 DSI to HDMI bridge
+ chip driver.
+ Please say Y if you have such hardware.
+
+ Say M here if you want to support this hardware as a module.
+ The module will be named "lontium-lt8912".
+
config DRM_LONTIUM_LT9611
tristate "Lontium LT9611 DSI/HDMI bridge"
select SND_SOC_HDMI_CODEC if SND_SOC
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 86e7acc76f8d..5a1b201cea1f 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
+obj-$(CONFIG_DRM_LONTIUM_LT8912) += lontium-lt8912.o
obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
obj-$(CONFIG_DRM_LONTIUM_LT9611UXC) += lontium-lt9611uxc.o
obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912.c
b/drivers/gpu/drm/bridge/lontium-lt8912.c
new file mode 100644
index ..d713d3365c3e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/lontium-lt8912.c
@@ -0,0 +1,719 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+#define I2C_MAIN 0
+#define I2C_ADDR_MAIN 0x48
+
+#define I2C_CEC_DSI 1
+#define I2C_ADDR_CEC_DSI 0x49
+
+#define I2C_MAX_IDX 2
+
+#define HPD_WORK_DELAY_MS 1000
+
+struct lt8912 {
+ struct device *dev;
+ struct drm_bridge bridge;
+ struct drm_connector connector;
+
+ struct i2c_client *i2c_client[I2C_MAX_IDX];
+ struct regmap *regmap[I2C_MAX_IDX];
+
+ struct device_node *host_node;
+ struct drm_bridge *hdmi_port;
+
+ struct mipi_dsi_device *dsi;
+
+ struct gpio_desc *gp_reset;
+
+ struct videomode mode;
+
+ u8 data_lanes;
+ bool is_power_on;
+ bool is_attached;
+};
+
+static int lt8912_write_init_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ /* Digital clock en*/
+ {0x08, 0xff},
+ {0x09, 0xff},
+ {0x0a, 0xff},
+ {0x0b, 0x7c},
+ {0x0c, 0xff},
+ {0x42, 0x04},
+
+ /*Tx Analog*/
+ {0x31, 0xb1},
+ {0x32, 0xb1},
+ {0x33, 0x0e},
+ {0x37, 0x00},
+ {0x38, 0x22},
+ {0x60, 0x82},
+
+ /*Cbus Analog*/
+ {0x39, 0x45},
+ {0x3a, 0x00},
+ {0x3b, 0x00},
+
+ /*HDMI Pll Analog*/
+ {0x44, 0x31},
+ {0x55, 0x44},
+ {0x57, 0x01},
+ {0x5a, 0x02},
+
+ /*MIPI Analog*/
+ {0x3e, 0xd6},
+ {0x3f, 0xd4},
+ {0x41, 0x3c},
+ {0xB2, 0x00},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_MAIN], seq,
ARRAY_SIZE(seq));
+}
+
+static int lt8912_write_mipi_basic_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+ {0x12, 0x04},
+ {0x14, 0x00},
+ {0x15, 0x00},
+ {0x1a, 0x03},
+ {0x1b, 0x03},
+ };
+
+ return regmap_multi_reg_write(lt->regmap[I2C_CEC_DSI], seq,
ARRAY_SIZE(seq));
+};
+
+static int lt8912_write_dds_config(struct lt8912 *lt)
+{
+ const struct reg_sequence seq[] = {
+
[PATCH v2 1/2] dt-bindings: display: bridge: Add documentation for LT8912
Lontium LT8912 is a DSI to HDMI bridge.
Signed-off-by: Adrien Grassein
---
.../display/bridge/lontium,lt8912.yaml| 102 ++
MAINTAINERS | 5 +
2 files changed, 107 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
new file mode 100644
index ..1e5a2ad5eb47
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
@@ -0,0 +1,102 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/lontium,lt8912.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lontium LT8912 MIPI to HDMI Bridge
+
+maintainers:
+ - Adrien Grassein
+
+description: |
+ The LT8912 is a bridge device which convert DSI to HDMI
+
+properties:
+ compatible:
+enum:
+ - lontium,lt8912
+
+ reg:
+maxItems: 1
+
+ reset-gpios:
+maxItems: 1
+description: GPIO connected to active high RESET pin.
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Primary MIPI port for MIPI input
+
+properties:
+ endpoint:
+$ref: /schemas/media/video-interfaces.yaml#
+unevaluatedProperties: false
+
+properties:
+ data-lanes: true
+
+required:
+ - data-lanes
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description: |
+ HDMI port, should be connected to a node compatible with the
+ hdmi-connector binding.
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+
+i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi-bridge@48 {
+compatible = "lontium,lt8912";
+reg = <0x48>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+
+ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+reg = <0>;
+
+hdmi_out_in: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <_dsi_out>;
+};
+ };
+
+ port@1 {
+ reg = <1>;
+
+ endpoint {
+ remote-endpoint = <_in>;
+ };
+ };
+};
+ };
+};
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c38651ca59a5..f010b485aa7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10440,6 +10440,11 @@ S: Maintained
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git
F: drivers/hid/hid-lg-g15.c
+LONTIUM LT8912 MIPI TO HDMI BRIDGE
+M: Adrien Grassein
+S: Maintained
+F: Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml
+
LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
M: Sathya Prakash
M: Sreekanth Reddy
--
2.25.1
[PATCH v2 0/2] Add support of Lontium lt8912 MIPI to HDMI bridge
Hello, this patch set adds the support of the Lontium lt8912 MIPI to HDMI bridge in the kernel. It's only support the video part, not the audio part yet since I don't have the datasheet of this component. I get the current i2c configuration from Digi and Boundary drivers. Developed using the DB_DSIHD board from BoundaryDevices. Update in v2 - Use standard data-lanes instead of a custom prop; - Use hdmi-connector node. Thanks, Adrien Grassein Adrien Grassein (2): dt-bindings: display: bridge: Add documentation for LT8912 drm/bridge: Introduce LT8912 DSI to HDMI bridge .../display/bridge/lontium,lt8912.yaml| 102 +++ MAINTAINERS | 6 + drivers/gpu/drm/bridge/Kconfig| 14 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/lontium-lt8912.c | 719 ++ 5 files changed, 842 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/lontium,lt8912.yaml create mode 100644 drivers/gpu/drm/bridge/lontium-lt8912.c -- 2.25.1
Re: [PATCH v1] clang_tools:gen_compile_commands: Change the default source directory
On Sun, Feb 14, 2021 at 07:49:22PM +0800, Stephen Zhang wrote: > Masahiro Yamada 于2021年2月13日周六 下午8:46写道： > > This is the steps I tested. > > > > > > masahiro@oscar:~/ref/linux$ make O=build defconfig all -j24 > > [ snip ] > > masahiro@oscar:~/ref/linux$ > > ./scripts/clang-tools/gen_compile_commands.py -d build > > masahiro@oscar:~/ref/linux$ grep '"file":' compile_commands.json | > > grep scripts/ | head -n5 > > "file": "/home/masahiro/ref/linux/scripts/mod/empty.c" > > "file": "/home/masahiro/ref/linux/scripts/mod/sumversion.c" > > "file": "/home/masahiro/ref/linux/scripts/mod/file2alias.c" > > "file": "/home/masahiro/ref/linux/scripts/mod/modpost.c" > > "file": "/home/masahiro/ref/linux/build/scripts/kconfig/parser.tab.c" > > > > -- > > Best Regards > > Masahiro Yamada > > Thanks. Nathan had a detailed description about this: > > > $ make O=build > > > > will work with '-d .' because the .cmd files are in '.' and the source > > files will be placed relative to '.', which is correct. Your command > > does not work for two reasons: > > > > 1. You are using a build directory that is not a subpath of the source > > directory. In other words, this script would not work for > > > > $ make O=/tmp/build > > > > because '-d /tmp/build' needs to be used to find the .cmd files but then > > the relative path of the source files is messed up, as you point out. > > This may help you reproduce the problem. So you shoud try: > > >masahiro@oscar:~/ref/linux$ make O=/tmp/build defconfig all -j24 > > where the build directory is not a subpath of the source directory. > This will actually work for the regular build system as it uses the full path to the files when O= is outside of the source tree. My comment applies only to the tools/ build system, which Masahiro has explicitly said he does not want this script to support. Cheers, Nathan
Re: [PATCH 1/3] ASoC: simple-card-utils: Fix device module clock
Hi Sameer > > /* > > * Parse dai->sysclk come from "clocks = <>" > > * (if system has common clock) > > * or "system-clock-frequency = " > > * or device's module clock. > > */ > > Yes, this can be rephrased now. Thanks. It is not a big-deal. no streass :) > > And also, this patch has too many unneeded exchange, > > thus it was difficult to read for me. > > I think it can be simply like this ? > > It is understandable what it want to do. > > I think the patch does exactly the same thing as what you are > suggesting below. Am I missing anything? Yes, it is 100% same, but is simple patch. I wanted to tell was it is easy to read/understand. Your patch is already applied, so nothing we can do now ;) Thank you for your help !! Best regards --- Kuninori Morimoto
Re: [PATCH v2 4/8] cxl/mem: Add basic IOCTL interface
On 21-02-14 16:30:09, Al Viro wrote:
> On Tue, Feb 09, 2021 at 04:02:55PM -0800, Ben Widawsky wrote:
>
> > +static int handle_mailbox_cmd_from_user(struct cxl_memdev *cxlmd,
> > + const struct cxl_mem_command *cmd,
> > + u64 in_payload, u64 out_payload,
> > + struct cxl_send_command __user *s)
> > +{
> > + struct cxl_mem *cxlm = cxlmd->cxlm;
> > + struct device *dev = >dev;
> > + struct mbox_cmd mbox_cmd = {
> > + .opcode = cmd->opcode,
> > + .size_in = cmd->info.size_in,
> > + };
> > + s32 user_size_out;
> > + int rc;
> > +
> > + if (get_user(user_size_out, >out.size))
> > + return -EFAULT;
>
> You have already copied it in. Never reread stuff from userland - it *can*
> change under you.
As it turns out, this is some leftover logic which doesn't need to exist at all,
and I'm happy to change it. Thanks for reviewing.
I wasn't familiar with this restriction though. For my edification could you
explain how that could happen? Also, is this something that should go in the
kdocs, because I don't see anything about this restriction there.
Thanks.
Ben
Re: [PATCH 0/6] Add generated flag to filesystem struct to block copy_file_range
On Fri, Feb 12, 2021 at 12:43:59PM +0800, Nicolas Boichat wrote: > We hit an issue when upgrading Go compiler from 1.13 to 1.15 [1], > as we use Go's `io.Copy` to copy the content of > `/sys/kernel/debug/tracing/trace` to a temporary file. > > Under the hood, Go 1.15 uses `copy_file_range` syscall to > optimize the copy operation. However, that fails to copy any > content when the input file is from tracefs, with an apparent > size of 0 (but there is still content when you `cat` it, of > course). > > >From discussions in [2][3], it is clear that copy_file_range > cannot be properly implemented on filesystems where the content > is generated at runtime: the file size is incorrect (because it > is unknown before the content is generated), and seeking in such > files (as required by partial writes) is unlikely to work > correctly. > > With this patch, Go's `io.Copy` gracefully falls back to a normal > read/write file copy. > > I'm not 100% sure which stable tree this should go in, I'd say > at least >=5.3 since this is what introduced support for > cross-filesystem copy_file_range (and where most users are > somewhat likely to hit this issue). But let's discuss the patch > series first. No. This is *NOT* an fs-wide flag. Decision regarding the usability of copy_file_range() is on per-file basis. The real constraint is "can freely seek back and expect to find consistent data". That is what's violated for seq_file. And frankly, I would rather add a flag and have seq_open() (and other suckers, if any) clear it. With check being "has both FMODE_PREAD and this new flag".
drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn20.c:326:8: warning: missing braces around initializer
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 358feceebbf68f33c44c6650d14455389e65282d
commit: 5fe6b98ae00dc2e0ac24ef8a45d828b82a4aae90 drm/amd/display: Update dmub
code
date: 3 months ago
config: i386-randconfig-a014-20200624 (attached as .config)
compiler: gcc-4.9 (Ubuntu 4.9.3-13ubuntu2) 4.9.3
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fe6b98ae00dc2e0ac24ef8a45d828b82a4aae90
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 5fe6b98ae00dc2e0ac24ef8a45d828b82a4aae90
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn20.c: In function
'dmub_dcn20_enable_dmub_boot_options':
>> drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn20.c:326:8: warning:
>> missing braces around initializer [-Wmissing-braces]
union dmub_fw_boot_options boot_options = {0};
^
drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn20.c:326:8: warning:
(near initialization for 'boot_options.bits') [-Wmissing-braces]
vim +326 drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn20.c
323
324 void dmub_dcn20_enable_dmub_boot_options(struct dmub_srv *dmub)
325 {
> 326 union dmub_fw_boot_options boot_options = {0};
327
328 REG_WRITE(DMCUB_SCRATCH14, boot_options.all);
329 }
330
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: linux-next: manual merge of the bpf-next tree with the net-next tree
Hi Arjun, On Sun, 14 Feb 2021 13:40:38 -0800 Arjun Roy wrote: > > Sorry, I was confused from the prior email. Is any action required at > the moment, or not? No. This is just something that the net-next and bpf-next maintainers need to sort out when they merge their trees. -- Cheers, Stephen Rothwell pgpmmMKJfzw_y.pgp Description: OpenPGP digital signature
Re: arch/alpha/lib/csum_partial_copy.c:328:1: error: no previous prototype for 'csum_and_copy_from_user'
On Thu, Feb 11, 2021 at 06:52:36PM -0800, Randy Dunlap wrote: > >>> arch/alpha/lib/csum_partial_copy.c:328:1: error: no previous prototype > >>> for 'csum_and_copy_from_user' [-Werror=missing-prototypes] > > 328 | csum_and_copy_from_user(const void __user *src, void *dst, int > > len, > > | ^~~ > >arch/alpha/lib/csum_partial_copy.c:375:1: error: no previous prototype > > for 'csum_partial_copy_nocheck' [-Werror=missing-prototypes] > > 375 | csum_partial_copy_nocheck(const void *src, void *dst, int len, > > __wsum sum) > > | ^ > >cc1: all warnings being treated as errors > > I can't reproduce this (wrong version of gcc) but it looks like adding > #include > to arch/alpha/lib/csum_partial_copy.c should fix the warnings. I'd rather go with net/checksum.h; converting all includes outside of net/checksum.h itself would have to wait, but let's not breed more of those without a good reason...
Linux 5.11
Nothing unexpected or particularly scary happened this week, so here we are - with 5.11 tagged and pushed out. In fact, it's a smaller-than-average set of commits from rc7 to final, which makes me happy. And I already have several pull requests lined up for tomorrow, so we're all set for the merge window to start. But in the meantime - and yes, I know it's Valentine's Day here in the US - maybe give this release a good testing before you go back and play with development kernels. All right? Because I'm sure your SO will understand. Linus --- Alain Volmat (1): i2c: stm32f7: fix configuration of the digital filter Alex Deucher (1): Revert "drm/amd/display: Update NV1x SR latency values" Alex Elder (1): net: ipa: set error code in gsi_channel_setup() Alexei Starovoitov (1): bpf: Unbreak BPF_PROG_TYPE_KPROBE when kprobe is called via do_int3 Andrea Parri (Microsoft) (1): hv_netvsc: Reset the RSC count if NVSP_STAT_FAIL in netvsc_receive() Andrey Konovalov (4): kasan: fix stack traces dependency for HW_TAGS MAINTAINERS: update KASAN file list MAINTAINERS: update Andrey Konovalov's email address MAINTAINERS: add Andrey Konovalov to KASAN reviewers Andrey Ryabinin (1): MAINTAINERS: update Andrey Ryabinin's email address Aneesh Kumar K.V (1): powerpc/kuap: Allow kernel thread to access userspace after kthread_use_mm Ard Biesheuvel (1): Revert "ACPICA: Interpreter: fix memory leak by using existing buffer" Arnd Bergmann (3): ath9k: fix build error with LEDS_CLASS=m mm/mremap: fix BUILD_BUG_ON() error in get_extent leds: rt8515: add V4L2_FLASH_LED_CLASS dependency Borislav Petkov (1): x86/build: Disable CET instrumentation in the kernel for 32-bit too Bui Quang Minh (1): bpf: Check for integer overflow when using roundup_pow_of_two() Camelia Groza (3): dpaa_eth: reserve space for the xdp_frame under the A050385 erratum dpaa_eth: reduce data alignment requirements for the A050385 erratum dpaa_eth: try to move the data in place for the A050385 erratum Catalin Marinas (1): arm64: mte: Allow PTRACE_PEEKMTETAGS access to the zero page Cezary Rojewski (1): dmaengine dw: Revert "dmaengine: dw: Enable runtime PM" Chen Zhou (1): cgroup-v1: add disabled controller check in cgroup1_parse_param() Christian König (1): drm/ttm: make sure pool pages are cleared Christoph Schemmel (1): NET: usb: qmi_wwan: Adding support for Cinterion MV31 Christophe JAILLET (1): dmaengine: ti: k3-udma: Fix a resource leak in an error handling path Daniel Borkmann (3): bpf: Fix verifier jsgt branch analysis on max bound bpf: Fix verifier jmp32 pruning decision logic bpf: Fix 32 bit src register truncation on div/mod Dave Jiang (4): dmaengine: idxd: Fix list corruption in description completion dmaengine: idxd: fix misc interrupt completion dmaengine: move channel device_node deletion to driver dmaengine: idxd: check device state before issue command David Howells (1): rxrpc: Fix clearance of Tx/Rx ring when releasing a call Edwin Peer (1): net: watchdog: hold device global xmit lock during tx disable Eric Dumazet (1): net: gro: do not keep too many GRO packets in napi->rx_list Fabian Frederick (1): selftests: netfilter: fix current year Fangrui Song (1): firmware_loader: align .builtin_fw to 8 Florian Westphal (1): netfilter: conntrack: skip identical origin tuple in same zone only Geert Uytterhoeven (1): gpio: mxs: GPIO_MXS should not default to y unconditionally Horatiu Vultur (2): bridge: mrp: Fix the usage of br_mrp_port_switchdev_set_state switchdev: mrp: Remove SWITCHDEV_ATTR_ID_MRP_PORT_STAT Imre Deak (2): drm/dp_mst: Don't report ports connected if nothing is attached to them drm/i915/tgl+: Make sure TypeC FIA is powered up when initializing it Jarkko Sakkinen (1): x86/sgx: Maintain encl->refcount for each encl->mm_list entry Jens Axboe (1): Revert "io_uring: don't take fs for recvmsg/sendmsg" Jernej Skrabec (5): drm/sun4i: tcon: set sync polarity for tcon1 channel drm/sun4i: dw-hdmi: always set clock rate drm/sun4i: Fix H6 HDMI PHY configuration drm/sun4i: dw-hdmi: Fix max. frequency for H6 clk: sunxi-ng: mp: fix parent rate change flag check Joachim Henke (1): nilfs2: make splice write available again Johannes Weiner (1): Revert "mm: memcontrol: avoid workload stalls when lowering memory.high" Jozsef Kadlecsik (1): netfilter: xt_recent: Fix attempt to update deleted entry Juergen Gross (1): xen/netback: avoid race in xenvif_rx_ring_slots_available() Julien Grall (1): arm/xen: Don't probe xenbus as part of an early initcall Linus Torvalds (1): Linux 5.11 Lorenzo Bianconi (1): mt76: dma: fix a possible memory leak in mt76_add_fragment()
Re: linux-next: build warning after merge of the v4l-dvb tree
Hi all,
On Mon, 8 Feb 2021 23:37:16 +1100 Stephen Rothwell
wrote:
>
> After merging the v4l-dvb tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/media/v4l2-async.h:178: warning: expecting prototype for
> v4l2_async_notifier_add_fwnode_subdev(). Prototype was for
> __v4l2_async_notifier_add_fwnode_subdev() instead
> include/media/v4l2-async.h:207: warning: expecting prototype for
> v4l2_async_notifier_add_fwnode_remote_subdev(). Prototype was for
> __v4l2_async_notifier_add_fwnode_remote_subdev() instead
> include/media/v4l2-async.h:230: warning: expecting prototype for
> v4l2_async_notifier_add_i2c_subdev(). Prototype was for
> __v4l2_async_notifier_add_i2c_subdev() instead
>
> Maybe introduced by commit
>
> c1cc23625062 ("media: v4l2-async: Discourage use of
> v4l2_async_notifier_add_subdev")
With the merge window about to open, this is a reminder that these
warnings still exist.
--
Cheers,
Stephen Rothwell
pgpLLQxXaUEDK.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the xfs tree with the pidfd tree
Hi all,
On Mon, 8 Feb 2021 10:33:48 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the xfs tree got a conflict in:
>
> fs/xfs/xfs_ioctl.c
>
> between commit:
>
> f736d93d76d3 ("xfs: support idmapped mounts")
>
> from the pidfd tree and commit:
>
> 7317a03df703 ("xfs: refactor inode ownership change transaction/inode/quota
> allocation idiom")
>
> from the xfs tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc fs/xfs/xfs_ioctl.c
> index 3d4c7ca080fb,248083ea0276..
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@@ -1280,9 -1275,9 +1280,10 @@@ xfs_ioctl_setattr_prepare_dax
>*/
> static struct xfs_trans *
> xfs_ioctl_setattr_get_trans(
> - struct file *file)
> -struct xfs_inode*ip,
> ++struct file *file,
> + struct xfs_dquot*pdqp)
> {
> +struct xfs_inode*ip = XFS_I(file_inode(file));
> struct xfs_mount*mp = ip->i_mount;
> struct xfs_trans*tp;
> int error = -EROFS;
> @@@ -1470,9 -1461,9 +1469,9 @@@ xfs_ioctl_setattr
>
> xfs_ioctl_setattr_prepare_dax(ip, fa);
>
> - tp = xfs_ioctl_setattr_get_trans(file);
> -tp = xfs_ioctl_setattr_get_trans(ip, pdqp);
> ++tp = xfs_ioctl_setattr_get_trans(file, pdqp);
> if (IS_ERR(tp)) {
> - code = PTR_ERR(tp);
> + error = PTR_ERR(tp);
> goto error_free_dquots;
> }
>
> @@@ -1615,7 -1599,7 +1606,7 @@@ xfs_ioc_setxflags
>
> xfs_ioctl_setattr_prepare_dax(ip, );
>
> - tp = xfs_ioctl_setattr_get_trans(filp);
> -tp = xfs_ioctl_setattr_get_trans(ip, NULL);
> ++tp = xfs_ioctl_setattr_get_trans(filp, NULL);
> if (IS_ERR(tp)) {
> error = PTR_ERR(tp);
> goto out_drop_write;
With the merge window about to open, this is a reminder that this
conflict still exists.
--
Cheers,
Stephen Rothwell
pgpPtXeE5dvkI.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the drivers-x86 tree with the drm-misc tree
Hi all,
On Thu, 4 Feb 2021 15:58:46 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> drivers/gpu/drm/gma500/Kconfig
> drivers/gpu/drm/gma500/mdfld_device.c
> drivers/gpu/drm/gma500/mdfld_dsi_output.c
> drivers/gpu/drm/gma500/mdfld_output.c
> drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c
>
> between commits:
>
> b51035c200bd ("drm/gma500: Remove Medfield support")
Now
e1da811218d2 ("drm/gma500: Remove Medfield support")
> 837f23bb4b60 ("drm/gma500: Drop DRM_GMA3600 config option")
Now
26499e0518a7 ("drm/gma500: Drop DRM_GMA3600 config option")
>
> from the drm-misc tree and commit:
>
> bfc838f8598e ("drm/gma500: Convert to use new SCU IPC API")
> 25ded39ad064 ("drm/gma500: Get rid of duplicate NULL checks")
>
> from the drivers-x86 tree.
>
> I fixed it up (the former removed the text that was updated by the
> latter and removed the last 4 files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
With the merge window about to open, this is a reminder that this
conflict still exists.
The two drivers-x86 tree commits have also been merged into the pm tree.
--
Cheers,
Stephen Rothwell
pgpDGtV7YejEI.pgp
Description: OpenPGP digital signature
Re: [PATCH] lkdtm: don't move ctors to .rodata
On Sun, Feb 14, 2021 at 06:16:29PM +0100, Greg Kroah-Hartman wrote:
On Thu, Feb 11, 2021 at 10:53:10AM -0800, Stephen Boyd wrote:
Sorry for the confusion. Can commit 65538943 ("vmlinux.lds.h: Create
section for protection against instrumentation") and commit 3f618ab33234
("lkdtm: don't move ctors to .rodata") be backported to 5.4.y and only
commit 3f618ab3323407ee4c6a6734a37eb6e9663ebfb9 be backported to 5.10.y?
65538943 ("vmlinux.lds.h: Create section for protection against
instrumentation") does not apply cleanly to 5.4.y, so can you provide a
working backport for both of those patches to 5.4.y that you have
tested?
It was due to a backport of eff8728fe698 ("vmlinux.lds.h: Add PGO and
AutoFDO input sections"). Taking 65538943 and 3f618ab33234 converged
us back with Linus's tree as eff8728fe698 worked around not having those
in 5.4.
I've fixed it up and queued both of those patches.
--
Thanks,
Sasha
Re: [PATCH v5 13/19] remoteproc: Properly deal with the resource table (fwd)
There are identical kfrees on lines 2078 and 2080.
julia
-- Forwarded message --
Date: Fri, 12 Feb 2021 10:45:50 +0800
From: kernel test robot
To: kbu...@lists.01.org
Cc: l...@intel.com, Julia Lawall
Subject: Re: [PATCH v5 13/19] remoteproc: Properly deal with the resource table
CC: kbuild-...@lists.01.org
In-Reply-To: <20210211234627.2669674-14-mathieu.poir...@linaro.org>
References: <20210211234627.2669674-14-mathieu.poir...@linaro.org>
TO: Mathieu Poirier
TO: o...@wizery.com
TO: bjorn.anders...@linaro.org
TO: arnaud.pouliq...@st.com
CC: robh...@kernel.org
CC: mcoquelin.st...@gmail.com
CC: alexandre.tor...@st.com
CC: linux-remotep...@vger.kernel.org
CC: devicet...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
Hi Mathieu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on linus/master v5.11-rc7 next-20210211]
[cannot apply to remoteproc/for-next rpmsg/for-next]
[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/Mathieu-Poirier/remoteproc-Add-support-for-detaching-a-remote-processor/20210212-075607
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
:: branch date: 3 hours ago
:: commit date: 3 hours ago
config: openrisc-randconfig-c003-20210209 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Julia Lawall
"coccinelle warnings: (new ones prefixed by >>)"
>> drivers/remoteproc/remoteproc_core.c:2080:7-26: ERROR: reference preceded by
>> free on line 2078
vim +2080 drivers/remoteproc/remoteproc_core.c
400e64df6b237e Ohad Ben-Cohen 2011-10-20 2012
eab58da78fe46f Mathieu Poirier 2021-02-11 2013 /**
eab58da78fe46f Mathieu Poirier 2021-02-11 2014 * rproc_detach() - Detach the
remote processor from the
eab58da78fe46f Mathieu Poirier 2021-02-11 2015 * remoteproc core
eab58da78fe46f Mathieu Poirier 2021-02-11 2016 *
eab58da78fe46f Mathieu Poirier 2021-02-11 2017 * @rproc: the remote processor
eab58da78fe46f Mathieu Poirier 2021-02-11 2018 *
eab58da78fe46f Mathieu Poirier 2021-02-11 2019 * Detach a remote processor
(previously attached to with rproc_attach()).
eab58da78fe46f Mathieu Poirier 2021-02-11 2020 *
eab58da78fe46f Mathieu Poirier 2021-02-11 2021 * In case @rproc is still
being used by an additional user(s), then
eab58da78fe46f Mathieu Poirier 2021-02-11 2022 * this function will just
decrement the power refcount and exit,
eab58da78fe46f Mathieu Poirier 2021-02-11 2023 * without disconnecting the
device.
eab58da78fe46f Mathieu Poirier 2021-02-11 2024 *
eab58da78fe46f Mathieu Poirier 2021-02-11 2025 * Function rproc_detach()
calls __rproc_detach() in order to let a remote
eab58da78fe46f Mathieu Poirier 2021-02-11 2026 * processor know that
services provided by the application processor are
eab58da78fe46f Mathieu Poirier 2021-02-11 2027 * no longer available. From
there it should be possible to remove the
eab58da78fe46f Mathieu Poirier 2021-02-11 2028 * platform driver and even
power cycle the application processor (if the HW
eab58da78fe46f Mathieu Poirier 2021-02-11 2029 * supports it) without
needing to switch off the remote processor.
eab58da78fe46f Mathieu Poirier 2021-02-11 2030 */
eab58da78fe46f Mathieu Poirier 2021-02-11 2031 int rproc_detach(struct rproc
*rproc)
eab58da78fe46f Mathieu Poirier 2021-02-11 2032 {
eab58da78fe46f Mathieu Poirier 2021-02-11 2033 struct device *dev =
>dev;
eab58da78fe46f Mathieu Poirier 2021-02-11 2034 int ret;
eab58da78fe46f Mathieu Poirier 2021-02-11 2035
eab58da78fe46f Mathieu Poirier 2021-02-11 2036 ret =
mutex_lock_interruptible(>lock);
eab58da78fe46f Mathieu Poirier 2021-02-11 2037 if (ret) {
eab58da78fe46f Mathieu Poirier 2021-02-11 2038 dev_err(dev,
"can't lock rproc %s: %d\n", rproc->name, ret);
eab58da78fe46f Mathieu Poirier 2021-02-11 2039 return ret;
eab58da78fe46f Mathieu Poirier 2021-02-11 2040 }
eab58da78fe46f Mathieu Poirier 2021-02-11 2041
eab58da78fe46f Mathieu Poirier 2021-02-11 2042 if (rproc->state !=
RPROC_RUNNING && rproc->state != RPROC_ATTACHED) {
eab58da78fe46f Mathieu Poirier 2021-02-11 2043 ret = -EPERM;
eab58da78fe46f Mathieu Poirier 2021-02-11 2044 goto out;
eab58da78fe46f Mathieu Poirier 2021-02-11 2045 }
eab58da78fe46f Mathieu Poirier 2021-02-11 2046
eab58da78fe46f Mathieu Poirier 2021-02-11 2047 /* if the remote proc
is still needed, bail out */
eab58da78fe46f Mathieu Poirier 2021-02-11 2048 if
(!atomic_dec_and_test(>power)) {
eab58da78fe46f
Re: linux-next: manual merge of the devicetree tree with the kbuild tree
Hi all,
On Fri, 5 Feb 2021 14:45:40 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the devicetree tree got a conflict in:
>
> scripts/Makefile.lib
>
> between commit:
>
> d73a6a04c76a ("kbuild: use always-y instead of extra-y")
>
> from the kbuild tree and commit:
>
> ce88c9c79455 ("kbuild: Add support to build overlays (%.dtbo)")
>
> from the devicetree tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc scripts/Makefile.lib
> index 6f248ff91982,b00855b247e0..
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@@ -85,12 -81,14 +85,14 @@@ always-y += $(userprogs-always-y) $(use
>
> # DTB
> # If CONFIG_OF_ALL_DTBS is enabled, all DT blobs are built
> -extra-y += $(dtb-y)
> -extra-$(CONFIG_OF_ALL_DTBS) += $(dtb-)
> +always-y+= $(dtb-y)
> +always-$(CONFIG_OF_ALL_DTBS)+= $(dtb-)
>
> ifneq ($(CHECK_DTBS),)
> -extra-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
> -extra-y += $(patsubst %.dtbo,%.dt.yaml, $(dtb-y))
> -extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-))
> -extra-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtbo,%.dt.yaml, $(dtb-))
> +always-y += $(patsubst %.dtb,%.dt.yaml, $(dtb-y))
> ++always-y += $(patsubst %.dtbo,%.dt.yaml, $(dtb-y))
> +always-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtb,%.dt.yaml, $(dtb-))
> ++always-$(CONFIG_OF_ALL_DTBS) += $(patsubst %.dtbo,%.dt.yaml, $(dtb-))
> endif
>
> # Add subdir path
With the merge window about to open, this is a reminder that this
conflict still exists.
--
Cheers,
Stephen Rothwell
pgpYDMK33W5ro.pgp
Description: OpenPGP digital signature
Re: linux-next: build failure after merge of the block tree
Hi all,
On Tue, 2 Feb 2021 14:16:18 +1100 Stephen Rothwell
wrote:
>
> On Tue, 2 Feb 2021 13:57:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > block/bio.c: In function 'bio_add_zone_append_page':
> > block/bio.c:860:31: error: 'struct bio' has no member named 'bi_disk'
> > 860 | struct request_queue *q = bio->bi_disk->queue;
> > | ^~
> >
> > Caused by commit
> >
> > 309dca309fc3 ("block: store a block_device pointer in struct bio")
> >
> > interacting with commit
> >
> > 9f678097f3de ("block: add bio_add_zone_append_page")
Now
ae29333fa644 ("block: add bio_add_zone_append_page")
> >
> > from the btrfs tree.
> >
> > I applied the following merge fix up for today.
> >
> > From: Stephen Rothwell
> > Date: Tue, 2 Feb 2021 13:54:29 +1100
> > Subject: [PATCH] block: bio: fix up for bi_disk removal
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > block/bio.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/block/bio.c b/block/bio.c
> > index bf3ab1b5c844..e3b9d3e0a196 100644
> > --- a/block/bio.c
> > +++ b/block/bio.c
> > @@ -857,7 +857,7 @@ EXPORT_SYMBOL(bio_add_pc_page);
> > int bio_add_zone_append_page(struct bio *bio, struct page *page,
> > unsigned int len, unsigned int offset)
> > {
> > - struct request_queue *q = bio->bi_disk->queue;
> > + struct request_queue *q = bio->bi_bdev->bd_disk->queue;
> > bool same_page = false;
> >
> > if (WARN_ON_ONCE(bio_op(bio) != REQ_OP_ZONE_APPEND))
> > --
> > 2.29.2
>
> This then lead to the following in my x86_64 allmodconfig build:
>
> fs/btrfs/zoned.c: In function 'btrfs_record_physical_zoned':
> fs/btrfs/zoned.c:1286:21: error: 'struct bio' has no member named 'bi_disk'
> 1286 | ordered->disk = bio->bi_disk;
> | ^~
> fs/btrfs/zoned.c:1287:23: error: 'struct bio' has no member named 'bi_partno'
> 1287 | ordered->partno = bio->bi_partno;
> | ^~
>
> Do to the above block tree commit interacting with commit
>
> bccc13e5fe0c ("btrfs: use ZONE_APPEND write for ZONED btrfs")
Now
d8e3fb106f39 ("btrfs: zoned: use ZONE_APPEND write for zoned mode")
>
> from the btrfs tree.
>
> For which I applied the following merge fix patch:
>
> From: Stephen Rothwell
> Date: Tue, 2 Feb 2021 14:08:44 +1100
> Subject: [PATCH] block: btrfs: another fix up for bi_disk removal
>
> Signed-off-by: Stephen Rothwell
> ---
> fs/btrfs/zoned.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
> index 334a54be587d..4829ffc5275b 100644
> --- a/fs/btrfs/zoned.c
> +++ b/fs/btrfs/zoned.c
> @@ -1283,8 +1283,8 @@ void btrfs_record_physical_zoned(struct inode *inode,
> u64 file_offset,
> return;
>
> ordered->physical = physical;
> - ordered->disk = bio->bi_disk;
> - ordered->partno = bio->bi_partno;
> + ordered->disk = bio->bi_bdev->bd_disk;
> + ordered->partno = bio->bi_bdev->bd_partno;
>
> btrfs_put_ordered_extent(ordered);
> }
> --
> 2.29.2
With the merge window about to open, this is a reminder that this
conflict still exists.
I am still applying both these merge fix ups.
--
Cheers,
Stephen Rothwell
pgpbITJjgFGak.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the block tree with the btrfs tree
Hi all,
On Tue, 2 Feb 2021 13:45:59 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the block tree got a conflict in:
>
> fs/iomap/direct-io.c
>
> between commit:
>
> dffd1df2d29a ("iomap: support REQ_OP_ZONE_APPEND")
>
> from the btrfs tree and commit:
>
> 3e1a88ec9625 ("bio: add a helper calculating nr segments to alloc")
>
> from the block tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc fs/iomap/direct-io.c
> index e4c258a2cefc,ea1e8f696076..
> --- a/fs/iomap/direct-io.c
> +++ b/fs/iomap/direct-io.c
> @@@ -292,13 -260,7 +289,14 @@@ iomap_dio_bio_actor(struct inode *inode
> iomap_dio_zero(dio, iomap, pos - pad, pad);
> }
>
> +/*
> + * Set the operation flags early so that bio_iov_iter_get_pages
> + * can set up the page vector appropriately for a ZONE_APPEND
> + * operation.
> + */
> +bio_opf = iomap_dio_bio_opflags(dio, iomap, use_fua);
> +
> + nr_pages = bio_iov_vecs_to_alloc(dio->submit.iter, BIO_MAX_PAGES);
> do {
> size_t n;
> if (dio->error) {
With the merge window about to open, this is a reminder that this
conflict still exists.
The btrfs tree commit is now
c3b0e880bbfa ("iomap: support REQ_OP_ZONE_APPEND")
--
Cheers,
Stephen Rothwell
pgpiHfsZdgqAW.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
On Tue, 2 Feb 2021 09:01:35 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the arm-soc tree got a conflict in:
>
> arch/arm/Kconfig.debug
>
> between commits:
>
> 9ca4efec0aba ("ARM: 9040/1: use DEBUG_UART_PHYS and DEBUG_UART_VIRT for sti
> LL_UART")
> 6e959ad8bb90 ("ARM: 9041/1: sti LL_UART: add STiH418 SBC UART0 support")
>
> from the arm tree and commits:
>
> f3a732843acc ("ARM: remove sirf prima2/atlas platforms")
> 89d4f98ae90d ("ARM: remove zte zx platform")
>
> from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/arm/Kconfig.debug
> index 7a8697a97c98,c36c5d4c6e9c..
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@@ -1623,10 -1546,7 +1550,9 @@@ config DEBUG_LL_INCLUD
> default "debug/renesas-scif.S" if DEBUG_RMOBILE_SCIFA4
> default "debug/s3c24xx.S" if DEBUG_S3C24XX_UART || DEBUG_S3C64XX_UART
> default "debug/s5pv210.S" if DEBUG_S5PV210_UART
> - default "debug/sirf.S" if DEBUG_SIRFSOC_UART
> -default "debug/sti.S" if DEBUG_STI_UART
> +default "debug/sti.S" if DEBUG_STIH41X_ASC2
> +default "debug/sti.S" if DEBUG_STIH41X_SBC_ASC1
> +default "debug/sti.S" if DEBUG_STIH418_SBC_ASC0
> default "debug/stm32.S" if DEBUG_STM32_UART
> default "debug/tegra.S" if DEBUG_TEGRA_UART
> default "debug/ux500.S" if DEBUG_UX500_UART
> @@@ -1659,8 -1579,6 +1585,7 @@@ config DEBUG_UART_PHY
> default 0x02531000 if DEBUG_KEYSTONE_UART1
> default 0x03010fe0 if ARCH_RPC
> default 0x0700 if DEBUG_SUN9I_UART0
> - default 0x09405000 if DEBUG_ZTE_ZX
> +default 0x0953 if DEBUG_STIH418_SBC_ASC0
> default 0x10009000 if DEBUG_REALVIEW_STD_PORT || \
> DEBUG_VEXPRESS_UART0_CA9
> default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT
> @@@ -1789,10 -1698,8 +1707,10 @@@
> DEBUG_RMOBILE_SCIFA4 || DEBUG_S3C24XX_UART || \
> DEBUG_S3C64XX_UART || \
> DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
> - DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
> + DEBUG_DIGICOLOR_UA0 || \
> -DEBUG_AT91_UART || DEBUG_STM32_UART
> +DEBUG_AT91_UART || DEBUG_STM32_UART || \
> +DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
> +DEBUG_STIH418_SBC_ASC0
>
> config DEBUG_UART_VIRT
> hex "Virtual base address of debug UART"
> @@@ -1854,12 -1760,9 +1772,11 @@@
> default 0xfb02 if DEBUG_OMAP3UART3
> default 0xfb042000 if DEBUG_OMAP3UART4
> default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
> - default 0xfc705000 if DEBUG_ZTE_ZX
> default 0xfcfe8600 if DEBUG_BCM63XX_UART
> default 0xfd00 if DEBUG_SPEAR3XX || DEBUG_SPEAR13XX
> +default 0xfd531000 if DEBUG_STIH41X_SBC_ASC1
> default 0xfd883000 if DEBUG_ALPINE_UART0
> +default 0xfdd32000 if DEBUG_STIH41X_ASC2
> default 0xfe01 if STM32MP1_DEBUG_UART
> default 0xfe017000 if DEBUG_MMP_UART2
> default 0xfe018000 if DEBUG_MMP_UART3
> @@@ -1904,10 -1802,8 +1816,10 @@@
> DEBUG_QCOM_UARTDM || DEBUG_S3C24XX_UART || \
> DEBUG_S3C64XX_UART || \
> DEBUG_BCM63XX_UART || DEBUG_ASM9260_UART || \
> - DEBUG_SIRFSOC_UART || DEBUG_DIGICOLOR_UA0 || \
> + DEBUG_DIGICOLOR_UA0 || \
> -DEBUG_AT91_UART || DEBUG_STM32_UART
> +DEBUG_AT91_UART || DEBUG_STM32_UART || \
> +DEBUG_STIH41X_ASC2 || DEBUG_STIH41X_SBC_ASC1 || \
> +DEBUG_STIH418_SBC_ASC0
>
> config DEBUG_UART_8250_SHIFT
> int "Register offset shift for the 8250 debug UART"
With the merge window about to open, this is a reminder that this
conflict still exists.
--
Cheers,
Stephen Rothwell
pgpv8WzgVY9M7.pgp
Description: OpenPGP digital signature
[PATCH] ntfs: move check for valid resident attribute offset and length
we should check for valid resident atribute offset and length before
loading STANDARD_INFORMATION attribute in ntfs_read_locked_inode()
let's make that check a bit earlier in the same function to avoid
use-after-free bug
Reported-and-tested-by: syzbot+c584225dabdea2f71...@syzkaller.appspotmail.com
Signed-off-by: Rustam Kovhaev
Link: https://syzkaller.appspot.com/bug?extid=c584225dabdea2f71969
---
fs/ntfs/inode.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/fs/ntfs/inode.c b/fs/ntfs/inode.c
index f7e4cbc26eaf..70745aea5106 100644
--- a/fs/ntfs/inode.c
+++ b/fs/ntfs/inode.c
@@ -629,6 +629,13 @@ static int ntfs_read_locked_inode(struct inode *vi)
}
a = ctx->attr;
/* Get the standard information attribute value. */
+ if ((u8 *)a + le16_to_cpu(a->data.resident.value_offset)
+ + le32_to_cpu(
+ a->data.resident.value_length) >
+ (u8 *)ctx->mrec + vol->mft_record_size) {
+ ntfs_error(vi->i_sb, "Corrupt attribute list in inode.");
+ goto unm_err_out;
+ }
si = (STANDARD_INFORMATION*)((u8*)a +
le16_to_cpu(a->data.resident.value_offset));
@@ -731,14 +738,6 @@ static int ntfs_read_locked_inode(struct inode *vi)
goto unm_err_out;
}
} else /* if (!a->non_resident) */ {
- if ((u8*)a + le16_to_cpu(a->data.resident.value_offset)
- + le32_to_cpu(
- a->data.resident.value_length) >
- (u8*)ctx->mrec + vol->mft_record_size) {
- ntfs_error(vi->i_sb, "Corrupt attribute list "
- "in inode.");
- goto unm_err_out;
- }
/* Now copy the attribute list. */
memcpy(ni->attr_list, (u8*)a + le16_to_cpu(
a->data.resident.value_offset),
--
2.30.0
Re: Linux 5.8-rc6
On Mon, Aug 10, 2020 at 5:30 PM Geert Uytterhoeven wrote:
>
> Hi Sedat,
>
> On Tue, Jul 21, 2020 at 10:19 AM Sedat Dilek wrote:
> > You happen to know if I can configure in my ~/.gitconfig to pull
> > linux-git stuff from two repositories - check first git.kernel.org
> > then GitHub.
> >
> > Some days ago GitHub had some maintenance issues and I was not able to pull.
> > Means I trust more the security and integrity concept of git.kernel.org.
> >
> > To pull from GitHub - saved 15-16mins of my life-time - meant
> > 15-16mins go earlier to sleep - as said I started my build 01:02a.m.
> > (German local-time).
>
> Assumed your cloned from kernel.org:
>
> git remote add github https://github.com/torvalds/linux
>
> After that:
> 1. "git remote update" will fetch data from both origin and github,
> 2. "git merge $(git tag | grep -v rc | sort -n | tail -1)" will
> merge in the latest release, if you don't have it merged already.
>
Last week or so I really used your recommendation.
Thanks Geert.
- Sedat -
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Re: linux-next: manual merge of the irqchip tree with the sunxi tree
Hi all,
On Mon, 1 Feb 2021 14:42:59 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the irqchip tree got a conflict in:
>
>
> Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
>
> between commit:
>
> 752b0aac99c7 ("dt-bindings: irq: sun7i-nmi: Add binding documentation for
> the V3s NMI")
>
> from the sunxi tree and commit:
>
> ad6b47cdef76 ("dt-bindings: irq: sun6i-r: Split the binding from sun7i-nmi")
>
> from the irqchip tree.
>
> I fixed it up (I think - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
> diff --cc
> Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> index 4fd1e2780026,f34ecc8c7093..
> ---
> a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun7i-a20-sc-nmi.yaml
> @@@ -25,17 -25,7 +25,10 @@@ properties
> - const: allwinner,sun6i-a31-sc-nmi
> deprecated: true
> - const: allwinner,sun7i-a20-sc-nmi
> - - items:
> - - const: allwinner,sun8i-a83t-r-intc
> - - const: allwinner,sun6i-a31-r-intc
> + - items:
> + - const: allwinner,sun8i-v3s-nmi
> + - const: allwinner,sun9i-a80-nmi
> - const: allwinner,sun9i-a80-nmi
> - - items:
> - - const: allwinner,sun50i-a64-r-intc
> - - const: allwinner,sun6i-a31-r-intc
> - items:
> - const: allwinner,sun50i-a100-nmi
> - const: allwinner,sun9i-a80-nmi
With the merge window about to open, this is a reminder that this
conflict still exists. It is now between the arm-soc tree and the
irqchip tree.
--
Cheers,
Stephen Rothwell
pgpfY1zj8PC_q.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the drm tree with Linus' tree
Hi all,
On Mon, 1 Feb 2021 12:30:12 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
>
> between commit:
>
> a119f87b86bc ("Revert "drm/amdgpu/swsmu: drop set_fan_speed_percent (v2)"")
>
> from Linus' tree and commit:
>
> d8a0b8dd690b ("drm/amd/pm: add pptable_funcs documentation (v3)")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> index 0d797fa9f5cc,a087e00382e6..
> --- a/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h
> @@@ -551,39 -924,199 +924,201 @@@ struct pptable_funcs
> int (*display_clock_voltage_request)(struct smu_context *smu, struct
>pp_display_clock_request
>*clock_req);
> +
> + /**
> + * @get_fan_control_mode: Get the current fan control mode.
> + */
> uint32_t (*get_fan_control_mode)(struct smu_context *smu);
> +
> + /**
> + * @set_fan_control_mode: Set the fan control mode.
> + */
> int (*set_fan_control_mode)(struct smu_context *smu, uint32_t mode);
> +
> +int (*set_fan_speed_percent)(struct smu_context *smu, uint32_t speed);
> ++
> + /**
> + * @set_fan_speed_rpm: Set a static fan speed in RPM.
> + */
> int (*set_fan_speed_rpm)(struct smu_context *smu, uint32_t speed);
> +
> + /**
> + * @set_xgmi_pstate: Set inter-chip global memory interconnect pstate.
> + * : Pstate to set. D0 if Nonzero, D3 otherwise.
> + */
> int (*set_xgmi_pstate)(struct smu_context *smu, uint32_t pstate);
> +
> + /**
> + * @gfx_off_control: Enable/disable graphics engine poweroff.
> + */
> int (*gfx_off_control)(struct smu_context *smu, bool enable);
> +
> +
> + /**
> + * @get_gfx_off_status: Get graphics engine poweroff status.
> + *
> + * Return:
> + * 0 - GFXOFF(default).
> + * 1 - Transition out of GFX State.
> + * 2 - Not in GFXOFF.
> + * 3 - Transition into GFXOFF.
> + */
> uint32_t (*get_gfx_off_status)(struct smu_context *smu);
> +
> + /**
> + * @register_irq_handler: Register interupt request handlers.
> + */
> int (*register_irq_handler)(struct smu_context *smu);
> +
> + /**
> + * @set_azalia_d3_pme: Wake the audio decode engine from d3 sleep.
> + */
> int (*set_azalia_d3_pme)(struct smu_context *smu);
> +
> + /**
> + * @get_max_sustainable_clocks_by_dc: Get a copy of the max sustainable
> + *clock speeds table.
> + *
> + * Provides a way for the display component (DC) to get the max
> + * sustainable clocks from the SMU.
> + */
> int (*get_max_sustainable_clocks_by_dc)(struct smu_context *smu, struct
> pp_smu_nv_clock_table *max_clocks);
> +
> + /**
> + * @baco_is_support: Check if GPU supports BACO (Bus Active, Chip Off).
> + */
> bool (*baco_is_support)(struct smu_context *smu);
> +
> + /**
> + * @baco_get_state: Get the current BACO state.
> + *
> + * Return: Current BACO state.
> + */
> enum smu_baco_state (*baco_get_state)(struct smu_context *smu);
> +
> + /**
> + * @baco_set_state: Enter/exit BACO.
> + */
> int (*baco_set_state)(struct smu_context *smu, enum smu_baco_state
> state);
> +
> + /**
> + * @baco_enter: Enter BACO.
> + */
> int (*baco_enter)(struct smu_context *smu);
> +
> + /**
> + * @baco_exit: Exit Baco.
> + */
> int (*baco_exit)(struct smu_context *smu);
> +
> + /**
> + * @mode1_reset_is_support: Check if GPU supports mode1 reset.
> + */
> bool (*mode1_reset_is_support)(struct smu_context *smu);
> +
> + /**
> + * @mode1_reset: Perform mode1 reset.
> + *
> + * Complete GPU reset.
> + */
> int (*mode1_reset)(struct smu_context *smu);
> +
> + /**
> + * @mode2_reset: Perform mode2 reset.
> + *
> + * Mode2 reset generally does not reset as many IPs as mode1 reset. The
> + * IPs reset varies by asic.
> + */
> int (*mode2_reset)(struct smu_context *smu);
> +
> + /**
> + * @get_dpm_ultimate_freq: Get the hard frequency range of a clock
> + * domain in MHz.
> + */
> int (*get_dpm_ultimate_freq)(struct smu_context *smu, enum smu_clk_type
> clk_type, uint32_t *min, uint32_t *max);
> +
> + /**
> +
