Re: [PATCH] pinctrl: use to octal permissions for debugfs files
On Tue, Jan 26, 2021 at 5:55 AM Drew Fustini wrote:
> Switch over pinctrl debugfs files to use octal permissions as they are
> preferred over symbolic permissions. Refer to commit f90774e1fd27
> ("checkpatch: look for symbolic permissions and suggest octal instead").
>
> Signed-off-by: Drew Fustini
That's right. Patch applied!
Yours,
Linus Walleij
[PATCH RESEND] regulator: bd718x7, bd71828, Fix dvs voltage levels
The ROHM BD718x7 and BD71828 drivers support setting HW state
specific voltages from device-tree. This is used also by various
in-tree DTS files.
These drivers do incorrectly try to compose bit-map using enum
values. By a chance this works for first two valid levels having
values 1 and 2 - but setting values for the rest of the levels
do indicate capability of setting values for first levels as
well. Luckily the regulators which support setting values for
SUSPEND/LPSR do usually also support setting values for RUN
and IDLE too - thus this has not been such a fatal issue.
Fix this by defining the old enum values as bits and fixing the
parsing code. This allows keeping existing IC specific drivers
intact and only slightly changing the rohm-regulator.c
Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7
specific parts")
Signed-off-by: Matti Vaittinen
---
I just noticed this fix never made it in-tree. So this is a resend of a
resend :)
drivers/regulator/rohm-regulator.c | 9 ++---
include/linux/mfd/rohm-generic.h | 14 ++
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/rohm-regulator.c
b/drivers/regulator/rohm-regulator.c
index 399002383b28..5c558b153d55 100644
--- a/drivers/regulator/rohm-regulator.c
+++ b/drivers/regulator/rohm-regulator.c
@@ -52,9 +52,12 @@ int rohm_regulator_set_dvs_levels(const struct
rohm_dvs_config *dvs,
char *prop;
unsigned int reg, mask, omask, oreg = desc->enable_reg;
- for (i = 0; i < ROHM_DVS_LEVEL_MAX && !ret; i++) {
- if (dvs->level_map & (1 << i)) {
- switch (i + 1) {
+ for (i = 0; i < ROHM_DVS_LEVEL_VALID_AMOUNT && !ret; i++) {
+ int bit;
+
+ bit = BIT(i);
+ if (dvs->level_map & bit) {
+ switch (bit) {
case ROHM_DVS_LEVEL_RUN:
prop = "rohm,dvs-run-voltage";
reg = dvs->run_reg;
diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 4283b5b33e04..2b85b9deb03a 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -20,14 +20,12 @@ struct rohm_regmap_dev {
struct regmap *regmap;
};
-enum {
- ROHM_DVS_LEVEL_UNKNOWN,
- ROHM_DVS_LEVEL_RUN,
- ROHM_DVS_LEVEL_IDLE,
- ROHM_DVS_LEVEL_SUSPEND,
- ROHM_DVS_LEVEL_LPSR,
- ROHM_DVS_LEVEL_MAX = ROHM_DVS_LEVEL_LPSR,
-};
+#define ROHM_DVS_LEVEL_RUN BIT(0)
+#define ROHM_DVS_LEVEL_IDLEBIT(1)
+#define ROHM_DVS_LEVEL_SUSPEND BIT(2)
+#define ROHM_DVS_LEVEL_LPSRBIT(3)
+#define ROHM_DVS_LEVEL_VALID_AMOUNT4
+#define ROHM_DVS_LEVEL_UNKNOWN 0
/**
* struct rohm_dvs_config - dynamic voltage scaling register descriptions
base-commit: 92bf22614b21a2706f4993b278017e437f7785b3
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Re: [RFC PATCH v4 00/17] virtio/vsock: introduce SOCK_SEQPACKET support
On Fri, Feb 12, 2021 at 09:11:50AM +0300, Arseny Krasnov wrote:
On 11.02.2021 17:57, Stefano Garzarella wrote:
Hi Arseny,
On Mon, Feb 08, 2021 at 09:32:59AM +0300, Arseny Krasnov wrote:
On 07.02.2021 19:20, Michael S. Tsirkin wrote:
On Sun, Feb 07, 2021 at 06:12:56PM +0300, Arseny Krasnov wrote:
This patchset impelements support of SOCK_SEQPACKET for virtio
transport.
As SOCK_SEQPACKET guarantees to save record boundaries, so to
do it, two new packet operations were added: first for start of record
and second to mark end of record(SEQ_BEGIN and SEQ_END later). Also,
both operations carries metadata - to maintain boundaries and payload
integrity. Metadata is introduced by adding special header with two
fields - message count and message length:
struct virtio_vsock_seq_hdr {
__le32 msg_cnt;
__le32 msg_len;
} __attribute__((packed));
This header is transmitted as payload of SEQ_BEGIN and SEQ_END
packets(buffer of second virtio descriptor in chain) in the same way as
data transmitted in RW packets. Payload was chosen as buffer for this
header to avoid touching first virtio buffer which carries header of
packet, because someone could check that size of this buffer is equal
to size of packet header. To send record, packet with start marker is
sent first(it's header contains length of record and counter), then
counter is incremented and all data is sent as usual 'RW' packets and
finally SEQ_END is sent(it also carries counter of message, which is
counter of SEQ_BEGIN + 1), also after sedning SEQ_END counter is
incremented again. On receiver's side, length of record is known from
packet with start record marker. To check that no packets were dropped
by transport, counters of two sequential SEQ_BEGIN and SEQ_END are
checked(counter of SEQ_END must be bigger that counter of SEQ_BEGIN by
1) and length of data between two markers is compared to length in
SEQ_BEGIN header.
Now as packets of one socket are not reordered neither on
vsock nor on vhost transport layers, such markers allows to restore
original record on receiver's side. If user's buffer is smaller that
record length, when all out of size data is dropped.
Maximum length of datagram is not limited as in stream socket,
because same credit logic is used. Difference with stream socket is
that user is not woken up until whole record is received or error
occurred. Implementation also supports 'MSG_EOR' and 'MSG_TRUNC' flags.
Tests also implemented.
Arseny Krasnov (17):
af_vsock: update functions for connectible socket
af_vsock: separate wait data loop
af_vsock: separate receive data loop
af_vsock: implement SEQPACKET receive loop
af_vsock: separate wait space loop
af_vsock: implement send logic for SEQPACKET
af_vsock: rest of SEQPACKET support
af_vsock: update comments for stream sockets
virtio/vsock: dequeue callback for SOCK_SEQPACKET
virtio/vsock: fetch length for SEQPACKET record
virtio/vsock: add SEQPACKET receive logic
virtio/vsock: rest of SOCK_SEQPACKET support
virtio/vsock: setup SEQPACKET ops for transport
vhost/vsock: setup SEQPACKET ops for transport
vsock_test: add SOCK_SEQPACKET tests
loopback/vsock: setup SEQPACKET ops for transport
virtio/vsock: simplify credit update function API
drivers/vhost/vsock.c | 8 +-
include/linux/virtio_vsock.h| 15 +
include/net/af_vsock.h | 9 +
include/uapi/linux/virtio_vsock.h | 16 +
net/vmw_vsock/af_vsock.c| 588 +++---
net/vmw_vsock/virtio_transport.c| 5 +
net/vmw_vsock/virtio_transport_common.c | 316 ++--
net/vmw_vsock/vsock_loopback.c | 5 +
tools/testing/vsock/util.c | 32 +-
tools/testing/vsock/util.h | 3 +
tools/testing/vsock/vsock_test.c| 126 +
11 files changed, 895 insertions(+), 228 deletions(-)
TODO:
- What to do, when server doesn't support SOCK_SEQPACKET. In current
implementation RST is replied in the same way when listening port
is not found. I think that current RST is enough,because case when
server doesn't support SEQ_PACKET is same when listener missed(e.g.
no listener in both cases).
I think is fine.
- virtio spec patch
Ok
Yes, please prepare a patch to discuss the VIRTIO spec changes.
For example for 'virtio_vsock_seq_hdr', I left a comment about 'msg_cnt'
naming that should be better to discuss with virtio guys.
Ok, i'll prepare it in v5. So I have to send it both LKML(as one of patches) and
virtio mailing lists? (e.g. virtio-comm...@lists.oasis-open.org)
I think you can send the VIRTIO spec patch separately from this series
to virtio-comment, maybe CCing virtualizat...@lists.linux-foundation.org
But Michael could correct me :-)
Anyway, I reviewed this series and I left some comments.
I think we are in a good shape :-)
Great, thanks for review. I'll c
Re: [PATCH v2 02/14] clk: stm32mp1: merge 'ck_hse_rtc' and 'ck_rtc' into one clock
On 2/9/21 9:00 AM, Stephen Boyd wrote:
Quoting gabriel.fernan...@foss.st.com (2021-01-26 01:01:08)
From: Gabriel Fernandez
'ck_rtc' has multiple clocks as input (ck_hsi, ck_lsi, and ck_hse).
A divider is available only on the specific rtc input for ck_hse.
This Merge will facilitate to have a more coherent clock tree
in no trusted / trusted world.
Signed-off-by: Gabriel Fernandez
---
drivers/clk/clk-stm32mp1.c | 49 +-
1 file changed, 43 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-stm32mp1.c b/drivers/clk/clk-stm32mp1.c
index 35d5aee8f9b0..0e1d4427a8df 100644
--- a/drivers/clk/clk-stm32mp1.c
+++ b/drivers/clk/clk-stm32mp1.c
@@ -245,7 +245,7 @@ static const char * const dsi_src[] = {
};
static const char * const rtc_src[] = {
- "off", "ck_lse", "ck_lsi", "ck_hse_rtc"
+ "off", "ck_lse", "ck_lsi", "ck_hse"
};
static const char * const mco1_src[] = {
@@ -1031,6 +1031,42 @@ static struct clk_hw *clk_register_cktim(struct device
*dev, const char *name,
return hw;
}
+/* The divider of RTC clock concerns only ck_hse clock */
+#define HSE_RTC 3
+
+static unsigned long clk_divider_rtc_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+ return clk_divider_ops.recalc_rate(hw, parent_rate);
+
+ return parent_rate;
+}
+
+static long clk_divider_rtc_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
This clk op can be called at basically any time. Maybe this should use
the determine rate op and then look to see what the parent is that comes
in via the rate request structure? Or is the intention to keep this
pinned to one particular parent? Looking at this right now it doesn't
really make much sense why the current parent state should play into
what rate the clk can round to, unless there is some more clk flags
going on that constrain the ability to change this clk's parent.
Yes the intention is to keep this pinned for one particular parent.
This divider is only applied on the 4th input of the MUX of the RTC and
doesn't affect the HSE frequency for all the system.
Oscillators
-
| lse |+> ck_lse
- |
- |
| lsi |+> ck_lsi
- | |
| |
- | |
| hse |+---|---|> ck_hse
- | | |
| | | |\ mux
| | | OFF -->| \
| | | | \ gate
| | ->| | ---
| | | |--->| |--> ck_rtc
| ->| | ---
| --- | |
| % 1 to 64 |--->| /
--- |/
divider
I manage the RTC with a clock composite with a gate a mux and a specific
rate ops for hse input.
That why i need to the parent state.
Best Regards
Gabriel
+ return clk_divider_ops.round_rate(hw, rate, prate);
+
+ return *prate;
+}
+
+static int clk_divider_rtc_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ if (clk_hw_get_parent(hw) == clk_hw_get_parent_by_index(hw, HSE_RTC))
+ return clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+ return parent_rate;
+}
+
Re: [PATCH v4 0/8] Make fw_devlink=on more forgiving
Hi Saravana,
On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan wrote:
> On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven
> wrote:
> > 1. R-Car Gen2 (Koelsch), R-Car Gen3 (Salvator-X(S), Ebisu).
> >
> > - Commit 2dfc564bda4a31bc ("soc: renesas: rcar-sysc: Mark device
> > node OF_POPULATED after init") is no longer needed (but already
> > queued for v5.12 anyway)
>
> Rob doesn't like the proliferation of OF_POPULATED and we don't need
> it anymore, so maybe work it out with him? It's a balance between some
> wasted memory (struct device(s)) vs not proliferating OF_POPULATED.
Rob: should it be reverted? For v5.13?
I guess other similar "fixes" went in in the mean time.
> > - Some devices are reprobed, despite their drivers returning
> > a real error code, and not -EPROBE_DEFER:
>
> Sorry, it's not obvious from the logs below where "reprobing" is
> happening. Can you give more pointers please?
My log was indeed not a full log, but just the reprobes happening.
I'll send you a full log by private email.
> Also, thinking more about this, the only way I could see this happen is:
> 1. Device fails with error that's not -EPROBE_DEFER
> 2. It somehow gets added to a device link (with AUTOPROBE_CONSUMER
> flag) where it's a consumer.
> 3. The supplier probes and the device gets added to the deferred probe
> list again.
>
> But I can't see how this sequence can happen. Device links are created
> only when a device is added. And is the supplier isn't added yet, the
> consumer wouldn't have probed in the first place.
The full log doesn't show any evidence of the device being added
to a list in between the two probes.
> Other than "annoying waste of time" is this causing any other problems?
Probably not. But see below.
> > - The PCI reprobing leads to a memory leak, for which I've sent a fix
> > "[PATCH] PCI: Fix memory leak in pci_register_io_range()"
> >
> > https://lore.kernel.org/linux-pci/20210202100332.829047-1-geert+rene...@glider.be/
>
> Wrt PCI reprobing,
> 1. Is this PCI never expected to probe, but it's being reattempted
> despite the NOT EPROBE_DEFER error? Or
There is no PCIe card present, so the failure is expected.
Later it is reprobed, which of course fails again.
> 2. The PCI was deferred probe when it should have probed and then when
> it's finally reattemped and it could succeed, we are hitting this mem
> leak issue?
I think the leak has always been there, but it was just exposed by
this unneeded reprobe. I don't think a reprobe after that specific
error path had ever happened before.
> I'm basically trying to distinguish between "this stuff should never
> be retried" vs "this/it's suppliers got probe deferred with
> fw_devlink=on vs but didn't get probe deferred with
> fw_devlink=permissive and that's causing issues"
There should not be a probe deferral, as no -EPROBE_DEFER was
returned.
> > - I2C on R-Car Gen3 does not seem to use DMA, according to
> > /sys/kernel/debug/dmaengine/summary:
> >
> > -dma4chan0| e66d8000.i2c:tx
> > -dma4chan1| e66d8000.i2c:rx
> > -dma5chan0| e651.i2c:tx
>
> I think I need more context on the problem before I can try to fix it.
> I'm also very unfamiliar with that file. With fw_devlink=permissive,
> I2C was using DMA? If so, the next step is to see if the I2C relative
> probe order with DMA is getting changed and if so, why.
Yes, I plan to dig deeper to see what really happens...
> > - On R-Mobile A1, I get a BUG and a memory leak:
> >
> > BUG: spinlock bad magic on CPU#0, swapper/1
>
> Hmm... I looked at this in bits and pieces throughout the day. At
> least spent an hour looking at this. This doesn't make a lot of sense
> to me. I don't even touch anything in this code path AFAICT. Are
> modules/kernel mixed up somehow? I need more info before I can help.
> Does reverting my pm domain change make any difference (assume it
> boots this far without it).
I plan to dig deeper to see what really happens...
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
[PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
This change fixes a checkpatch CHECK style issue for "Alignment should match
open parenthesis".
Signed-off-by: Pritthijit Nath
---
drivers/staging/greybus/hid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
index ed706f39e87a..a56c3fb5d35a 100644
--- a/drivers/staging/greybus/hid.c
+++ b/drivers/staging/greybus/hid.c
@@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
}
static int __gb_hid_get_raw_report(struct hid_device *hid,
- unsigned char report_number, __u8 *buf, size_t count,
- unsigned char report_type)
+ unsigned char report_number, __u8 *buf,
size_t count,
+ unsigned char report_type)
{
struct gb_hid *ghid = hid->driver_data;
int ret;
--
2.25.1
Re: [PATCH V4] mtd: rawnand: qcom: update last code word register
Hello,
mda...@codeaurora.org wrote on Fri, 12 Feb 2021 01:00:47 +0530:
> On 2021-02-11 19:37, Miquel Raynal wrote:
> > Hello,
> >
> > Manivannan Sadhasivam wrote on Wed,
> > 10 Feb 2021 14:31:44 +0530:
> >
> >> On Fri, Jan 29, 2021 at 03:09:19AM +0530, Md Sadre Alam wrote:
> >> > From QPIC version 2.0 onwards new register got added to
> >> > read last codeword. This change will add the READ_LOCATION_LAST_CW_n
> >> > register.
> >> >
> >> > For first three code word READ_LOCATION_n register will be
> >> > use.For last code word READ_LOCATION_LAST_CW_n register will be
> >> > use.
> >
> > Sorry for the late notice, I think the patch is fine but if you don't
> > mind I would like to propose a small change that should simplify your
> > patch a lot, see below.
> >
> >> >
> >> > Signed-off-by: Md Sadre Alam
> >> >> Reviewed-by: Manivannan Sadhasivam
> >> >> Thanks,
> >> Mani
> >> >> > ---
> >> > [V4]
> >> > * Modified condition for nandc_set_read_loc_last() in
> >> > qcom_nandc_read_cw_raw().
> >> > * Added one additional argument "last_cw" to the function
> >> > config_nand_cw_read()
> >> >to handle last code word condition.
> >> > * Changed total number of last code word register
> >> > "NAND_READ_LOCATION_LAST_CW_0" to 4
> >> >while doing code word configuration.
> >> > drivers/mtd/nand/raw/qcom_nandc.c | 110
> >> > +-
> >> > 1 file changed, 84 insertions(+), 26 deletions(-)
> >> >
> >> > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
> >> > b/drivers/mtd/nand/raw/qcom_nandc.c
> >> > index 667e4bf..9484be8 100644
> >> > --- a/drivers/mtd/nand/raw/qcom_nandc.c
> >> > +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> >> > @@ -48,6 +48,10 @@
> >> > #define NAND_READ_LOCATION_10xf24
> >> > #define NAND_READ_LOCATION_20xf28
> >> > #define NAND_READ_LOCATION_30xf2c
> >> > +#define NAND_READ_LOCATION_LAST_CW_00xf40
> >> > +#define NAND_READ_LOCATION_LAST_CW_10xf44
> >> > +#define NAND_READ_LOCATION_LAST_CW_20xf48
> >> > +#define NAND_READ_LOCATION_LAST_CW_30xf4c
> >> >
> >> > /* dummy register offsets, used by write_reg_dma */
> >> > #define NAND_DEV_CMD1_RESTORE 0xdead
> >> > @@ -187,6 +191,12 @@ nandc_set_reg(nandc, NAND_READ_LOCATION_##reg,
> >> > \
> >> >((size) << READ_LOCATION_SIZE) | \
> >> >((is_last) << READ_LOCATION_LAST))
> >> >
> >> > +#define nandc_set_read_loc_last(nandc, reg, offset, size, is_last)
> >> > \
> >> > +nandc_set_reg(nandc, NAND_READ_LOCATION_LAST_CW_##reg,
> >> > \
> >> > + ((offset) << READ_LOCATION_OFFSET) | \
> >> > + ((size) << READ_LOCATION_SIZE) | \
> >> > + ((is_last) << READ_LOCATION_LAST))
> >> > +
> >
> > You could rename the macro nandc_set_read_loc() into
> > nandc_set_read_loc_first() or anything else that make sense, then have
> > a helper which does:
> >
> > nandc_set_read_loc()
> > {
> > if (condition for first)
> > return nandc_set_read_loc_first();
> > else
> > return nandc_set_read_loc_last();
> > }
> >
>
>Yes this is more precise way & simplify the patch a lot.
>But for this i have to change these two macro as a function.
>
>nandc_set_read_loc() & nandc_set_read_loc_last().
>
>Since for last code word register we are using Token Pasting Operator##.
>
>So if i am implementing like the below.
>
>/* helper to configure location register values */
>static void nandc_set_read_loc(struct qcom_nand_controller *nandc, int reg,
>int offset, int size, int is_last, bool last_cw)
>{
>if (last_cw)
>return nandc_set_read_loc_last(nandc, reg, offset, size,
> is_last);
>else
>return nandc_set_read_loc_first(nandc, reg, offset, size,
> is_last);
> }
>
>So here for macro expansion reg should be a value not a variable else it
> will be expended like
>NAND_READ_LOCATION_LAST_CW_reg instead of
> NAND_READ_LOCATION_LAST_CW_0,1,2,3 etc.
I know it involves a little bit more computation but I wonder if using
funcs instead of macros here would not be nicer? Perhaps something like:
loc = is_last ? NAND_READ_LOCATION /* 0xf20 */ :
NAND_READ_LOCATION_LAST /* 0xf40 */;
loc += reg * 2;
> the call for nandc_set_read_loc() as nandc_set_read_loc(nandc, 0, read_loc,
> data_size1, 0, true); ---> for last code word.
> nandc_set_read_loc(nandc, 0, read_loc, data_size1, 0, false); ---> for
> first three code wrod.
I think it's best to forward 'cw' as a parameter and do the
computation of is_last locally.
> So is this ok for you to convert these two macro into function ?
>
> > And in the rest of your patch you won't have to touch anything else.
> >
> > Thanks,
> > Miquèl
Thanks,
Miquèl
[PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
Fixed the spelling of 'transfered' to 'transferred'. Signed-off-by: Pritthijit Nath --- drivers/staging/greybus/hid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c index a56c3fb5d35a..6b19ff4743a9 100644 --- a/drivers/staging/greybus/hid.c +++ b/drivers/staging/greybus/hid.c @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device *hid, __u8 *buf, ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); if (report_id && ret >= 0) - ret++; /* add report_id to the number of transfered bytes */ + ret++; /* add report_id to the number of transferrid bytes */ return 0; } -- 2.25.1
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 3:46 PM 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?
Which ones did I miss? (apart from configfs, see the conversation on
patch 6/6). Anyway, hopefully auditing all filesystems is an order of
magnitude easier task, and easier to maintain in the longer run ,-)
> 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 :)
Some of this is covered in the cover letter 0/6. To expand a bit:
copy_file_range has only supported cross-filesystem copies since 5.3
[1], before that the kernel would return EXDEV and userspace
application would fall back to a read/write based copy. After 5.3,
copy_file_range copies no data as it thinks the input file is empty.
[1] I think it makes little sense to try to use copy_file_range
between 2 files in /proc, but technically, I think that has been
broken since copy_file_range fallback to do_splice_direct was
introduced (eac70053a141 ("vfs: Add vfs_copy_file_range() support for
pagecache copies", ~4.4).
>
> thanks,
>
> greg k-h
Re: [PATCH v2 0/3] pinctrl: at91-pio4: add support for slew-rate
On Wed, Jan 27, 2021 at 12:45 PM Claudiu Beznea wrote: > This series adds support for slew rate on SAMA7G5. Along with this > patch 3/3 fixes some checkpatch.pl warnings. Patches applied! Yours, Linus Walleij
Re: [PATCH] docs: kernel-hacking: Remove the word fuck,trying to be civil :)
On 09:10 Thu 11 Feb 2021, Randy Dunlap wrote: On 2/11/21 9:04 AM, Jonathan Corbet wrote: Bhaskar Chowdhury writes: s/fuck// Signed-off-by: Bhaskar Chowdhury --- Documentation/kernel-hacking/locking.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index c3448929a824..ed1284c6f078 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -958,7 +958,7 @@ grabs a read lock, searches a list, fails to find what it wants, drops the read lock, grabs a write lock and inserts the object has a race condition. -If you don't see why, please stay the fuck away from my code. +If you don't see why, please stay away from my code. Sigh. I've gotten a few variants of this patch over the years...I guess maybe the time has come to apply one, so I did. If the word is too offensive to be in our docs, though, perhaps it shouldn't be in the changelog either, so I rewrote it: docs: kernel-hacking: be more civil Remove the f-bomb from locking.rst. Let's have a moment of silence, though, as we mark the passing of the last of Rusty's once plentiful profanities in this venerable document. I really like that tribute there, Jon. :) Indeed! -- ~Randy signature.asc Description: PGP signature
Re: [PATCH] pinctrl: nuvoton: npcm7xx: Fix alignment of table header comment
On Sat, Jan 30, 2021 at 5:30 PM Jonathan Neuschäfer wrote: > Make it so that each column label is in the column that it is supposed > to refer to. > > Signed-off-by: Jonathan Neuschäfer Patch applied, sorry for delay. Yours, Linus Walleij
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
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.
In retrospect, I think it would have been safer to allow cross-fs CFR
only to the filesystems that implement ->{copy,remap}_file_range()...
Our option now are:
- Restore the cross-fs restriction into generic_copy_file_range()
- Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does
Preference anyone?
Thanks,
Amir.
Re: [PATCH 4/5] keys: define build time generated ephemeral kernel CA key
Hi Nayna,
I love your patch! Yet something to improve:
[auto build test ERROR on kbuild/for-next]
[also build test ERROR on integrity/next-integrity linus/master
security/next-testing v5.11-rc7]
[cannot apply to next-20210211]
[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/Nayna-Jain/ima-kernel-build-support-for-loading-the-kernel-module-signing-key/20210212-040003
base:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
for-next
config: x86_64-randconfig-a013-20210209 (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 x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/84acbcedcd14fe43bf648857b4642c9bf426afd4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Nayna-Jain/ima-kernel-build-support-for-loading-the-kernel-module-signing-key/20210212-040003
git checkout 84acbcedcd14fe43bf648857b4642c9bf426afd4
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
Can't open certs/signing_key.crt for reading, No such file or directory
>> 140683809875072:error:02001002:system library:fopen:No such file or
>> directory:../crypto/bio/bss_file.c:69:fopen('certs/signing_key.crt','r')
>> 140683809875072:error:2006D080:BIO routines:BIO_new_file:no such
>> file:../crypto/bio/bss_file.c:76:
unable to load certificate
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] pinctrl: Support pin that does not support configuration option
On Mon, Feb 1, 2021 at 12:54 PM Michael Nazzareno Trimarchi wrote: > On Mon, Feb 1, 2021 at 12:47 PM Fabio Estevam wrote: > > > > Hi Michael, > > > > On Sat, Jan 30, 2021 at 5:21 AM Michael Trimarchi > > wrote: > > > > > > Some of the iMX25 pins have not an associated configuration register so > > > when they are configured the standard way through the device tree the > > > kernel complains with: > > > > > > imx25-pinctrl 43fac000.iomuxc: Pin(MX25_PAD_EXT_ARMCLK) does not support > > > config function > > > > Could you please share your device tree that causes this warning? > > > > Shouldn't you pass 0x8000 in the devicetree for this pad then? > > > > 0x8000 means that the kernel should not touch the PAD_CTL register > > and use the default configuration from the bootloader/POR. > > arch/arm/boot/dts/imx25-lisa.dts: > MX25_PAD_EXT_ARMCLK__GPIO_3_15 0x8000 > > The problem that exists pad that can be muxed but not configured Did you reach any conclusion on this? I need Fabio's consent to apply the patch, but it seems maybe the DTS should be changed instead? Yours, Linus Walleij
Re: [PATCH] pinctrl: Support pin that does not support configuration option
Hi On Fri, Feb 12, 2021 at 9:26 AM Linus Walleij wrote: > > On Mon, Feb 1, 2021 at 12:54 PM Michael Nazzareno Trimarchi > wrote: > > On Mon, Feb 1, 2021 at 12:47 PM Fabio Estevam wrote: > > > > > > Hi Michael, > > > > > > On Sat, Jan 30, 2021 at 5:21 AM Michael Trimarchi > > > wrote: > > > > > > > > Some of the iMX25 pins have not an associated configuration register so > > > > when they are configured the standard way through the device tree the > > > > kernel complains with: > > > > > > > > imx25-pinctrl 43fac000.iomuxc: Pin(MX25_PAD_EXT_ARMCLK) does not support > > > > config function > > > > > > Could you please share your device tree that causes this warning? > > > > > > Shouldn't you pass 0x8000 in the devicetree for this pad then? > > > > > > 0x8000 means that the kernel should not touch the PAD_CTL register > > > and use the default configuration from the bootloader/POR. > > > > arch/arm/boot/dts/imx25-lisa.dts: > > MX25_PAD_EXT_ARMCLK__GPIO_3_15 0x8000 > > > > The problem that exists pad that can be muxed but not configured > > Did you reach any conclusion on this? > > I need Fabio's consent to apply the patch, but it seems maybe the > DTS should be changed instead? > Let me re-check with the latest linux code. I did not find any change there. It's on my side now Michael > Yours, > Linus Walleij -- Michael Nazzareno Trimarchi Amarula Solutions BV COO Co-Founder Cruquiuskade 47 Amsterdam 1018 AM NL T. +31(0)851119172 M. +39(0)3479132170 [`as] https://www.amarulasolutions.com
Re: [PATCH 1/2] ARM: dts: am335x-pocketbeagle: unique gpio-line-names
On Thu, Feb 4, 2021 at 8:47 AM Drew Fustini wrote: > On Thu, Feb 04, 2021 at 08:58:20AM +0200, Tony Lindgren wrote: > > * Drew Fustini [210127 02:04]: > > > Based on linux-gpio discussion [1], it is best practice to make the > > > gpio-line-names unique. Generic names like "[ethernet]" are replaced > > > with the name of the unique signal on the AM3358 SoC ball corresponding > > > to the gpio line. "[NC]" is also renamed to the standard "NC" name to > > > represent "not connected". > > > > > > [1] https://lore.kernel.org/linux-gpio/20201216195357.GA2583366@x1/ > > > > So are these needed for v5.12 as fixes, or can these wait until after > > the merge window for v5.13? > > > > Regards, > > > > Tony > > I suppose it depends on if/when the patches to make gpio lines unique > go in. I believe the last response from Linus W. was in mid-December > and indicated he holding off merging as it was immature [1] There is no hurry with that plus I hold that patch back indefinately as it seems. I want to make line names unique for devices not probing from DT but DT devices, I dunno. Yours, Linus Walleij
arch/alpha/lib/csum_partial_copy.c:328:1: error: no previous prototype for 'csum_and_copy_from_user'
Hi Al,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: dcc0b49040c70ad827a7f3d58a21b01fdb14e749
commit: 808b49da54e640cba5c5c92dee658018a529226b alpha: turn
csum_partial_copy_from_user() into csum_and_copy_from_user()
date: 9 months ago
config: alpha-randconfig-r031-20210211 (attached as .config)
compiler: alpha-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=808b49da54e640cba5c5c92dee658018a529226b
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 808b49da54e640cba5c5c92dee658018a529226b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> 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
vim +/csum_and_copy_from_user +328 arch/alpha/lib/csum_partial_copy.c
326
327 __wsum
> 328 csum_and_copy_from_user(const void __user *src, void *dst, int len,
329 __wsum sum, int *errp)
330 {
331 unsigned long checksum = (__force u32) sum;
332 unsigned long soff = 7 & (unsigned long) src;
333 unsigned long doff = 7 & (unsigned long) dst;
334
335 if (len) {
336 if (!access_ok(src, len)) {
337 if (errp) *errp = -EFAULT;
338 memset(dst, 0, len);
339 return sum;
340 }
341 if (!doff) {
342 if (!soff)
343 checksum = csum_partial_cfu_aligned(
344 (const unsigned long __user *)
src,
345 (unsigned long *) dst,
346 len-8, checksum, errp);
347 else
348 checksum =
csum_partial_cfu_dest_aligned(
349 (const unsigned long __user *)
src,
350 (unsigned long *) dst,
351 soff, len-8, checksum, errp);
352 } else {
353 unsigned long partial_dest;
354 ldq_u(partial_dest, dst);
355 if (!soff)
356 checksum = csum_partial_cfu_src_aligned(
357 (const unsigned long __user *)
src,
358 (unsigned long *) dst,
359 doff, len-8, checksum,
360 partial_dest, errp);
361 else
362 checksum = csum_partial_cfu_unaligned(
363 (const unsigned long __user *)
src,
364 (unsigned long *) dst,
365 soff, doff, len-8, checksum,
366 partial_dest, errp);
367 }
368 checksum = from64to16 (checksum);
369 }
370 return (__force __wsum)checksum;
371 }
372 EXPORT_SYMBOL(csum_and_copy_from_user);
373
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] perf libperf: Remove unused xyarray.c
On Thu, Feb 11, 2021 at 08:38:03PM -0800, Ian Rogers wrote:
> Migrated to libperf in:
> commit 4b247fa7314c ("libperf: Adopt xyarray class from perf")
Acked-by: Jiri Olsa
thanks,
jirka
>
> Signed-off-by: Ian Rogers
> ---
> tools/perf/util/xyarray.c | 33 -
> 1 file changed, 33 deletions(-)
> delete mode 100644 tools/perf/util/xyarray.c
>
> diff --git a/tools/perf/util/xyarray.c b/tools/perf/util/xyarray.c
> deleted file mode 100644
> index 86889ebc3514..
> --- a/tools/perf/util/xyarray.c
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -#include "xyarray.h"
> -#include
> -#include
> -#include
> -
> -struct xyarray *xyarray__new(int xlen, int ylen, size_t entry_size)
> -{
> - size_t row_size = ylen * entry_size;
> - struct xyarray *xy = zalloc(sizeof(*xy) + xlen * row_size);
> -
> - if (xy != NULL) {
> - xy->entry_size = entry_size;
> - xy->row_size = row_size;
> - xy->entries= xlen * ylen;
> - xy->max_x = xlen;
> - xy->max_y = ylen;
> - }
> -
> - return xy;
> -}
> -
> -void xyarray__reset(struct xyarray *xy)
> -{
> - size_t n = xy->entries * xy->entry_size;
> -
> - memset(xy->contents, 0, n);
> -}
> -
> -void xyarray__delete(struct xyarray *xy)
> -{
> - free(xy);
> -}
> --
> 2.30.0.478.g8a0d178c01-goog
>
Re: [PATCH v4 net-next 6/9] net: dsa: act as ass passthrough for bridge port flags
On Fri, Feb 12, 2021 at 03:05:28AM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean > > There are multiple ways in which a PORT_BRIDGE_FLAGS attribute can be > expressed by the bridge through switchdev, and not all of them can be > emulated by DSA mid-layer API at the same time. Oops, odd typo in the commit title. I only remember something was not right, I had noticed the "as" word was missing so I added it, but I apparently did not notice why it was missing...
Re: [PATCH 1/3] cfg80211: Add wiphy flag to trigger STA disconnect after hardware restart
On Tue, 2020-12-15 at 23:00 +0530, Youghandhar Chintala wrote: > > * @WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK: The device supports bigger kek and kck > keys > + * @WIPHY_FLAG_STA_DISCONNECT_ON_HW_RESTART: The device needs a trigger to > + * disconnect STA after target hardware restart. This flag should be > + * exposed by drivers which support target recovery. You're not doing anything with this information in cfg80211, so consequently it doesn't belong there. johannes
Re: [PATCH] perf env: Remove unneeded internal/cpumap inclusions
On Thu, Feb 11, 2021 at 10:39:14AM -0800, Ian Rogers wrote: > Minor cleanup. > > Signed-off-by: Ian Rogers Acked-by: Jiri Olsa thanks, jirka > --- > tools/perf/bench/epoll-ctl.c | 1 - > tools/perf/bench/epoll-wait.c | 1 - > tools/perf/bench/futex-hash.c | 1 - > tools/perf/bench/futex-lock-pi.c | 1 - > tools/perf/bench/futex-requeue.c | 1 - > tools/perf/bench/futex-wake-parallel.c | 1 - > tools/perf/bench/futex-wake.c | 1 - > tools/perf/tests/openat-syscall-all-cpus.c | 1 - > tools/perf/util/synthetic-events.c | 1 - > 9 files changed, 9 deletions(-) > > diff --git a/tools/perf/bench/epoll-ctl.c b/tools/perf/bench/epoll-ctl.c > index ca2d591aad8a..ddaca75c3bc0 100644 > --- a/tools/perf/bench/epoll-ctl.c > +++ b/tools/perf/bench/epoll-ctl.c > @@ -21,7 +21,6 @@ > #include > #include > #include > -#include > #include > > #include "../util/stat.h" > diff --git a/tools/perf/bench/epoll-wait.c b/tools/perf/bench/epoll-wait.c > index 75dca9773186..0a0ff1247c83 100644 > --- a/tools/perf/bench/epoll-wait.c > +++ b/tools/perf/bench/epoll-wait.c > @@ -76,7 +76,6 @@ > #include > #include > #include > -#include > #include > > #include "../util/stat.h" > diff --git a/tools/perf/bench/futex-hash.c b/tools/perf/bench/futex-hash.c > index 915bf3da7ce2..b65373ce5c4f 100644 > --- a/tools/perf/bench/futex-hash.c > +++ b/tools/perf/bench/futex-hash.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > #include > > #include "../util/stat.h" > diff --git a/tools/perf/bench/futex-lock-pi.c > b/tools/perf/bench/futex-lock-pi.c > index bb25d8beb3b8..89c6d160379c 100644 > --- a/tools/perf/bench/futex-lock-pi.c > +++ b/tools/perf/bench/futex-lock-pi.c > @@ -14,7 +14,6 @@ > #include > #include > #include > -#include > #include > #include "bench.h" > #include "futex.h" > diff --git a/tools/perf/bench/futex-requeue.c > b/tools/perf/bench/futex-requeue.c > index 7a15c2e61022..5fa23295ee5f 100644 > --- a/tools/perf/bench/futex-requeue.c > +++ b/tools/perf/bench/futex-requeue.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > #include > #include "bench.h" > #include "futex.h" > diff --git a/tools/perf/bench/futex-wake-parallel.c > b/tools/perf/bench/futex-wake-parallel.c > index cd2b81a845ac..6e6f5247e1fe 100644 > --- a/tools/perf/bench/futex-wake-parallel.c > +++ b/tools/perf/bench/futex-wake-parallel.c > @@ -29,7 +29,6 @@ int bench_futex_wake_parallel(int argc __maybe_unused, > const char **argv __maybe > #include > #include > #include "futex.h" > -#include > #include > > #include > diff --git a/tools/perf/bench/futex-wake.c b/tools/perf/bench/futex-wake.c > index 2dfcef3e371e..6d217868f53c 100644 > --- a/tools/perf/bench/futex-wake.c > +++ b/tools/perf/bench/futex-wake.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > #include > #include "bench.h" > #include "futex.h" > diff --git a/tools/perf/tests/openat-syscall-all-cpus.c > b/tools/perf/tests/openat-syscall-all-cpus.c > index 71f85e2cc127..f7dd6c463f04 100644 > --- a/tools/perf/tests/openat-syscall-all-cpus.c > +++ b/tools/perf/tests/openat-syscall-all-cpus.c > @@ -15,7 +15,6 @@ > #include "tests.h" > #include "thread_map.h" > #include > -#include > #include "debug.h" > #include "stat.h" > #include "util/counts.h" > diff --git a/tools/perf/util/synthetic-events.c > b/tools/perf/util/synthetic-events.c > index c6f9db3faf83..0b767233ae1f 100644 > --- a/tools/perf/util/synthetic-events.c > +++ b/tools/perf/util/synthetic-events.c > @@ -24,7 +24,6 @@ > #include > #include > #include > -#include > #include > #include // page_size > #include > -- > 2.30.0.478.g8a0d178c01-goog >
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
On Fri, Feb 12, 2021 at 04:20:17PM +0800, Nicolas Boichat wrote:
> On Fri, Feb 12, 2021 at 3:46 PM 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?
>
> Which ones did I miss? (apart from configfs, see the conversation on
> patch 6/6). Anyway, hopefully auditing all filesystems is an order of
> magnitude easier task, and easier to maintain in the longer run ,-)
Are you going to be the one to add this to each new filesystem that is
added to the kernel?
I see filesystems in drivers/char/mem.c and
drivers/infiniband/hw/qib/qib_fs.c and drivers/misc/ibmasm/ibmasmfs.c
and loads of other driver-specific filesystems. Do all of those "just
work" somehow?
> > 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 :)
>
> Some of this is covered in the cover letter 0/6. To expand a bit:
> copy_file_range has only supported cross-filesystem copies since 5.3
> [1], before that the kernel would return EXDEV and userspace
> application would fall back to a read/write based copy. After 5.3,
> copy_file_range copies no data as it thinks the input file is empty.
So older kernels work fine with this system call on procfs, but newer
ones do not? If so, that's a regression that should be fixed in the
original area, but should not require a new filesystem flag for every
individual one out there. That way lies madness and constant auditing
that I do not see anyone signing up for for the next 20 years, right?
> [1] I think it makes little sense to try to use copy_file_range
> between 2 files in /proc, but technically, I think that has been
> broken since copy_file_range fallback to do_splice_direct was
> introduced (eac70053a141 ("vfs: Add vfs_copy_file_range() support for
> pagecache copies", ~4.4).
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.
thanks,
greg k-h
Re: [PATCH 1/2] quota: Add mountpath based quota support
On Thu, Feb 11, 2021 at 03:38:13PM +, Christoph Hellwig wrote:
> > + if (!mountpoint)
> > + return -ENODEV;
> > +
> > + ret = user_path_at(AT_FDCWD, mountpoint,
> > +LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT, &mountpath);
>
> user_path_at handles an empty path, although you'll get EFAULT instead.
> Do we care about the -ENODEV here?
The quotactl manpage documents EFAULT as error code for invalid addr or
special argument, so we really should return -EFAULT here.
Existing quotactl gets this wrong as well:
if (!special) {
if (cmds == Q_SYNC)
return quota_sync_all(type);
return -ENODEV;
}
Should we fix this or is there userspace code that is confused by a changed
return value?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on hardware restart
On Fri, 2021-02-05 at 13:51 -0800, Abhishek Kumar wrote: > Since using DELBA frame to APs to re-establish BA session has a > dependency on APs and also some APs may not honour the DELBA frame. That's completely out of spec ... Can you say which AP this was? You could also try sending a BAR that updates the SN. johannes
RE: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610)
> -Original Message- > From: Oleksandr Natalenko [mailto:oleksa...@natalenko.name] > Sent: Friday, February 12, 2021 8:43 PM > To: Song Bao Hua (Barry Song) > Cc: Mikhail Gavrilov ; > sjenn...@linux.vnet.ibm.com; Linux List Kernel Mailing > ; Linux Memory Management List > > Subject: Re: kernel BUG at mm/zswap.c:1275! (rc6 - git 61556703b610) > > Hello. > > On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote: > > Are you using zsmalloc? There is a known bug on the combination > > of zsmalloc and zswap, fixed by patches of tiantao: > > > > mm: set the sleep_mapped to true for zbud and z3fold > > mm/zswap: fix variable 'entry' is uninitialized when used > > mm/zswap: fix potential memory leak > > mm/zswap: add the flag can_sleep_mapped > > > > at Linux-next: > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?q > t=author&q=tiantao6%40hisilicon.com > > Is this a future stable-5.11 material (and/or, potentially, older stable > branches > as well)? I would believe this should be put into 5.11. I will ask Andrew. > > -- > Oleksandr Natalenko (post-factum) Thanks Barry
Re: [PATCH 1/6] fs: Add flag to file_system_type to indicate content is generated
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.
> - Explicitly opt-out of CFR per-fs and/or per-file as Nicolas' patch does
No. That way lies constant auditing and someone being "vigilant" for
the next 30+ years. Which will not happen.
thanks,
greg k-h
Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on hardware restart
On Tue, 2020-12-15 at 22:53 +0530, Youghandhar Chintala wrote:
> The right fix would be to pull the entire data path into the host
> +++ b/net/mac80211/ieee80211_i.h
> @@ -748,6 +748,8 @@ struct ieee80211_if_mesh {
> * back to wireless media and to the local net stack.
> * @IEEE80211_SDATA_DISCONNECT_RESUME: Disconnect after resume.
> * @IEEE80211_SDATA_IN_DRIVER: indicates interface was added to driver
> + * @IEEE80211_SDATA_DISCONNECT_HW_RESTART: Disconnect after hardware restart
> + * recovery
How did you model this on IEEE80211_SDATA_DISCONNECT_RESUME, but than
didn't check how that's actually used?
Please change it so that the two models are the same. You really don't
need the wiphy flag.
johannes
Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on hardware restart
On Fri, 2021-02-12 at 09:42 +0100, Johannes Berg wrote:
> On Tue, 2020-12-15 at 22:53 +0530, Youghandhar Chintala wrote:
> > The right fix would be to pull the entire data path into the host
> > +++ b/net/mac80211/ieee80211_i.h
> > @@ -748,6 +748,8 @@ struct ieee80211_if_mesh {
> > * back to wireless media and to the local net stack.
> > * @IEEE80211_SDATA_DISCONNECT_RESUME: Disconnect after resume.
> > * @IEEE80211_SDATA_IN_DRIVER: indicates interface was added to driver
> > + * @IEEE80211_SDATA_DISCONNECT_HW_RESTART: Disconnect after hardware
> > restart
> > + * recovery
>
> How did you model this on IEEE80211_SDATA_DISCONNECT_RESUME, but than
> didn't check how that's actually used?
>
> Please change it so that the two models are the same. You really don't
> need the wiphy flag.
In fact, you could even simply
generalize IEEE80211_SDATA_DISCONNECT_RESUME
and ieee80211_resume_disconnect() to _reconfig_ instead of _resume_, and
call it from the driver just before requesting HW restart.
johannes
Re: [PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
On Fri, Feb 12, 2021 at 01:48:35PM +0530, Pritthijit Nath wrote: > Fixed the spelling of 'transfered' to 'transferred'. > > Signed-off-by: Pritthijit Nath > --- > drivers/staging/greybus/hid.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c > index a56c3fb5d35a..6b19ff4743a9 100644 > --- a/drivers/staging/greybus/hid.c > +++ b/drivers/staging/greybus/hid.c > @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device > *hid, __u8 *buf, > > ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); > if (report_id && ret >= 0) > - ret++; /* add report_id to the number of transfered bytes */ > + ret++; /* add report_id to the number of transferrid bytes */ You now misspelled transferred in a different way. > > return 0; > } Johan
[PATCH] crypto: sun8i-ss: fix result memory leak on error path
This patch fixes a memory leak on an error path.
Fixes: d9b45418a917 ("crypto: sun8i-ss - support hash algorithms")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
index 11cbcbc83a7b..0b9aa24a5edd 100644
--- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
+++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c
@@ -438,8 +438,8 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void
*breq)
kfree(pad);
memcpy(areq->result, result, algt->alg.hash.halg.digestsize);
- kfree(result);
theend:
+ kfree(result);
crypto_finalize_hash_request(engine, breq, err);
return 0;
}
--
2.26.2
[RFC][PATCH v2 8/7] objtool,x86: More ModRM sugar
I promise, I'll stop poking at it more :-)
---
Subject: objtool,x86: More ModRM sugar
From: Peter Zijlstra
Date: Fri Feb 12 09:13:00 CET 2021
Better helpers to decode ModRM.
Signed-off-by: Peter Zijlstra (Intel)
---
tools/objtool/arch/x86/decode.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -82,15 +82,21 @@ unsigned long arch_jump_destination(stru
* 01 | [r/m + d8]|[S+d]| [r/m + d8] |
* 10 | [r/m + d32] |[S+D]| [r/m + d32] |
* 11 | r/ m |
- *
*/
+
+#define mod_is_mem() (modrm_mod != 3)
+#define mod_is_reg() (modrm_mod == 3)
+
#define is_RIP() ((modrm_rm & 7) == CFI_BP && modrm_mod == 0)
-#define have_SIB() ((modrm_rm & 7) == CFI_SP && modrm_mod != 3)
+#define have_SIB() ((modrm_rm & 7) == CFI_SP && mod_is_mem())
#define rm_is(reg) (have_SIB() ? \
sib_base == (reg) && sib_index == CFI_SP : \
modrm_rm == (reg))
+#define rm_is_mem(reg) (mod_is_mem() && !is_RIP() && rm_is(reg))
+#define rm_is_reg(reg) (mod_is_reg() && modrm_rm == (reg))
+
int arch_decode_instruction(const struct elf *elf, const struct section *sec,
unsigned long offset, unsigned int maxlen,
unsigned int *len, enum insn_type *type,
@@ -154,7 +160,7 @@ int arch_decode_instruction(const struct
case 0x1:
case 0x29:
- if (rex_w && modrm_mod == 3 && modrm_rm == CFI_SP) {
+ if (rex_w && rm_is_reg(CFI_SP)) {
/* add/sub reg, %rsp */
ADD_OP(op) {
@@ -219,7 +225,7 @@ int arch_decode_instruction(const struct
break;
/* %rsp target only */
- if (!(modrm_mod == 3 && modrm_rm == CFI_SP))
+ if (!rm_is_reg(CFI_SP))
break;
imm = insn.immediate.value;
@@ -272,7 +278,7 @@ int arch_decode_instruction(const struct
if (modrm_reg == CFI_SP) {
- if (modrm_mod == 3) {
+ if (mod_is_reg()) {
/* mov %rsp, reg */
ADD_OP(op) {
op->src.type = OP_SRC_REG;
@@ -308,7 +314,7 @@ int arch_decode_instruction(const struct
break;
}
- if (modrm_mod == 3 && modrm_rm == CFI_SP) {
+ if (rm_is_reg(CFI_SP)) {
/* mov reg, %rsp */
ADD_OP(op) {
@@ -325,7 +331,7 @@ int arch_decode_instruction(const struct
if (!rex_w)
break;
- if ((modrm_mod == 1 || modrm_mod == 2) && modrm_rm == CFI_BP) {
+ if (rm_is_mem(CFI_BP)) {
/* mov reg, disp(%rbp) */
ADD_OP(op) {
@@ -338,7 +344,7 @@ int arch_decode_instruction(const struct
break;
}
- if (modrm_mod != 3 && rm_is(CFI_SP)) {
+ if (rm_is_mem(CFI_SP)) {
/* mov reg, disp(%rsp) */
ADD_OP(op) {
@@ -357,7 +363,7 @@ int arch_decode_instruction(const struct
if (!rex_w)
break;
- if ((modrm_mod == 1 || modrm_mod == 2) && modrm_rm == CFI_BP) {
+ if (rm_is_mem(CFI_BP)) {
/* mov disp(%rbp), reg */
ADD_OP(op) {
@@ -370,7 +376,7 @@ int arch_decode_instruction(const struct
break;
}
- if (modrm_mod != 3 && rm_is(CFI_SP)) {
+ if (rm_is_mem(CFI_SP)) {
/* mov disp(%rsp), reg */
ADD_OP(op) {
@@ -386,7 +392,7 @@ int arch_decode_instruction(const struct
break;
case 0x8d:
- if (modrm_mod == 3) {
+ if (mod_is_reg()) {
WARN("invalid LEA encoding at %s:0x%lx", sec->name,
offset);
break;
}
RE: [EXT] Re: [PATCH v13 net-next 00/15] net: mvpp2: Add TX Flow Control support
> -- > Hello: > > This series was applied to netdev/net-next.git (refs/heads/master): > > On Thu, 11 Feb 2021 12:48:47 +0200 you wrote: > > From: Stefan Chulski > > > > Armada hardware has a pause generation mechanism in GOP (MAC). > > The GOP generate flow control frames based on an indication programmed > in Ports Control 0 Register. There is a bit per port. > > However assertion of the PortX Pause bits in the ports control 0 register > only sends a one time pause. > > To complement the function the GOP has a mechanism to periodically send > pause control messages based on periodic counters. > > This mechanism ensures that the pause is effective as long as the > Appropriate PortX Pause is asserted. > > > > [...] > > Here is the summary with links: > - [v13,net-next,01/15] doc: marvell: add CM3 address space and PPv2.3 > description Next week I would prepare small patch series to address Russell King comments. Thanks, Stefan.
Re: [PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
On Fri, Feb 12, 2021 at 09:44:04AM +0100, Johan Hovold wrote: > On Fri, Feb 12, 2021 at 01:48:35PM +0530, Pritthijit Nath wrote: > > Fixed the spelling of 'transfered' to 'transferred'. > > > > Signed-off-by: Pritthijit Nath > > --- > > drivers/staging/greybus/hid.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c > > index a56c3fb5d35a..6b19ff4743a9 100644 > > --- a/drivers/staging/greybus/hid.c > > +++ b/drivers/staging/greybus/hid.c > > @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device > > *hid, __u8 *buf, > > > > ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); > > if (report_id && ret >= 0) > > - ret++; /* add report_id to the number of transfered bytes */ > > + ret++; /* add report_id to the number of transferrid bytes */ > > You now misspelled transferred in a different way. Oops, will go revert this, I need more coffee...
Re: [PATCH v13 02/15] iommu: Introduce bind/unbind_guest_msi
Hi Keqian,
On 2/1/21 12:52 PM, Keqian Zhu wrote:
> Hi Eric,
>
> On 2020/11/18 19:21, Eric Auger wrote:
>> On ARM, MSI are translated by the SMMU. An IOVA is allocated
>> for each MSI doorbell. If both the host and the guest are exposed
>> with SMMUs, we end up with 2 different IOVAs allocated by each.
>> guest allocates an IOVA (gIOVA) to map onto the guest MSI
>> doorbell (gDB). The Host allocates another IOVA (hIOVA) to map
>> onto the physical doorbell (hDB).
>>
>> So we end up with 2 untied mappings:
>> S1S2
>> gIOVA->gDB
>> hIOVA->hDB
>>
>> Currently the PCI device is programmed by the host with hIOVA
>> as MSI doorbell. So this does not work.
>>
>> This patch introduces an API to pass gIOVA/gDB to the host so
>> that gIOVA can be reused by the host instead of re-allocating
>> a new IOVA. So the goal is to create the following nested mapping:
> Does the gDB can be reused under non-nested mode?
Under non nested mode the hIOVA is allocated within the MSI reserved
region exposed by the SMMU driver, [0x800, 80f]. see
iommu_dma_prepare_msi/iommu_dma_get_msi_page in dma_iommu.c. this hIOVA
is programmed in the physical device so that the physical SMMU
translates it into the physical doorbell (hDB = host physical ITS
doorbell). The gDB is not used at pIOMMU programming level. It is only
used when setting up the KVM irq route.
Hope this answers your question.
>
>>
>> S1S2
>> gIOVA->gDB ->hDB
>>
>> and program the PCI device with gIOVA MSI doorbell.
>>
>> In case we have several devices attached to this nested domain
>> (devices belonging to the same group), they cannot be isolated
>> on guest side either. So they should also end up in the same domain
>> on guest side. We will enforce that all the devices attached to
>> the host iommu domain use the same physical doorbell and similarly
>> a single virtual doorbell mapping gets registered (1 single
>> virtual doorbell is used on guest as well).
>>
> [...]
>
>> + *
>> + * The associated IOVA can be reused by the host to create a nested
>> + * stage2 binding mapping translating into the physical doorbell used
>> + * by the devices attached to the domain.
>> + *
>> + * All devices within the domain must share the same physical doorbell.
>> + * A single MSI GIOVA/GPA mapping can be attached to an iommu_domain.
>> + */
>> +
>> +int iommu_bind_guest_msi(struct iommu_domain *domain,
>> + dma_addr_t giova, phys_addr_t gpa, size_t size)
>> +{
>> +if (unlikely(!domain->ops->bind_guest_msi))
>> +return -ENODEV;
>> +
>> +return domain->ops->bind_guest_msi(domain, giova, gpa, size);
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_bind_guest_msi);
>> +
>> +void iommu_unbind_guest_msi(struct iommu_domain *domain,
>> +dma_addr_t iova)
> nit: s/iova/giova
sure
>
>> +{
>> +if (unlikely(!domain->ops->unbind_guest_msi))
>> +return;
>> +
>> +domain->ops->unbind_guest_msi(domain, iova);
>> +}
>> +EXPORT_SYMBOL_GPL(iommu_unbind_guest_msi);
>> +
> [...]
>
> Thanks,
> Keqian
>
Thanks
Eric
[PATCH for 5.10] powerpc/32: Preserve cr1 in exception prolog stack check to fix build error
This is backport of 3642eb21256a ("powerpc/32: Preserve cr1 in
exception prolog stack check to fix build error") for kernel 5.10
It fixes the build failure on v5.10 reported by kernel test robot
and by David Michael.
This fix is not in Linux tree yet, it is in next branch in powerpc tree.
(cherry picked from commit 3642eb21256a317ac14e9ed560242c6d20cf06d9)
THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
Maximum PAGE_SHIFT is 18 for 256k pages so
THREAD_ALIGN_SHIFT is 19 at the maximum.
No need to clobber cr1, it can be preserved when moving r1
into CR when we check stack overflow.
This reduces the number of instructions in Machine Check Exception
prolog and fixes a build failure reported by the kernel test robot
on v5.10 stable when building with RTAS + VMAP_STACK + KVM. That
build failure is due to too many instructions in the prolog hence
not fitting between 0x200 and 0x300. Allthough the problem doesn't
show up in mainline, it is still worth the change.
Fixes: 98bf2d3f4970 ("powerpc/32s: Fix RTAS machine check with VMAP stack")
Cc: sta...@vger.kernel.org
Reported-by: kernel test robot
Signed-off-by: Christophe Leroy
Signed-off-by: Michael Ellerman
Link:
https://lore.kernel.org/r/5ae4d545e3ac58e133d2599e0deb88843cb494fc.1612768623.git.christophe.le...@csgroup.eu
---
arch/powerpc/kernel/head_32.h| 2 +-
arch/powerpc/kernel/head_book3s_32.S | 6 --
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.h b/arch/powerpc/kernel/head_32.h
index c88e66adecb5..fef0b34a77c9 100644
--- a/arch/powerpc/kernel/head_32.h
+++ b/arch/powerpc/kernel/head_32.h
@@ -56,7 +56,7 @@
1:
tophys_novmstack r11, r11
#ifdef CONFIG_VMAP_STACK
- mtcrf 0x7f, r1
+ mtcrf 0x3f, r1
bt 32 - THREAD_ALIGN_SHIFT, stack_overflow
#endif
.endm
diff --git a/arch/powerpc/kernel/head_book3s_32.S
b/arch/powerpc/kernel/head_book3s_32.S
index d66da35f2e8d..2729d8fa6e77 100644
--- a/arch/powerpc/kernel/head_book3s_32.S
+++ b/arch/powerpc/kernel/head_book3s_32.S
@@ -280,12 +280,6 @@ MachineCheck:
7: EXCEPTION_PROLOG_2
addir3,r1,STACK_FRAME_OVERHEAD
#ifdef CONFIG_PPC_CHRP
-#ifdef CONFIG_VMAP_STACK
- mfspr r4, SPRN_SPRG_THREAD
- tovirt(r4, r4)
- lwz r4, RTAS_SP(r4)
- cmpwi cr1, r4, 0
-#endif
beq cr1, machine_check_tramp
twi 31, 0, 0
#else
--
2.25.0
Re: [PATCH] gpiolib: cdev: convert stream-like files from
On Sun, Feb 7, 2021 at 10:00 AM Yang Li wrote: > Eliminate the following coccicheck warning: > ./drivers/gpio/gpiolib-cdev.c:2307:7-23: WARNING: gpio_fileops: .read() > has stream semantic; safe to change nonseekable_open -> stream_open. > > Reported-by: Abaci Robot > Signed-off-by: Yang Li This doesn't make any sense to me. It is pretty clear from context that this file should *not* be seeked and it seems just dangerous to randomly allow that. Better safe than sorry. I don't know if the function nonseekable_open() has an unintuitive name if it means anything else than that. I burnt myself on the FS before. Yours, Linus Walleij
Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas
On Fri 12-02-21 00:59:29, Mike Rapoport wrote: > On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote: [...] > > Have a look how hugetlb proliferates through our MM APIs. I strongly > > suspect this is strong signal that this won't be any different. > > > > > And even if yes, adding SECRETMEM_HUGE > > > flag seems to me less confusing than saying "from kernel x.y you can use > > > MFD_CREATE | MFD_SECRET | MFD_HUGE" etc for all possible combinations. > > > > I really fail to see your point. This is a standard model we have. It is > > quite natural that flags are added. Moreover adding a new syscall will > > not make it any less of a problem. > > Nowadays adding a new syscall is not as costly as it used to be. And I > think it'll provide better extensibility when new features would be added > to secretmem. > > For instance, for creating a secretmem fd backed with sealing we'd have > > memfd_secretm(SECRETMEM_HUGE); You mean SECRETMEM_HUGE_1G_AND_SEALED or SECRET_HUGE_2MB_WITHOUT_SEALED? This would be rather an antipatern to our flags design, no? Really there are orthogonal requirements here and there is absolutely zero reason to smash everything into a single thing. It is just perfectly fine to combine those functionalities without a pre-described way how to do that. > rather than > > memfd_create(MFD_ALLOW_SEALING | MFD_HUGETLB | MFD_SECRET); > > > Besides, if we overload memfd_secret we add complexity to flags validation > of allowable flag combinations even with the simplest initial > implementation. This is the least of my worry, really. The existing code in memfd_create, unlike others legacy interfaces, allows extensions just fine. > And what it will become when more features are added to secretmem? Example? > > > > I by no means do not insist one way or the other but from what I have > > > > seen so far I have a feeling that the interface hasn't been thought > > > > through enough. > > > > > > It has been, but we have different thoughts about it ;-) > > > > Then you must be carrying a lot of implicit knowledge which I want you > > to document. > > I don't have any implicit knowledge, we just have a different perspective. OK, I will stop discussing now because it doesn't really seem to lead anywhere. Just to recap my current understanding. Your main argument so far is that this is somehow special and you believe it would be confusing to use an existing interface. I beg to disagree here because memfd interface is exactly a way to get a file handle to describe a memory which is what you want. About the only thing that secretmem is special is that it only operates on mapped areas and read/write interface is not supported (but I do not see a fundamental reason this couldn't be added in the future). All the rest is just operating on a memory backed file. I envison the hugetlb support will follow and sealing sounds like a useful thing to be requested as well. All that would have to be added to a new syscall over time and then we will land at two parallel interface supporting a largerly overlapping feature set. To me all the above sounds to be much stronher argument than your worry this might be confusing. I will not insist on this but you should have some more thought on those arguments. -- Michal Hocko SUSE Labs
Re: [PATCH] tpm: ibmvtpm: Avoid -EINTR error when IMA talks to TPM
On Tue, Feb 09, 2021 at 05:13:39PM -0500, Stefan Berger wrote:
> When IMA is taking measurements during compilation for example and a
> user presses ctrl-c to abort the compilation, lots of these types of
> messages will appear in the kernel log:
>
> [ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4
> [ 7406.275242] ima: Error Communicating to TPM chip, result: -4
>
> The issue is caused by the fact that the IBM vTPM driver's recv()
> function is called immediately after send() without waiting for
> status on whether a response was received. It currently waits for
> the current command to finish using this call that ends up throwing
> these error messages because it is 'interruptible':
Why it is an issue?
> sig = wait_event_interruptible(ibmvtpm->wq,
>!ibmvtpm->tpm_processing_cmd);
>
> Instead, it should be using the polling loop in tpm_try_transmit()
> that uses a command's duration to poll until a result has been
> returned by the TPM, thus ending when the timeout has occurred but
> not responding to users' ctrl-c request anymore. To stay in this
> polling loop we now extend tpm_ibmvtpm_status() to return
> PM_STATUS_BUSY for as long as the vTPM is busy. Since we will need
> the timeouts in this loop now we get the TPM 1.2 and TPM 2 timeouts
> with tpm_get_timeouts().
>
> We change tpm_processing_cmd to tpm_status and set the TPM_STATUS_BUSY
> flag while the vTPM is busy processing a command.
Please, never use "we". The commit message should describe in
imperative form the action taken.
>
> Signed-off-by: Stefan Berger
> Fixes: 18b3670d79ae9 ("tpm: ibmvtpm: Add support for TPM2")
> Cc: Nayna Jain
> Cc: George Wilson
Your SOB should be last.
> ---
> drivers/char/tpm/tpm_ibmvtpm.c | 31 ++-
> drivers/char/tpm/tpm_ibmvtpm.h | 3 ++-
> 2 files changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
> index 994385bf37c0..6290bd8889e4 100644
> --- a/drivers/char/tpm/tpm_ibmvtpm.c
> +++ b/drivers/char/tpm/tpm_ibmvtpm.c
> @@ -106,17 +106,12 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8
> *buf, size_t count)
> {
> struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
> u16 len;
> - int sig;
>
> if (!ibmvtpm->rtce_buf) {
> dev_err(ibmvtpm->dev, "ibmvtpm device is not ready\n");
> return 0;
> }
>
> - sig = wait_event_interruptible(ibmvtpm->wq,
> !ibmvtpm->tpm_processing_cmd);
> - if (sig)
> - return -EINTR;
> -
> len = ibmvtpm->res_len;
>
> if (count < len) {
> @@ -220,11 +215,12 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8
> *buf, size_t count)
> return -EIO;
> }
>
> - if (ibmvtpm->tpm_processing_cmd) {
> + if ((ibmvtpm->tpm_status & TPM_STATUS_BUSY)) {
> dev_info(ibmvtpm->dev,
>"Need to wait for TPM to finish\n");
> /* wait for previous command to finish */
> - sig = wait_event_interruptible(ibmvtpm->wq,
> !ibmvtpm->tpm_processing_cmd);
> + sig = wait_event_interruptible(ibmvtpm->wq,
> + (ibmvtpm->tpm_status & TPM_STATUS_BUSY) == 0);
> if (sig)
> return -EINTR;
> }
> @@ -237,7 +233,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8
> *buf, size_t count)
>* set the processing flag before the Hcall, since we may get the
>* result (interrupt) before even being able to check rc.
>*/
> - ibmvtpm->tpm_processing_cmd = true;
> + ibmvtpm->tpm_status |= TPM_STATUS_BUSY;
>
> again:
> rc = ibmvtpm_send_crq(ibmvtpm->vdev,
> @@ -255,7 +251,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8
> *buf, size_t count)
> goto again;
> }
> dev_err(ibmvtpm->dev, "tpm_ibmvtpm_send failed rc=%d\n", rc);
> - ibmvtpm->tpm_processing_cmd = false;
> + ibmvtpm->tpm_status &= ~TPM_STATUS_BUSY;
> }
>
> spin_unlock(&ibmvtpm->rtce_lock);
> @@ -269,7 +265,9 @@ static void tpm_ibmvtpm_cancel(struct tpm_chip *chip)
>
> static u8 tpm_ibmvtpm_status(struct tpm_chip *chip)
> {
> - return 0;
> + struct ibmvtpm_dev *ibmvtpm = dev_get_drvdata(&chip->dev);
> +
> + return ibmvtpm->tpm_status;
> }
>
> /**
> @@ -459,7 +457,7 @@ static const struct tpm_class_ops tpm_ibmvtpm = {
> .send = tpm_ibmvtpm_send,
> .cancel = tpm_ibmvtpm_cancel,
> .status = tpm_ibmvtpm_status,
> - .req_complete_mask = 0,
> + .req_complete_mask = TPM_STATUS_BUSY,
> .req_complete_val = 0,
> .req_canceled = tpm_ibmvtpm_req_canceled,
> };
> @@ -552,7 +550,7 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
> case VTPM_TPM_COMMAND_RES:
> /* len of the data in rtce buffer */
>
Re: [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
Hey Nicolas,
Thanks for submitting this, making these flags more intuitive is really nice.
This looks good to me, feel free to add my r-b.
Reviewed-by: Robert Foss
On Thu, 11 Feb 2021 at 04:34, Nicolas Boichat wrote:
>
> Many of the DSI flags have names opposite to their actual effects,
> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> be disabled. Fix this by including _NO_ in the flag names, e.g.
> MIPI_DSI_MODE_NO_EOT_PACKET.
>
> Signed-off-by: Nicolas Boichat
> ---
> I considered adding _DISABLE_ instead, but that'd make the
> flag names a big too long.
>
> Generated with:
> flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
> flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
> flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
> xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
> (then minor format changes)
>
> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
> drivers/gpu/drm/bridge/tc358768.c| 2 +-
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> drivers/gpu/drm/msm/dsi/dsi_host.c | 8
> drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
> drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
> drivers/gpu/drm/panel/panel-khadas-ts050.c | 2 +-
> drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 +-
> drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
> drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
> drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
> drivers/gpu/drm/panel/panel-simple.c | 2 +-
> drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
> drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
> include/drm/drm_mipi_dsi.h | 8
> 25 files changed, 36 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> index aa19d5a40e31..59d718bde8c4 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7533.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7533.c
> @@ -165,7 +165,7 @@ int adv7533_attach_dsi(struct adv7511 *adv)
> dsi->lanes = adv->num_dsi_lanes;
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
> + MIPI_DSI_MODE_NO_EOT_PACKET |
> MIPI_DSI_MODE_VIDEO_HSE;
>
> ret = mipi_dsi_attach(dsi);
> if (ret < 0) {
> diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
> b/drivers/gpu/drm/bridge/analogix/anx7625.c
> index 65cc05982f82..beecfe6bf359 100644
> --- a/drivers/gpu/drm/bridge/analogix/anx7625.c
> +++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
> @@ -1334,7 +1334,7 @@ static int anx7625_attach_dsi(struct anx7625_data *ctx)
> dsi->format = MIPI_DSI_FMT_RGB888;
> dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> - MIPI_DSI_MODE_EOT_PACKET|
> + MIPI_DSI_MODE_NO_EOT_PACKET |
> MIPI_DSI_MODE_VIDEO_HSE;
>
> if (mipi_dsi_attach(dsi) < 0) {
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c
> index 76373e31df92..34aa24269a57 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -829,7 +829,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> tmp = DIV_ROUND_UP(dsi_cfg.htotal, nlanes) -
> DIV_ROUND_UP(dsi_cfg.hsa, nlanes);
>
> - if (!(output->dev->mode_flags & MIPI_DSI_MODE_EOT_PACKET))
> + if (!(output->dev->mode_flags & MIPI_DSI_MODE_NO_EOT_PACKET))
> tmp -= DIV_ROUND_UP(DSI_EOT_PKT_SIZE, nlanes);
>
> tx_byte_period = DIV_ROUND_DOWN_ULL((u64)NSEC_PER_SEC * 8,
> @@ -902,7 +902,7 @@ static void cdns_dsi_bridge_enable(struct drm_bridge
> *bridge)
> tmp =
Re: [PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
On 12-02-21, 09:54, Greg KH wrote: > On Fri, Feb 12, 2021 at 09:44:04AM +0100, Johan Hovold wrote: > > On Fri, Feb 12, 2021 at 01:48:35PM +0530, Pritthijit Nath wrote: > > > Fixed the spelling of 'transfered' to 'transferred'. > > > > > > Signed-off-by: Pritthijit Nath > > > --- > > > drivers/staging/greybus/hid.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c > > > index a56c3fb5d35a..6b19ff4743a9 100644 > > > --- a/drivers/staging/greybus/hid.c > > > +++ b/drivers/staging/greybus/hid.c > > > @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct > > > hid_device *hid, __u8 *buf, > > > > > > ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); > > > if (report_id && ret >= 0) > > > - ret++; /* add report_id to the number of transfered bytes */ > > > + ret++; /* add report_id to the number of transferrid bytes */ > > > > You now misspelled transferred in a different way. > > Oops, will go revert this, I need more coffee... Yeah, its Friday.. You need a break too :) -- viresh
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On 12-02-21, 13:48, Pritthijit Nath wrote:
> This change fixes a checkpatch CHECK style issue for "Alignment should match
> open parenthesis".
>
> Signed-off-by: Pritthijit Nath
> ---
> drivers/staging/greybus/hid.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
> index ed706f39e87a..a56c3fb5d35a 100644
> --- a/drivers/staging/greybus/hid.c
> +++ b/drivers/staging/greybus/hid.c
> @@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
> }
>
> static int __gb_hid_get_raw_report(struct hid_device *hid,
> - unsigned char report_number, __u8 *buf, size_t count,
> - unsigned char report_type)
> +unsigned char report_number, __u8 *buf,
> size_t count,
> +unsigned char report_type)
> {
> struct gb_hid *ghid = hid->driver_data;
> int ret;
I can't even count the number of attempts we have seen in previous
years to make checkpatch --strict happy for greybus.
I say we make this change once and for all across greybus, so we don't
have to review or NAK someone afterwards.
Should I send a patch for this ?
--
viresh
[PATCH v6 0/3] perf vendor events: Support PMU events for A64FX
This patch series supports A64FX PMU event v1.2. The first patch add more common and microarchitecture events. This patch is based on john's patch [1]. The second patch fixes the lexical definition of event name so that perf can recognize event name that start with a number. The third patch adds PMU events for A64FX. Changes in v5: - Removed john's patch [1] from this patch series. - Added the missing Reviewed-by tag to the patch. - Fixed the base of the patch series.[2] - Changed subject from fix to added. Changes in v4: - Add arm64 to the subjects of the second and fourth patches. - Add reference URLs to the body of the second patch. Changes in v3: - Add linux-arm-kernel mailing list to cc. Changes in v2: - Added armv8-common-and-microarch based on John's patch.[1] - Fixed A64FX Json to refer to standard events in armv8-common-and-microarch. [1] https://lore.kernel.org/lkml/1611835236-34696-3-git-send-email-john.ga...@huawei.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core Shunsuke Nakamura (3): perf vendor events arm64: Add more common and uarch events perf tools: Add lexical definition of event name perf vendor events arm64: Add Fujitsu A64FX pmu event .../arm64/armv8-common-and-microarch.json | 228 ++ .../arch/arm64/fujitsu/a64fx/branch.json | 8 + .../arch/arm64/fujitsu/a64fx/bus.json | 62 + .../arch/arm64/fujitsu/a64fx/cache.json | 128 ++ .../arch/arm64/fujitsu/a64fx/cycle.json | 5 + .../arch/arm64/fujitsu/a64fx/exception.json | 29 +++ .../arch/arm64/fujitsu/a64fx/instruction.json | 131 ++ .../arch/arm64/fujitsu/a64fx/memory.json | 8 + .../arch/arm64/fujitsu/a64fx/other.json | 188 +++ .../arch/arm64/fujitsu/a64fx/pipeline.json| 194 +++ .../arch/arm64/fujitsu/a64fx/sve.json | 110 + tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 + tools/perf/util/parse-events.l| 2 +- 13 files changed, 1093 insertions(+), 1 deletion(-) create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/branch.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/bus.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/cache.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/cycle.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/exception.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/instruction.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/memory.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/other.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/pipeline.json create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/sve.json -- 2.25.1
[PATCH v6 1/3] perf vendor events arm64: Add more common and uarch events
Add the following events.[1]
Common architectural events:
- L2I_TLB_REFILL
- L2I_TLB
- SIMD_INST_RETIRED
- SVE_INST_RETIRED
Common microarchitectural events:
- UOP_SPEC
- SVE_MATH_SPEC
- FP_SPEC
- FP_FMA_SPEC
- FP_RECPE_SPEC
- FP_CVT_SPEC
- ASE_SVE_INT_SPEC
- SVE_PRED_SPEC
- SVE_MOVPRFX_SPEC
- SVE_MOVPRFX_U_SPEC
- ASE_SVE_LD_SPEC
- ASE_SVE_ST_SPEC
- PRF_SPEC
- BASE_LD_REG_SPEC
- BASE_ST_REG_SPEC
- SVE_LDR_REG_SPEC
- SVE_STR_REG_SPEC
- SVE_LDR_PREG_SPEC
- SVE_STR_PREG_SPEC
- SVE_PRF_CONTIG_SPEC
- ASE_SVE_LD_MULTI_SPEC
- ASE_SVE_ST_MULTI_SPEC
- SVE_LD_GATHER_SPEC
- SVE_ST_SCATTER_SPEC
- SVE_PRF_GATHER_SPEC
- SVE_LDFF_SPEC
- FP_SCALE_OPS_SPEC
- FP_FIXED_OPS_SPEC
- FP_HP_SCALE_OPS_SPEC
- FP_HP_FIXED_OPS_SPEC
- FP_SP_SCALE_OPS_SPEC
- FP_SP_FIXED_OPS_SPEC
- FP_DP_SCALE_OPS_SPEC
- FP_DP_FIXED_OPS_SPEC
Reference document is at the following:
[1] https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_PMU_Events_v1.2.pdf
Signed-off-by: Shunsuke Nakamura
Reviewed-by: John Garry
---
.../arm64/armv8-common-and-microarch.json | 228 ++
1 file changed, 228 insertions(+)
diff --git a/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
index 75376c7cc072..913fb200ea52 100644
--- a/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
+++ b/tools/perf/pmu-events/arch/arm64/armv8-common-and-microarch.json
@@ -209,12 +209,24 @@
"EventName": "L2D_TLB_REFILL",
"BriefDescription": "Attributable Level 2 data TLB refill"
},
+{
+"PublicDescription": "Attributable Level 2 instruction TLB refill.",
+"EventCode": "0x2E",
+"EventName": "L2I_TLB_REFILL",
+"BriefDescription": "Attributable Level 2 instruction TLB refill."
+},
{
"PublicDescription": "Attributable Level 2 data or unified TLB access",
"EventCode": "0x2F",
"EventName": "L2D_TLB",
"BriefDescription": "Attributable Level 2 data or unified TLB access"
},
+{
+"PublicDescription": "Attributable Level 2 instruction TLB access.",
+"EventCode": "0x30",
+"EventName": "L2I_TLB",
+"BriefDescription": "Attributable Level 2 instruction TLB access."
+},
{
"PublicDescription": "Access to another socket in a multi-socket
system",
"EventCode": "0x31",
@@ -244,5 +256,221 @@
"EventCode": "0x37",
"EventName": "LL_CACHE_MISS_RD",
"BriefDescription": "Last level cache miss, read"
+},
+{
+"PublicDescription": "SIMD Instruction architecturally executed.",
+"EventCode": "0x8000",
+"EventName": "SIMD_INST_RETIRED",
+"BriefDescription": "SIMD Instruction architecturally executed."
+},
+{
+"PublicDescription": "Instruction architecturally executed, SVE.",
+"EventCode": "0x8002",
+"EventName": "SVE_INST_RETIRED",
+"BriefDescription": "Instruction architecturally executed, SVE."
+},
+{
+"PublicDescription": "Microarchitectural operation, Operations
speculatively executed.",
+"EventCode": "0x8008",
+"EventName": "UOP_SPEC",
+"BriefDescription": "Microarchitectural operation, Operations
speculatively executed."
+},
+{
+"PublicDescription": "SVE Math accelerator Operations speculatively
executed.",
+"EventCode": "0x800E",
+"EventName": "SVE_MATH_SPEC",
+"BriefDescription": "SVE Math accelerator Operations speculatively
executed."
+},
+{
+"PublicDescription": "Floating-point Operations speculatively
executed.",
+"EventCode": "0x8010",
+"EventName": "FP_SPEC",
+"BriefDescription": "Floating-point Operations speculatively executed."
+},
+{
+"PublicDescription": "Floating-point FMA Operations speculatively
executed.",
+"EventCode": "0x8028",
+"EventName": "FP_FMA_SPEC",
+"BriefDescription": "Floating-point FMA Operations speculatively
executed."
+},
+{
+"PublicDescription": "Floating-point reciprocal estimate Operations
speculatively executed.",
+"EventCode": "0x8034",
+"EventName": "FP_RECPE_SPEC",
+"BriefDescription": "Floating-point reciprocal estimate Operations
speculatively executed."
+},
+{
+"PublicDescription": "floating-point convert Operations speculatively
executed.",
+"EventCode": "0x8038",
+"EventName": "FP_CVT_SPEC",
+"BriefDescription": "floating-point convert Operations speculatively
executed."
+},
+{
+"PublicDescription": "Advanced SIMD and SVE integer Operations
speculatively executed.",
+"EventCode": "0x8043",
+"EventName": "ASE_SVE_INT_SPEC",
+"BriefDescription": "Advanced SIMD and SVE integer Operations
speculatively executed."
+},
[PATCH v6 3/3] perf vendor events arm64: Add Fujitsu A64FX pmu event
Add pmu events for A64FX.
Documentation source:
https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_PMU_Events_v1.2.pdf
Signed-off-by: Shunsuke Nakamura
---
.../arch/arm64/fujitsu/a64fx/branch.json | 8 +
.../arch/arm64/fujitsu/a64fx/bus.json | 62 ++
.../arch/arm64/fujitsu/a64fx/cache.json | 128
.../arch/arm64/fujitsu/a64fx/cycle.json | 5 +
.../arch/arm64/fujitsu/a64fx/exception.json | 29 +++
.../arch/arm64/fujitsu/a64fx/instruction.json | 131
.../arch/arm64/fujitsu/a64fx/memory.json | 8 +
.../arch/arm64/fujitsu/a64fx/other.json | 188 +
.../arch/arm64/fujitsu/a64fx/pipeline.json| 194 ++
.../arch/arm64/fujitsu/a64fx/sve.json | 110 ++
tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 +
11 files changed, 864 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/branch.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/bus.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/cache.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/cycle.json
create mode 100644
tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/exception.json
create mode 100644
tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/instruction.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/memory.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/other.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/pipeline.json
create mode 100644 tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/sve.json
diff --git a/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/branch.json
b/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/branch.json
new file mode 100644
index ..b011af11bf94
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/branch.json
@@ -0,0 +1,8 @@
+[
+ {
+"ArchStdEvent": "BR_MIS_PRED"
+ },
+ {
+"ArchStdEvent": "BR_PRED"
+ }
+]
diff --git a/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/bus.json
b/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/bus.json
new file mode 100644
index ..084e88d7df73
--- /dev/null
+++ b/tools/perf/pmu-events/arch/arm64/fujitsu/a64fx/bus.json
@@ -0,0 +1,62 @@
+[
+ {
+"PublicDescription": "This event counts read transactions from tofu
controller to measured CMG.",
+"EventCode": "0x314",
+"EventName": "BUS_READ_TOTAL_TOFU",
+"BriefDescription": "This event counts read transactions from tofu
controller to measured CMG."
+ },
+ {
+"PublicDescription": "This event counts read transactions from PCI
controller to measured CMG.",
+"EventCode": "0x315",
+"EventName": "BUS_READ_TOTAL_PCI",
+"BriefDescription": "This event counts read transactions from PCI
controller to measured CMG."
+ },
+ {
+"PublicDescription": "This event counts read transactions from measured
CMG local memory to measured CMG.",
+"EventCode": "0x316",
+"EventName": "BUS_READ_TOTAL_MEM",
+"BriefDescription": "This event counts read transactions from measured CMG
local memory to measured CMG."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to CMG0, if measured CMG is not CMG0.",
+"EventCode": "0x318",
+"EventName": "BUS_WRITE_TOTAL_CMG0",
+"BriefDescription": "This event counts write transactions from measured
CMG to CMG0, if measured CMG is not CMG0."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to CMG1, if measured CMG is not CMG1.",
+"EventCode": "0x319",
+"EventName": "BUS_WRITE_TOTAL_CMG1",
+"BriefDescription": "This event counts write transactions from measured
CMG to CMG1, if measured CMG is not CMG1."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to CMG2, if measured CMG is not CMG2.",
+"EventCode": "0x31A",
+"EventName": "BUS_WRITE_TOTAL_CMG2",
+"BriefDescription": "This event counts write transactions from measured
CMG to CMG2, if measured CMG is not CMG2."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to CMG3, if measured CMG is not CMG3.",
+"EventCode": "0x31B",
+"EventName": "BUS_WRITE_TOTAL_CMG3",
+"BriefDescription": "This event counts write transactions from measured
CMG to CMG3, if measured CMG is not CMG3."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to tofu controller.",
+"EventCode": "0x31C",
+"EventName": "BUS_WRITE_TOTAL_TOFU",
+"BriefDescription": "This event counts write transactions from measured
CMG to tofu controller."
+ },
+ {
+"PublicDescription": "This event counts write transactions from measured
CMG to PCI controller.",
+"EventCode": "0x31D",
+"EventName": "BUS_WRITE_TOTAL_PCI",
+"BriefDescription": "This event counts
[PATCH v6 2/3] perf tools: Add lexical definition of event name
Add the lexical definition of event name so that the numbers are recognizable.
A64FX defines an event name that starts with a number.
- 0inst_commit
- 1inst_commit
- 2inst_commit
- 3inst_commit
- 4inst_commit
Signed-off-by: Shunsuke Nakamura
---
tools/perf/util/parse-events.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 0b36285a9435..33f627187415 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -205,7 +205,7 @@ bpf_source [^,{}]+\.c[a-zA-Z0-9._]*
num_dec[0-9]+
num_hex0x[a-fA-F0-9]+
num_raw_hex[a-fA-F0-9]+
-name [a-zA-Z_*?\[\]][a-zA-Z0-9_*?.\[\]]*
+name [a-zA-Z0-9_*?\[\]][a-zA-Z0-9_*?.\[\]]*
name_tag [\'][a-zA-Z_*?\[\]][a-zA-Z0-9_*?\-,\.\[\]:=]*[\']
name_minus [a-zA-Z_*?][a-zA-Z0-9\-_*?.:]*
drv_cfg_term [a-zA-Z0-9_\.]+(=[a-zA-Z0-9_*?\.:]+)?
--
2.25.1
Re: [PATCH RESEND] regulator: bd718x7, bd71828, Fix dvs voltage levels
On Fri, 12 Feb 2021, Matti Vaittinen wrote:
> The ROHM BD718x7 and BD71828 drivers support setting HW state
> specific voltages from device-tree. This is used also by various
> in-tree DTS files.
>
> These drivers do incorrectly try to compose bit-map using enum
> values. By a chance this works for first two valid levels having
> values 1 and 2 - but setting values for the rest of the levels
> do indicate capability of setting values for first levels as
> well. Luckily the regulators which support setting values for
> SUSPEND/LPSR do usually also support setting values for RUN
> and IDLE too - thus this has not been such a fatal issue.
>
> Fix this by defining the old enum values as bits and fixing the
> parsing code. This allows keeping existing IC specific drivers
> intact and only slightly changing the rohm-regulator.c
>
> Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7
> specific parts")
> Signed-off-by: Matti Vaittinen
> ---
>
> I just noticed this fix never made it in-tree. So this is a resend of a
> resend :)
Not sure what you mean. Isn't this patch part of:
[PATCH v2 00/17] Support ROHM BD71815 PMIC
... which has just been reviewed and is awaiting rework?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On Fri, Feb 12, 2021 at 02:39:26PM +0530, Viresh Kumar wrote:
> On 12-02-21, 13:48, Pritthijit Nath wrote:
> > This change fixes a checkpatch CHECK style issue for "Alignment should match
> > open parenthesis".
> >
> > Signed-off-by: Pritthijit Nath
> > ---
> > drivers/staging/greybus/hid.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
> > index ed706f39e87a..a56c3fb5d35a 100644
> > --- a/drivers/staging/greybus/hid.c
> > +++ b/drivers/staging/greybus/hid.c
> > @@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
> > }
> >
> > static int __gb_hid_get_raw_report(struct hid_device *hid,
> > - unsigned char report_number, __u8 *buf, size_t count,
> > - unsigned char report_type)
> > + unsigned char report_number, __u8 *buf,
> > size_t count,
> > + unsigned char report_type)
> > {
> > struct gb_hid *ghid = hid->driver_data;
> > int ret;
>
> I can't even count the number of attempts we have seen in previous
> years to make checkpatch --strict happy for greybus.
>
> I say we make this change once and for all across greybus, so we don't
> have to review or NAK someone afterwards.
>
> Should I send a patch for this ?
Sure, but note that over time, checkpatch adds new things so there will
always be something to change in here, until we move it out of the
drivers/staging/ area :)
I need to go fix up the greybus vibrator patch which was my first
attempt at getting back into that effort...
thanks,
greg k-h
Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas
On 12.02.21 00:09, Mike Rapoport wrote: On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: On 11.02.21 12:27, Mike Rapoport wrote: On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: So let's talk about the main user-visible differences to other memfd files (especially, other purely virtual files like hugetlbfs). With secretmem: - File content can only be read/written via memory mappings. - File content cannot be swapped out. I think there are still valid ways to modify file content using syscalls: e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just fine. These work perfectly with any file, so maybe we should have added memfd_create as a flag to open(2) back then and now the secretmem file descriptors? I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently. Also, open() might open existing files - memfd always creates new files. AFAIKS, we would need MFD_SECRET and disallow MFD_ALLOW_SEALING and MFD_HUGETLB. So here we start to multiplex. Yes. And as Michal said, maybe we can support combinations in the future. Isn't there a general agreement that syscall multiplexing is not a good thing? Looking at mmap(), madvise(), fallocate(), I think multiplexing is just fine and flags can be mutually exclusive - as long as we're not squashing completely unrelated things into a single system call. As one example: we don't have mmap_private() vs. mmap_shared() vs. mmap_shared_validate(). E.g., MAP_SYNC is only available for MAP_SHARED_VALIDATE. memfd_create already has flags validation that does not look very nice. I assume you're talking about the hugetlb size specifications, right? It's not nice but fairly compact. Adding there only MFD_SECRET will make it a bit less nice, but when we'll grow new functionality into secretmem that will become horrible. What do you have in mind? A couple of MFD_SECRET_* flags that only work with MFD_SECRET won't hurt IMHO. Just like we allow MFD_HUGE_* only with MFD_HUGETLB. Thanks, David / dhildenb
Re: [PATCH 00/21] [Set 2] Rid W=1 warnings from Clock
On Thu, 11 Feb 2021, Stephen Boyd wrote: > Quoting Lee Jones (2021-02-11 13:10:54) > > On Thu, 11 Feb 2021, Stephen Boyd wrote: > > > > > Quoting Lee Jones (2021-01-26 04:45:19) > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > > > This is the last set. Clock is clean after this. > > > > > > Is it possible to slam in some patch that makes W=1 the default for the > > > clk directory? I'm trying to avoid seeing this patch series again. > > > > One of my main goals of this project is that everyone (contributors, > > maintainers auto-builder robots etc) will be enabling W=1 builds > > *locally*. > > > > This isn't something you'll want to do at a global (i.e. in Mainline) > > level. That's kinda the point of W=1. > > > > Agreed, but is it possible to pass W=1 in the drivers/clk/Makefile? That would circumvent the point of W=1. Level-1 warnings are deemed, and I'm paraphrasing/making this up "not worth rejecting pull-requests over". In contrast, if Linus catches any W=0 warnings at pull-time, he will reject the pull-request as 'untested'. W=1 is defiantly something you'll want to enable locally though, and subsequently push back on contributors submitting code adding new ones. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On 12-02-21, 10:17, Greg KH wrote:
> On Fri, Feb 12, 2021 at 02:39:26PM +0530, Viresh Kumar wrote:
> > On 12-02-21, 13:48, Pritthijit Nath wrote:
> > > This change fixes a checkpatch CHECK style issue for "Alignment should
> > > match
> > > open parenthesis".
> > >
> > > Signed-off-by: Pritthijit Nath
> > > ---
> > > drivers/staging/greybus/hid.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c
> > > index ed706f39e87a..a56c3fb5d35a 100644
> > > --- a/drivers/staging/greybus/hid.c
> > > +++ b/drivers/staging/greybus/hid.c
> > > @@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
> > > }
> > >
> > > static int __gb_hid_get_raw_report(struct hid_device *hid,
> > > - unsigned char report_number, __u8 *buf, size_t count,
> > > - unsigned char report_type)
> > > +unsigned char report_number, __u8 *buf,
> > > size_t count,
> > > +unsigned char report_type)
> > > {
> > > struct gb_hid *ghid = hid->driver_data;
> > > int ret;
> >
> > I can't even count the number of attempts we have seen in previous
> > years to make checkpatch --strict happy for greybus.
> >
> > I say we make this change once and for all across greybus, so we don't
> > have to review or NAK someone afterwards.
> >
> > Should I send a patch for this ?
>
> Sure, but note that over time, checkpatch adds new things so there will
> always be something to change in here, until we move it out of the
> drivers/staging/ area :)
Right, though I wasn't worried about other checkpatch warning but
specially the "alignment - parenthesis" one. Everyone (specially
newbies) want to fix that everywhere :)
--
viresh
Re: [PATCH 3/3] i2c: i2c-qcom-geni: Add support for 'assigned-performance-states'
On 2021-01-20 19:01, Ulf Hansson wrote: On Tue, 19 Jan 2021 at 12:05, Viresh Kumar wrote: On 19-01-21, 12:02, Ulf Hansson wrote: > As a matter of fact this was quite recently discussed [1], which also > pointed out some issues when using the "required-opps" in combination, > but perhaps that got resolved? Viresh? Perhaps we never did anything there .. Okay. Looks like we should pick up that discussion again, to conclude on how to move forward. Soft Reminder! -- viresh Kind regards Uffe - Roja
Re: [PATCH v5 1/2] dt-bindings: counter: add event-counter binding
On Wed, Feb 10, 2021 at 7:41 PM Rob Herring wrote: > On Mon, Feb 08, 2021 at 02:53:46PM +0100, Oleksij Rempel wrote: > > + interrupts: > > +maxItems: 1 > > + > > + gpios: > > +description: Optional diagnostic interface to measure signal level > > This description seems wrong in the case of only having a GPIO. > > Also, a GPIO only implies polled mode because if the GPIO is interrupt > capable, 'interrupts' should be required. For gpio-keys, we split the > compatible strings in this case. I leave it to you if you want to make > it more explicit. Ouch. This is a bit of semantic confusion where I see different things if I put my Linux hat on than if I put my DT hat on ... :/ Linux (or some other OS I suppose) has the ability to look up an interrupt resource for a GPIO line and that is used quite extensively. In this case it is certainly possible to write a Linux driver that only take a GPIO resource and looks up a corresponding interrupt without the involvement of any DT interrupt resources. This happens a lot. A typical example is cd-gpios in Documentation/devicetree/bindings/mmc/mmc-controller.yaml The operating system will take cd-gpios and infer the corresponding IRQ from the GPIO hardware by OS-internal mechanisms (in the Linux case simply using irqdomain) in almost cases, and that is how that is used today. It is an hardware interrupt that gets allocated and used but the DT is blissfully ignorant about. The reason is that GPIO is "general purpose" so they don't have very specific use cases and the interrupts are general purpose as well. A certain GPIO line may not even have a certain interrupt associated with it: there exist GPIO controllers with e.g. 32 GPIO lines but only 8 interrupts that can be assigned to GPIO lines on a first-come-first-serve basis so there could not be anything like a cell in the bindings pointing to a certain interrupt: it has to be resolved by software, at runtime. In many cases the corresponsing GPIO hardware will have both gpio-controller and interrupt-controller flags, but I bet there exist cases that are only flagged with gpio-controller and then the drivers in the OS goes and implement interrupts using its abstractions and assign them anyway. I don't know if this can be solved in a generic way (solved as in DT needs to know all about the systems interrupt resources, and the OS should not be handing out interrupts behind the back of the DT description for things that are not flagged as interrupt-controller) or if this ambiguity around GPIO chips just has to stay around forever. I think it may be one of those cases where DT bindings can't be all that imperialistic about controlling every resource, but there may be other views on this. Yours, Linus Walleij
Re: [PATCH net-next] misc: Add Renesas Synchronization Management Unit (SMU) support
On Fri, Feb 12, 2021 at 2:40 AM Min Li wrote: > > There should probably be a description of the purpose of the hardware both > > here and in the patch description. > > > > In particular, please explain how it relates to the existing clockmatrix > > driver. > > I just uploaded v2 patch to provide more background info for this change. It appears that you accidentally dropped the Cc list, adding them back in the reply. Also adding the PTP maintainer, as this clearly needs to be reviewed in the context of the PTP subsystem. Please keep Richard and the netdev list on Cc in future submissions. > This driver is developed to be only used by Renesas PTP Clock Manager for > Linux (pcm4l) software. > > This driver supports 1588/PTP releated functionalities that > specific to Renesas devices but are not supported by general PHC framework. > So pcm4l will use both the existing PHC driver and this driver to complete > 1588/PTP support. Ah, so if this is for a PTP related driver, it should probably be integrated into the PTP subsystem rather than being a separate class. > > A pure list of register values seems neither particular portable nor > > intuitive. > > How is a user expected to interpret these, and are you sure that any driver > > for this class would have the same interpretation at the same register > > index? > > > > Yes we need a way to dump register values when remote debugging with > customers. > And all the Renesas SMU has similar register layout A sysfs interface is a poor choice for this though -- how can you guarantee that even future Renesas devices follow the exact same register layout? By encoding the current hardware generation into the user interface, you would end up having to emulate this on other chips you want to support later. If it's only for debugging, best leave it out of the public interface, and only have it in your own copy of the driver until the bugs are gone, or add a debugfs interface. > > Can you explain the purpose of this restriction? Why is it ok for two > > threads > > to access the same file descriptor, but not two different file descriptors > > for > > the same device? > > > > The mutex is there to provide synchronization to the device access while PHC > driver is accessing the device. > The atomic count is to make sure only one user space program is using the > driver at a time. Then remove the atomic count, as it clearly doesn't do what you describe when you can have multiple threads access the driver concurrently. > > Each of these needs a device tree binding. It's usually better to name the > > compatible strings according to the chips that contain this hardware, such > > as > > "renesas,r8a1234567-rsmucdev" instead of "renesas,rsmu-cdev0". > > > > Since you don't seem to about the difference between the devices, the driver > > can also just bind to one of them (usually the oldest) and then the newer > > devices contain the string as a fallback, so you don't have to update the > > driver every time another variant gets made. > > > > > > Actually the device is not spawned from device tree but from Renesas MFD > driver (submitted in a separate thread). > The MFD driver will call mfd_add_devices to create the platform devices. I am > not sure if I still need to create binding > In this case. If you have an of_device_id table, it needs a binding. It sounds like you don't need the of_device_id though. > > This should probably be part of the .c file, as no other driver needs to > > interface with it. > > > > We actually run a unit test on the driver that needs to access this structure. > That is why I need to put it in a header Unit tests are good, but it's better to have them in the kernel. Can you add the unit test into the patch then? We now have the kunit framework for running unit tests. > > This tells me that you got the abstraction the wrong way: the common files > > should not need to know anything about the specific implementations. > > > > Instead, these should be in separate modules that call exported functions > > from the common code. > > > > > > I got what you mean. But so far it only supports small set of functions, > which is why > I don't feet it is worth the effort to over abstract things. Then maybe pick one of the two hardware variants and drop the abstraction you have. You can then add more features before you add a proper abstraction layer and then the second driver. Arnd
Re: [PATCH v3] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add DSI and panel bits
Hi,
On Thu, 11 Feb 2021 at 00:25, AngeloGioacchino Del Regno
wrote:
>
> Il 10/02/21 09:18, Amit Pundir ha scritto:
> > From: Sumit Semwal
> >
> > Enabling the Display panel for beryllium requires DSI
> > labibb regulators and panel dts nodes to be added.
> > It is also required to keep some of the regulators as
> > always-on.
> >
> > Signed-off-by: Sumit Semwal
> > Signed-off-by: Amit Pundir
> > ---
>
> Hello!
> Your patch looks good, however, I have a few concerns...
>
> > v3: Addressed Konrad's concerns. Configured labibb regulators
> > explicitly based on downstream microvolt values. Display
> > comes up fine with default discharge-resistor-kohms and
> > soft-start-us properties, so didn't touch them.
> > Smoke tested on next-20210209.
> > v2: Rebased to mainline (v5.11-rc6) and fixed build warnings.
> >
> > .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 64
> > ++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > index 86cbae63eaf7..5ac049a247e1 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> > @@ -157,6 +157,14 @@
> > regulator-initial-mode = ;
> > };
> >
> > + vreg_l14a_1p8: ldo14 {
> > + regulator-min-microvolt = <180>;
> > + regulator-max-microvolt = <180>;
> > + regulator-initial-mode = ;
> > + regulator-boot-on;
> > + regulator-always-on;
> > + };
> > +
> > vreg_l17a_1p3: ldo17 {
> > regulator-min-microvolt = <1304000>;
> > regulator-max-microvolt = <1304000>;
> > @@ -191,6 +199,7 @@
> > regulator-min-microvolt = <120>;
> > regulator-max-microvolt = <120>;
> > regulator-initial-mode = ;
> > + regulator-boot-on;
> > };
> > };
> > };
> > @@ -200,6 +209,43 @@
> > firmware-name = "qcom/sdm845/cdsp.mdt";
> > };
> >
> > +&dsi0 {
> > + status = "okay";
> > + vdda-supply = <&vreg_l26a_1p2>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + panel@0 {
> > + compatible = "tianma,fhd-video";
> > + reg = <0>;
> > + vddi0-supply = <&vreg_l14a_1p8>;
> > + vddpos-supply = <&lab>;
> > + vddneg-supply = <&ibb>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
> > +
> > + port {
> > + tianma_nt36672a_in_0: endpoint {
> > + remote-endpoint = <&dsi0_out>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&dsi0_out {
> > + remote-endpoint = <&tianma_nt36672a_in_0>;
> > + data-lanes = <0 1 2 3>;
> > +};
> > +
> > +&dsi0_phy {
> > + status = "okay";
> > + vdds-supply = <&vreg_l1a_0p875>;
> > +};
> > +
> > &gcc {
> > protected-clocks = ,
> > ,
> > @@ -215,6 +261,24 @@
> > };
> > };
> >
> > +&ibb {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> I think you want to also configure overvoltage and overcurrent
> protection values for both LAB and IBB, as these regulators may be a bit
> dangerous if used without.
Can you point me to the relevant DT properties please. I didn't find
any DT properties which set the over voltage/current protection
properties explicitly in upstream as well as in downstream kernel.
Plus I also do not see "regulator-min/max-microamp" values set
downstream, otherwise I'd have used that as well atleast.
Regards,
Amit Pundir
> Besides that, even if it wouldn't be that dangerous, since the
> protection features are present, it would be nice to configure them
> properly as in the rare event that something bad happens, you would be
> able to save the hardware (or at least have a chance to!).
>
> > +&lab {
> > + regulator-min-microvolt = <460>;
> > + regulator-max-microvolt = <600>;
> > +};
> > +
>
> Same here.
>
> Yours,
> -- Angelo
>
> > +&mdss {
> > + status = "okay";
> > +};
> > +
> > +&mdss_mdp {
> > + status = "okay";
> > +};
> > +
> > &mss_pil {
> > status = "okay";
> > firmware-name = "qcom/sdm845/mba.mbn", "qcom/sdm845/modem.mdt";
> >
>
Re: [PATCH v5 2/2] counter: add IRQ or GPIO based event counter
On Mon, Feb 8, 2021 at 2:53 PM Oleksij Rempel wrote: > Add simple IRQ or GPIO base event counter. This device is used to measure > rotation speed of some agricultural devices, so no high frequency on the > counter pin is expected. > > The maximal measurement frequency depends on the CPU and system load. On > the idle iMX6S I was able to measure up to 20kHz without count drops. > > Signed-off-by: Oleksij Rempel > Reviewed-by: Ahmad Fatoum >From GPIO and interrupt point of view this driver looks good to me. I don't know about the userspace interface etc. Yours, Linus Walleij
[PATCH] nvme/hwmon: Return error code when registration fails
The hwmon pointer wont be NULL if the registration fails. Though the
exit code path will assign it to ctrl->hwmon_device. Later
nvme_hwmon_exit() will try to free the invalid pointer. Avoid this by
returning the error code from hwmon_device_register_with_info().
Fixes: ec420cdcfab4 ("nvme/hwmon: rework to avoid devm allocation")
Cc: Hannes Reinecke
Signed-off-by: Daniel Wagner
---
This patch is against linux-block/for-next.
drivers/nvme/host/hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c
index 8f9e96986780..0a586d712920 100644
--- a/drivers/nvme/host/hwmon.c
+++ b/drivers/nvme/host/hwmon.c
@@ -248,6 +248,7 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl)
if (IS_ERR(hwmon)) {
dev_warn(dev, "Failed to instantiate hwmon device\n");
kfree(data);
+ return PTR_ERR(hwmon);
}
ctrl->hwmon_device = hwmon;
return 0;
--
2.29.2
Re: [PATCH v5 1/2] dt-bindings: counter: add event-counter binding
On Mon, Feb 8, 2021 at 2:53 PM Oleksij Rempel wrote: > Add binding for the event counter node > > Signed-off-by: Oleksij Rempel Works for me: Reviewed-by: Linus Walleij > +required: > + - compatible Ideally it should be "interrupts OR gpios required" (at least one of them must be present) but I don't know if we can express that. Perhaps also write that if both are defined, the interrupt will take precedence for counting events. Yours, Linus Walleij
Re: [PATCH v2 4/4] arm: dts: visconti: Add DT support for Toshiba Visconti5 ethernet controller
On Fri, Feb 12, 2021 at 4:03 AM Nobuhiro Iwamatsu
wrote:
> @@ -384,6 +398,16 @@ spi6: spi@28146000 {
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + piether: ethernet@2800 {
> + compatible = "toshiba,visconti-dwmac";
Shouldn't there be a more specific compatible string here, as well as the
particular version of the dwmac you use?
In the binding example, you list the device as "dma-coherent",
but in this instance, it is not marked that way. Can you find out
whether the device is in fact connected properly to a cache-coherent
bus?
Note that failing to mark it as cache-coherent will make the device
rather slow and possibly not work correctly if it is in fact coherent,
but the default is non-coherent since a lot of SoCs are lacking
that hardware support.
Arnd
Re: [RFC PATCH 3/7] regulator: IRQ based event/error notification helpers
On Thu, 2021-02-11 at 14:35 +0200, Matti Vaittinen wrote:
> Provide helper function for IC's implementing regulator notifications
> when an IRQ fires. The helper also works for IRQs which can not be
> acked.
> Helper can be set to disable the IRQ at handler and then re-enabling
> it
> on delayed work later. The helper also adds
> regulator_get_error_flags()
> errors in cache for the duration of IRQ disabling.
>
> Signed-off-by: Matti Vaittinen
> ---
>
> This patch has gone through only a very limited amount of testing.
> All
> reviews / suggestions / testing is highly appreciated.
>
/* SNIP */
> +
> +static void dev_delayed_work_drop(struct device *dev, void *res)
> +{
> + cancel_delayed_work_sync(*(struct delayed_work **)res);
> +}
> +
> +int dev_delayed_work_autocancel(struct device *dev, struct
> delayed_work *w,
> + void (*worker)(struct work_struct
> *work))
> +{
> + struct delayed_work **ptr;
> +
> + ptr = devres_alloc(dev_delayed_work_drop, sizeof(*ptr),
> GFP_KERNEL);
> + if (!ptr)
> + return -ENOMEM;
> +
> + INIT_DELAYED_WORK(w, worker);
> + *ptr = w;
> + devres_add(dev, ptr);
> +
> + return 0;
> +}
> +
I got mail from build-bot. Sparse warning. Bot suggested staticizing
the dev_delayed_work_autocancel(). I should've been more careful.
It how ever made me wonder if this would actually be worth exporting?
There seems to be few drivers which need delayed wq and which implement
.remove() just to call the cancel_delayed_work_sync().
I think this might help cleaning up those(?) Or am I completely off
here?
I just did:
git grep -A15 remove |grep -B10 -A10 cancel_delayed_work_sync
in drivers directory and spotted couple of candidates like
watchdog/retu_wdt.c (should also use devm_watchdog_register_device)
regulator/qcom_spmi-regulator.c
power/supply/sbs-charger.c
power/supply/sbs-battery.c
power/supply/ltc2941-battery-gauge.c
...
And no. I am not offering to go through _all_ drivers, but I guess I
could go through at least few of them :)
And sorry for noise if this has been suggested and rejected before - I
didn't spot something like this from mail lists. (Maybe I am missing
something?)
Best Regards
Matti Vaittinen
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit
(Thanks for the translation Simon)
Re: [PATCH 08/21] clk: clkdev: Ignore suggestion to use gnu_printf() as it's not appropriate here
On Thu, 11 Feb 2021, Stephen Boyd wrote:
> Quoting Lee Jones (2021-01-26 04:45:27)
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/clk/clkdev.c: In function ‘vclkdev_alloc’:
> > drivers/clk/clkdev.c:173:3: warning: function ‘vclkdev_alloc’ might be a
> > candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
> >
> > Cc: Russell King
> > Cc: linux-arm-ker...@lists.infradead.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/clk/clkdev.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> > index 0f2e3fcf0f19f..5e5f25d568724 100644
> > --- a/drivers/clk/clkdev.c
> > +++ b/drivers/clk/clkdev.c
> > @@ -153,6 +153,11 @@ struct clk_lookup_alloc {
> > charcon_id[MAX_CON_ID];
> > };
> >
> > +#pragma GCC diagnostic push
> > +#ifndef __clang__
> > +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
> > +#endif
>
> Can this be some macro banished to compiler.h?
This is probably a question for Arnd.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: linux-next: Tree for Feb 11
On Thu 11 Feb 2021 at 22:30, Heiko Carstens wrote:
> On Thu, Feb 11, 2021 at 10:26:04PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20210210:
>>
>> The powerpc tree still had its build failure in the allyesconfig for
>> which I applied a supplied patch.
>>
>> The v4l-dvb tree lost its build failure.
>>
>> The drm-misc tree lost its build failure.
>>
>> The modules tree lost its build failure.
>>
>> The device-mapper tree gained a build failure so I used the version
>> from next-20210210.
>>
>> The tip tree lost its boot failure.
>>
>> The rcu tree gained conflicts against the block tree.
>>
>> The driver-core tree lost its build failure.
>>
>> The akpm-current tree gained conflicts against the fscache tree.
>>
>> Non-merge commits (relative to Linus' tree): 9533
>> 9470 files changed, 385794 insertions(+), 266880 deletions(-)
>>
>>
>
> Build fails on s390 using defconfig with:
>
> In file included from drivers/net/ethernet/mellanox/mlx5/core/en_tc.h:40,
> from drivers/net/ethernet/mellanox/mlx5/core/en_main.c:45:
> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:24:29: error: field
> 'match_level' has incomplete type
>24 | enum mlx5_flow_match_level match_level;
> | ^~~
> drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun.h:27:26: warning: 'struct
> mlx5e_encap_entry' declared inside parameter list will not be visible outside
> of this definition or declaration
>27 | int (*calc_hlen)(struct mlx5e_encap_entry *e);
> | ^
>
> caused by this:
> commit 0d9f96471493d5483d116c137693f03604332a04 (HEAD, refs/bisect/bad)
> Author: Vlad Buslov
> Date: Sun Jan 24 22:07:04 2021 +0200
>
> net/mlx5e: Extract tc tunnel encap/decap code to dedicated file
>
> Following patches in series extend the extracted code with routing
> infrastructure. To improve code modularity created a dedicated
> tc_tun_encap.c source file and move encap/decap related code to the new
> file. Export code that is used by both regular TC code and encap/decap
> code
> into tc_priv.h (new header intended to be used only by TC module). Rename
> some exported functions by adding "mlx5e_" prefix to their names.
>
> Signed-off-by: Vlad Buslov
> Signed-off-by: Dmytro Linkin
> Reviewed-by: Roi Dayan
> Signed-off-by: Saeed Mahameed
>
> Note: switching on NET_SWITCHDEV fixes the build error.
Hi Heiko,
This problem is supposed to be fixed by 36280f0797df ("net/mlx5e: Fix
tc_tun.h to verify MLX5_ESWITCH config"). I'm trying to reproduce with
config supplied by test robot in another thread (config: s390-defconfig)
and current net-next builds fine for me. I've also verified that config
option you mentioned is not set in that config:
$ grep NET_SWITCHDEV .config
# CONFIG_NET_SWITCHDEV is not set
Can you help me reproduce?
Thanks,
Vlad
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On Fri, Feb 12, 2021 at 02:51:30PM +0530, Viresh Kumar wrote:
> On 12-02-21, 10:17, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 02:39:26PM +0530, Viresh Kumar wrote:
> > > On 12-02-21, 13:48, Pritthijit Nath wrote:
> > > > This change fixes a checkpatch CHECK style issue for "Alignment should
> > > > match
> > > > open parenthesis".
> > > >
> > > > Signed-off-by: Pritthijit Nath
> > > > ---
> > > > drivers/staging/greybus/hid.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/greybus/hid.c
> > > > b/drivers/staging/greybus/hid.c
> > > > index ed706f39e87a..a56c3fb5d35a 100644
> > > > --- a/drivers/staging/greybus/hid.c
> > > > +++ b/drivers/staging/greybus/hid.c
> > > > @@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
> > > > }
> > > >
> > > > static int __gb_hid_get_raw_report(struct hid_device *hid,
> > > > - unsigned char report_number, __u8 *buf, size_t count,
> > > > - unsigned char report_type)
> > > > + unsigned char report_number, __u8
> > > > *buf, size_t count,
> > > > + unsigned char report_type)
> > > > {
> > > > struct gb_hid *ghid = hid->driver_data;
> > > > int ret;
> > >
> > > I can't even count the number of attempts we have seen in previous
> > > years to make checkpatch --strict happy for greybus.
> > >
> > > I say we make this change once and for all across greybus, so we don't
> > > have to review or NAK someone afterwards.
> > >
> > > Should I send a patch for this ?
> >
> > Sure, but note that over time, checkpatch adds new things so there will
> > always be something to change in here, until we move it out of the
> > drivers/staging/ area :)
>
> Right, though I wasn't worried about other checkpatch warning but
> specially the "alignment - parenthesis" one. Everyone (specially
> newbies) want to fix that everywhere :)
Sure, fix it up "right" if you want to, I'll take coding style fixes
from anyone :)
Re: [PATCH v1] gpiolib: Don't probe gpio_device if it's not the primary device
On Fri, Feb 5, 2021 at 3:07 AM Saravana Kannan wrote:
> Dmitry reported[1] boot error messages caused by
> commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default").
>
> gpio-1022 (cpu-pwr-req-hog): hogged as input
> max77620-pinctrl max77620-pinctrl: pin gpio4 already requested by
> max77620-pinctrl; cannot claim for gpiochip1
> max77620-pinctrl max77620-pinctrl: pin-4 (gpiochip1) status -22
> max77620-pinctrl max77620-pinctrl: could not request pin 4 (gpio4) from group
> gpio4 on device max77620-pinctrl
> gpio_stub_drv gpiochip1: Error applying setting, reverse things back
> gpio_stub_drv: probe of gpiochip1 failed with error -22
>
> This happens because when we try to probe a device, driver core calls
> into pinctrl to set up the pins. However, if the GPIO DT node already
> has a proper device created and probed, trying to probe the gpio_device
> with a stub driver makes the pins be claimed twice. pinctrl doesn't like
> this and throws an error.
>
> So, this patch makes sure the gpio_stub_drv doesn't match with a
> gpio_device if it's not the primary device for the fwnode.
>
> [1] -
> https://lore.kernel.org/lkml/544ad0e4-0954-274c-8e77-866aaa566...@gmail.com/
> Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
> fw_devlink=on by default")
> Signed-off-by: Saravana Kannan
> Tested-by: Dmitry Osipenko
> ---
> Greg/Linus,
>
> This will need to go into driver-core because the Fixes is in
> driver-core too.
OK that seems to be the right solution. Maybe I would try to
explain the situation in the comment in gpio_bus_match
a bit more, but anyway:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Re: [PATCH v3 3/7] mfd: max8997: Add of_compatible to extcon and charger mfd_cell
On Thu, 11 Feb 2021, Timon Baetz wrote:
> On Tue, 22 Dec 2020 09:55:22 +, Lee Jones wrote:
> > On Tue, 22 Dec 2020, Timon Baetz wrote:
> >
> > > Add of_compatible ("maxim,max8997-muic") to the mfd_cell to have a
> > > of_node set in the extcon driver.
> > >
> > > Add of_compatible ("maxim,max8997-battery") to the mfd_cell to configure
> > > the charger driver.
> > >
> > > Signed-off-by: Timon Baetz
> > > ---
> > > drivers/mfd/max8997.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > Applied, thanks.
>
> Once
> https://lore.kernel.org/lkml/20210130172747.2022977-1-timon.ba...@protonmail.com/
> gets accepted, this is not needed anymore. Can this be reverted or
> should I create a new patch?
Please submit a revert with the reasons why.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 0/3] mm/page_alloc: Fix pageblock_order with HUGETLB_PAGE_SIZE_VARIABLE
On 12.02.21 08:02, Anshuman Khandual wrote:
On 2/11/21 2:07 PM, David Hildenbrand wrote:
On 11.02.21 07:22, Anshuman Khandual wrote:
The following warning gets triggered while trying to boot a 64K page size
without THP config kernel on arm64 platform.
WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
Modules linked in:
CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
Hardware name: linux,dummy-virt (DT)
[ 8.810673] pstate: 2045 (nzCv daif +PAN -UAO -TCO BTYPE=--)
[ 8.811732] pc : __fragmentation_index+0xa4/0xc0
[ 8.812555] lr : fragmentation_index+0xf8/0x138
[ 8.813360] sp : 864079b0
[ 8.813958] x29: 864079b0 x28: 0372
[ 8.814901] x27: 7682 x26: 8000135b3948
[ 8.815847] x25: 1fffe00010c80f48 x24:
[ 8.816805] x23: x22: 000d
[ 8.817764] x21: 0030 x20: 0005ffcb4d58
[ 8.818712] x19: 000b x18:
[ 8.819656] x17: x16:
[ 8.820613] x15: x14: 8000114c6258
[ 8.821560] x13: 6000bff969ba x12: 1fffe000bff969b9
[ 8.822514] x11: 1fffe000bff969b9 x10: 6000bff969b9
[ 8.823461] x9 : dfff8000 x8 : 0005ffcb4dcf
[ 8.824415] x7 : 0001 x6 : 41b58ab3
[ 8.825359] x5 : 600010c80f48 x4 : dfff8000
[ 8.826313] x3 : 8000102be670 x2 : 0007
[ 8.827259] x1 : 86407a60 x0 : 000d
[ 8.828218] Call trace:
[ 8.828667] __fragmentation_index+0xa4/0xc0
[ 8.829436] fragmentation_index+0xf8/0x138
[ 8.830194] compaction_suitable+0x98/0xb8
[ 8.830934] wakeup_kcompactd+0xdc/0x128
[ 8.831640] balance_pgdat+0x71c/0x7a0
[ 8.832327] kswapd+0x31c/0x520
[ 8.832902] kthread+0x224/0x230
[ 8.833491] ret_from_fork+0x10/0x30
[ 8.834150] ---[ end trace 472836f79c15516b ]---
This warning comes from __fragmentation_index() when the requested order
is greater than MAX_ORDER.
static int __fragmentation_index(unsigned int order,
struct contig_page_info *info)
{
unsigned long requested = 1UL << order;
if (WARN_ON_ONCE(order >= MAX_ORDER)) <= Triggered here
return 0;
Digging it further reveals that pageblock_order has been assigned a value
which is greater than MAX_ORDER failing the above check. But why this
happened ? Because HUGETLB_PAGE_ORDER for the given config on arm64 is
greater than MAX_ORDER.
The solution involves enabling HUGETLB_PAGE_SIZE_VARIABLE which would make
pageblock_order a variable instead of constant HUGETLB_PAGE_ORDER. But that
change alone also did not really work as pageblock_order still got assigned
as HUGETLB_PAGE_ORDER in set_pageblock_order(). HUGETLB_PAGE_ORDER needs to
be less than MAX_ORDER for its appropriateness as pageblock_order otherwise
just fallback to MAX_ORDER - 1 as before. While here it also fixes a build
problem via type casting MAX_ORDER in rmem_cma_setup().
I'm wondering, is there any real value in allowing FORCE_MAX_ZONEORDER to be
"11" with ARM64_64K_PAGES/ARM64_16K_PAGES?
MAX_ORDER should be as high as would be required for the current config.
Unless THP is enabled, there is no need for it to be any higher than 11.
But I might be missing historical reasons around this as well. Probably
others from arm64 could help here.
Theoretically yes, practically no. If nobody cares about a
configuration, no need to make the code more complicated for that
configuration.
Meaning: are there any real use cases that actually build a kernel without
TRANSPARENT_HUGEPAGE and with ARM64_64K_PAGES/ARM64_16K_PAGES?
THP is always optional. Besides kernel builds without THP should always
be supported. Assuming that all builds will have THP enabled, might not
be accurate.
As builds are essentially broken, I assume this is not that relevant? Or how
long has it been broken?
Git blame shows that it's been there for some time now. But how does
that make this irrelevant ? A problem should be fixed nonetheless.
When exactly did I say not to fix it? I'm saying if nobody uses it, we
might be able to simplify.
It might be easier to just drop the "TRANSPARENT_HUGEPAGE" part from the
FORCE_MAX_ZONEORDER config.
Not sure if it would be a good idea to unnecessarily have larger MAX_ORDER
value for a given config. But I might be missing other contexts here.
My point is: keep it simple if there is no need to make it complicated.
If these arm64 variants are the only cases where we run into that issue
and nobody uses them ("hat it's been there for some time now"), why make
stuff complicated?
The current code seems to assume that HUGETLB_PAGE_ORDER <= MAX_ORDER.
Instead of changing that for optimizing an unused use case (it is
broken), just simplify the arm64 conditions. I'd even say add a
/*
* Some code assumes that HUGETLB_PAG
Re: [tip: objtool/urgent] objtool: Fix seg fault with Clang non-section symbols
Hi Greg and Nick, On 2021-02-11 10:46 -0800, Nick Desaulniers wrote: > On Thu, Feb 11, 2021 at 5:55 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Feb 11, 2021 at 09:32:03PM +0800, Xi Ruoyao wrote: > > > Hi all, > > > > > > The latest GNU assembler (binutils-2.36.1) is removing unused section > > > symbols > > > like Clang [1]. So linux-5.10.15 can't be built with binutils-2.36.1 > > > now. It > > > has been reported as https://bugzilla.kernel.org/show_bug.cgi?id=211693. > > Xi, > Happy Lunar New Year to you, too, and thanks for the report. Did you > observe such segfaults for older branches of stable? We found this issue building Linux From Scratch (http://www.linuxfromscratch.org/lfs/view/development/). We use the latest stable kernel in the project so we have no report of older branches. I tried 5.4.97 with a configuration "looks like" the one triggers the segfault in 5.10.15. But 5.4.97 build does not segfault. However, I guess for "some" config older branches may segfault too. > > 2.36 of binutils fails to build the 4.4.y tree right now as well, but as > > objtool isn't there, I don't know what to do about it :( > > Greg, > There may be multiple issues in the latest binutils release for the > kernel; we should still avoid segfaults in host tools so I do > recommend considering this patch for inclusion at least into 5.10.y. I strongly agree, or it may affect "rolling-release" distros (which are likely to use binutils-2.36.1 and linux-5.10.y together) in an annoying way. > Arnd's report in https://github.com/ClangBuiltLinux/linux/issues/1207 > mentions this was found via randconfig testing, so likely some set of > configs is needed to reproduce reliably. I attached a config in https://bugzilla.kernel.org/show_bug.cgi?id=211693 (also attached in this mail). It reproduces the issue for 5.10.15 very reliably. At least three of us tried this configuration on the system personally used (with binutils-2.36.1) and we got exactly same error: objtool segfaults on apic.o. > Do you have more info about the failure you're observing? Trolling > lore, I only see: > https://lore.kernel.org/stable/yclejcqfsdisr...@kroah.com/ > (Maybe it was reported on a different list; I only searched stable ML). -- Xi Ruoyao School of Aerospace Science and Technology, Xidian University config-segfault.gz Description: application/gzip
Re: [PATCH] drm/msm/dp: Add a missing semi-colon
On Mon, 2021-02-08 at 10:57 -0800, Stephen Boyd wrote: > Quoting Joe Perches (2021-02-06 21:06:54) > > Wow, that's really unfortunate that dp_panel_update_tu_timings > > is also void. > > > > Perhaps this as YA checkpatch warning: > > > > --- > > Acked-by: Stephen Boyd Are you acking the proposed checkpatch patch?
Re: [Linuxarm] Re: [PATCH for next v1 1/2] gpio: omap: Replace raw_spin_lock_irqsave with raw_spin_lock in omap_gpio_irq_handler()
On Fri, Feb 12, 2021 at 6:05 AM Song Bao Hua (Barry Song) wrote: > > -Original Message- > > > > Note. there is also generic_handle_irq() call inside. > > So generic_handle_irq() is not safe to run in thread thus requires > an interrupt-disabled environment to run? If so, I'd rather this > irqsave moved into generic_handle_irq() rather than asking everyone > calling it to do irqsave. In a preempt-rt kernel, interrupts are run in task context, so they clearly should not be called with interrupts disabled, that would defeat the purpose of making them preemptible. generic_handle_irq() does need to run with in_irq()==true though, but this should be set by the caller of the gpiochip's handler, and it is not set by raw_spin_lock_irqsave(). Arnd
Re: [PATCH RESEND] regulator: bd718x7, bd71828, Fix dvs voltage levels
Hello Lee,
On Fri, 2021-02-12 at 09:16 +, Lee Jones wrote:
> On Fri, 12 Feb 2021, Matti Vaittinen wrote:
>
> > The ROHM BD718x7 and BD71828 drivers support setting HW state
> > specific voltages from device-tree. This is used also by various
> > in-tree DTS files.
> >
> > These drivers do incorrectly try to compose bit-map using enum
> > values. By a chance this works for first two valid levels having
> > values 1 and 2 - but setting values for the rest of the levels
> > do indicate capability of setting values for first levels as
> > well. Luckily the regulators which support setting values for
> > SUSPEND/LPSR do usually also support setting values for RUN
> > and IDLE too - thus this has not been such a fatal issue.
> >
> > Fix this by defining the old enum values as bits and fixing the
> > parsing code. This allows keeping existing IC specific drivers
> > intact and only slightly changing the rohm-regulator.c
> >
> > Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common
> > and bd718x7 specific parts")
> > Signed-off-by: Matti Vaittinen
> > ---
> >
> > I just noticed this fix never made it in-tree. So this is a resend
> > of a
> > resend :)
>
> Not sure what you mean. Isn't this patch part of:
>
> [PATCH v2 00/17] Support ROHM BD71815 PMIC
>
> ... which has just been reviewed and is awaiting rework?
Sorry for the confusion Lee.
It was originally part of the series but I did intend to submit it
separately. That's because it is a bugfix for existing drivers - and
because the series "[PATCH v2 00/17] Support ROHM BD71815 PMIC"
is expected to take some time as it needs to wait the dependency
patches to get merged in relevant sub-systems. (The parent-data removal
patches to gpio, regulator and clk).
So my thinking was that that fix could've been merged in as it's own
patch to get existing things fixed in next release. I could then rebase
the "PATCH v2 00/17] Support ROHM BD71815 PMIC" - series on top of this
when it is in-tree.
I think I should have communicated this better. Sorry.
Please let me know what works for you guys the best.
Best Regards
Matti Vaittinen
Re: [PATCH] dt-bindings: pinctrl: Group tuples in pin control properties
On Thu, Feb 4, 2021 at 7:02 PM Geert Uytterhoeven wrote: > To improve human readability and enable automatic validation, the tuples > in "pinctrl-*" properties should be grouped using angle brackets. > > Signed-off-by: Geert Uytterhoeven Patch applied. Yours, Linus Walleij
Re: [PATCH v4 2/2] staging: rtl8723bs: remove obsolete commented out code
On Thu, Feb 11, 2021 at 06:36:04PM +0530, karthik alapati wrote: > There is a bunch of messy, commented out code. Just delete it. > > Suggested-by: Dan Carpenter > Signed-off-by: karthik alapati Perfect, thanks. Greg already merged this as well so good job. regards, dan carepnter
Re: [PATCH v2] printk: avoid prb_first_valid_seq() where possible
On Thu 2021-02-11 18:37:52, John Ogness wrote:
> If message sizes average larger than expected (more than 32
> characters), the data_ring will wrap before the desc_ring. Once the
> data_ring wraps, it will start invalidating descriptors. These
> invalid descriptors hang around until they are eventually recycled
> when the desc_ring wraps. Readers do not care about invalid
> descriptors, but they still need to iterate past them. If the
> average message size is much larger than 32 characters, then there
> will be many invalid descriptors preceding the valid descriptors.
>
> The function prb_first_valid_seq() always begins at the oldest
> descriptor and searches for the first valid descriptor. This can
> be rather expensive for the above scenario. And, in fact, because
> of its heavy usage in /dev/kmsg, there have been reports of long
> delays and even RCU stalls.
>
> For code that does not need to search from the oldest record,
> replace prb_first_valid_seq() usage with prb_read_valid_*()
> functions, which provide a start sequence number to search from.
>
> Fixes: 896fbe20b4e2333fb55 ("printk: use the lockless ringbuffer")
> Reported-by: kernel test robot
> Reported-by: J. Avila
> Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
I am going to push the patch later today. I would prefer to do it
later and give a chance others to react. But the merge window
will likely start the following week and Sergey was fine
with this approach.
Best Regard,
Petr
Re: [PATCH v2] mm/hugetlb: use helper huge_page_size() to get hugepage size
On 09.02.21 03:18, Miaohe Lin wrote:
We can use helper huge_page_size() to get the hugepage size directly to
simplify the code slightly.
Reviewed-by: Mike Kravetz
Signed-off-by: Miaohe Lin
---
v1 -> v2
change huge_page_size(h) >> 10 to huge_page_size(h) / SZ_1K
collect Reviewed-by tag
---
mm/hugetlb.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 18628f8dbfb0..06719fdf9fd6 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3199,7 +3199,7 @@ void __init hugetlb_add_hstate(unsigned int order)
BUG_ON(order == 0);
h = &hstates[hugetlb_max_hstate++];
h->order = order;
- h->mask = ~((1ULL << (order + PAGE_SHIFT)) - 1);
+ h->mask = ~(huge_page_size(h) - 1);
for (i = 0; i < MAX_NUMNODES; ++i)
INIT_LIST_HEAD(&h->hugepage_freelists[i]);
INIT_LIST_HEAD(&h->hugepage_activelist);
@@ -3474,7 +3474,7 @@ void hugetlb_report_meminfo(struct seq_file *m)
for_each_hstate(h) {
unsigned long count = h->nr_huge_pages;
- total += (PAGE_SIZE << huge_page_order(h)) * count;
+ total += huge_page_size(h) * count;
if (h == &default_hstate)
seq_printf(m,
@@ -3487,10 +3487,10 @@ void hugetlb_report_meminfo(struct seq_file *m)
h->free_huge_pages,
h->resv_huge_pages,
h->surplus_huge_pages,
- (PAGE_SIZE << huge_page_order(h)) / 1024);
+ huge_page_size(h) / SZ_1K);
}
- seq_printf(m, "Hugetlb:%8lu kB\n", total / 1024);
+ seq_printf(m, "Hugetlb:%8lu kB\n", total / SZ_1K);
}
int hugetlb_report_node_meminfo(char *buf, int len, int nid)
@@ -3524,7 +3524,7 @@ void hugetlb_show_meminfo(void)
h->nr_huge_pages_node[nid],
h->free_huge_pages_node[nid],
h->surplus_huge_pages_node[nid],
- 1UL << (huge_page_order(h) + PAGE_SHIFT - 10));
+ huge_page_size(h) / SZ_1K);
}
void hugetlb_report_usage(struct seq_file *m, struct mm_struct *mm)
@@ -3647,9 +3647,7 @@ static int hugetlb_vm_op_split(struct vm_area_struct
*vma, unsigned long addr)
static unsigned long hugetlb_vm_op_pagesize(struct vm_area_struct *vma)
{
- struct hstate *hstate = hstate_vma(vma);
-
- return 1UL << huge_page_shift(hstate);
+ return huge_page_size(hstate_vma(vma));
}
/*
Reviewed-by: David Hildenbrand
Thanks!
--
Thanks,
David / dhildenb
Re: [PATCH] hugetlbfs: Remove unneeded return value of hugetlb_vmtruncate()
On 08.02.21 09:46, Miaohe Lin wrote:
The function hugetlb_vmtruncate() is guaranteed to always success since
commit 7aa91e104028 ("hugetlb: allow extending ftruncate on hugetlbfs").
So we should remove the unneeded return value which is always 0.
Signed-off-by: Miaohe Lin
---
fs/hugetlbfs/inode.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 394da2ab08ad..701c82c36138 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -567,7 +567,7 @@ static void hugetlbfs_evict_inode(struct inode *inode)
clear_inode(inode);
}
-static int hugetlb_vmtruncate(struct inode *inode, loff_t offset)
+static void hugetlb_vmtruncate(struct inode *inode, loff_t offset)
{
pgoff_t pgoff;
struct address_space *mapping = inode->i_mapping;
@@ -582,7 +582,6 @@ static int hugetlb_vmtruncate(struct inode *inode, loff_t
offset)
hugetlb_vmdelete_list(&mapping->i_mmap, pgoff, 0);
i_mmap_unlock_write(mapping);
remove_inode_hugepages(inode, offset, LLONG_MAX);
- return 0;
}
static long hugetlbfs_punch_hole(struct inode *inode, loff_t offset, loff_t len)
@@ -781,9 +780,7 @@ static int hugetlbfs_setattr(struct user_namespace
*mnt_userns,
if ((newsize < oldsize && (info->seals & F_SEAL_SHRINK)) ||
(newsize > oldsize && (info->seals & F_SEAL_GROW)))
return -EPERM;
- error = hugetlb_vmtruncate(inode, newsize);
- if (error)
- return error;
+ hugetlb_vmtruncate(inode, newsize);
}
setattr_copy(&init_user_ns, inode, attr);
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On Fri, Feb 12, 2021 at 02:51:30PM +0530, Viresh Kumar wrote:
> On 12-02-21, 10:17, Greg KH wrote:
> > On Fri, Feb 12, 2021 at 02:39:26PM +0530, Viresh Kumar wrote:
> > > On 12-02-21, 13:48, Pritthijit Nath wrote:
> > > > This change fixes a checkpatch CHECK style issue for "Alignment should
> > > > match
> > > > open parenthesis".
> > > >
> > > > Signed-off-by: Pritthijit Nath
> > > > ---
> > > > drivers/staging/greybus/hid.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/staging/greybus/hid.c
> > > > b/drivers/staging/greybus/hid.c
> > > > index ed706f39e87a..a56c3fb5d35a 100644
> > > > --- a/drivers/staging/greybus/hid.c
> > > > +++ b/drivers/staging/greybus/hid.c
> > > > @@ -221,8 +221,8 @@ static void gb_hid_init_reports(struct gb_hid *ghid)
> > > > }
> > > >
> > > > static int __gb_hid_get_raw_report(struct hid_device *hid,
> > > > - unsigned char report_number, __u8 *buf, size_t count,
> > > > - unsigned char report_type)
> > > > + unsigned char report_number, __u8
> > > > *buf, size_t count,
> > > > + unsigned char report_type)
> > > > {
> > > > struct gb_hid *ghid = hid->driver_data;
> > > > int ret;
> > >
> > > I can't even count the number of attempts we have seen in previous
> > > years to make checkpatch --strict happy for greybus.
> > >
> > > I say we make this change once and for all across greybus, so we don't
> > > have to review or NAK someone afterwards.
> > >
> > > Should I send a patch for this ?
> >
> > Sure, but note that over time, checkpatch adds new things so there will
> > always be something to change in here, until we move it out of the
> > drivers/staging/ area :)
>
> Right, though I wasn't worried about other checkpatch warning but
> specially the "alignment - parenthesis" one. Everyone (specially
> newbies) want to fix that everywhere :)
But what will the checkpatch crew then work on? Better staging than the
rest of the kernel.
Perhaps just let them keep at it until we move the rest out (the price
we pay for taking this through staging apparently).
But there can't be that many instances left of this alignment
"violation" in staging/greybus (~4 it seems) if you want to get it over
with.
Johan
[PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
Fixed the spelling of 'transfered' to 'transferred'. Signed-off-by: Pritthijit Nath --- Fixed the typo in the patch which was meant to fix that very typo. Really sorry for last time. Hope this does not have any other typo. drivers/staging/greybus/hid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c index a56c3fb5d35a..adb91286803a 100644 --- a/drivers/staging/greybus/hid.c +++ b/drivers/staging/greybus/hid.c @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device *hid, __u8 *buf, ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); if (report_id && ret >= 0) - ret++; /* add report_id to the number of transfered bytes */ + ret++; /* add report_id to the number of transferred bytes */ return 0; } -- 2.25.1
linux-next: manual merge of the akpm-current tree with the fscache tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/linux/pagemap.h
between commit:
13aecd8259dc ("mm: Implement readahead_control pageset expansion")
from the fscache tree and commit:
3ad6bba07ad0 ("mm/filemap: add mapping_seek_hole_data")
from the akpm-current 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 include/linux/pagemap.h
index d2786607d297,20225b067583..
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@@ -758,11 -756,11 +757,13 @@@ int add_to_page_cache_lru(struct page *
pgoff_t index, gfp_t gfp_mask);
extern void delete_from_page_cache(struct page *page);
extern void __delete_from_page_cache(struct page *page, void *shadow);
- int replace_page_cache_page(struct page *old, struct page *new, gfp_t
gfp_mask);
+ void replace_page_cache_page(struct page *old, struct page *new);
void delete_from_page_cache_batch(struct address_space *mapping,
struct pagevec *pvec);
+void readahead_expand(struct readahead_control *ractl,
+loff_t new_start, size_t new_len);
+ loff_t mapping_seek_hole_data(struct address_space *, loff_t start, loff_t
end,
+ int whence);
/*
* Like add_to_page_cache_locked, but used to add newly allocated pages:
pgp8sYPvq5g_v.pgp
Description: OpenPGP digital signature
Re: [PATCH v6 3/3] perf vendor events arm64: Add Fujitsu A64FX pmu event
On 12/02/2021 09:03, Shunsuke Nakamura wrote: Add pmu events for A64FX. Documentation source: https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_PMU_Events_v1.2.pdf Signed-off-by: Shunsuke Nakamura Reviewed-by: John Garry
Re: [PATCH v6 2/3] perf tools: Add lexical definition of event name
On 12/02/2021 09:03, Shunsuke Nakamura wrote:
Add the lexical definition of event name so that the numbers are recognizable.
A64FX defines an event name that starts with a number.
- 0inst_commit
- 1inst_commit
- 2inst_commit
- 3inst_commit
- 4inst_commit
Signed-off-by: Shunsuke Nakamura
---
FWIW,
Acked-by: John Garry
I would prefer if more knowledgeable perf reviewers also checked this...
tools/perf/util/parse-events.l | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 0b36285a9435..33f627187415 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -205,7 +205,7 @@ bpf_source [^,{}]+\.c[a-zA-Z0-9._]*
num_dec [0-9]+
num_hex 0x[a-fA-F0-9]+
num_raw_hex [a-fA-F0-9]+
-name [a-zA-Z_*?\[\]][a-zA-Z0-9_*?.\[\]]*
+name [a-zA-Z0-9_*?\[\]][a-zA-Z0-9_*?.\[\]]*
name_tag [\'][a-zA-Z_*?\[\]][a-zA-Z0-9_*?\-,\.\[\]:=]*[\']
name_minus[a-zA-Z_*?][a-zA-Z0-9\-_*?.:]*
drv_cfg_term [a-zA-Z0-9_\.]+(=[a-zA-Z0-9_*?\.:]+)?
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On 12-02-21, 10:52, Johan Hovold wrote: > But what will the checkpatch crew then work on? Lol.. > Better staging than the rest of the kernel. [ /me wondering on who stops them from sending patches for rest of the kernel ? ] -- viresh
Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout
On 08.02.21 12:08, Mike Rapoport wrote:
From: Mike Rapoport
There could be struct pages that are not backed by actual physical memory.
This can happen when the actual memory bank is not a multiple of
SECTION_SIZE or when an architecture does not register memory holes
reserved by the firmware as memblock.memory.
Such pages are currently initialized using init_unavailable_mem() function
that iterates through PFNs in holes in memblock.memory and if there is a
struct page corresponding to a PFN, the fields of this page are set to
default values and it is marked as Reserved.
init_unavailable_mem() does not take into account zone and node the page
belongs to and sets both zone and node links in struct page to zero.
On a system that has firmware reserved holes in a zone above ZONE_DMA, for
instance in a configuration below:
# grep -A1 E820 /proc/iomem
7a17b000-7a216fff : Unknown E820 type
7a217000-7bff : System RAM
unset zone link in struct page will trigger
VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
because there are pages in both ZONE_DMA32 and ZONE_DMA (unset zone link
in struct page) in the same pageblock.
Moreover, it is possible that the lowest node and zone start is not aligned
to the section boundarie, for example on x86:
[0.078898] Zone ranges:
[0.078899] DMA [mem 0x1000-0x00ff]
...
[0.078910] Early memory node ranges
[0.078912] node 0: [mem 0x1000-0x0009cfff]
[0.078913] node 0: [mem 0x0010-0x3fff]
and thus with SPARSEMEM memory model the beginning of the memory map will
have struct pages that are not spanned by any node and zone.
Update detection of node boundaries in get_pfn_range_for_nid() so that the
node range will be expanded to cover memory map section. Since zone spans
are derived from the node span, there always will be a zone that covers the
part of the memory map with unavailable pages.
Interleave initialization of the unavailable pages with the normal
initialization of memory map, so that zone and node information will be
properly set on struct pages that are not backed by the actual memory.
Fixes: 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
that check each PFN")
Reported-by: Andrea Arcangeli
Signed-off-by: Mike Rapoport
Cc: Baoquan He
Cc: David Hildenbrand
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Qian Cai
Cc: Vlastimil Babka
---
mm/page_alloc.c | 160 +++-
1 file changed, 75 insertions(+), 85 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6446778cbc6b..1c3f7521028f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6257,22 +6257,84 @@ static void __meminit zone_init_free_lists(struct zone
*zone)
}
}
+#if !defined(CONFIG_FLAT_NODE_MEM_MAP)
+/*
+ * Only struct pages that correspond to ranges defined by memblock.memory
+ * are zeroed and initialized by going through __init_single_page() during
+ * memmap_init_zone().
+ *
+ * But, there could be struct pages that correspond to holes in
+ * memblock.memory. This can happen because of the following reasons:
+ * - phyiscal memory bank size is not necessarily the exact multiple of the
+ * arbitrary section size
+ * - early reserved memory may not be listed in memblock.memory
+ * - memory layouts defined with memmap= kernel parameter may not align
+ * nicely with memmap sections
+ *
+ * Explicitly initialize those struct pages so that:
+ * - PG_Reserved is set
+ * - zone and node links point to zone and node that span the page
+ */
+static u64 __meminit init_unavailable_range(unsigned long spfn,
+ unsigned long epfn,
+ int zone, int node)
+{
+ unsigned long pfn;
+ u64 pgcnt = 0;
+
+ for (pfn = spfn; pfn < epfn; pfn++) {
+ if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) {
+ pfn = ALIGN_DOWN(pfn, pageblock_nr_pages)
+ + pageblock_nr_pages - 1;
+ continue;
+ }
+ __init_single_page(pfn_to_page(pfn), pfn, zone, node);
+ __SetPageReserved(pfn_to_page(pfn));
+ pgcnt++;
+ }
+
+ return pgcnt;
+}
+#else
+static inline u64 init_unavailable_range(unsigned long spfn, unsigned long
epfn,
+int zone, int node)
+{
+ return 0;
+}
+#endif
+
void __meminit __weak memmap_init_zone(struct zone *zone)
{
unsigned long zone_start_pfn = zone->zone_start_pfn;
unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
unsigned long start_pfn, end_pfn;
+ unsigned long hole_pfn = 0;
+ u64 pgcnt = 0;
for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
Re: [PATCH v5 1/1] mm: refactor initialization of struct page for holes in memory layout
On 12.02.21 10:55, David Hildenbrand wrote:
On 08.02.21 12:08, Mike Rapoport wrote:
From: Mike Rapoport
There could be struct pages that are not backed by actual physical memory.
This can happen when the actual memory bank is not a multiple of
SECTION_SIZE or when an architecture does not register memory holes
reserved by the firmware as memblock.memory.
Such pages are currently initialized using init_unavailable_mem() function
that iterates through PFNs in holes in memblock.memory and if there is a
struct page corresponding to a PFN, the fields of this page are set to
default values and it is marked as Reserved.
init_unavailable_mem() does not take into account zone and node the page
belongs to and sets both zone and node links in struct page to zero.
On a system that has firmware reserved holes in a zone above ZONE_DMA, for
instance in a configuration below:
# grep -A1 E820 /proc/iomem
7a17b000-7a216fff : Unknown E820 type
7a217000-7bff : System RAM
unset zone link in struct page will trigger
VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
because there are pages in both ZONE_DMA32 and ZONE_DMA (unset zone link
in struct page) in the same pageblock.
Moreover, it is possible that the lowest node and zone start is not aligned
to the section boundarie, for example on x86:
[0.078898] Zone ranges:
[0.078899] DMA [mem 0x1000-0x00ff]
...
[0.078910] Early memory node ranges
[0.078912] node 0: [mem 0x1000-0x0009cfff]
[0.078913] node 0: [mem 0x0010-0x3fff]
and thus with SPARSEMEM memory model the beginning of the memory map will
have struct pages that are not spanned by any node and zone.
Update detection of node boundaries in get_pfn_range_for_nid() so that the
node range will be expanded to cover memory map section. Since zone spans
are derived from the node span, there always will be a zone that covers the
part of the memory map with unavailable pages.
Interleave initialization of the unavailable pages with the normal
initialization of memory map, so that zone and node information will be
properly set on struct pages that are not backed by the actual memory.
Fixes: 73a6e474cb37 ("mm: memmap_init: iterate over memblock regions rather
that check each PFN")
Reported-by: Andrea Arcangeli
Signed-off-by: Mike Rapoport
Cc: Baoquan He
Cc: David Hildenbrand
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Qian Cai
Cc: Vlastimil Babka
---
mm/page_alloc.c | 160 +++-
1 file changed, 75 insertions(+), 85 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6446778cbc6b..1c3f7521028f 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6257,22 +6257,84 @@ static void __meminit zone_init_free_lists(struct zone
*zone)
}
}
+#if !defined(CONFIG_FLAT_NODE_MEM_MAP)
+/*
+ * Only struct pages that correspond to ranges defined by memblock.memory
+ * are zeroed and initialized by going through __init_single_page() during
+ * memmap_init_zone().
+ *
+ * But, there could be struct pages that correspond to holes in
+ * memblock.memory. This can happen because of the following reasons:
+ * - phyiscal memory bank size is not necessarily the exact multiple of the
+ * arbitrary section size
+ * - early reserved memory may not be listed in memblock.memory
+ * - memory layouts defined with memmap= kernel parameter may not align
+ * nicely with memmap sections
+ *
+ * Explicitly initialize those struct pages so that:
+ * - PG_Reserved is set
+ * - zone and node links point to zone and node that span the page
+ */
+static u64 __meminit init_unavailable_range(unsigned long spfn,
+ unsigned long epfn,
+ int zone, int node)
+{
+ unsigned long pfn;
+ u64 pgcnt = 0;
+
+ for (pfn = spfn; pfn < epfn; pfn++) {
+ if (!pfn_valid(ALIGN_DOWN(pfn, pageblock_nr_pages))) {
+ pfn = ALIGN_DOWN(pfn, pageblock_nr_pages)
+ + pageblock_nr_pages - 1;
+ continue;
+ }
+ __init_single_page(pfn_to_page(pfn), pfn, zone, node);
+ __SetPageReserved(pfn_to_page(pfn));
+ pgcnt++;
+ }
+
+ return pgcnt;
+}
+#else
+static inline u64 init_unavailable_range(unsigned long spfn, unsigned long
epfn,
+int zone, int node)
+{
+ return 0;
+}
+#endif
+
void __meminit __weak memmap_init_zone(struct zone *zone)
{
unsigned long zone_start_pfn = zone->zone_start_pfn;
unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
unsigned long start_pfn, end_pfn;
+ unsigned long hole_pfn = 0;
+ u64 pgcnt = 0;
for_each_mem_pfn_ran
Re: [RFC PATCH 11/12] platform/x86: skeleton for oftree based board device initialization
On Mon, Feb 8, 2021 at 11:22 PM Enrico Weigelt, metux IT consult wrote: > Lots of boards have extra devices that can't be fully probed via bus'es > (like PCI) or generic firmware mechanisms like ACPI. Often those capabilities > are just partial or even highly depend on firmware version. I think Intel people often take the stance that the ACPI DSDT (or whatever) needs to be fixed. 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. 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 haven't worked with this in practice so I suppose it is a bit up to the people who end up having to fix this kind of stuff, Hans de Goede and Andy are fixing this kind of stuff all the time so their buy-in is important, we need to see that this is a real, useful tool for people like them, not just nice to have. Yours, Linus Walleij
Re: [PATCH RESEND] regulator: bd718x7, bd71828, Fix dvs voltage levels
On Fri, 12 Feb 2021, Matti Vaittinen wrote:
> The ROHM BD718x7 and BD71828 drivers support setting HW state
> specific voltages from device-tree. This is used also by various
> in-tree DTS files.
>
> These drivers do incorrectly try to compose bit-map using enum
> values. By a chance this works for first two valid levels having
> values 1 and 2 - but setting values for the rest of the levels
> do indicate capability of setting values for first levels as
> well. Luckily the regulators which support setting values for
> SUSPEND/LPSR do usually also support setting values for RUN
> and IDLE too - thus this has not been such a fatal issue.
>
> Fix this by defining the old enum values as bits and fixing the
> parsing code. This allows keeping existing IC specific drivers
> intact and only slightly changing the rohm-regulator.c
>
> Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7
> specific parts")
> Signed-off-by: Matti Vaittinen
> ---
>
> I just noticed this fix never made it in-tree. So this is a resend of a
> resend :)
>
> drivers/regulator/rohm-regulator.c | 9 ++---
> include/linux/mfd/rohm-generic.h | 14 ++
> 2 files changed, 12 insertions(+), 11 deletions(-)
Happy for Mark to take this in:
Acked-by: Lee Jones
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] ACPI: property: Fix fwnode string properties matching
Hi Rafael,
On Thu, Feb 11, 2021 at 07:30:01PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Property matching does not work for ACPI fwnodes if the value of the
> given property is not represented as a package in the _DSD package
> containing it. For example, the "compatible" property in the _DSD
> below
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", "ethernet-phy-ieee802.3-c45"}
> }
> })
>
> will not be found by fwnode_property_match_string(), because the ACPI
> code handling device properties does not regard the single value as a
> "list" in that case.
>
> Namely, fwnode_property_match_string() invoked to match a given
> string property value first calls fwnode_property_read_string_array()
> with the last two arguments equal to NULL and 0, respectively, in
> order to count the items in the value of the given property, with the
> assumption that this value may be an array. For ACPI fwnodes, that
> operation is carried out by acpi_node_prop_read() which calls
> acpi_data_prop_read() for this purpose. However, when the return
> (val) pointer is NULL, that function only looks for a property whose
> value is a package without checking the single-value case at all.
>
> To fix that, make acpi_data_prop_read() check the single-value case
> regardless of the return pointer value if its return pointer argument
> is NULL and modify acpi_data_prop_read_single() handling that case to
> attempt to read the value of the property if the return pointer is
> NULL and return 1 if that succeeds.
>
> Fixes: 3708184afc77 ("device property: Move FW type specific functionality to
> FW specific files")
> Reported-by: Calvin Johnson
> Cc: 4.13+ # 4.13+
> Signed-off-by: Rafael J. Wysocki
Thanks for addressing this.
Reviewed-by: Sakari Ailus
--
Sakari Ailus
Re: [PATCH v6 2/3] v4l: ioctl: Use %p4cc printk modifier to print FourCC codes
Hi Petr,
On Thu, Feb 11, 2021 at 05:31:46PM +0100, Petr Mladek wrote:
> On Mon 2021-02-08 22:09:02, Sakari Ailus wrote:
> > Now that we can print FourCC codes directly using printk, make use of the
> > feature in V4L2 core.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/v4l2-core/v4l2-ioctl.c | 85 +++-
> > 1 file changed, 21 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
> > b/drivers/media/v4l2-core/v4l2-ioctl.c
> > index 31d1342e61e8..31662c3a8c9e 100644
> > --- a/drivers/media/v4l2-core/v4l2-ioctl.c
> > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c
> > @@ -265,13 +265,9 @@ static void v4l_print_fmtdesc(const void *arg, bool
> > write_only)
> > {
> > const struct v4l2_fmtdesc *p = arg;
> >
> > - pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%c%c%c%c,
> > mbus_code=0x%04x, description='%.*s'\n",
> > + pr_cont("index=%u, type=%s, flags=0x%x, pixelformat=%p4cc,
> > mbus_code=0x%04x, description='%.*s'\n",
>
> Is %p4cc really acceptable here?
>
> The original code printed only the 4 characters. The original code
> would print something like:
>
> index=21, type=bla, flags=0x0, pixelformat=BG12, mbus_code=0x0a9f,
> descrition="bla bla bla"
>
> while the new code will do:
>
> index=21, type=bla, flags=0x0, pixelformat=BG12 little-endian (0x32314742),
> mbus_code=0x0a9f, descrition="bla bla bla"
>
> This is much harder to parse because there are spaces also inside
> pixel_format=
Note that also the fourcc code itself could contains spaces so that's not
new.
The fourcc (debug) form is now one and the same for V4L2 and DRM, but I
guess nothing would prevent adding a shorter form if needed. This is not
continuously happening during streaming so this is also not performance
critical in any way. The fourcc code was used to be printed this way here
mainly because it was, well, easy to do for "just" debugging purposes.
Hans, any opinion?
--
Kind regards,
Sakari Ailus
Re: [PATCH 3/3] [v3] lib/vsprintf: debug_never_hash_pointers prints all addresses as unhashed
On Thu 2021-02-11 17:20:26, Matthew Wilcox wrote: > On Thu, Feb 11, 2021 at 11:08:12AM -0600, Timur Tabi wrote: > > > > > > On 2/11/21 6:31 AM, Pavel Machek wrote: > > > Can we make this something shorter? Clearly you don't want people > > > placing this in their grub config, so they'll be most likely typing > > > this a lot... > > > > > > debug_pointers or debug_ptrs would be better. > > > > dbg_unhash_ptrs? "debug_ptrs" is too vague IMHO, and I want to keep the > > word "hash" somewhere there to indicate exactly what's happening. > > no_hash_pointers ? I am fine with this. I am still a bit scared of a bikeshedng. But AFAIK, Mathew was most active on proposing clear names. So, when he is fine with this... Anyway, we should use the same name also for the variable. Best Regards, Petr
Re: [PATCH 2/2] staging: greybus: Fixed a misspelling in hid.c
On Fri, Feb 12, 2021 at 03:20:08PM +0530, Pritthijit Nath wrote: > Fixed the spelling of 'transfered' to 'transferred'. > > Signed-off-by: Pritthijit Nath > --- > Fixed the typo in the patch which was meant to fix that very typo. > Really sorry for last time. > Hope this does not have any other typo. > > drivers/staging/greybus/hid.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/greybus/hid.c b/drivers/staging/greybus/hid.c > index a56c3fb5d35a..adb91286803a 100644 > --- a/drivers/staging/greybus/hid.c > +++ b/drivers/staging/greybus/hid.c > @@ -254,7 +254,7 @@ static int __gb_hid_output_raw_report(struct hid_device > *hid, __u8 *buf, > > ret = gb_hid_set_report(ghid, report_type, report_id, buf, len); > if (report_id && ret >= 0) > - ret++; /* add report_id to the number of transfered bytes */ > + ret++; /* add report_id to the number of transferred bytes */ > > return 0; > } > -- > 2.25.1 > > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version, or properly version the subject line of your patch. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH] video: use getter/setter functions
On Tue, 09 Feb 2021, Julia Lawall wrote: > Use getter and setter functions, for platform_device structures and a > spi_device structure. > > Signed-off-by: Julia Lawall > > --- > drivers/video/backlight/qcom-wled.c |2 > +- > drivers/video/fbdev/amifb.c |4 > ++-- > drivers/video/fbdev/da8xx-fb.c |4 > ++-- > drivers/video/fbdev/imxfb.c |2 > +- > drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c |6 > +++--- > drivers/video/fbdev/omap2/omapfb/dss/dpi.c |4 > ++-- > drivers/video/fbdev/omap2/omapfb/dss/dsi.c |4 > ++-- > drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c |2 > +- > drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c |2 > +- > drivers/video/fbdev/xilinxfb.c |2 > +- > 10 files changed, 16 insertions(+), 16 deletions(-) I fixed-up the subject line and commit message a bit and applied. Thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH v2 2/3] misc/pvpanic: add PCI driver
Add support for pvpanic PCI device added in qemu [1]. At probe time, obtain the
address where to read/write pvpanic events and pass it to the generic handling
code. Will follow the same logic as pvpanic MMIO device driver. At remove time,
unmap base address and disable PCI device.
[1] https://github.com/qemu/qemu/commit/9df52f58e76e904fb141b10318362d718f470db2
Signed-off-by: Mihai Carabas
---
drivers/misc/pvpanic/Kconfig | 8 +++
drivers/misc/pvpanic/Makefile | 2 ++
drivers/misc/pvpanic/pci.c| 49 +++
3 files changed, 59 insertions(+)
create mode 100644 drivers/misc/pvpanic/pci.c
diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig
index 0dce6ef..ce8b93e 100644
--- a/drivers/misc/pvpanic/Kconfig
+++ b/drivers/misc/pvpanic/Kconfig
@@ -10,3 +10,11 @@ config PVPANIC_MMIO
This driver provides support for the pvpanic device. pvpanic is
a paravirtualized device provided by QEMU; it lets a virtual machine
(guest) communicate panic events to the host.
+
+config PVPANIC_PCI
+ tristate "pvpanic PCI device support"
+ depends on PCI && PVPANIC
+ help
+ This driver provides support for the pvpanic device. pvpanic is
+ a paravirtualized device provided by QEMU; it lets a virtual machine
+ (guest) communicate panic events to the host.
diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile
index 9ea3355..1763450 100644
--- a/drivers/misc/pvpanic/Makefile
+++ b/drivers/misc/pvpanic/Makefile
@@ -1,2 +1,4 @@
obj-$(CONFIG_PVPANIC_MMIO) += pvpanic-mmio.o
pvpanic-mmio-objs := pvpanic-common.o mmio.o
+obj-$(CONFIG_PVPANIC_PCI) += pvpanic-pci.o
+pvpanic-pci-objs := pvpanic-common.o pci.o
diff --git a/drivers/misc/pvpanic/pci.c b/drivers/misc/pvpanic/pci.c
new file mode 100644
index ..b672727
--- /dev/null
+++ b/drivers/misc/pvpanic/pci.c
@@ -0,0 +1,49 @@
+#include
+#include
+#include
+#include
+#include "pvpanic.h"
+
+#define PCI_VENDOR_ID_REDHAT 0x1b36
+#define PCI_DEVICE_ID_REDHAT_PVPANIC 0x0011
+
+static void __iomem *base;
+static const struct pci_device_id pvpanic_pci_id_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_PVPANIC),},
+ {}
+};
+
+static int pvpanic_pci_probe(struct pci_dev *pdev,
+const struct pci_device_id *ent)
+{
+ int ret;
+ struct resource res;
+
+ ret = pci_enable_device(pdev);
+ if (ret < 0)
+ return ret;
+
+ base = pci_iomap(pdev, 0, 0);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
+
+ pvpanic_probe(base);
+
+ return 0;
+}
+
+static void pvpanic_pci_remove(struct pci_dev *pdev)
+{
+ pvpanic_remove();
+ iounmap(base);
+ pci_disable_device(pdev);
+}
+
+static struct pci_driver pvpanic_pci_driver = {
+ .name = "pvpanic-pci",
+ .id_table = pvpanic_pci_id_tbl,
+ .probe =pvpanic_pci_probe,
+ .remove = pvpanic_pci_remove,
+};
+
+module_pci_driver(pvpanic_pci_driver);
--
1.8.3.1
[PATCH v2 3/3] misc/pvpanic: add license
Add license to the newly created files in adding support for pvpanic PCI device driver. Signed-off-by: Mihai Carabas --- drivers/misc/pvpanic/Kconfig | 7 +++ drivers/misc/pvpanic/Makefile | 7 +++ drivers/misc/pvpanic/pci.c | 7 +++ drivers/misc/pvpanic/pvpanic.h | 7 +++ 4 files changed, 28 insertions(+) diff --git a/drivers/misc/pvpanic/Kconfig b/drivers/misc/pvpanic/Kconfig index ce8b93e..004c2b7 100644 --- a/drivers/misc/pvpanic/Kconfig +++ b/drivers/misc/pvpanic/Kconfig @@ -1,3 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Pvpanic Kconfig +# +# Copyright (C) 2021 Oracle. +# + config PVPANIC bool "pvpanic device support" help diff --git a/drivers/misc/pvpanic/Makefile b/drivers/misc/pvpanic/Makefile index 1763450..898a731 100644 --- a/drivers/misc/pvpanic/Makefile +++ b/drivers/misc/pvpanic/Makefile @@ -1,3 +1,10 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Pvpanic Makefile +# +# Copyright (C) 2021 Oracle. +# + obj-$(CONFIG_PVPANIC_MMIO) += pvpanic-mmio.o pvpanic-mmio-objs := pvpanic-common.o mmio.o obj-$(CONFIG_PVPANIC_PCI) += pvpanic-pci.o diff --git a/drivers/misc/pvpanic/pci.c b/drivers/misc/pvpanic/pci.c index b672727..d1c1ed9 100644 --- a/drivers/misc/pvpanic/pci.c +++ b/drivers/misc/pvpanic/pci.c @@ -1,3 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Pvpanic PCI Device Support + * + * Copyright (C) 2021 Oracle. +*/ + #include #include #include diff --git a/drivers/misc/pvpanic/pvpanic.h b/drivers/misc/pvpanic/pvpanic.h index 4d6c221..7e75dce 100644 --- a/drivers/misc/pvpanic/pvpanic.h +++ b/drivers/misc/pvpanic/pvpanic.h @@ -1,3 +1,10 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Pvpanic Device Support + * + * Copyright (C) 2021 Oracle. +*/ + #ifndef PVPANIC_H_ #define PVPANIC_H_ -- 1.8.3.1
[PATCH v2] add support for pci in the pvpanic driver
This patchset adds support for PCI in the pvpanic driver. The device already
got in qemu [1].
v2:
- mmio -> MMIO, pci -> PCI suggested by Randy Dunlap.
- group pvpanic-common.c and mmio.c in the same module. The intention was to
have only one module and the common code splitted up to be re-used by the
pvpanic-pci module in the next patch.
- add a new patch where add the licenses for the new files (when I moved the
code to mmio.c I preserved the original licenses there)
- properly clean-up PCI device when driver removed.
How to test:
Run a VM with latest qemu which has the pvpanic-pci device:
qemu-system-aarch64 -device pvpanic-pci
Generate a panic in the guest:
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
Observe in the QMP console the panic events received by the device:
{"timestamp": {"seconds": 1613122186, "microseconds": 141729}, "event":
"GUEST_PANICKED", "data": {"action": "pause"}}
{"timestamp": {"seconds": 1613122186, "microseconds": 141833}, "event":
"GUEST_PANICKED", "data": {"action": "poweroff"}}
{"timestamp": {"seconds": 1613122186, "microseconds": 141896}, "event":
"SHUTDOWN", "data": {"guest": true, "reason": "guest-panic"}}
[1] https://github.com/qemu/qemu/commit/9df52f58e76e904fb141b10318362d718f470db2
Mihai Carabas (3):
misc/pvpanic: split-up generic and platform dependent code
misc/pvpanic: add PCI driver
misc/pvpanic: add license
drivers/misc/Kconfig | 9 +--
drivers/misc/Makefile | 2 +-
drivers/misc/pvpanic.c| 111 --
drivers/misc/pvpanic/Kconfig | 27 +
drivers/misc/pvpanic/Makefile | 11
drivers/misc/pvpanic/mmio.c | 83 +
drivers/misc/pvpanic/pci.c| 56 +
drivers/misc/pvpanic/pvpanic-common.c | 60 ++
drivers/misc/pvpanic/pvpanic.h| 17 ++
9 files changed, 256 insertions(+), 120 deletions(-)
delete mode 100644 drivers/misc/pvpanic.c
create mode 100644 drivers/misc/pvpanic/Kconfig
create mode 100644 drivers/misc/pvpanic/Makefile
create mode 100644 drivers/misc/pvpanic/mmio.c
create mode 100644 drivers/misc/pvpanic/pci.c
create mode 100644 drivers/misc/pvpanic/pvpanic-common.c
create mode 100644 drivers/misc/pvpanic/pvpanic.h
--
1.8.3.1
[PATCH v2 1/3] misc/pvpanic: split-up generic and platform dependent code
Split-up generic and platform dependent code in order to be able to re-use
generic event handling code in pvpanic PCI device driver in the next patch.
The code from pvpanic.c was split in two new files:
- pvpanic-common.c: generic code that handles pvpanic events
- mmio.c: platform/bus dependent code
Signed-off-by: Mihai Carabas
---
drivers/misc/Kconfig | 9 +--
drivers/misc/Makefile | 2 +-
drivers/misc/pvpanic.c| 111 --
drivers/misc/pvpanic/Kconfig | 12
drivers/misc/pvpanic/Makefile | 2 +
drivers/misc/pvpanic/mmio.c | 83 +
drivers/misc/pvpanic/pvpanic-common.c | 60 ++
drivers/misc/pvpanic/pvpanic.h| 10 +++
8 files changed, 169 insertions(+), 120 deletions(-)
delete mode 100644 drivers/misc/pvpanic.c
create mode 100644 drivers/misc/pvpanic/Kconfig
create mode 100644 drivers/misc/pvpanic/Makefile
create mode 100644 drivers/misc/pvpanic/mmio.c
create mode 100644 drivers/misc/pvpanic/pvpanic-common.c
create mode 100644 drivers/misc/pvpanic/pvpanic.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index fafa8b0..0273ecb 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -448,14 +448,6 @@ config MISC_RTSX
tristate
default MISC_RTSX_PCI || MISC_RTSX_USB
-config PVPANIC
- tristate "pvpanic device support"
- depends on HAS_IOMEM && (ACPI || OF)
- help
- This driver provides support for the pvpanic device. pvpanic is
- a paravirtualized device provided by QEMU; it lets a virtual machine
- (guest) communicate panic events to the host.
-
config HISI_HIKEY_USB
tristate "USB GPIO Hub on HiSilicon Hikey 960/970 Platform"
depends on (OF && GPIOLIB) || COMPILE_TEST
@@ -481,4 +473,5 @@ source "drivers/misc/ocxl/Kconfig"
source "drivers/misc/cardreader/Kconfig"
source "drivers/misc/habanalabs/Kconfig"
source "drivers/misc/uacce/Kconfig"
+source "drivers/misc/pvpanic/Kconfig"
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d23231e..9f411b8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -52,7 +52,7 @@ obj-$(CONFIG_CXL_BASE)+= cxl/
obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
obj-$(CONFIG_OCXL) += ocxl/
obj-y += cardreader/
-obj-$(CONFIG_PVPANIC) += pvpanic.o
+obj-$(CONFIG_PVPANIC) += pvpanic/
obj-$(CONFIG_HABANA_AI)+= habanalabs/
obj-$(CONFIG_UACCE)+= uacce/
obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
deleted file mode 100644
index 41cab29..
--- a/drivers/misc/pvpanic.c
+++ /dev/null
@@ -1,111 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Pvpanic Device Support
- *
- * Copyright (C) 2013 Fujitsu.
- * Copyright (C) 2018 ZTE.
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-static void __iomem *base;
-
-MODULE_AUTHOR("Hu Tao ");
-MODULE_DESCRIPTION("pvpanic device driver");
-MODULE_LICENSE("GPL");
-
-static void
-pvpanic_send_event(unsigned int event)
-{
- iowrite8(event, base);
-}
-
-static int
-pvpanic_panic_notify(struct notifier_block *nb, unsigned long code,
-void *unused)
-{
- unsigned int event = PVPANIC_PANICKED;
-
- if (kexec_crash_loaded())
- event = PVPANIC_CRASH_LOADED;
-
- pvpanic_send_event(event);
-
- return NOTIFY_DONE;
-}
-
-static struct notifier_block pvpanic_panic_nb = {
- .notifier_call = pvpanic_panic_notify,
- .priority = 1, /* let this called before broken drm_fb_helper */
-};
-
-static int pvpanic_mmio_probe(struct platform_device *pdev)
-{
- struct device *dev = &pdev->dev;
- struct resource *res;
-
- res = platform_get_mem_or_io(pdev, 0);
- if (!res)
- return -EINVAL;
-
- switch (resource_type(res)) {
- case IORESOURCE_IO:
- base = devm_ioport_map(dev, res->start, resource_size(res));
- if (!base)
- return -ENOMEM;
- break;
- case IORESOURCE_MEM:
- base = devm_ioremap_resource(dev, res);
- if (IS_ERR(base))
- return PTR_ERR(base);
- break;
- default:
- return -EINVAL;
- }
-
- atomic_notifier_chain_register(&panic_notifier_list,
- &pvpanic_panic_nb);
-
- return 0;
-}
-
-static int pvpanic_mmio_remove(struct platform_device *pdev)
-{
-
- atomic_notifier_chain_unregister(&panic_notifier_list,
-&pvpanic_panic_nb);
-
- return 0;
-}
-
-static const struct of_device_id pvpanic_mmio_match[] = {
-
Re: arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared
On Fri, Feb 12, 2021 at 6:48 AM kernel test robot wrote: > > FYI, the error/warning still remains. > | ^~~~ >arch/m68k/68000/dragen2.c: In function 'init_dragen2': > >> arch/m68k/68000/dragen2.c:73:16: error: 'screen_bits' undeclared (first > >> use in this function) > 73 | LSSA = (long) screen_bits; > |^~~ >arch/m68k/68000/dragen2.c:73:16: note: each undeclared identifier is > reported only once for each function it appears in This problem existed before my patch, I just moved the line to another file. To fix it, one needs to test on real hardware and figure out what is supposed to go in there. The bug was apparently introduced in linux-2.5.70 in this commit: commit 2b1a7e97c8c2d6330a432cbcaf83a0ef5fab848e Author: gerg Date: Mon May 26 16:45:57 2003 + [PATCH] fix m68knommu DragonEngine2 target setup code Numerous fixes for the m68knommu DragonEngine2 setup code. It was out of date relative to more recent kernels. Original patches from Georges Menie. BKrev: 3ed244c5dPVeFKP63b4kkeS_rEshag Arnd
Re: [PATCH v2] mm: page-writeback: simplify memcg handling in test_clear_page_writeback()
On Wed 10-02-21 12:44:00, Johannes Weiner wrote:
[...]
> >From 5bcc0f468460aa2670c40318bb657e8b08ef96d5 Mon Sep 17 00:00:00 2001
> From: Johannes Weiner
> Date: Tue, 9 Feb 2021 16:22:42 -0500
> Subject: [PATCH] mm: page-writeback: simplify memcg handling in
> test_clear_page_writeback()
>
> Page writeback doesn't hold a page reference, which allows truncate to
> free a page the second PageWriteback is cleared. This used to require
> special attention in test_clear_page_writeback(), where we had to be
> careful not to rely on the unstable page->memcg binding and look up
> all the necessary information before clearing the writeback flag.
>
> Since commit 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and
> BUG_ON(PageWriteback)") test_clear_page_writeback() is called with an
> explicit reference on the page, and this dance is no longer needed.
>
> Use unlock_page_memcg() and dec_lruvec_page_state() directly.
>
> This removes the last user of the lock_page_memcg() return value,
> change it to void. Touch up the comments in there as well. This also
> removes the last extern user of __unlock_page_memcg(), make it
> static. Further, it removes the last user of dec_lruvec_state(),
> delete it, along with a few other unused helpers.
>
> Signed-off-by: Johannes Weiner
> Acked-by: Hugh Dickins
> Reviewed-by: Shakeel Butt
Acked-by: Michal Hocko
Thanks!
> ---
> include/linux/memcontrol.h | 10 ++
> include/linux/vmstat.h | 24 +++-
> mm/memcontrol.c| 36 +++-
> mm/page-writeback.c| 9 +++--
> 4 files changed, 19 insertions(+), 60 deletions(-)
>
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index a44b2d51aecc..b17053af3287 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -874,8 +874,7 @@ void mem_cgroup_print_oom_group(struct mem_cgroup *memcg);
> extern bool cgroup_memory_noswap;
> #endif
>
> -struct mem_cgroup *lock_page_memcg(struct page *page);
> -void __unlock_page_memcg(struct mem_cgroup *memcg);
> +void lock_page_memcg(struct page *page);
> void unlock_page_memcg(struct page *page);
>
> void __mod_memcg_state(struct mem_cgroup *memcg, int idx, int val);
> @@ -1269,12 +1268,7 @@ mem_cgroup_print_oom_meminfo(struct mem_cgroup *memcg)
> {
> }
>
> -static inline struct mem_cgroup *lock_page_memcg(struct page *page)
> -{
> - return NULL;
> -}
> -
> -static inline void __unlock_page_memcg(struct mem_cgroup *memcg)
> +static inline void lock_page_memcg(struct page *page)
> {
> }
>
> diff --git a/include/linux/vmstat.h b/include/linux/vmstat.h
> index 506d625163a1..3299cd69e4ca 100644
> --- a/include/linux/vmstat.h
> +++ b/include/linux/vmstat.h
> @@ -512,16 +512,10 @@ static inline void mod_lruvec_page_state(struct page
> *page,
>
> #endif /* CONFIG_MEMCG */
>
> -static inline void __inc_lruvec_state(struct lruvec *lruvec,
> - enum node_stat_item idx)
> -{
> - __mod_lruvec_state(lruvec, idx, 1);
> -}
> -
> -static inline void __dec_lruvec_state(struct lruvec *lruvec,
> - enum node_stat_item idx)
> +static inline void inc_lruvec_state(struct lruvec *lruvec,
> + enum node_stat_item idx)
> {
> - __mod_lruvec_state(lruvec, idx, -1);
> + mod_lruvec_state(lruvec, idx, 1);
> }
>
> static inline void __inc_lruvec_page_state(struct page *page,
> @@ -536,18 +530,6 @@ static inline void __dec_lruvec_page_state(struct page
> *page,
> __mod_lruvec_page_state(page, idx, -1);
> }
>
> -static inline void inc_lruvec_state(struct lruvec *lruvec,
> - enum node_stat_item idx)
> -{
> - mod_lruvec_state(lruvec, idx, 1);
> -}
> -
> -static inline void dec_lruvec_state(struct lruvec *lruvec,
> - enum node_stat_item idx)
> -{
> - mod_lruvec_state(lruvec, idx, -1);
> -}
> -
> static inline void inc_lruvec_page_state(struct page *page,
>enum node_stat_item idx)
> {
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 9e455815fb7a..e29d3d64c27e 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -2124,11 +2124,10 @@ void mem_cgroup_print_oom_group(struct mem_cgroup
> *memcg)
> * This function protects unlocked LRU pages from being moved to
> * another cgroup.
> *
> - * It ensures lifetime of the returned memcg. Caller is responsible
> - * for the lifetime of the page; __unlock_page_memcg() is available
> - * when @page might get freed inside the locked section.
> + * It ensures lifetime of the locked memcg. Caller is responsible
> + * for the lifetime of the page.
> */
> -struct mem_cgroup *lock_page_memcg(struct page *page)
> +void lock_page_memcg(struct page *page)
> {
> struct page *head = compound_head(page); /* rmap on tail pages */
> struct mem_cgroup *memcg;
> @@ -2138,21 +2137,15 @@ st
Re: [PATCH 1/2] staging: greybus: Fixed alignment issue in hid.c
On Fri, Feb 12, 2021 at 03:25:29PM +0530, Viresh Kumar wrote: > On 12-02-21, 10:52, Johan Hovold wrote: > > But what will the checkpatch crew then work on? > > Lol.. > > > Better staging than the rest of the kernel. > > [ /me wondering on who stops them from sending patches for rest of the > kernel ? ] Ideally maintainers should at least push back when they do. Johan
[PATCH] PCI : check if type 0 devices have all BARs of size zero
From: Wasim Khan
Log a message if all BARs of type 0 devices are of
size zero. This can help detecting type 0 devices
not reporting BAR size correctly.
Signed-off-by: Wasim Khan
---
drivers/pci/probe.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 953f15abc850..6438d6d56777 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -321,6 +321,7 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
unsigned int pos, reg;
+ bool found = false;
if (dev->non_compliant_bars)
return;
@@ -333,8 +334,12 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
int howmany, int rom)
struct resource *res = &dev->resource[pos];
reg = PCI_BASE_ADDRESS_0 + (pos << 2);
pos += __pci_read_base(dev, pci_bar_unknown, res, reg);
+ found |= res->flags ? 1 : 0;
}
+ if (!dev->hdr_type && !found)
+ pci_info(dev, "BAR size is 0 for BAR[0..%d]\n", howmany - 1);
+
if (rom) {
struct resource *res = &dev->resource[PCI_ROM_RESOURCE];
dev->rom_base_reg = rom;
--
2.25.1
[PATCH v2 0/3] iio: core,buffer-dma: add mmap support
Changelog v1 -> v2: * https://lore.kernel.org/linux-iio/20210211123353.78963-1-alexandru.ardel...@analog.com/T/#t * removed IIO_BUFFER_BLOCK_FLAG_CYCLIC flag; will be added in a later patch * removed extra line in tools/iio/iio_generic_buffer.c * patch 'iio: core: Add mmap interface infrastructure' added docstrings for new hooks (alloc_blocks, mmap, etc) This is basically Lars' work adapted from branch: https://github.com/larsclausen/linux/commits/iio-high-speed-5.10 [hopefully i got the stuff correctly from that branch] What is different, is that this one is adapted on top of the multibuffer support (currently at v5) discussed here: https://lore.kernel.org/linux-iio/20210211122452.78106-1-alexandru.ardel...@analog.com/T/#t Also, adapted an example for high-speed/mmap support in 'tools/iio/iio_generic_buffer.c' The example is adapted from libiio: https://github.com/analogdevicesinc/libiio/blob/master/local.c#L51 but will all the ioctl()s organized after the one that are reserved (hopefully) for IIO Tested that mmap() works. Moved (artifically) valid buffer0 as buffer2 and the operation still works. Alexandru Ardelean (1): tools: iio: add example for high-speed buffer support Lars-Peter Clausen (2): iio: core: Add mmap interface infrastructure iio: buffer-dma: Add mmap support drivers/iio/buffer/industrialio-buffer-dma.c | 314 -- .../buffer/industrialio-buffer-dmaengine.c| 22 +- drivers/iio/industrialio-buffer.c | 158 + include/linux/iio/buffer-dma.h| 25 +- include/linux/iio/buffer_impl.h | 23 ++ include/uapi/linux/iio/buffer.h | 26 ++ tools/iio/iio_generic_buffer.c| 183 +- 7 files changed, 704 insertions(+), 47 deletions(-) -- 2.17.1
[PATCH v2 1/3] iio: core: Add mmap interface infrastructure
From: Lars-Peter Clausen
Add the necessary infrastructure to the IIO core to support an mmap based
interface to access the capture data.
The advantage of the mmap based interface compared to the read() based
interface is that it avoids an extra copy of the data between kernel and
userspace. This is particular useful for high-speed devices which produce
several megabytes or even gigabytes of data per second.
The data for the mmap interface is managed at the granularity of so called
blocks. A block is a contiguous region of memory (at the moment both
physically and virtually contiguous). Reducing the granularity from byte
level to block level is done to reduce the userspace-kernelspace
synchronization overhead since performing syscalls for each byte at a
data-rate of a few megabytes is not feasible.
This of course leads to a slightly increased latency. For this reason an
application can choose the size of the blocks as well as how many blocks it
allocates. E.g. two blocks would be a traditional double buffering scheme.
But using a higher number might be necessary to avoid underflow/overflow
situations in the presence of scheduling latencies.
A block can either be owned by kernel space or userspace. When owned by
userspace it save to access the data in the block and process it. When
owned by kernel space the block can be in one of 3 states.
It can be in the incoming queue where all blocks submitted from userspace
are placed and are waiting to be processed by the kernel driver.
It can be currently being processed by the kernel driver, this means it is
actively placing capturing data in it (usually using DMA).
Or it can be in the outgoing queue where all blocks that have been
processed by the kernel are placed. Userspace can dequeue the blocks as
necessary.
As part of the interface 5 new IOCTLs to manage the blocks and exchange
them between userspace and kernelspace. The IOCTLs can be accessed through
a open file descriptor to a IIO device.
IIO_BUFFER_BLOCK_ALLOC_IOCTL(struct iio_buffer_block_alloc_req *):
Allocates new blocks. Can be called multiple times if necessary. A newly
allocated block is initially owned by userspace.
IIO_BUFFER_BLOCK_FREE_IOCTL(void):
Frees all previously allocated blocks. If the backing memory of a block is
still in use by a kernel driver (i.e. active DMA transfer) it will be
freed once the kernel driver has released it.
IIO_BUFFER_BLOCK_QUERY_IOCTL(struct iio_buffer_block *):
Queries information about a block. The id of the block about which
information is to be queried needs to be set by userspace.
IIO_BUFFER_BLOCK_ENQUEUE_IOCTL(struct iio_buffer_block *):
Places a block on the incoming queue. This transfers ownership of the
block from userspace to kernelspace. Userspace must populate the id field
of the block to indicate which block to enqueue.
IIO_BUFFER_BLOCK_DEQUEUE_IOCTL(struct iio_buffer_block *):
Removes the first block from the outgoing queue. This transfers ownership
of the block from kernelspace to userspace. Kernelspace will populate all
fields of the block. If the queue is empty and the file descriptor is set
to blocking the IOCTL will block until a new block is available on the
outgoing queue.
To access the data stored in a block by userspace the block must be mapped
to the process's memory. This is done by calling mmap() on the IIO device
file descriptor. Each block has a unique offset assigned to it which should
be passed to the mmap interface. E.g.
mmap(0, block.size, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
block.offset);
A typical workflow for the new interface is:
BLOCK_ALLOC
foreach block
BLOCK_QUERY block
mmap block.data.offset
BLOCK_ENQUEUE block
enable buffer
while !done
BLOCK_DEQUEUE block
process data
BLOCK_ENQUEUE block
disable buffer
BLOCK_FREE
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Alexandru Ardelean
---
drivers/iio/industrialio-buffer.c | 157 ++
include/linux/iio/buffer-dma.h| 5 -
include/linux/iio/buffer_impl.h | 23 +
include/uapi/linux/iio/buffer.h | 26 +
4 files changed, 206 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/industrialio-buffer.c
b/drivers/iio/industrialio-buffer.c
index 3aa6702a5811..50228df0b09f 100644
--- a/drivers/iio/industrialio-buffer.c
+++ b/drivers/iio/industrialio-buffer.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1370,6 +1371,12 @@ static void
iio_buffer_unregister_legacy_sysfs_groups(struct iio_dev *indio_dev)
kfree(iio_dev_opaque->legacy_scan_el_group.attrs);
}
+static void iio_buffer_free_blocks(struct iio_buffer *buffer)
+{
+ if (buffer->access->free_blocks)
+ buffer->access->free_blocks(buffer);
+}
+
static int iio_buffer_chrdev_release(struct inode *inode, struct file *filep)
{
struct iio_dev_buffer_pair *ib = filep->private_data;
@@ -1378,18 +1385,24 @@
