rcu_read_lock lost its compiler barrier
Digging up an old email because I was not aware of this previously
but Paul pointed me to it during another discussion.
On Mon, Sep 21, 2015 at 01:43:27PM -0700, Paul E. McKenney wrote:
> On Mon, Sep 21, 2015 at 09:30:49PM +0200, Frederic Weisbecker wrote:
>
> > > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > > index d63bb77..6c3cece 100644
> > > --- a/include/linux/rcupdate.h
> > > +++ b/include/linux/rcupdate.h
> > > @@ -297,12 +297,14 @@ void synchronize_rcu(void);
> > >
> > > static inline void __rcu_read_lock(void)
> > > {
> > > - preempt_disable();
> > > + if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > > + preempt_disable();
> >
> > preempt_disable() is a no-op when !CONFIG_PREEMPT_COUNT, right?
> > Or rather it's a barrier(), which is anyway implied by rcu_read_lock().
> >
> > So perhaps we can get rid of the IS_ENABLED() check?
>
> Actually, barrier() is not intended to be implied by rcu_read_lock().
> In a non-preemptible RCU implementation, it doesn't help anything
> to have the compiler flush its temporaries upon rcu_read_lock()
> and rcu_read_unlock().
This is seriously broken. RCU has been around for years and is
used throughout the kernel while the compiler barrier existed.
You can't then go and decide to remove the compiler barrier! To do
that you'd need to audit every single use of rcu_read_lock in the
kernel to ensure that they're not depending on the compiler barrier.
This is also contrary to the definition of almost every other
*_lock primitive in the kernel where the compiler barrier is
included.
So please revert this patch.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: ss: Checking efficient analysis for network connections
> If you use netlink operations directly, Thanks for such feedback. Should this programming interface become better known? > you can have the kernel filter on various criteria > and only get the socket entries you are interested in. This is good to know. > This whole discussion has zero to do with what text format 'ss' outputs. Some software components are affected here. The socket statistic tool is using data from the directory “/proc/net”. * Provided text files refer to known Linux data formats. Can it happen to work with other data formats there? * The analysis program can also be extended for the support of additional data formats, can't it? Regards, Markus
Re: [PATCH v2] arm64: dts: rockchip: Add missing configuration pwr amd rst for PCIe
Hi Manivannan,
Thanks for your review comment.
On Sat, 1 Jun 2019 at 15:21, Manivannan Sadhasivam
wrote:
>
> Hi,
>
> On Fri, May 31, 2019 at 08:19:13PM +, Anand Moon wrote:
> > This patch add missing PCIe gpio pin (#PCIE_PWR) for vcc3v3_pcie power
> > regulator node also add missing reset pinctrl (#PCIE_PERST_L) for PCIe node.
> >
> > Signed-off-by: Anand Moon
> > ---
> > using schematics: thanks for suggested by Manivannan
> > [1]
> > https://dl.vamrs.com/products/rock960/docs/hw/rock960_sch_v12_20180314.pdf
> >
> > Changes from prevoius patch:
> > [2] https://patchwork.kernel.org/patch/10968695/
> >
> > Fix the suject and commit message and corrected the PWR and PERST
> > configuration
> > as per shematics and dts nodes.
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399-ficus.dts| 7 +++
> > arch/arm64/boot/dts/rockchip/rk3399-rock960.dts | 7 +++
> > arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi | 3 +--
> > 3 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > index 6b059bd7a04f..94e2a59bc1c7 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts
> > @@ -89,6 +89,8 @@
> >
> > {
> > ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_clkreqn_cpm _perst_l>;
>
> Looks like ep-gpio is wrong here :/ I probably referred old schematics
> at that time. Correct pin mapping is,
>
> ep-gpios = < RK_PD4 GPIO_ACTIVE_HIGH>;
>
> And this should be fixed in a separate patch with "Fixes" tag!
>
Ok I will changes per the above. I have also check this with the
u-boot changes .
> > };
> >
> > {
> > @@ -104,6 +106,11 @@
> > rockchip,pins =
> > <1 RK_PD0 RK_FUNC_GPIO _pull_none>;
> > };
> > +
> > + pcie_perst_l: pcie-perst-l {
> > + rockchip,pins =
> > + <4 RK_PD4 RK_FUNC_GPIO _pull_none>;
> > + };
> > };
> >
> > usb2 {
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > index 12285c51cceb..665fe09c7c74 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dts
> > @@ -64,6 +64,8 @@
> >
> > {
> > ep-gpios = < RK_PA2 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_clkreqn_cpm _perst_l>;
> > };
> >
> > {
> > @@ -104,6 +106,11 @@
> > rockchip,pins =
> > <2 RK_PA5 RK_FUNC_GPIO _pull_none>;
> > };
> > +
> > + pcie_perst_l: pcie-perst-l {
> > + rockchip,pins =
> > + <2 RK_PA2 RK_FUNC_GPIO _pull_none>;
> > + };
> > };
> >
> > usb2 {
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > index c7d48d41e184..3df0cd67b4b2 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-rock960.dtsi
> > @@ -55,6 +55,7 @@
> >
> > vcc3v3_pcie: vcc3v3-pcie-regulator {
> > compatible = "regulator-fixed";
> > + gpio = < RK_PA5 GPIO_ACTIVE_HIGH>;
>
> Actually the PWR pin mapping is defined in a separate node for both Rock960
> and Ficus in respective dts. So defining it here would be wrong as the PWR
> pin mapping is different for both boards.
>
Ok Thanks, so I will move the PWR pin nodes the respective dts files.
PCIE_PERST PCIE_PWR
Rock960 GPIO2_A2 GPIO2_A5
Ficus GPIO2_D4 GPIO1_D0 /* reference u-boot */
Pls confirm this is correct.
Best Regards
-Anand
> Thanks,
> Mani
Re: [PATCH] ceph: use ceph_evict_inode to cleanup inode's resource
On Sun, Jun 02, 2019 at 10:25:46AM +0800, Yan, Zheng wrote:
> remove_session_caps() relies on __wait_on_freeing_inode(), to wait for
> freezing inode to remove its caps. But VFS wakes freeing inode waiters
> before calling destroy_inode().
*blink*
Which tree is that against?
> -static void ceph_i_callback(struct rcu_head *head)
> -{
> - struct inode *inode = container_of(head, struct inode, i_rcu);
> - struct ceph_inode_info *ci = ceph_inode(inode);
> -
> - kfree(ci->i_symlink);
> - kmem_cache_free(ceph_inode_cachep, ci);
> -}
... is gone from mainline, and AFAICS not reintroduced in ceph tree.
What am I missing here?
[PATCH] ceph: use ceph_evict_inode to cleanup inode's resource
remove_session_caps() relies on __wait_on_freeing_inode(), to wait for
freezing inode to remove its caps. But VFS wakes freeing inode waiters
before calling destroy_inode().
Signed-off-by: "Yan, Zheng"
---
fs/ceph/inode.c | 25 ++---
fs/ceph/super.c | 1 +
fs/ceph/super.h | 1 +
3 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/ceph/inode.c b/fs/ceph/inode.c
index 125ac54b5841..9e481b41d5bc 100644
--- a/fs/ceph/inode.c
+++ b/fs/ceph/inode.c
@@ -515,22 +515,13 @@ struct inode *ceph_alloc_inode(struct super_block *sb)
return >vfs_inode;
}
-static void ceph_i_callback(struct rcu_head *head)
-{
- struct inode *inode = container_of(head, struct inode, i_rcu);
- struct ceph_inode_info *ci = ceph_inode(inode);
-
- kfree(ci->i_symlink);
- kmem_cache_free(ceph_inode_cachep, ci);
-}
-
-void ceph_destroy_inode(struct inode *inode)
+void ceph_evict_inode(struct inode *inode)
{
struct ceph_inode_info *ci = ceph_inode(inode);
struct ceph_inode_frag *frag;
struct rb_node *n;
- dout("destroy_inode %p ino %llx.%llx\n", inode, ceph_vinop(inode));
+ dout("evict_inode %p ino %llx.%llx\n", inode, ceph_vinop(inode));
ceph_fscache_unregister_inode_cookie(ci);
@@ -577,7 +568,19 @@ void ceph_destroy_inode(struct inode *inode)
ceph_buffer_put(ci->i_xattrs.prealloc_blob);
ceph_put_string(rcu_dereference_raw(ci->i_layout.pool_ns));
+}
+static void ceph_i_callback(struct rcu_head *head)
+{
+ struct inode *inode = container_of(head, struct inode, i_rcu);
+ struct ceph_inode_info *ci = ceph_inode(inode);
+
+ kfree(ci->i_symlink);
+ kmem_cache_free(ceph_inode_cachep, ci);
+}
+
+void ceph_destroy_inode(struct inode *inode)
+{
call_rcu(>i_rcu, ceph_i_callback);
}
diff --git a/fs/ceph/super.c b/fs/ceph/super.c
index b1ee41372e85..67eb9d592ab7 100644
--- a/fs/ceph/super.c
+++ b/fs/ceph/super.c
@@ -842,6 +842,7 @@ static const struct super_operations ceph_super_ops = {
.destroy_inode = ceph_destroy_inode,
.write_inode= ceph_write_inode,
.drop_inode = ceph_drop_inode,
+ .evict_inode= ceph_evict_inode,
.sync_fs= ceph_sync_fs,
.put_super = ceph_put_super,
.remount_fs = ceph_remount,
diff --git a/fs/ceph/super.h b/fs/ceph/super.h
index 9c82d213a5ab..98d2bafc2ee2 100644
--- a/fs/ceph/super.h
+++ b/fs/ceph/super.h
@@ -882,6 +882,7 @@ static inline bool __ceph_have_pending_cap_snap(struct
ceph_inode_info *ci)
extern const struct inode_operations ceph_file_iops;
extern struct inode *ceph_alloc_inode(struct super_block *sb);
+extern void ceph_evict_inode(struct inode *inode);
extern void ceph_destroy_inode(struct inode *inode);
extern int ceph_drop_inode(struct inode *inode);
--
2.17.2
Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver
On Sat, Jun 01, 2019 at 03:06:59PM +0300, Vladimir Oltean wrote: > PTP frames will reconstruct the full timestamp without waiting for any > meta (they are the meta), while other MAC-trapped frames (STP etc) > will just carry a meaningless skb->cb when passed up the stack. > In retrospect, it would have been amazing if the switch gave me the > meta frames *before* the actual link-local frames that needed the > timestamp. I didn't follow everything you wrote, but it sounds like you are on the right track! Thanks, Richard
Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver
On Sat, Jun 01, 2019 at 01:31:34PM +0300, Vladimir Oltean wrote:
> If I dress the meta frame into a PTP frame (btw is there any
> preferable event message for this purpose?)
I would just make a L2 PTP event message from a specific source
address, just like the phyter does.
Use Ethertype ETH_P_1588 (0x88f7), and make sure the "general" bit
(0x8) of the messageType field (the first payload byte, at offset 14)
is clear.
dp83640.c uses a magic source address to identify a time stamping
status frame:
static u8 status_frame_src[6] = { 0x08, 0x00, 0x17, 0x0B, 0x6B, 0x0F };
HTH,
Richard
RE: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
Hi Dan,
> > > > if (is_multicast_ether_addr(ra)) {
> > > > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > > > + if (!skb_uap)
> > > > + return -ENOMEM;
> > >
> > > I think we would want to free dev_kfree_skb_any(skb) before returning.
> > I think if the pointer is NULL, no need to free it;
>
> You're misreading skb vs skb_uap. "skb_uap" is NULL but "skb" is non-NULL
> and I'm pretty sure we should free it.
Oh, right. I missed it; Yes you are correct.
Regards,
Ganapathi
[PATCH 4/7] scsi: mac_scsi: Increase PIO/PDMA transfer length threshold
Some targets introduce delays when handshaking the response to certain
commands. For example, a disk may send a 96-byte response to an INQUIRY
command (or a 24-byte response to a MODE SENSE command) too slowly.
Apparently the first 12 or 14 bytes are handshaked okay but then the
system bus error timeout is reached while transferring the next word.
Since the scsi bus phase hasn't changed, the driver then sets the target
borken flag to prevent further PDMA transfers. The driver also logs the
warning, "switching to slow handshake".
Raise the PDMA threshold to 512 bytes so that PIO transfers will be used
for these commands. This default is sufficiently low that PDMA will still
be used for READ and WRITE commands.
The existing threshold (16 bytes) was chosen more or less at random.
However, best performance requires the threshold to be as low as possible.
Those systems that don't need the PIO workaround at all may benefit from
mac_scsi.setup_use_pdma=1
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org # v4.14+
Fixes: 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/mac_scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mac_scsi.c b/drivers/scsi/mac_scsi.c
index 8b4b5b1a13d7..ba1afcaadae8 100644
--- a/drivers/scsi/mac_scsi.c
+++ b/drivers/scsi/mac_scsi.c
@@ -52,7 +52,7 @@ static int setup_cmd_per_lun = -1;
module_param(setup_cmd_per_lun, int, 0);
static int setup_sg_tablesize = -1;
module_param(setup_sg_tablesize, int, 0);
-static int setup_use_pdma = -1;
+static int setup_use_pdma = 512;
module_param(setup_use_pdma, int, 0);
static int setup_hostid = -1;
module_param(setup_hostid, int, 0);
@@ -305,7 +305,7 @@ static int macscsi_dma_xfer_len(struct NCR5380_hostdata
*hostdata,
struct scsi_cmnd *cmd)
{
if (hostdata->flags & FLAG_NO_PSEUDO_DMA ||
- cmd->SCp.this_residual < 16)
+ cmd->SCp.this_residual < setup_use_pdma)
return 0;
return cmd->SCp.this_residual;
--
2.21.0
[PATCH 7/7] scsi: mac_scsi: Treat Last Byte Sent time-out as failure
A system bus error during a PDMA send operation can result in bytes being
lost. Theoretically that could cause the target to remain in DATA OUT
phase and the initiator (expecting a phase change) would time-out waiting
for the Last Byte Sent flag. Should that happen, fail the transfer so the
core driver will stop using PDMA with this target.
Cc: Michael Schmitz
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/mac_scsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/mac_scsi.c b/drivers/scsi/mac_scsi.c
index 2e503f06ac99..68d4665112b5 100644
--- a/drivers/scsi/mac_scsi.c
+++ b/drivers/scsi/mac_scsi.c
@@ -188,9 +188,12 @@ static inline int macscsi_pwrite(struct NCR5380_hostdata
*hostdata,
if (hostdata->pdma_residual == 0) {
if (NCR5380_poll_politely(hostdata, TARGET_COMMAND_REG,
TCR_LAST_BYTE_SENT,
- TCR_LAST_BYTE_SENT, HZ / 64)
< 0)
+ TCR_LAST_BYTE_SENT,
+ HZ / 64) < 0) {
scmd_printk(KERN_ERR, hostdata->connected,
"%s: Last Byte Sent timeout\n",
__func__);
+ result = -1;
+ }
goto out;
}
--
2.21.0
[PATCH 0/7] NCR5380 drivers: fixes and improvements
Among other improvements, this patch series fixes a data corruption bug in the mac_scsi driver and a bug in the EH abort routine in the core 5380 driver. For consistency I have ignored certain checkpatch.pl complaints about the indentation in mac_scsi.c. The remaining complaints seem to be false positives. Some of these patches are not trivial to backport. Those patches have been nominated for recent -stable branches only. Finn Thain (7): Revert "scsi: ncr5380: Increase register polling limit" scsi: NCR5380: Always re-enable reselection interrupt scsi: NCR5380: Handle PDMA failure reliably scsi: mac_scsi: Increase PIO/PDMA transfer length threshold scsi: mac_scsi: Fix pseudo DMA implementation, take 2 scsi: mac_scsi: Enable PDMA on Mac IIfx scsi: mac_scsi: Treat Last Byte Sent time-out as failure arch/m68k/include/asm/mac_pdma.h | 179 ++ arch/m68k/mac/config.c | 10 +- drivers/scsi/NCR5380.c | 18 +-- drivers/scsi/NCR5380.h | 2 +- drivers/scsi/mac_scsi.c | 249 +++ 5 files changed, 280 insertions(+), 178 deletions(-) create mode 100644 arch/m68k/include/asm/mac_pdma.h -- 2.21.0
[PATCH 3/7] scsi: NCR5380: Handle PDMA failure reliably
A PDMA error is handled in the core driver by setting the device's
'borken' flag and aborting the command. Unfortunately, do_abort() is not
dependable. Perform a SCSI bus reset instead, to make sure that the
command fails and gets retried.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org # v4.20+
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 08e3ea8159b3..d9fa9cf2fd8b 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -1761,10 +1761,8 @@ static void NCR5380_information_transfer(struct
Scsi_Host *instance)
scmd_printk(KERN_INFO, cmd,
"switching to slow
handshake\n");
cmd->device->borken = 1;
- sink = 1;
- do_abort(instance);
- cmd->result = DID_ERROR << 16;
- /* XXX - need to source or sink
data here, as appropriate */
+ do_reset(instance);
+ bus_reset_cleanup(instance);
}
} else {
/* Transfer a small chunk so that the
--
2.21.0
[PATCH 1/7] Revert "scsi: ncr5380: Increase register polling limit"
This reverts commit 4822827a69d7cd3bc5a07b7637484ebd2cf88db6.
The purpose of that commit was to suppress a timeout warning message
which appeared to be caused by target latency. But suppressing the warning
is undesirable as the warning may indicate a messed up transfer count.
Another problem with that commit is that 15 ms is too long to keep
interrupts disabled as interrupt latency can cause system clock drift
and other problems.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org
Fixes: 4822827a69d7 ("scsi: ncr5380: Increase register polling limit")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/NCR5380.h b/drivers/scsi/NCR5380.h
index efca509b92b0..5935fd6d1a05 100644
--- a/drivers/scsi/NCR5380.h
+++ b/drivers/scsi/NCR5380.h
@@ -235,7 +235,7 @@ struct NCR5380_cmd {
#define NCR5380_PIO_CHUNK_SIZE 256
/* Time limit (ms) to poll registers when IRQs are disabled, e.g. during PDMA
*/
-#define NCR5380_REG_POLL_TIME 15
+#define NCR5380_REG_POLL_TIME 10
static inline struct scsi_cmnd *NCR5380_to_scmd(struct NCR5380_cmd *ncmd_ptr)
{
--
2.21.0
[PATCH 6/7] scsi: mac_scsi: Enable PDMA on Mac IIfx
Add support for Apple's custom "SCSI DMA" chip. This patch doesn't make
use of its DMA capability. Just the PDMA capability is sufficient to
improve sequential read throughput by a factor of 5.
Cc: Michael Schmitz
Cc: Joshua Thompson
Cc: Geert Uytterhoeven
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/mac/config.c | 10 +++--
drivers/scsi/mac_scsi.c | 47 ++---
2 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/arch/m68k/mac/config.c b/arch/m68k/mac/config.c
index 39835ca5a474..611f73bfc87c 100644
--- a/arch/m68k/mac/config.c
+++ b/arch/m68k/mac/config.c
@@ -911,6 +911,10 @@ static const struct resource mac_scsi_iifx_rsrc[]
__initconst = {
.flags = IORESOURCE_MEM,
.start = 0x50008000,
.end = 0x50009FFF,
+ }, {
+ .flags = IORESOURCE_MEM,
+ .start = 0x50008000,
+ .end = 0x50009FFF,
},
};
@@ -1012,10 +1016,12 @@ int __init mac_platform_init(void)
case MAC_SCSI_IIFX:
/* Addresses from The Guide to Mac Family Hardware.
* $5000 8000 - $5000 9FFF: SCSI DMA
+* $5000 A000 - $5000 BFFF: Alternate SCSI
* $5000 C000 - $5000 DFFF: Alternate SCSI (DMA)
* $5000 E000 - $5000 : Alternate SCSI (Hsk)
-* The SCSI DMA custom IC embeds the 53C80 core. mac_scsi does
-* not make use of its DMA or hardware handshaking logic.
+* The A/UX header file sys/uconfig.h says $50F0 8000.
+* The "SCSI DMA" custom IC embeds the 53C80 core and
+* supports Programmed IO, DMA and PDMA (hardware handshake).
*/
platform_device_register_simple("mac_scsi", 0,
mac_scsi_iifx_rsrc, ARRAY_SIZE(mac_scsi_iifx_rsrc));
diff --git a/drivers/scsi/mac_scsi.c b/drivers/scsi/mac_scsi.c
index e83b47a7e4b5..2e503f06ac99 100644
--- a/drivers/scsi/mac_scsi.c
+++ b/drivers/scsi/mac_scsi.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -90,11 +91,22 @@ static int __init mac_scsi_setup(char *str)
__setup("mac5380=", mac_scsi_setup);
#endif /* !MODULE */
+/* The "SCSI DMA" chip on the IIfx implements this register. */
+#define CTRL_REG0x8
+#define CTRL_INTERRUPTS_ENABLE BIT(1)
+#define CTRL_HANDSHAKE_MODE BIT(3)
+
+static inline void write_ctrl_reg(struct NCR5380_hostdata *hostdata, u32 value)
+{
+ out_be32(hostdata->io + (CTRL_REG << 4), value);
+}
+
static inline int macscsi_pread(struct NCR5380_hostdata *hostdata,
unsigned char *dst, int len)
{
u8 __iomem *s = hostdata->pdma_io + (INPUT_DATA_REG << 4);
unsigned char *d = dst;
+ int result = 0;
hostdata->pdma_residual = len;
@@ -103,6 +115,10 @@ static inline int macscsi_pread(struct NCR5380_hostdata
*hostdata,
BASR_DRQ | BASR_PHASE_MATCH, HZ / 64)) {
int bytes;
+ if (macintosh_config->ident == MAC_MODEL_IIFX)
+ write_ctrl_reg(hostdata, CTRL_HANDSHAKE_MODE |
+CTRL_INTERRUPTS_ENABLE);
+
bytes = mac_pdma_recv(s, d, min(hostdata->pdma_residual, 512));
if (bytes > 0) {
@@ -111,7 +127,7 @@ static inline int macscsi_pread(struct NCR5380_hostdata
*hostdata,
}
if (hostdata->pdma_residual == 0)
- return 0;
+ goto out;
if (NCR5380_poll_politely2(hostdata, STATUS_REG, SR_REQ, SR_REQ,
BUS_AND_STATUS_REG, BASR_ACK,
@@ -119,7 +135,7 @@ static inline int macscsi_pread(struct NCR5380_hostdata
*hostdata,
scmd_printk(KERN_DEBUG, hostdata->connected,
"%s: !REQ and !ACK\n", __func__);
if (!(NCR5380_read(BUS_AND_STATUS_REG) & BASR_PHASE_MATCH))
- return 0;
+ goto out;
if (bytes == 0)
udelay(MAC_PDMA_DELAY);
@@ -130,13 +146,18 @@ static inline int macscsi_pread(struct NCR5380_hostdata
*hostdata,
dsprintk(NDEBUG_PSEUDO_DMA, hostdata->host,
"%s: bus error (%d/%d)\n", __func__, d - dst, len);
NCR5380_dprint(NDEBUG_PSEUDO_DMA, hostdata->host);
- return -1;
+ result = -1;
+ goto out;
}
scmd_printk(KERN_ERR, hostdata->connected,
"%s: phase mismatch or !DRQ\n", __func__);
NCR5380_dprint(NDEBUG_PSEUDO_DMA, hostdata->host);
- return -1;
+ result = -1;
+out:
+ if (macintosh_config->ident == MAC_MODEL_IIFX)
+ write_ctrl_reg(hostdata,
[PATCH 5/7] scsi: mac_scsi: Fix pseudo DMA implementation, take 2
A system bus error during a PDMA transfer can mess up the calculation of
the transfer residual (the PDMA handshaking hardware lacks a byte
counter). This results in data corruption.
The algorithm in this patch anticipates a bus error by starting each
transfer with a MOVE.B instruction. If a bus error is caught the transfer
will be retried. If a bus error is caught later in the transfer (for a
MOVE.W instruction) the transfer gets failed and subsequent requests for
that target will use PIO instead of PDMA.
This avoids the "!REQ and !ACK" error so the severity level of that
message is reduced to KERN_DEBUG.
Cc: Michael Schmitz
Cc: Geert Uytterhoeven
Cc: sta...@vger.kernel.org # v4.14+
Fixes: 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation")
Reported-by: Chris Jones
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
arch/m68k/include/asm/mac_pdma.h | 179 +++
drivers/scsi/mac_scsi.c | 201 ---
2 files changed, 226 insertions(+), 154 deletions(-)
create mode 100644 arch/m68k/include/asm/mac_pdma.h
diff --git a/arch/m68k/include/asm/mac_pdma.h b/arch/m68k/include/asm/mac_pdma.h
new file mode 100644
index ..44e2fb6d4b1c
--- /dev/null
+++ b/arch/m68k/include/asm/mac_pdma.h
@@ -0,0 +1,179 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/* Copyright (C) 2019 Finn Thain */
+
+#ifndef _ASM_MAC_PDMA_H_
+#define _ASM_MAC_PDMA_H_
+
+#include
+
+/*
+ * According to "Inside Macintosh: Devices", Mac OS requires disk drivers to
+ * specify the number of bytes between the delays expected from a SCSI target.
+ * This allows the operating system to "prevent bus errors when a target fails
+ * to deliver the next byte within the processor bus error timeout period."
+ * Linux SCSI drivers lack knowledge of the timing behaviour of SCSI targets
+ * so bus errors are unavoidable.
+ *
+ * If a MOVE.B instruction faults, we assume that zero bytes were transferred
+ * and simply retry. That assumption probably depends on target behaviour but
+ * seems to hold up okay. The NOP provides synchronization: without it the
+ * fault can sometimes occur after the program counter has moved past the
+ * offending instruction. Post-increment addressing can't be used.
+ */
+
+#define MOVE_BYTE(operands) \
+ asm volatile ( \
+ "1: moveb " operands " \n" \
+ "11:nop\n" \
+ " addq #1,%0 \n" \
+ " subq #1,%1 \n" \
+ "40: \n" \
+ " \n" \
+ ".section .fixup,\"ax\"\n" \
+ ".even \n" \
+ "90:movel #1, %2 \n" \
+ " jra 40b\n" \
+ ".previous \n" \
+ " \n" \
+ ".section __ex_table,\"a\" \n" \
+ ".align 4 \n" \
+ ".long 1b,90b\n" \
+ ".long 11b,90b\n" \
+ ".previous \n" \
+ : "+a" (addr), "+r" (n), "+r" (result) : "a" (io))
+
+/*
+ * If a MOVE.W (or MOVE.L) instruction faults, it cannot be retried because
+ * the residual byte count would be uncertain. In that situation the MOVE_WORD
+ * macro clears n in the fixup section to abort the transfer.
+ */
+
+#define MOVE_WORD(operands) \
+ asm volatile ( \
+ "1: movew " operands " \n" \
+ "11:nop\n" \
+ " subq #2,%1 \n" \
+ "40: \n" \
+ " \n" \
+ ".section .fixup,\"ax\"\n" \
+ ".even \n" \
+ "90:movel #0, %1 \n" \
+ " movel #2, %2 \n" \
+ " jra 40b\n" \
+ ".previous \n" \
+ " \n" \
+ ".section __ex_table,\"a\" \n" \
+ ".align 4 \n" \
+ ".long 1b,90b\n" \
+ ".long 11b,90b\n" \
+ ".previous \n" \
+ : "+a" (addr), "+r" (n), "+r" (result) : "a" (io))
+
+#define MOVE_16_WORDS(operands) \
+ asm volatile ( \
+ "1: movew " operands " \n" \
+ "2: movew " operands " \n" \
+ "3: movew " operands " \n" \
+ "4: movew " operands " \n" \
+ "5: movew " operands " \n" \
+ "6: movew " operands " \n" \
+ "7: movew " operands " \n" \
+
[PATCH 2/7] scsi: NCR5380: Always re-enable reselection interrupt
The reselection interrupt gets disabled during selection and must be
re-enabled when hostdata->connected becomes NULL. If it isn't re-enabled
a disconnected command may time-out or the target may wedge the bus while
trying to reselect the host. This can happen after a command is aborted.
Fix this by enabling the reselection interrupt in NCR5380_main() after
calls to NCR5380_select() and NCR5380_information_transfer() return.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org # v4.9+
Fixes: 8b00c3d5d40d ("ncr5380: Implement new eh_abort_handler")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index fe0535affc14..08e3ea8159b3 100644
--- a/drivers/scsi/NCR5380.c
+++ b/drivers/scsi/NCR5380.c
@@ -709,6 +709,8 @@ static void NCR5380_main(struct work_struct *work)
NCR5380_information_transfer(instance);
done = 0;
}
+ if (!hostdata->connected)
+ NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
spin_unlock_irq(>lock);
if (!done)
cond_resched();
@@ -1110,8 +1112,6 @@ static bool NCR5380_select(struct Scsi_Host *instance,
struct scsi_cmnd *cmd)
spin_lock_irq(>lock);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
NCR5380_reselect(instance);
- if (!hostdata->connected)
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
shost_printk(KERN_ERR, instance, "reselection after won
arbitration?\n");
goto out;
}
@@ -1119,7 +1119,6 @@ static bool NCR5380_select(struct Scsi_Host *instance,
struct scsi_cmnd *cmd)
if (err < 0) {
spin_lock_irq(>lock);
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
/* Can't touch cmd if it has been reclaimed by the scsi ML */
if (!hostdata->selecting)
@@ -1157,7 +1156,6 @@ static bool NCR5380_select(struct Scsi_Host *instance,
struct scsi_cmnd *cmd)
if (err < 0) {
shost_printk(KERN_ERR, instance, "select: REQ timeout\n");
NCR5380_write(INITIATOR_COMMAND_REG, ICR_BASE);
- NCR5380_write(SELECT_ENABLE_REG, hostdata->id_mask);
goto out;
}
if (!hostdata->selecting) {
@@ -1826,9 +1824,6 @@ static void NCR5380_information_transfer(struct Scsi_Host
*instance)
*/
NCR5380_write(TARGET_COMMAND_REG, 0);
- /* Enable reselect interrupts */
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
-
maybe_release_dma_irq(instance);
return;
case MESSAGE_REJECT:
@@ -1860,8 +1855,6 @@ static void NCR5380_information_transfer(struct Scsi_Host
*instance)
*/
NCR5380_write(TARGET_COMMAND_REG, 0);
- /* Enable reselect interrupts */
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
#ifdef SUN3_SCSI_VME
dregs->csr |= CSR_DMA_ENABLE;
#endif
@@ -1964,7 +1957,6 @@ static void NCR5380_information_transfer(struct Scsi_Host
*instance)
cmd->result = DID_ERROR << 16;
complete_cmd(instance, cmd);
maybe_release_dma_irq(instance);
- NCR5380_write(SELECT_ENABLE_REG,
hostdata->id_mask);
return;
}
msgout = NOP;
--
2.21.0
Re: fix controller busy issue and add 24bits segment support
Hi Ulf, Gentle ping for this patch. On Sun, 2019-05-19 at 15:57 +0800, Chaotian Jing wrote: > the below 2 patches fix controller busy issue when plug out SD card > and add 24bits segment size support. > > Chaotian Jing (2): > mmc: mediatek: fix controller busy when plug out SD > mmc: mediatek: support 24bits segment size > > drivers/mmc/host/mtk-sd.c | 24 ++-- > 1 file changed, 18 insertions(+), 6 deletions(-) >
[PATCH HACK RFC] cpu: Prevent late-arriving interrupts from disrupting offline
Scheduling-clock interrupts can arrive late in the CPU-offline process, after idle entry and the subsequent call to cpuhp_report_idle_dead(). Once execution passes the call to rcu_report_dead(), RCU is ignoring the CPU, which results in lockdep complaints when the interrupt handler uses RCU: = WARNING: suspicious RCU usage 5.2.0-rc1+ #681 Not tainted - kernel/sched/fair.c:9542 suspicious rcu_dereference_check() usage! other info that might help us debug this: RCU used illegally from offline CPU! rcu_scheduler_active = 2, debug_locks = 1 no locks held by swapper/5/0. stack backtrace: CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.2.0-rc1+ #681 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x5e/0x8b trigger_load_balance+0xa8/0x390 ? tick_sched_do_timer+0x60/0x60 update_process_times+0x3b/0x50 tick_sched_handle+0x2f/0x40 tick_sched_timer+0x32/0x70 __hrtimer_run_queues+0xd3/0x3b0 hrtimer_interrupt+0x11d/0x270 ? sched_clock_local+0xc/0x74 smp_apic_timer_interrupt+0x79/0x200 apic_timer_interrupt+0xf/0x20 RIP: 0010:delay_tsc+0x22/0x50 Code: ff 0f 1f 80 00 00 00 00 65 44 8b 05 18 a7 11 48 0f ae e8 0f 31 48 89 d6 48 c1 e6 20 48 09 c6 eb 0e f3 90 65 8b 05 fe a6 11 48 <41> 39 c0 75 18 0f ae e8 0f 31 48 c1 e2 20 48 09 c2 48 89 d0 48 29 RSP: :8f92c0157ed0 EFLAGS: 0212 ORIG_RAX: ff13 RAX: 0005 RBX: 8c861f356400 RCX: 8f92c0157e64 RDX: 00321214c8cc RSI: 0032120daa7f RDI: 00260f15 RBP: 0005 R08: 0005 R09: R10: 0001 R11: 0001 R12: R13: R14: 8c861ee18000 R15: 8c861ee18000 cpuhp_report_idle_dead+0x31/0x60 do_idle+0x1d5/0x200 ? _raw_spin_unlock_irqrestore+0x2d/0x40 cpu_startup_entry+0x14/0x20 start_secondary+0x151/0x170 secondary_startup_64+0xa4/0xb0 This happens rarely, but can be forced by happen more often by placing delays in cpuhp_report_idle_dead() following the call to rcu_report_dead(). With this in place, the folloiwng rcutorture scenario reproduces the problem within a few minute: tools/testing/selftests/rcutorture/bin/kvm.sh --cpus 8 --duration 5 --kconfig "CONFIG_DEBUG_LOCK_ALLOC=y CONFIG_PROVE_LOCKING=y" --configs "TREE04" This commit uses the crude by effective expedient of disabling interrupts via local_irq_disable() just prior to the call to rcu_report_dead(). This passes light testing. Of course, preventing the scheduling-clock interrupt might be preferable. However, this commit does have the advantage of allowing progress to be made on other RCU bugs. Signed-off-by: Paul E. McKenney diff --git a/kernel/cpu.c b/kernel/cpu.c index 448efc06bb2d..3b33d83b793d 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -930,6 +930,7 @@ void cpuhp_report_idle_dead(void) struct cpuhp_cpu_state *st = this_cpu_ptr(_state); BUG_ON(st->state != CPUHP_AP_OFFLINE); + local_irq_disable(); rcu_report_dead(smp_processor_id()); st->state = CPUHP_AP_IDLE_DEAD; udelay(1000);
[PATCH v1 3/4] Bluetooth: btmtkuart: add an implementation for boot-gpios property
From: Sean Wang
Not every platform has the pinctrl device integrates the GPIO the function
such as MT7621 whose pinctrl and GPIO are separate hardware so the driver
adds additional boot-gpios to let the MT766[3,8]U can enter the proper boot
mode by gpiod for such platform.
Signed-off-by: Sean Wang
---
drivers/bluetooth/btmtkuart.c | 34 +-
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index f5dbeec8e274..1257149cfdc4 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -119,6 +119,7 @@ struct btmtkuart_dev {
struct regulator *vcc;
struct gpio_desc *reset;
+ struct gpio_desc *boot;
struct pinctrl *pinctrl;
struct pinctrl_state *pins_runtime;
struct pinctrl_state *pins_boot;
@@ -911,6 +912,13 @@ static int btmtkuart_parse_dt(struct serdev_device *serdev)
return err;
}
+ bdev->boot = devm_gpiod_get_optional(>dev, "boot",
+GPIOD_OUT_LOW);
+ if (IS_ERR(bdev->boot)) {
+ err = PTR_ERR(bdev->boot);
+ return err;
+ }
+
bdev->pinctrl = devm_pinctrl_get(>dev);
if (IS_ERR(bdev->pinctrl)) {
err = PTR_ERR(bdev->pinctrl);
@@ -919,8 +927,10 @@ static int btmtkuart_parse_dt(struct serdev_device *serdev)
bdev->pins_boot = pinctrl_lookup_state(bdev->pinctrl,
"default");
- if (IS_ERR(bdev->pins_boot)) {
+ if (IS_ERR(bdev->pins_boot) && !bdev->boot) {
err = PTR_ERR(bdev->pins_boot);
+ dev_err(>dev,
+ "Should assign RXD to LOW at boot stage\n");
return err;
}
@@ -996,8 +1006,14 @@ static int btmtkuart_probe(struct serdev_device *serdev)
set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
if (btmtkuart_is_standalone(bdev)) {
- /* Switch to the specific pin state for the booting requires */
- pinctrl_select_state(bdev->pinctrl, bdev->pins_boot);
+ if (bdev->boot) {
+ gpiod_set_value_cansleep(bdev->boot, 1);
+ } else {
+ /* Switch to the specific pin state for the booting
+* requires.
+*/
+ pinctrl_select_state(bdev->pinctrl, bdev->pins_boot);
+ }
/* Power on */
err = regulator_enable(bdev->vcc);
@@ -1017,6 +1033,10 @@ static int btmtkuart_probe(struct serdev_device *serdev)
* mode the device requires for UART transfers.
*/
msleep(50);
+
+ if (bdev->boot)
+ devm_gpiod_put(>dev, bdev->boot);
+
pinctrl_select_state(bdev->pinctrl, bdev->pins_runtime);
/* A standalone device doesn't depends on power domain on SoC,
@@ -1037,10 +1057,8 @@ static int btmtkuart_probe(struct serdev_device *serdev)
return 0;
err_regulator_disable:
- if (btmtkuart_is_standalone(bdev)) {
- pinctrl_select_state(bdev->pinctrl, bdev->pins_boot);
+ if (btmtkuart_is_standalone(bdev))
regulator_disable(bdev->vcc);
- }
return err;
}
@@ -1050,10 +1068,8 @@ static void btmtkuart_remove(struct serdev_device
*serdev)
struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
struct hci_dev *hdev = bdev->hdev;
- if (btmtkuart_is_standalone(bdev)) {
- pinctrl_select_state(bdev->pinctrl, bdev->pins_boot);
+ if (btmtkuart_is_standalone(bdev))
regulator_disable(bdev->vcc);
- }
hci_unregister_dev(hdev);
hci_free_dev(hdev);
--
2.17.1
[PATCH v1 1/4] dt-bindings: net: bluetooth: add boot-gpios property to UART-based device
From: Sean Wang Not every platform has the pinctrl device integrates the GPIO the function such as MT7621 whose pinctrl and GPIO are separate hardware so adding an additional boot-gpios property for such platform allows them to bring up the device. Signed-off-by: Sean Wang --- .../devicetree/bindings/net/mediatek-bluetooth.txt | 13 + 1 file changed, 13 insertions(+) diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt index 41a7dcc80f5b..14f23b354a6d 100644 --- a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt @@ -50,11 +50,24 @@ Required properties: "mediatek,mt7663u-bluetooth": for MT7663U device "mediatek,mt7668u-bluetooth": for MT7668U device - vcc-supply: Main voltage regulator + +If the pin controller on the platform can support both pinmux and GPIO +control such as the most of MediaTek platform. Please use below properties. + - pinctrl-names: Should be "default", "runtime" - pinctrl-0: Should contain UART RXD low when the device is powered up to enter proper bootstrap mode. - pinctrl-1: Should contain UART mode pin ctrl +Else, the pin controller on the platform only can support pinmux control and +the GPIO control still has to rely on the dedicated GPIO controller such as +a legacy MediaTek SoC, MT7621. Please use the below properties. + +- boot-gpios: GPIO same to the pin as UART RXD and used to keep LOW when + the device is powered up to enter proper bootstrap mode when +- pinctrl-names: Should be "default" +- pinctrl-0: Should contain UART mode pin ctrl + Optional properties: - reset-gpios: GPIO used to reset the device whose initial state keeps low, -- 2.17.1
[PATCH v1 2/4] dt-bindings: net: bluetooth: add clock property to UART-based device
From: Sean Wang Some board requires explicitily control external osscilator via GPIO. So, add a clock property for an external oscillator for the device. Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/net/mediatek-bluetooth.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt index 14f23b354a6d..112011c51d5e 100644 --- a/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt +++ b/Documentation/devicetree/bindings/net/mediatek-bluetooth.txt @@ -73,6 +73,10 @@ Optional properties: - reset-gpios: GPIO used to reset the device whose initial state keeps low, if the GPIO is missing, then board-level design should be guaranteed. +- clocks: Should be the clock specifiers corresponding to the entry in + clock-names property. If the clock is missing, then board-level + design should be guaranteed. +- clock-names: Should contain "osc" entry for the external oscillator. - current-speed: Current baud rate of the device whose defaults to 921600 Example: -- 2.17.1
[PATCH v1 4/4] Bluetooth: btmtkuart: add an implementation for clock osc property
From: Sean Wang
Some board requires explicitily control external osscilator via GPIO.
So, add an implementation of a clock property for an external oscillator
to the device.
Signed-off-by: Sean Wang
---
drivers/bluetooth/btmtkuart.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btmtkuart.c b/drivers/bluetooth/btmtkuart.c
index 1257149cfdc4..e11169ad8247 100644
--- a/drivers/bluetooth/btmtkuart.c
+++ b/drivers/bluetooth/btmtkuart.c
@@ -115,8 +115,9 @@ struct btmtk_hci_wmt_params {
struct btmtkuart_dev {
struct hci_dev *hdev;
struct serdev_device *serdev;
- struct clk *clk;
+ struct clk *clk;
+ struct clk *osc;
struct regulator *vcc;
struct gpio_desc *reset;
struct gpio_desc *boot;
@@ -912,6 +913,12 @@ static int btmtkuart_parse_dt(struct serdev_device *serdev)
return err;
}
+ bdev->osc = devm_clk_get_optional(>dev, "osc");
+ if (IS_ERR(bdev->osc)) {
+ err = PTR_ERR(bdev->osc);
+ return err;
+ }
+
bdev->boot = devm_gpiod_get_optional(>dev, "boot",
GPIOD_OUT_LOW);
if (IS_ERR(bdev->boot)) {
@@ -1006,6 +1013,10 @@ static int btmtkuart_probe(struct serdev_device *serdev)
set_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks);
if (btmtkuart_is_standalone(bdev)) {
+ err = clk_prepare_enable(bdev->osc);
+ if (err < 0)
+ return err;
+
if (bdev->boot) {
gpiod_set_value_cansleep(bdev->boot, 1);
} else {
@@ -1017,8 +1028,10 @@ static int btmtkuart_probe(struct serdev_device *serdev)
/* Power on */
err = regulator_enable(bdev->vcc);
- if (err < 0)
+ if (err < 0) {
+ clk_disable_unprepare(bdev->osc);
return err;
+ }
/* Reset if the reset-gpios is available otherwise the board
* -level design should be guaranteed.
@@ -1068,8 +1081,10 @@ static void btmtkuart_remove(struct serdev_device
*serdev)
struct btmtkuart_dev *bdev = serdev_device_get_drvdata(serdev);
struct hci_dev *hdev = bdev->hdev;
- if (btmtkuart_is_standalone(bdev))
+ if (btmtkuart_is_standalone(bdev)) {
regulator_disable(bdev->vcc);
+ clk_disable_unprepare(bdev->osc);
+ }
hci_unregister_dev(hdev);
hci_free_dev(hdev);
--
2.17.1
[PATCH v1 0/4] add boot-gpios and clock property to btmtkuart
From: Sean Wang Update dt-binding and the corresponding implmentation of boot-gpios and clock property to btmtkuart. Sean Wang (4): dt-bindings: net: bluetooth: add boot-gpios property to UART-based device dt-bindings: net: bluetooth: add clock property to UART-based device Bluetooth: btmtkuart: add an implementation for boot-gpios property Bluetooth: btmtkuart: add an implementation for clock osc property .../bindings/net/mediatek-bluetooth.txt | 17 +++ drivers/bluetooth/btmtkuart.c | 51 +++ 2 files changed, 58 insertions(+), 10 deletions(-) -- 2.17.1
Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression
On Tue, 28 May 2019, Lars Ellenberg wrote: > On Fri, May 10, 2019 at 05:36:32PM +, Eric Wheeler wrote: > > Hi Lars, > > > > We just tried 4.19.x and this bugs still exists. We applied the patch > > which was originally submitted to this thread and it still applies cleanly > > and seems to work for our use case. You mentioned that you had some older > > code which zeroed out unaligned discard requests (or perhaps it was for a > > different purpose) that you may be able to use to patch this. Could you > > dig those up and see if we can get this solved? > > > > It would be nice to be able to use drbd with thin backing volumes from the > > vanilla kernel. If this has already been fixed in something newer than > > 4.19, then please point me to the commit. > > I think it was merged upstream in 5.0 > f31e583aa2c2 drbd: introduce P_ZEROES (REQ_OP_WRITE_ZEROES on the "wire") Thanks Lars, I appreciate your patch. Your unaligned zerout code in drbd_issue_discard_or_zero_out() looks great. I particulary like how you adjusted max_discard_sectors to the granularity, as well as alignment handling. Well thought out. Your commit notes that "for backward compatibility, P_TRIM means zero-out, unless the DRBD_FF_WZEROES feature flag is agreed upon during handshake." We test our environment by deploying the newer kernel on one of the DRBD servers and checking for regressions---but this will cause a zero-out on the new server because the old server doesn't yet support DRBD_FF_WZEROES. For our purpose, can you think of any reason that it would be unsafe to hack the following into drbd_do_features() so the newer version will not zero-out while we test and get both nodes up to the newer version? diff --git a/drivers/block/drbd/drbd_receiver.c b/drivers/block/drbd/drbd_receiver.c index c7ad88d..76191e6 100644 --- a/drivers/block/drbd/drbd_receiver.c +++ b/drivers/block/drbd/drbd_receiver.c @@ -5382,6 +5382,8 @@ static int drbd_do_features(struct drbd_connection *connection) connection->agreed_pro_version = min_t(int, PRO_VERSION_MAX, p->protocol_max); connection->agreed_features = PRO_FEATURES & be32_to_cpu(p->feature_flags); + connection->agreed_features |= DRBD_FF_WZEROES; + drbd_info(connection, "Handshake successful: " "Agreed network protocol version %d\n", connection->agreed_pro_version); -- Eric Wheeler > > -- > : Lars Ellenberg > : LINBIT | Keeping the Digital World Running > : DRBD -- Heartbeat -- Corosync -- Pacemaker > : R, Integration, Ops, Consulting, Support > > DRBD® and LINBIT® are registered trademarks of LINBIT >
Re: [PATCH] ext4: remove unnecessary gotos in ext4_xattr_set_entry
On Fri, May 31, 2019 at 03:46:54PM -0600, Andreas Dilger wrote: > On May 31, 2019, at 6:10 AM, Pavel Tikhomirov > wrote: > > > > In the "out" label we only iput old/new_ea_inode-s, in all these places > > these variables are always NULL so there is no point in goto to "out". > > > > Signed-off-by: Pavel Tikhomirov > > I'm not a fan of changes like this, since it adds potential complexity/bugs > if the error handling path is changed in the future. That is one of the major > benefits of the "goto out_*" model of error handling is that you only need to > add one new label to the end of the function when some new state is added that > needs to be cleaned up, compared to having to check each individual error to > see if something needs to be cleaned up. I'm not a fan either, for the reasons Andreas stated; if you ever move code around, it's much more hazardous because you now have to check if what had previously been a "return ret" now has to change into "goto outl". In some case, it's really obvious, if the code is at the very beginning of the function, but when you're 35 lines down, well over the size of many of an editor window, it's no longer quite so obvious whether or not "goto out" is necessary. - Ted
[PATCH v7 0/2] Bluetooth: btusb: Add protocol support for MediaTek USB devices
From: Sean Wang v7: * rebase to latest code base. v6: * fix drivers/bluetooth/btusb.c:2683:2-3: Unneeded semicolon based reported by [1] * update power-on sequence with adding neccesary tci sleep comand to set up low-power environmnet and a delay to wait the device to be stable. * sort variables declarations in reverse xmas order. [1] http://lists.infradead.org/pipermail/linux-mediatek/2019-January/017017.html v5: * rebase to latest code base. * change the subject prefix. * change the place the firmware located at. v4: * use new BTUSB_TX_WAIT_VND_EVT instead of BTMTKUSB_TX_WAIT_VND_EVT to avoid definition conflict and to fix bulk data transfer fails. * use the bluetooth-next as the base v3: add fixes and enhancements based on [1] * reuse flags and evt_skb btusb already had * add ctrl_anchor and the corresponding handling * apply mtk specific recv function * add more comments explaining wmt ctrl urbs behavior. [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014724.html v2: add fixes and enhancements based on [1] * include /sys/kernel/debug/usb/devices portion in the commit message. * turn default into n for config BT_HCIBTUSB_MTK in Kconfig * only add MediaTek support to btusb.c * drop cmd_sync callback usage * use __hci_cmd_send to send WMT commands * add wait event handling similar to what is being done in btmtkuart.c * submit a control IN URB similar to interrupt IN URB on demand for the WMT commands during setup * add cosmetic changes [1] http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014650.html http://lists.infradead.org/pipermail/linux-mediatek/2018-August/014656.html v1: This adds the support of enabling MT7668U and MT7663U Bluetooth function running on the top of btusb driver. The patch also adds a newly created file mtkbt.c able to be reused independently from the transport type such as UART, USB and SDIO. Sean Wang (2): Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices Bluetooth: btusb: Add protocol support for MediaTek MT7663U USB devices drivers/bluetooth/Kconfig | 11 + drivers/bluetooth/btusb.c | 581 ++ 2 files changed, 592 insertions(+) -- 2.17.1
[PATCH v7 1/2] Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices
From: Sean Wang
This adds the support of enabling MT7668U Bluetooth function running
on the top of btusb driver.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=0e8d ProdID=7668 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=0
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
Signed-off-by: Sean Wang
---
drivers/bluetooth/Kconfig | 11 +
drivers/bluetooth/btusb.c | 576 ++
2 files changed, 587 insertions(+)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index b9c34ff9a0d3..57d710e619a6 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -52,6 +52,17 @@ config BT_HCIBTUSB_BCM
Say Y here to compile support for Broadcom protocol.
+config BT_HCIBTUSB_MTK
+ bool "MediaTek protocol support"
+ depends on BT_HCIBTUSB
+ default n
+ help
+ The MediaTek protocol support enables firmware download
+ support and chip initialization for MediaTek Bluetooth
+ USB controllers.
+
+ Say Y here to compile support for MediaTek protocol.
+
config BT_HCIBTUSB_RTL
bool "Realtek protocol support"
depends on BT_HCIBTUSB
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7db48ae65cd2..91b4ac7cb203 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -70,6 +71,7 @@ static struct usb_driver btusb_driver;
#define BTUSB_BCM2045 0x4
#define BTUSB_IFNUM_2 0x8
#define BTUSB_CW6622 0x10
+#define BTUSB_MEDIATEK 0x20
static const struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
@@ -361,6 +363,10 @@ static const struct usb_device_id blacklist_table[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(0x0bda, 0xe0, 0x01, 0x01),
.driver_info = BTUSB_REALTEK },
+ /* MediaTek Bluetooth devices */
+ { USB_VENDOR_AND_INTERFACE_INFO(0x0e8d, 0xe0, 0x01, 0x01),
+ .driver_info = BTUSB_MEDIATEK },
+
/* Additional Realtek 8723AE Bluetooth devices */
{ USB_DEVICE(0x0930, 0x021d), .driver_info = BTUSB_REALTEK },
{ USB_DEVICE(0x13d3, 0x3394), .driver_info = BTUSB_REALTEK },
@@ -441,6 +447,7 @@ static const struct dmi_system_id
btusb_needs_reset_resume_table[] = {
#define BTUSB_DIAG_RUNNING 10
#define BTUSB_OOB_WAKE_ENABLED 11
#define BTUSB_HW_RESET_ACTIVE 12
+#define BTUSB_TX_WAIT_VND_EVT 13
struct btusb_data {
struct hci_dev *hdev;
@@ -464,6 +471,7 @@ struct btusb_data {
struct usb_anchor bulk_anchor;
struct usb_anchor isoc_anchor;
struct usb_anchor diag_anchor;
+ struct usb_anchor ctrl_anchor;
spinlock_t rxlock;
struct sk_buff *evt_skb;
@@ -1217,6 +1225,7 @@ static void btusb_stop_traffic(struct btusb_data *data)
usb_kill_anchored_urbs(>bulk_anchor);
usb_kill_anchored_urbs(>isoc_anchor);
usb_kill_anchored_urbs(>diag_anchor);
+ usb_kill_anchored_urbs(>ctrl_anchor);
}
static int btusb_close(struct hci_dev *hdev)
@@ -2452,6 +2461,563 @@ static int btusb_shutdown_intel_new(struct hci_dev
*hdev)
return 0;
}
+#ifdef CONFIG_BT_HCIBTUSB_MTK
+
+#define FIRMWARE_MT7668"mediatek/mt7668pr2h.bin"
+
+#define HCI_WMT_MAX_EVENT_SIZE 64
+
[PATCH v7 2/2] Bluetooth: btusb: Add protocol support for MediaTek MT7663U USB devices
From: Sean Wang
This adds the support of enabling MT7663U Bluetooth function running
on the top of btusb driver.
The information in /sys/kernel/debug/usb/devices about the Bluetooth
device is listed as the below.
T: Bus=04 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 5 Spd=5000 MxCh= 0
D: Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=0e8d ProdID=7663 Rev= 1.00
S: Manufacturer=MediaTek Inc.
S: Product=Wireless_Device
S: SerialNumber=0
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=160mA
A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=125us
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms
I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms
I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms
I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms
I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms
I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms
I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms
E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms
Signed-off-by: Sean Wang
---
drivers/bluetooth/btusb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 91b4ac7cb203..31cec3657916 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2463,6 +2463,7 @@ static int btusb_shutdown_intel_new(struct hci_dev *hdev)
#ifdef CONFIG_BT_HCIBTUSB_MTK
+#define FIRMWARE_MT7663"mediatek/mt7663pr2h.bin"
#define FIRMWARE_MT7668"mediatek/mt7668pr2h.bin"
#define HCI_WMT_MAX_EVENT_SIZE 64
@@ -2904,6 +2905,9 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
}
switch (dev_id) {
+ case 0x7663:
+ fwname = FIRMWARE_MT7663;
+ break;
case 0x7668:
fwname = FIRMWARE_MT7668;
break;
@@ -3015,6 +3019,7 @@ static int btusb_mtk_shutdown(struct hci_dev *hdev)
return 0;
}
+MODULE_FIRMWARE(FIRMWARE_MT7663);
MODULE_FIRMWARE(FIRMWARE_MT7668);
#endif
--
2.17.1
Re: ss: Checking efficient analysis for network connections
From: Markus Elfring Date: Sat, 1 Jun 2019 10:36:40 +0200 > I imagine then that it would be also nicer to perform filtering based on > configurable constraints at the data source directly. > How much can Linux help more in this software area? > How do you think about such ideas? If you use netlink operations directly, you can have the kernel filter on various criteria and only get the socket entries you are interested in. This whole discussion has zero to do with what text format 'ss' outputs.
Re: RFC: switch the remaining architectures to use generic GUP v2
From: Christoph Hellwig Date: Sat, 1 Jun 2019 09:49:43 +0200 > below is a series to switch mips, sh and sparc64 to use the generic > GUP code so that we only have one codebase to touch for further > improvements to this code. I don't have hardware for any of these > architectures, and generally no clue about their page table > management, so handle with care. > > Changes since v1: > - fix various issues found by the build bot > - cherry pick and use the untagged_addr helper form Andrey > - add various refactoring patches to share more code over architectures > - move the powerpc hugepd code to mm/gup.c and sync it with the generic >hup semantics I will today look seriously at the sparc64 stuff wrt. tagged pointers.
[GIT PULL] Thermal-SoC management fixes for v5.2-rc3
Please consider the following thermal soc changes for v5.2-rc3. This is really a single revert, detected to cause issues on the tsens driver. The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to ca657468a0d4bcc25445f6636485a19a525267bd: Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" (2019-05-28 19:30:33 -0700) Specifics: - Revert tsens change that is reported to cause issues. BR, Eduardo Valentin (1): Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" drivers/thermal/qcom/tsens-common.c | 14 -- drivers/thermal/qcom/tsens-v0_1.c | 1 - drivers/thermal/qcom/tsens-v2.c | 1 - drivers/thermal/qcom/tsens.c| 5 - drivers/thermal/qcom/tsens.h| 1 - 5 files changed, 22 deletions(-)
with due respect
Dear Friend, I know that this mail will come to you as a surprise as we have never met before, but need not to worry as I am contacting you independently of my investigation and no one is informed of this communication. I need your urgent assistance in transferring the sum of $11.3million immediately to your private account.The money has been here in our Bank lying dormant for years now without anybody coming for the claim of it. I want to release the money to you as the relative to our deceased customer (the account owner) who died a long with his supposed NEXT OF KIN since 16th October 2005. The Banking laws here does not allow such money to stay more than 14 years, because the money will be recalled to the Bank treasury account as unclaimed fund. By indicating your interest I will send you the full details on how the business will be executed. Please respond urgently and delete if you are not interested. Best Regards, Mr. Duna Wattara.
RE: [PATCH] PCI: hv: Fix build error without CONFIG_SYSFS
From: YueHaibing Sent: Friday, May 31, 2019 8:09 AM > > while building without CONFIG_SYSFS, fails as below: > > drivers/pci/controller/pci-hyperv.o: In function 'hv_pci_assign_slots': > pci-hyperv.c:(.text+0x40a): undefined reference to 'pci_create_slot' > drivers/pci/controller/pci-hyperv.o: In function 'pci_devices_present_work': > pci-hyperv.c:(.text+0xc02): undefined reference to 'pci_destroy_slot' > drivers/pci/controller/pci-hyperv.o: In function 'hv_pci_remove': > pci-hyperv.c:(.text+0xe50): undefined reference to 'pci_destroy_slot' > drivers/pci/controller/pci-hyperv.o: In function 'hv_eject_device_work': > pci-hyperv.c:(.text+0x11f9): undefined reference to 'pci_destroy_slot' > > Select SYSFS while PCI_HYPERV is set to fix this. > I'm wondering if is the right way to fix the problem. Conceptually is it possible to setup & operate virtual PCI devices like pci-hyperv.c does, even if sysfs is not present? Or is it right to always required sysfs? The function pci_dev_assign_slot() in slot.c has a null implementation in include/linux/pci.h when CONFIG_SYSFS is not defined, which seems to be trying to solve the same problem for that function. And if CONFIG_HOTPLUG_PCI is defined but CONFIG_SYSFS is not, pci_hp_create_module_link() and pci_hp_remove_module_link() look like they would have the same problem. Maybe there should be degenerate implementations of pci_create_slot() and pci_destroy_slot() for cases when CONFIG_SYSFS is not defined? But I'll admit I don't know the full story behind how PCI slots are represented and used, so maybe I'm off base. I just noticed the inconsistency in how other functions in slot.c are handled. Thoughts? Michael
Re: [RFC PATCH 4/5] media: ov6650: Fix frame scaling not reset on crop
Hi Janusz, On Fri, May 31, 2019 at 07:56:33PM +0200, Janusz Krzysztofik wrote: > Hi Sakari, > > On Friday, May 31, 2019 1:42:58 PM CEST Sakari Ailus wrote: > > Hi Janusz, > > > > On Sun, May 26, 2019 at 10:47:57PM +0200, Janusz Krzysztofik wrote: > > > According to V4L2 subdevice interface specification, frame scaling > > > factors should be reset to default values on modification of input frame > > > format. Assuming that requirement also applies in case of crop > > > rectangle modification unless V4L2_SEL_FLAG_KEEP_CONFIG is requested, > > > the driver now does not respect it. > > > > > > The KEEP_CONFIG case is already implemented, fix the other path. > > > > > > Signed-off-by: Janusz Krzysztofik > > > --- > > > drivers/media/i2c/ov6650.c | 8 > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/drivers/media/i2c/ov6650.c b/drivers/media/i2c/ov6650.c > > > index 47590cd51190..cc70d8952999 100644 > > > --- a/drivers/media/i2c/ov6650.c > > > +++ b/drivers/media/i2c/ov6650.c > > > @@ -472,6 +472,8 @@ static int ov6650_get_selection(struct v4l2_subdev > *sd, > > > } > > > } > > > > > > +static int ov6650_s_fmt(struct v4l2_subdev *sd, u32 code, bool > half_scale); > > > + > > > > Would it be possible to rearrange the functions in the file so you wouldn't > > need extra prototypes? Preferrably that'd be a new patch. > > Sure. I've intentionally done it like that for better readability of the > patches, but I have a task in my queue for rearrangement of functions order > as > soon as other modifications are in place. I'm totally fine with doing that after this set on as well. Up to you. > > > > static int ov6650_set_selection(struct v4l2_subdev *sd, > > > struct v4l2_subdev_pad_config *cfg, > > > struct v4l2_subdev_selection *sel) > > > @@ -515,7 +517,13 @@ static int ov6650_set_selection(struct v4l2_subdev > *sd, > > > } > > > if (!ret) > > > priv->rect.height = sel->r.height; > > > + else > > > + return ret; > > > > if (ret) > > return ret; > > OK > > Perhaps you will have more comments on other patches so I'll wait a bit and > then resubmit the series as v2. Not so much on this set BUT I realised that the subtle effect of "media: ov6650: Register with asynchronous subdevice framework" is that the driver is now responsible for serialising the access to its own data structures now. And it doesn't do that. Could you submit a fix, please? It'd be good to get that to 5.2 through the fixes branch. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com
Re: [RFC PATCH 5/5] media: ov6650: Add .init_cfg() pad operation callback
Hi Janusz,
On Sun, May 26, 2019 at 10:47:58PM +0200, Janusz Krzysztofik wrote:
> The driver now supports V4L2_SUBDEV_FORMAT_TRY operation mode only in
> .get/set_fmt() pad operation callbacks. That means only .try_format
> member of pad config is maintained. As a consequence, active crop
> rectangle is used as a referece while V4L2_SUBDEV_FORMAT_TRY requests
> are processed. In order to fix that, a method for initialization of
> .try_crop pad config member is needed.
>
> Implement .init_cfg() pad operation callback which initializes the pad
> config from current active format and selection settings. From now on,
The values set by init_cfg should be the defaults and not reflect the
current configuration. Apart from that the patch seems fine.
> and before the driver V4L2_SUBDEV_FORMAT_TRY support is further
> modified, host interface drivers should call .init_cfg() on a pad
> config before passing it to V4L2_SUBDEV_FORMAT_TRY operations.
>
> Signed-off-by: Janusz Krzysztofik
> ---
> drivers/media/i2c/ov6650.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/media/i2c/ov6650.c b/drivers/media/i2c/ov6650.c
> index cc70d8952999..c3d4c1f598b2 100644
> --- a/drivers/media/i2c/ov6650.c
> +++ b/drivers/media/i2c/ov6650.c
> @@ -447,6 +447,26 @@ static int ov6650_s_power(struct v4l2_subdev *sd, int on)
> return ret;
> }
>
> +static int ov6650_init_cfg(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct ov6650 *priv = to_ov6650(client);
> + struct v4l2_mbus_framefmt *mf;
> + struct v4l2_rect *rect;
> +
> + mf = >try_fmt;
> + *mf = ov6650_def_fmt;
> + mf->width = priv->rect.width >> priv->half_scale;
> + mf->height = priv->rect.height >> priv->half_scale;
> + mf->code = priv->code;
> +
> + rect = >try_crop;
> + *rect = priv->rect;
> +
> + return 0;
> +}
> +
> static int ov6650_get_selection(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_selection *sel)
> @@ -959,6 +979,7 @@ static const struct v4l2_subdev_video_ops
> ov6650_video_ops = {
> };
>
> static const struct v4l2_subdev_pad_ops ov6650_pad_ops = {
> + .init_cfg = ov6650_init_cfg,
> .enum_mbus_code = ov6650_enum_mbus_code,
> .get_selection = ov6650_get_selection,
> .set_selection = ov6650_set_selection,
> --
> 2.21.0
>
--
Sakari Ailus
sakari.ai...@linux.intel.com
[RFC 4/6] workqueue: Convert for_each_wq to use built-in list check
list_for_each_entry_rcu now has support to check for RCU reader sections
as well as lock. Just use the support in it, instead of explictly
checking in the caller.
Signed-off-by: Joel Fernandes (Google)
---
kernel/workqueue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9657315405de..91ed7aca16e5 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -424,9 +424,8 @@ static void workqueue_sysfs_unregister(struct
workqueue_struct *wq);
* ignored.
*/
#define for_each_pwq(pwq, wq) \
- list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node) \
- if (({ assert_rcu_or_wq_mutex(wq); false; })) { } \
- else
+ list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node, \
+lock_is_held(&(wq->mutex).dep_map))
#ifdef CONFIG_DEBUG_OBJECTS_WORK
--
2.22.0.rc1.311.g5d7573a151-goog
[RFC 3/6] driver/core: Convert to use built-in RCU list checking
list_for_each_entry_rcu has built-in RCU and lock checking. Make use of
it in driver core.
Signed-off-by: Joel Fernandes (Google)
---
drivers/base/base.h | 1 +
drivers/base/core.c | 10 ++
drivers/base/power/runtime.c | 15 ++-
3 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index b405436ee28e..0d32544b6f91 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -165,6 +165,7 @@ static inline int devtmpfs_init(void) { return 0; }
/* Device links support */
extern int device_links_read_lock(void);
extern void device_links_read_unlock(int idx);
+extern int device_links_read_lock_held(void);
extern int device_links_check_suppliers(struct device *dev);
extern void device_links_driver_bound(struct device *dev);
extern void device_links_driver_cleanup(struct device *dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd7511e04e62..6c5ca9685647 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -68,6 +68,11 @@ void device_links_read_unlock(int idx)
{
srcu_read_unlock(_links_srcu, idx);
}
+
+int device_links_read_lock_held(void)
+{
+ return srcu_read_lock_held(_links_srcu);
+}
#else /* !CONFIG_SRCU */
static DECLARE_RWSEM(device_links_lock);
@@ -91,6 +96,11 @@ void device_links_read_unlock(int not_used)
{
up_read(_links_lock);
}
+
+int device_links_read_lock_held(void)
+{
+ return lock_is_held(_links_lock);
+}
#endif /* !CONFIG_SRCU */
/**
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 952a1e7057c7..7a10e8379a70 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -287,7 +287,8 @@ static int rpm_get_suppliers(struct device *dev)
{
struct device_link *link;
- list_for_each_entry_rcu(link, >links.suppliers, c_node) {
+ list_for_each_entry_rcu(link, >links.suppliers, c_node,
+ device_links_read_lock_held()) {
int retval;
if (!(link->flags & DL_FLAG_PM_RUNTIME) ||
@@ -309,7 +310,8 @@ static void rpm_put_suppliers(struct device *dev)
{
struct device_link *link;
- list_for_each_entry_rcu(link, >links.suppliers, c_node) {
+ list_for_each_entry_rcu(link, >links.suppliers, c_node,
+ device_links_read_lock_held()) {
if (READ_ONCE(link->status) == DL_STATE_SUPPLIER_UNBIND)
continue;
@@ -1640,7 +1642,8 @@ void pm_runtime_clean_up_links(struct device *dev)
idx = device_links_read_lock();
- list_for_each_entry_rcu(link, >links.consumers, s_node) {
+ list_for_each_entry_rcu(link, >links.consumers, s_node,
+ device_links_read_lock_held()) {
if (link->flags & DL_FLAG_STATELESS)
continue;
@@ -1662,7 +1665,8 @@ void pm_runtime_get_suppliers(struct device *dev)
idx = device_links_read_lock();
- list_for_each_entry_rcu(link, >links.suppliers, c_node)
+ list_for_each_entry_rcu(link, >links.suppliers, c_node,
+ device_links_read_lock_held())
if (link->flags & DL_FLAG_PM_RUNTIME) {
link->supplier_preactivated = true;
refcount_inc(>rpm_active);
@@ -1683,7 +1687,8 @@ void pm_runtime_put_suppliers(struct device *dev)
idx = device_links_read_lock();
- list_for_each_entry_rcu(link, >links.suppliers, c_node)
+ list_for_each_entry_rcu(link, >links.suppliers, c_node,
+ device_links_read_lock_held())
if (link->supplier_preactivated) {
link->supplier_preactivated = false;
if (refcount_dec_not_one(>rpm_active))
--
2.22.0.rc1.311.g5d7573a151-goog
[RFC 0/6] Harden list_for_each_entry_rcu() and family
Hi,
Please consider this as an RFC / proof-of-concept to gather some feedback. This
series aims to provide lockdep checking to RCU list macros.
RCU has a number of primitives for "consumption" of an RCU protected pointer.
Most of the time, these consumers make sure that such accesses are under a RCU
reader-section (such as rcu_dereference{,sched,bh} or under a lock, such as
with rcu_dereference_protected()).
However, there are other ways to consume RCU pointers, such as by
list_for_each_enry_rcu or hlist_for_each_enry_rcu. Unlike the rcu_dereference
family, these consumers do no lockdep checking at all. And with the growing
number of RCU list uses, it is possible for bugs to creep in and go unnoticed
which lockdep checks can catch.
Since RCU consolidation efforts last year, the different traditional RCU
flavors (preempt, bh, sched) are all consolidated. In other words, any of these
flavors can cause a reader section to occur and all of them must cease before
the reader section is considered to be unlocked.
Now, the list_for_each_entry_rcu and family are different from the
rcu_dereference family in that, there is no _bh or _sched version of this
macro. They are used under many different RCU reader flavors, and also SRCU.
This series adds a new internal function rcu_read_lock_any_held() which checks
if any reader section is active at all, when these macros are called. If no
reader section exists, then the optional fourth argument to
list_for_each_entry_rcu() can be a lockdep expression which is evaluated
(similar to how rcu_dereference_check() works).
The optional argument trick to list_for_each_entry_rcu() can also be used in
the future to possibly remove rcu_dereference_{,bh,sched}_protected() API and
we can pass an optional lockdep expression to rcu_dereference() itself. Thus
eliminating 3 more RCU APIs.
Note that some list macro wrappers already do their own lockdep checking in the
caller side. These can be eliminated in favor of the built-in lockdep checking
in the list macro that this series adds. For example, workqueue code has a
assert_rcu_or_wq_mutex() function which is called in for_each_wq(). This
series replaces that in favor of the built-in one.
Also in the future, we can extend these checks to list_entry_rcu() and other
list macros as well.
Joel Fernandes (Google) (6):
rcu: Add support for consolidated-RCU reader checking
ipv4: add lockdep condition to fix for_each_entry
driver/core: Convert to use built-in RCU list checking
workqueue: Convert for_each_wq to use built-in list check
x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator
acpi: Use built-in RCU list checking for acpi_ioremaps list
arch/x86/pci/mmconfig-shared.c | 5 +++--
drivers/acpi/osl.c | 6 +++--
drivers/base/base.h| 1 +
drivers/base/core.c| 10 +
drivers/base/power/runtime.c | 15 -
include/linux/rculist.h| 40 ++
include/linux/rcupdate.h | 7 ++
kernel/rcu/update.c| 26 ++
kernel/workqueue.c | 5 ++---
net/ipv4/fib_frontend.c| 3 ++-
10 files changed, 101 insertions(+), 17 deletions(-)
--
2.22.0.rc1.311.g5d7573a151-goog
[RFC 5/6] x86/pci: Pass lockdep condition to pcm_mmcfg_list iterator
The pcm_mmcfg_list is traversed with list_for_each_entry_rcu without a
reader-lock held, because the pci_mmcfg_lock is already held. Make this
known to the list macro so that it fixes new lockdep warnings that
trigger due to lockdep checks added to list_for_each_entry_rcu().
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/pci/mmconfig-shared.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 7389db538c30..6fa42e9c4e6f 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -29,6 +29,7 @@
static bool pci_mmcfg_running_state;
static bool pci_mmcfg_arch_init_failed;
static DEFINE_MUTEX(pci_mmcfg_lock);
+#define pci_mmcfg_lock_held() lock_is_held(&(pci_mmcfg_lock).dep_map)
LIST_HEAD(pci_mmcfg_list);
@@ -54,7 +55,7 @@ static void list_add_sorted(struct pci_mmcfg_region *new)
struct pci_mmcfg_region *cfg;
/* keep list sorted by segment and starting bus number */
- list_for_each_entry_rcu(cfg, _mmcfg_list, list) {
+ list_for_each_entry_rcu(cfg, _mmcfg_list, list,
pci_mmcfg_lock_held()) {
if (cfg->segment > new->segment ||
(cfg->segment == new->segment &&
cfg->start_bus >= new->start_bus)) {
@@ -118,7 +119,7 @@ struct pci_mmcfg_region *pci_mmconfig_lookup(int segment,
int bus)
{
struct pci_mmcfg_region *cfg;
- list_for_each_entry_rcu(cfg, _mmcfg_list, list)
+ list_for_each_entry_rcu(cfg, _mmcfg_list, list,
pci_mmcfg_lock_held())
if (cfg->segment == segment &&
cfg->start_bus <= bus && bus <= cfg->end_bus)
return cfg;
--
2.22.0.rc1.311.g5d7573a151-goog
[RFC 1/6] rcu: Add support for consolidated-RCU reader checking
This patch adds support for checking RCU reader sections in list
traversal macros. Optionally, if the list macro is called under SRCU or
other lock/mutex protection, then appropriate lockdep expressions can be
passed to make the checks pass.
Existing list_for_each_entry_rcu() invocations don't need to pass the
optional fourth argument (cond) unless they are under some non-RCU
protection and needs to make lockdep check pass.
Signed-off-by: Joel Fernandes (Google)
---
include/linux/rculist.h | 40
include/linux/rcupdate.h | 7 +++
kernel/rcu/update.c | 26 ++
3 files changed, 69 insertions(+), 4 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index e91ec9ddcd30..b641fdd9f1a2 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -40,6 +40,25 @@ static inline void INIT_LIST_HEAD_RCU(struct list_head *list)
*/
#define list_next_rcu(list)(*((struct list_head __rcu **)(&(list)->next)))
+/*
+ * Check during list traversal that we are within an RCU reader
+ */
+#define __list_check_rcu() \
+ RCU_LOCKDEP_WARN(!rcu_read_lock_any_held(), \
+"RCU-list traversed in non-reader section!")
+
+static inline void __list_check_rcu_cond(int dummy, ...)
+{
+ va_list ap;
+ int cond;
+
+ va_start(ap, dummy);
+ cond = va_arg(ap, int);
+ va_end(ap);
+
+ RCU_LOCKDEP_WARN(!cond && !rcu_read_lock_any_held(),
+"RCU-list traversed in non-reader section!");
+}
/*
* Insert a new entry between two known consecutive entries.
*
@@ -338,6 +357,9 @@ static inline void list_splice_tail_init_rcu(struct
list_head *list,
member) : NULL; \
})
+#define SIXTH_ARG(a1, a2, a3, a4, a5, a6, ...) a6
+#define COUNT_VARGS(...) SIXTH_ARG(dummy, ## __VA_ARGS__, 4, 3, 2, 1, 0)
+
/**
* list_for_each_entry_rcu - iterate over rcu list of given type
* @pos: the type * to use as a loop cursor.
@@ -348,9 +370,14 @@ static inline void list_splice_tail_init_rcu(struct
list_head *list,
* the _rcu list-mutation primitives such as list_add_rcu()
* as long as the traversal is guarded by rcu_read_lock().
*/
-#define list_for_each_entry_rcu(pos, head, member) \
- for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
- >member != (head); \
+#define list_for_each_entry_rcu(pos, head, member, cond...)\
+ if (COUNT_VARGS(cond) != 0) { \
+ __list_check_rcu_cond(0, ## cond); \
+ } else {\
+ __list_check_rcu(); \
+ } \
+ for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
+ >member != (head); \
pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
/**
@@ -621,7 +648,12 @@ static inline void hlist_add_behind_rcu(struct hlist_node
*n,
* the _rcu list-mutation primitives such as hlist_add_head_rcu()
* as long as the traversal is guarded by rcu_read_lock().
*/
-#define hlist_for_each_entry_rcu(pos, head, member)\
+#define hlist_for_each_entry_rcu(pos, head, member, cond...) \
+ if (COUNT_VARGS(cond) != 0) { \
+ __list_check_rcu_cond(0, ## cond); \
+ } else {\
+ __list_check_rcu(); \
+ } \
for (pos = hlist_entry_safe
(rcu_dereference_raw(hlist_first_rcu(head)),\
typeof(*(pos)), member);\
pos;\
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 922bb6848813..712b464ab960 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -223,6 +223,7 @@ int debug_lockdep_rcu_enabled(void);
int rcu_read_lock_held(void);
int rcu_read_lock_bh_held(void);
int rcu_read_lock_sched_held(void);
+int rcu_read_lock_any_held(void);
#else /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
@@ -243,6 +244,12 @@ static inline int rcu_read_lock_sched_held(void)
{
return !preemptible();
}
+
+static inline int rcu_read_lock_any_held(void)
+{
+ return !preemptible();
+}
+
#endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
#ifdef CONFIG_PROVE_RCU
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index c3bf44ba42e5..9cb30006a5e1 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -298,6 +298,32
[RFC 6/6] acpi: Use built-in RCU list checking for acpi_ioremaps list
list_for_each_entry_rcu has built-in RCU and lock checking. Make use of
it for acpi_ioremaps list traversal.
Signed-off-by: Joel Fernandes (Google)
---
drivers/acpi/osl.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index f29e427d0d1d..c8b5d712c7ae 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,6 +95,7 @@ struct acpi_ioremap {
static LIST_HEAD(acpi_ioremaps);
static DEFINE_MUTEX(acpi_ioremap_lock);
+#define acpi_ioremap_lock_held() lock_is_held(_ioremap_lock.dep_map)
static void __init acpi_request_region (struct acpi_generic_address *gas,
unsigned int length, char *desc)
@@ -220,7 +222,7 @@ acpi_map_lookup(acpi_physical_address phys, acpi_size size)
{
struct acpi_ioremap *map;
- list_for_each_entry_rcu(map, _ioremaps, list)
+ list_for_each_entry_rcu(map, _ioremaps, list,
acpi_ioremap_lock_held())
if (map->phys <= phys &&
phys + size <= map->phys + map->size)
return map;
@@ -263,7 +265,7 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size)
{
struct acpi_ioremap *map;
- list_for_each_entry_rcu(map, _ioremaps, list)
+ list_for_each_entry_rcu(map, _ioremaps, list,
acpi_ioremap_lock_held())
if (map->virt <= virt &&
virt + size <= map->virt + map->size)
return map;
--
2.22.0.rc1.311.g5d7573a151-goog
[RFC 2/6] ipv4: add lockdep condition to fix for_each_entry
Signed-off-by: Joel Fernandes (Google)
---
net/ipv4/fib_frontend.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index b298255f6fdb..ef7c9f8e8682 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -127,7 +127,8 @@ struct fib_table *fib_get_table(struct net *net, u32 id)
h = id & (FIB_TABLE_HASHSZ - 1);
head = >ipv4.fib_table_hash[h];
- hlist_for_each_entry_rcu(tb, head, tb_hlist) {
+ hlist_for_each_entry_rcu(tb, head, tb_hlist,
+lockdep_rtnl_is_held()) {
if (tb->tb_id == id)
return tb;
}
--
2.22.0.rc1.311.g5d7573a151-goog
Re: BUG: gpio: pca953x: 24 bit expanders broken since v5.2-rc1
On Fri, May 31, 2019 at 7:06 PM H. Nikolaus Schaller wrote: > Now, this was not a (visible) problem until patch > > 8b9f9d4dc511 regmap: verify if register is writeable before writing > operations > > enforces to check the register number before invoking the > callback pca953x_writeable_register(). pca953x_writeable_register() > seems to know about REG_ADDR_AI (through reg & REG_ADDR_MASK) and > accepts 0x88 as a valid register number. > > After the regmap patch the register is checked against > pca953x_i2c_regmap.max_register before applying REG_ADDR_MASK > and 0x88 is obviously beyond, explaining the symptom. Can we simply bump the .max_register in pca953x_i2c_regmap to 0xff for a quick fix with a comment FIXME to figure it out the right way? Yours, Linus Walleij
Re: [PATCH v3] dt-bindings: arm: Convert Atmel board/soc bindings to json-schema
On 17/05/2019 10:39:11-0500, Rob Herring wrote: > Convert Atmel SoC bindings to DT schema format using json-schema. > > Cc: Mark Rutland > Cc: Nicolas Ferre > Cc: Alexandre Belloni > Cc: devicet...@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Signed-off-by: Rob Herring Acked-by: Alexandre Belloni > --- > v3: > - correct maintainers > > .../devicetree/bindings/arm/atmel-at91.txt| 72 -- > .../devicetree/bindings/arm/atmel-at91.yaml | 133 ++ > 2 files changed, 133 insertions(+), 72 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.txt > create mode 100644 Documentation/devicetree/bindings/arm/atmel-at91.yaml > > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt > b/Documentation/devicetree/bindings/arm/atmel-at91.txt > deleted file mode 100644 > index 4bf1b4da7659.. > --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt > +++ /dev/null > @@ -1,72 +0,0 @@ > -Atmel AT91 device tree bindings. > - > - > -Boards with a SoC of the Atmel AT91 or SMART family shall have the following > -properties: > - > -Required root node properties: > -compatible: must be one of: > - * "atmel,at91rm9200" > - > - * "atmel,at91sam9" for SoCs using an ARM926EJ-S core, shall be extended with > - the specific SoC family or compatible: > -o "atmel,at91sam9260" > -o "atmel,at91sam9261" > -o "atmel,at91sam9263" > -o "atmel,at91sam9x5" for the 5 series, shall be extended with the > specific > - SoC compatible: > - - "atmel,at91sam9g15" > - - "atmel,at91sam9g25" > - - "atmel,at91sam9g35" > - - "atmel,at91sam9x25" > - - "atmel,at91sam9x35" > -o "atmel,at91sam9g20" > -o "atmel,at91sam9g45" > -o "atmel,at91sam9n12" > -o "atmel,at91sam9rl" > -o "atmel,at91sam9xe" > - * "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the > specific > - SoC family: > -o "atmel,sama5d2" shall be extended with the specific SoC compatible: > - - "atmel,sama5d27" > -o "atmel,sama5d3" shall be extended with the specific SoC compatible: > - - "atmel,sama5d31" > - - "atmel,sama5d33" > - - "atmel,sama5d34" > - - "atmel,sama5d35" > - - "atmel,sama5d36" > -o "atmel,sama5d4" shall be extended with the specific SoC compatible: > - - "atmel,sama5d41" > - - "atmel,sama5d42" > - - "atmel,sama5d43" > - - "atmel,sama5d44" > - > - * "atmel,samv7" for MCUs using a Cortex-M7, shall be extended with the > specific > - SoC family: > -o "atmel,sams70" shall be extended with the specific MCU compatible: > - - "atmel,sams70j19" > - - "atmel,sams70j20" > - - "atmel,sams70j21" > - - "atmel,sams70n19" > - - "atmel,sams70n20" > - - "atmel,sams70n21" > - - "atmel,sams70q19" > - - "atmel,sams70q20" > - - "atmel,sams70q21" > -o "atmel,samv70" shall be extended with the specific MCU compatible: > - - "atmel,samv70j19" > - - "atmel,samv70j20" > - - "atmel,samv70n19" > - - "atmel,samv70n20" > - - "atmel,samv70q19" > - - "atmel,samv70q20" > -o "atmel,samv71" shall be extended with the specific MCU compatible: > - - "atmel,samv71j19" > - - "atmel,samv71j20" > - - "atmel,samv71j21" > - - "atmel,samv71n19" > - - "atmel,samv71n20" > - - "atmel,samv71n21" > - - "atmel,samv71q19" > - - "atmel,samv71q20" > - - "atmel,samv71q21" > diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml > b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > new file mode 100644 > index ..7cc1d6c7af55 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml > @@ -0,0 +1,133 @@ > +# SPDX-License-Identifier: GPL-2.0 > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/arm/atmel-at91.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Atmel AT91 device tree bindings. > + > +maintainers: > + - Alexandre Belloni > + - Ludovic Desroches > + > +description: | > + Boards with a SoC of the Atmel AT91 or SMART family shall have the > following > + > +properties: > + $nodename: > +const: '/' > + compatible: > +oneOf: > + - items: > + - const: atmel,at91rm9200 > + - items: > + - enum: > + - olimex,sam9-l9260 > + - enum: > + - atmel,at91sam9260 > + - atmel,at91sam9261 > + - atmel,at91sam9263 > + - atmel,at91sam9g20 > + - atmel,at91sam9g45 > + - atmel,at91sam9n12 > + - atmel,at91sam9rl > + - atmel,at91sam9xe > + - const: atmel,at91sam9 > + > + - items: > + - enum: > + - atmel,at91sam9g15 > + - atmel,at91sam9g25 > + - atmel,at91sam9g35 > + -
[PATCH] counter: ftm-quaddec: needs HAS_IOMEM
the driver fails for UML with: drivers/counter/ftm-quaddec.c:301: undefined reference to `devm_ioremap' Fix it by depending on HAS_IOMEM --- drivers/counter/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/counter/Kconfig b/drivers/counter/Kconfig index 138ecd8a8fbd..6298344b536b 100644 --- a/drivers/counter/Kconfig +++ b/drivers/counter/Kconfig @@ -50,6 +50,7 @@ config STM32_LPTIMER_CNT module will be called stm32-lptimer-cnt. config FTM_QUADDEC + depends on HAS_IOMEM tristate "Flex Timer Module Quadrature decoder driver" help Select this option to enable the Flex Timer Quadrature decoder -- 2.21.0
Re: 5.1.0-next-20190520 -- emacs segfaults on 32-bit machine Re: 5.2-rc0.8: emacs segfaults?! x220, with 32-bit userland
On Mon 2019-05-27 15:08:48, Sebastian Andrzej Siewior wrote: > On 2019-05-27 15:03:17 [+0200], Pavel Machek wrote: > > > could you please send me (offlist) your .config? Also, what kind of > > > userland do you run? Something like Debian stable? > > > > Yep, debian stable. > > Since we had a little bit of development recently, could you please > check if > http://lkml.kernel.org/r/20190526173325.lpt5qtg7c6rnb...@linutronix.de > > makes any difference? X version of emacs keeps crashing, but I guess that's something unrelated. Looks like this one is solved. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH V7 4/4] rtc: imx-sc: add rtc alarm support
On 09/04/2019 05:00:07+, Anson Huang wrote: > Add i.MX system controller RTC alarm support, the RTC alarm > is implemented via SIP(silicon provider) runtime service call > and ARM-Trusted-Firmware will communicate with system controller > via MU(message unit) IPC to set RTC alarm. When RTC alarm fires, > system controller will generate a common MU irq event and notify > system controller RTC driver to handle the irq event. > > Signed-off-by: Anson Huang > Reviewed-by: Dong Aisheng > --- > Changes since V6: > - add comments to .read_alarm callback function to explain why it is an > empty function; > - improve irq notify callback function name. > -- > drivers/rtc/rtc-imx-sc.c | 87 > > 1 file changed, 87 insertions(+) > Applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
On Sat, Jun 01, 2019 at 05:29:26PM +, Ganapathi Bhat wrote:
> Hi Dan,
>
> > > if (is_multicast_ether_addr(ra)) {
> > > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > > + if (!skb_uap)
> > > + return -ENOMEM;
> >
> > I think we would want to free dev_kfree_skb_any(skb) before returning.
> I think if the pointer is NULL, no need to free it;
You're misreading skb vs skb_uap. "skb_uap" is NULL but "skb" is
non-NULL and I'm pretty sure we should free it.
regards,
dan carpenter
Re: [PATCH 1/1] rtc: rv3028: check return value
Hello,
On 29/05/2019 15:22:20+0800, Xidong Wang wrote:
> In rv3028_probe(), the return value of devm_regmap_init_i2c() should
> be checked before it is used.
>
> Signed-off-by: Xidong Wang
> ---
> drivers/rtc/rtc-rv3028.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/rtc/rtc-rv3028.c b/drivers/rtc/rtc-rv3028.c
> index 06884eb..29a8c4e 100644
> --- a/drivers/rtc/rtc-rv3028.c
> +++ b/drivers/rtc/rtc-rv3028.c
> @@ -626,6 +626,10 @@ static int rv3028_probe(struct i2c_client *client)
>
> rv3028->regmap = devm_regmap_init_i2c(client, _config);
>
Remove that empty line.
> + if (IS_ERR(rv3028->regmap)) {
> + return PTR_ERR(rv3028->regmap);
> + }
Unnecessary braces.
> +
> i2c_set_clientdata(client, rv3028);
>
> ret = regmap_read(rv3028->regmap, RV3028_STATUS, );
> --
> 2.7.4
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH 0/3] rtc: tegra: Dust off and deferred probe support
On 27/05/2019 12:13:56+0200, Thierry Reding wrote: > From: Thierry Reding > > The NVIDIA Tegra RTC driver has accumulated a bit of dust over the > years. Make a pass over it, addressing checkpatch warnings and fixing > some inconsistencies in comments and kernel messages as well as in > variable types and names. > > Once cleaned up, also turn the driver into a regular driver in order > to support deferred probe which is needed to avoid a future regression > on Tegra186 and later. > > Thierry > > Thierry Reding (3): > rtc: tegra: checkpatch and miscellaneous cleanups > rtc: tegra: Use consistent variable names and types > rtc: tegra: Turn into regular driver > > drivers/rtc/rtc-tegra.c | 254 > 1 file changed, 128 insertions(+), 126 deletions(-) > All applied, thanks. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH] tty/serial: digicolor: Fix digicolor-usart already registered warning
Hi Kefeng,
On Fri, May 31 2019, Kefeng Wang wrote:
> When modprobe/rmmod/modprobe module, if platform_driver_register() fails,
> the kernel complained,
>
> proc_dir_entry 'driver/digicolor-usart' already registered
> WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270
>
> Fix this by adding uart_unregister_driver() when platform_driver_register()
> fails.
>
> Reported-by: Hulk Robot
> Signed-off-by: Kefeng Wang
Acked-by: Baruch Siach
Thanks,
baruch
> ---
> drivers/tty/serial/digicolor-usart.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/digicolor-usart.c
> b/drivers/tty/serial/digicolor-usart.c
> index f460cca139e2..13ac36e2da4f 100644
> --- a/drivers/tty/serial/digicolor-usart.c
> +++ b/drivers/tty/serial/digicolor-usart.c
> @@ -541,7 +541,11 @@ static int __init digicolor_uart_init(void)
> if (ret)
> return ret;
>
> - return platform_driver_register(_uart_platform);
> + ret = platform_driver_register(_uart_platform);
> + if (ret)
> + uart_unregister_driver(_uart);
> +
> + return ret;
> }
> module_init(digicolor_uart_init);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
[GIT PULL 1/1] bcm2835-dt-next-2019-06-01
Hi Florian, the following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9: Linux 5.2-rc1 (2019-05-19 15:47:09 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2019-06-01 for you to fetch changes up to 08e3c41585386f5cefc91ede8835005742df4ba9: ARM: bcm283x: Enable DMA support for SPI controller (2019-05-25 12:50:18 +0200) This pull requests enables DMA support for the main SPI controller on all Raspberry Pis. Lukas Wunner (1): ARM: bcm283x: Enable DMA support for SPI controller arch/arm/boot/dts/bcm283x.dtsi | 2 ++ 1 file changed, 2 insertions(+)
Re: [PATCH 8/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
On Sun, 2019-06-02 at 00:13 +0530, Deepak Mishra wrote:
> This patch fixes CamelCase blnEnableRxFF0Filter by renaming it
> to bln_enable_rx_ff0_filter in drv_types.h and related files rtl871x_cmd.c
> xmit_linux.c
One could also improve this by removing the
hungarian like bln_ prefix and simplify the
name of the boolean variable.
> diff --git a/drivers/staging/rtl8712/drv_types.h
> b/drivers/staging/rtl8712/drv_types.h
[]
> @@ -164,7 +164,7 @@ struct _adapter {
> struct iw_statistics iwstats;
> int pid; /*process id from UI*/
> struct work_struct wk_filter_rx_ff0;
> - u8 blnEnableRxFF0Filter;
> + u8 bln_enable_rx_ff0_filter;
e.g.:
bool enable_rx_ff0_filter;
> diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
> b/drivers/staging/rtl8712/rtl871x_cmd.c
[]
> @@ -238,7 +238,7 @@ u8 r8712_sitesurvey_cmd(struct _adapter *padapter,
> mod_timer(>scan_to_timer,
> jiffies + msecs_to_jiffies(SCANNING_TIMEOUT));
> padapter->ledpriv.LedControlHandler(padapter, LED_CTL_SITE_SURVEY);
> - padapter->blnEnableRxFF0Filter = 0;
> + padapter->bln_enable_rx_ff0_filter = 0;
padapter->enable_rx_ff0_filter = false;
> diff --git a/drivers/staging/rtl8712/xmit_linux.c
> b/drivers/staging/rtl8712/xmit_linux.c
[]
> @@ -103,11 +103,11 @@ void r8712_SetFilter(struct work_struct *work)
> r8712_write8(padapter, 0x117, newvalue);
>
> spin_lock_irqsave(>lockRxFF0Filter, irqL);
> - padapter->blnEnableRxFF0Filter = 1;
> + padapter->bln_enable_rx_ff0_filter = 1;
padapter->enable_rx_ff0_filter = true;
etc...
Then you could rename padapter to adapter, and maybe
"struct _adapter" to something more sensible like
"struct rtl8712dev" etc...
And one day, hopefully sooner than later, realtek will
improve their driver software base and help eliminate
all the duplicated non-style defects across the family
of drivers for their hardware...
Re: [RFC 0/2] Support for buttons on newer MS Surface devices
Hi, any comments on this? I should also mention that this has been tested via https://github.com/jakeday/linux-surface. Maximilian On 5/16/19 4:25 PM, Maximilian Luz wrote: This series adds suport for power and volume buttons on 5th and 6th generation Microsoft Surface devices. Specifically, it adds support for the power-button on the Surface Laptop 1 and Laptop 2, as well as support for power- and (on-device) volume-buttons on the Surface Pro 5 (2017), Pro 6, and Book 2. These devices use the same MSHW0040 device as on the Surface Pro 4, however, whereas the Pro 4 uses an ACPI notify handler, the newer devices use GPIO interrupts to signal these events. The first patch of this series ensures that the surfacepro3_button driver, used for MSHW0040 on the Pro 4, does not probe for the newer devices. The second patch adapts soc_button_array to implement the actual button support. I think the changes to soc_button_array in the second patch warrant a thorough review. I've tried to make things a bit more generic to be able to integrate arbitrary ACPI GPIO power-/volume-button devices more easily, I'm not sure if there may be reasons against this. Maximilian Luz (2): platform: Fix device check for surfacepro3_button input: soc_button_array for newer surface devices drivers/input/misc/soc_button_array.c | 134 -- drivers/platform/x86/surfacepro3_button.c | 38 ++ 2 files changed, 160 insertions(+), 12 deletions(-)
[PATCH 2/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase ImrContent from struct _adapter and in related
files drv_types.h, rtl871x_eeprom.c, usb_intf.c
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/rtl871x_eeprom.c | 6 +++---
drivers/staging/rtl8712/usb_intf.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 89ebb5a49d25..7d1178278ecc 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -150,7 +150,7 @@ struct _adapter {
boolsuspended;
u32 IsrContent;
u32 imr_content;
- u8 EepromAddressSize;
+ u8 eeprom_address_size;
u8 hw_init_completed;
struct task_struct *cmdThread;
pid_t evtThread;
diff --git a/drivers/staging/rtl8712/rtl871x_eeprom.c
b/drivers/staging/rtl8712/rtl871x_eeprom.c
index 0027d8eb22fa..221bf92e1b1c 100644
--- a/drivers/staging/rtl8712/rtl871x_eeprom.c
+++ b/drivers/staging/rtl8712/rtl871x_eeprom.c
@@ -150,7 +150,7 @@ void r8712_eeprom_write16(struct _adapter *padapter, u16
reg, u16 data)
x |= _EEM1 | _EECS;
r8712_write8(padapter, EE_9346CR, x);
shift_out_bits(padapter, EEPROM_EWEN_OPCODE, 5);
- if (padapter->EepromAddressSize == 8) /*CF+ and SDIO*/
+ if (padapter->eeprom_address_size == 8) /*CF+ and SDIO*/
shift_out_bits(padapter, 0, 6);
else/* USB */
shift_out_bits(padapter, 0, 4);
@@ -165,7 +165,7 @@ void r8712_eeprom_write16(struct _adapter *padapter, u16
reg, u16 data)
*/
shift_out_bits(padapter, EEPROM_WRITE_OPCODE, 3);
/* select which word in the EEPROM that we are writing to. */
- shift_out_bits(padapter, reg, padapter->EepromAddressSize);
+ shift_out_bits(padapter, reg, padapter->eeprom_address_size);
/* write the data to the selected EEPROM word. */
shift_out_bits(padapter, data, 16);
if (wait_eeprom_cmd_done(padapter)) {
@@ -207,7 +207,7 @@ u16 r8712_eeprom_read16(struct _adapter *padapter, u16 reg)
/*ReadEEprom*/
* The opcode is 3bits in length, reg is 6 bits long
*/
shift_out_bits(padapter, EEPROM_READ_OPCODE, 3);
- shift_out_bits(padapter, reg, padapter->EepromAddressSize);
+ shift_out_bits(padapter, reg, padapter->eeprom_address_size);
/* Now read the data (16 bits) in from the selected EEPROM word */
data = shift_in_bits(padapter);
eeprom_clean(padapter);
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index 7478bbd3de78..200a271c28e1 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -246,7 +246,7 @@ static uint r8712_usb_dvobj_init(struct _adapter *padapter)
struct usb_device *pusbd = pdvobjpriv->pusbdev;
pdvobjpriv->padapter = padapter;
- padapter->EepromAddressSize = 6;
+ padapter->eeprom_address_size = 6;
phost_iface = >altsetting[0];
piface_desc = _iface->desc;
pdvobjpriv->nr_endpoint = piface_desc->bNumEndpoints;
--
2.19.1
[PATCH 0/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patchset fixes CamelCase checks in struct _adapter in drv_types.h and in files where struct _adapter is used by renaming the variables without camel case. These check were reported by checkpatch.pl Deepak Mishra (8): staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h drivers/staging/rtl8712/drv_types.h| 18 +- drivers/staging/rtl8712/os_intfs.c | 6 +++--- drivers/staging/rtl8712/rtl871x_cmd.c | 2 +- drivers/staging/rtl8712/rtl871x_eeprom.c | 6 +++--- drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 2 +- drivers/staging/rtl8712/rtl871x_pwrctrl.h | 2 +- drivers/staging/rtl8712/rtl871x_xmit.c | 2 +- drivers/staging/rtl8712/usb_intf.c | 2 +- drivers/staging/rtl8712/xmit_linux.c | 6 +++--- 9 files changed, 23 insertions(+), 23 deletions(-) -- 2.19.1
[PATCH 4/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase evtThread in struct _adapter as reported by
checkpatch.pl
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index c6faafb13bdf..5360f049088a 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -153,7 +153,7 @@ struct _adapter {
u8 eeprom_address_size;
u8 hw_init_completed;
struct task_struct *cmd_thread;
- pid_t evtThread;
+ pid_t evt_thread;
struct task_struct *xmitThread;
pid_t recvThread;
uint (*dvobj_init)(struct _adapter *adapter);
--
2.19.1
[PATCH 6/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase as reported by checkpatch.pl
xmitThread renamed to xmit_thread
recvThread renamed to recv_thread
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index a5060a020b2b..1f8aa0358b77 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -154,8 +154,8 @@ struct _adapter {
u8 hw_init_completed;
struct task_struct *cmd_thread;
pid_t evt_thread;
- struct task_struct *xmitThread;
- pid_t recvThread;
+ struct task_struct *xmit_thread;
+ pid_t recv_thread;
uint (*dvobj_init)(struct _adapter *adapter);
void (*dvobj_deinit)(struct _adapter *adapter);
struct net_device *pnetdev;
--
2.19.1
[PATCH 8/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase blnEnableRxFF0Filter by renaming it
to bln_enable_rx_ff0_filter in drv_types.h and related files rtl871x_cmd.c
xmit_linux.c
It was reported by checkpatch.pl
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/rtl871x_cmd.c | 2 +-
drivers/staging/rtl8712/xmit_linux.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index ddab6514a549..33caa9477f9f 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -164,7 +164,7 @@ struct _adapter {
struct iw_statistics iwstats;
int pid; /*process id from UI*/
struct work_struct wk_filter_rx_ff0;
- u8 blnEnableRxFF0Filter;
+ u8 bln_enable_rx_ff0_filter;
spinlock_t lockRxFF0Filter;
const struct firmware *fw;
struct usb_interface *pusb_intf;
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
b/drivers/staging/rtl8712/rtl871x_cmd.c
index 05a78ac24987..873232d0be9f 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -238,7 +238,7 @@ u8 r8712_sitesurvey_cmd(struct _adapter *padapter,
mod_timer(>scan_to_timer,
jiffies + msecs_to_jiffies(SCANNING_TIMEOUT));
padapter->ledpriv.LedControlHandler(padapter, LED_CTL_SITE_SURVEY);
- padapter->blnEnableRxFF0Filter = 0;
+ padapter->bln_enable_rx_ff0_filter = 0;
return _SUCCESS;
}
diff --git a/drivers/staging/rtl8712/xmit_linux.c
b/drivers/staging/rtl8712/xmit_linux.c
index e65a51c7f372..241c0c91122b 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -103,11 +103,11 @@ void r8712_SetFilter(struct work_struct *work)
r8712_write8(padapter, 0x117, newvalue);
spin_lock_irqsave(>lockRxFF0Filter, irqL);
- padapter->blnEnableRxFF0Filter = 1;
+ padapter->bln_enable_rx_ff0_filter = 1;
spin_unlock_irqrestore(>lockRxFF0Filter, irqL);
do {
msleep(100);
- } while (padapter->blnEnableRxFF0Filter == 1);
+ } while (padapter->bln_enable_rx_ff0_filter == 1);
r8712_write8(padapter, 0x117, oldvalue);
}
--
2.19.1
[PATCH 1/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase ImrContent from struct _adapter and in related
files drv_types.h, rtl871x_mp_ioctl.c, rtl871x_pwrctrl.h
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h| 2 +-
drivers/staging/rtl8712/rtl871x_mp_ioctl.c | 2 +-
drivers/staging/rtl8712/rtl871x_pwrctrl.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 9ae86631fa8b..89ebb5a49d25 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -149,7 +149,7 @@ struct _adapter {
boolsurprise_removed;
boolsuspended;
u32 IsrContent;
- u32 ImrContent;
+ u32 imr_content;
u8 EepromAddressSize;
u8 hw_init_completed;
struct task_struct *cmdThread;
diff --git a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
index 588346da1412..4cf9d3afd2c5 100644
--- a/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
+++ b/drivers/staging/rtl8712/rtl871x_mp_ioctl.c
@@ -665,7 +665,7 @@ uint oid_rt_pro_write_register_hdl(struct oid_par_priv
*poid_par_priv)
if ((status == RNDIS_STATUS_SUCCESS) &&
(RegRWStruct->offset == HIMR) &&
(RegRWStruct->width == 4))
- Adapter->ImrContent = RegRWStruct->value;
+ Adapter->imr_content = RegRWStruct->value;
}
return status;
}
diff --git a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
index 11b5034f203d..cca81a3f4031 100644
--- a/drivers/staging/rtl8712/rtl871x_pwrctrl.h
+++ b/drivers/staging/rtl8712/rtl871x_pwrctrl.h
@@ -88,7 +88,7 @@ structpwrctrl_priv {
uint pwr_mode;
uint smart_ps;
uint alives;
- uint ImrContent;/* used to store original imr. */
+ uint imr_content; /* used to store original imr. */
uint bSleep; /* sleep -> active is different from active -> sleep. */
struct work_struct SetPSModeWorkItem;
--
2.19.1
[PATCH 7/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch renames CamelCase variable wkFilterRxFF0 to wk_filter_rx_ff0
in drv_types.h and related files rtl871x_xmit.c and xmit_linux.c as
reported by checkpatch.pl
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h| 2 +-
drivers/staging/rtl8712/rtl871x_xmit.c | 2 +-
drivers/staging/rtl8712/xmit_linux.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 1f8aa0358b77..ddab6514a549 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -163,7 +163,7 @@ struct _adapter {
struct net_device_stats stats;
struct iw_statistics iwstats;
int pid; /*process id from UI*/
- struct work_struct wkFilterRxFF0;
+ struct work_struct wk_filter_rx_ff0;
u8 blnEnableRxFF0Filter;
spinlock_t lockRxFF0Filter;
const struct firmware *fw;
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c
b/drivers/staging/rtl8712/rtl871x_xmit.c
index bfd5538a4652..5d63d2721eb6 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -139,7 +139,7 @@ sint _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
pxmitbuf++;
}
pxmitpriv->free_xmitbuf_cnt = NR_XMITBUFF;
- INIT_WORK(>wkFilterRxFF0, r8712_SetFilter);
+ INIT_WORK(>wk_filter_rx_ff0, r8712_SetFilter);
alloc_hwxmits(padapter);
init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
tasklet_init(>xmit_tasklet,
diff --git a/drivers/staging/rtl8712/xmit_linux.c
b/drivers/staging/rtl8712/xmit_linux.c
index 8bcb0775411f..e65a51c7f372 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -94,7 +94,7 @@ void r8712_set_qos(struct pkt_file *ppktfile, struct
pkt_attrib *pattrib)
void r8712_SetFilter(struct work_struct *work)
{
struct _adapter *padapter = container_of(work, struct _adapter,
- wkFilterRxFF0);
+ wk_filter_rx_ff0);
u8 oldvalue = 0x00, newvalue = 0x00;
unsigned long irqL;
--
2.19.1
[PATCH 5/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase IsrContent to isr_content as suggested by
checkpatch.pl
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 5360f049088a..a5060a020b2b 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -148,7 +148,7 @@ struct _adapter {
booldriver_stopped;
boolsurprise_removed;
boolsuspended;
- u32 IsrContent;
+ u32 isr_content;
u32 imr_content;
u8 eeprom_address_size;
u8 hw_init_completed;
--
2.19.1
[PATCH 3/8] staging: rtl8712: Fixed CamelCase in struct _adapter from drv_types.h
This patch fixes CamelCase cmdThread from struct _adapter and in related
files drv_types.h,os_intfs.c
CHECK: Avoid CamelCase:
Signed-off-by: Deepak Mishra
---
drivers/staging/rtl8712/drv_types.h | 2 +-
drivers/staging/rtl8712/os_intfs.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8712/drv_types.h
b/drivers/staging/rtl8712/drv_types.h
index 7d1178278ecc..c6faafb13bdf 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -152,7 +152,7 @@ struct _adapter {
u32 imr_content;
u8 eeprom_address_size;
u8 hw_init_completed;
- struct task_struct *cmdThread;
+ struct task_struct *cmd_thread;
pid_t evtThread;
struct task_struct *xmitThread;
pid_t recvThread;
diff --git a/drivers/staging/rtl8712/os_intfs.c
b/drivers/staging/rtl8712/os_intfs.c
index c962696c9822..1653b36c4bfd 100644
--- a/drivers/staging/rtl8712/os_intfs.c
+++ b/drivers/staging/rtl8712/os_intfs.c
@@ -221,9 +221,9 @@ struct net_device *r8712_init_netdev(void)
static u32 start_drv_threads(struct _adapter *padapter)
{
- padapter->cmdThread = kthread_run(r8712_cmd_thread, padapter, "%s",
+ padapter->cmd_thread = kthread_run(r8712_cmd_thread, padapter, "%s",
padapter->pnetdev->name);
- if (IS_ERR(padapter->cmdThread))
+ if (IS_ERR(padapter->cmd_thread))
return _FAIL;
return _SUCCESS;
}
@@ -235,7 +235,7 @@ void r8712_stop_drv_threads(struct _adapter *padapter)
/*Below is to terminate r8712_cmd_thread & event_thread...*/
complete(>cmdpriv.cmd_queue_comp);
- if (padapter->cmdThread)
+ if (padapter->cmd_thread)
wait_for_completion_interruptible(completion);
padapter->cmdpriv.cmd_seq = 1;
}
--
2.19.1
[PATCH] PCI: hv: Detect and fix Hyper-V PCI domain number collision
From: Haiyang Zhang
Due to Azure host agent settings, the device instance ID's bytes 8 and 9
are no longer unique. This causes some of the PCI devices not showing up
in VMs with multiple passthrough devices, such as GPUs. So, as recommended
by Azure host team, we now use the bytes 4 and 5 which usually provide
unique numbers.
In the rare cases of collision, we will detect and find another number
that is not in use.
Thanks to Michael Kelley for proposing this idea.
Signed-off-by: Haiyang Zhang
Cc: sta...@kernel.org
Signed-off-by: Sasha Levin
---
drivers/pci/controller/pci-hyperv.c | 91 -
1 file changed, 78 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c
b/drivers/pci/controller/pci-hyperv.c
index 82acd6155adf3..6b9cc6e60a040 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -37,6 +37,8 @@
* the PCI back-end driver in Hyper-V.
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include
#include
#include
@@ -2507,6 +2509,47 @@ static void put_hvpcibus(struct hv_pcibus_device *hbus)
complete(>remove_event);
}
+#define HVPCI_DOM_MAP_SIZE (64 * 1024)
+static DECLARE_BITMAP(hvpci_dom_map, HVPCI_DOM_MAP_SIZE);
+
+/* PCI domain number 0 is used by emulated devices on Gen1 VMs, so define 0
+ * as invalid for passthrough PCI devices of this driver.
+ */
+#define HVPCI_DOM_INVALID 0
+
+/**
+ * hv_get_dom_num() - Get a valid PCI domain number
+ * Check if the PCI domain number is in use, and return another number if
+ * it is in use.
+ *
+ * @dom: Requested domain number
+ *
+ * return: domain number on success, HVPCI_DOM_INVALID on failure
+ */
+static u16 hv_get_dom_num(u16 dom)
+{
+ unsigned int i;
+
+ if (test_and_set_bit(dom, hvpci_dom_map) == 0)
+ return dom;
+
+ for_each_clear_bit(i, hvpci_dom_map, HVPCI_DOM_MAP_SIZE) {
+ if (test_and_set_bit(i, hvpci_dom_map) == 0)
+ return i;
+ }
+
+ return HVPCI_DOM_INVALID;
+}
+
+/**
+ * hv_put_dom_num() - Mark the PCI domain number as free
+ * @dom: Domain number to be freed
+ */
+static void hv_put_dom_num(u16 dom)
+{
+ clear_bit(dom, hvpci_dom_map);
+}
+
/**
* hv_pci_probe() - New VMBus channel probe, for a root PCI bus
* @hdev: VMBus's tracking struct for this root PCI bus
@@ -2518,6 +2561,7 @@ static int hv_pci_probe(struct hv_device *hdev,
const struct hv_vmbus_device_id *dev_id)
{
struct hv_pcibus_device *hbus;
+ u16 dom_req, dom;
int ret;
/*
@@ -2532,19 +2576,32 @@ static int hv_pci_probe(struct hv_device *hdev,
hbus->state = hv_pcibus_init;
/*
-* The PCI bus "domain" is what is called "segment" in ACPI and
-* other specs. Pull it from the instance ID, to get something
-* unique. Bytes 8 and 9 are what is used in Windows guests, so
-* do the same thing for consistency. Note that, since this code
-* only runs in a Hyper-V VM, Hyper-V can (and does) guarantee
-* that (1) the only domain in use for something that looks like
-* a physical PCI bus (which is actually emulated by the
-* hypervisor) is domain 0 and (2) there will be no overlap
-* between domains derived from these instance IDs in the same
-* VM.
+* The PCI bus "domain" is what is called "segment" in ACPI and other
+* specs. Pull it from the instance ID, to get something usually
+* unique. In rare cases of collision, we will find out another number
+* not in use.
+* Note that, since this code only runs in a Hyper-V VM, Hyper-V
+* together with this guest driver can guarantee that (1) The only
+* domain used by Gen1 VMs for something that looks like a physical
+* PCI bus (which is actually emulated by the hypervisor) is domain 0.
+* (2) There will be no overlap between domains (after fixing possible
+* collisions) in the same VM.
*/
- hbus->sysdata.domain = hdev->dev_instance.b[9] |
- hdev->dev_instance.b[8] << 8;
+ dom_req = hdev->dev_instance.b[5] << 8 | hdev->dev_instance.b[4];
+ dom = hv_get_dom_num(dom_req);
+
+ if (dom == HVPCI_DOM_INVALID) {
+ pr_err("Unable to use dom# 0x%hx or other numbers",
+ dom_req);
+ ret = -EINVAL;
+ goto free_bus;
+ }
+
+ if (dom != dom_req)
+ pr_info("PCI dom# 0x%hx has collision, using 0x%hx",
+ dom_req, dom);
+
+ hbus->sysdata.domain = dom;
hbus->hdev = hdev;
refcount_set(>remove_lock, 1);
@@ -2559,7 +2616,7 @@ static int hv_pci_probe(struct hv_device *hdev,
hbus->sysdata.domain);
if (!hbus->wq) {
ret = -ENOMEM;
- goto free_bus;
+
Re: [PATCH] drivers: hid: Add a module description line to the hid_hyperv driver
On Sat, Jun 01, 2019 at 12:19:11AM +0200, Jiri Kosina wrote:
On Thu, 30 May 2019, Sasha Levin wrote:
From: Joseph Salisbury
This patch only adds a MODULE_DESCRIPTION statement to the driver.
This change is only cosmetic, so there should be no runtime impact.
Signed-off-by: Joseph Salisbury
Reviewed-by: Michael Kelley
Signed-off-by: Sasha Levin
---
drivers/hid/hid-hyperv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/hid/hid-hyperv.c b/drivers/hid/hid-hyperv.c
index 704049e62d58a..d3311d714d359 100644
--- a/drivers/hid/hid-hyperv.c
+++ b/drivers/hid/hid-hyperv.c
@@ -614,5 +614,7 @@ static void __exit mousevsc_exit(void)
}
MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Microsoft Hyper-V Synthetic HID Driver");
+
Is there a reason why you didn't CC Joseph on this submission?
Hm, no, I just went with my usual get_maintainers.pl + whomever git
adds. Sorry Joe!
--
Thanks,
Sasha
[GIT PULL] LED fix for 5.2-rc3
Hi Linus, Please pull LED fix for recent change in LED core, that didn't take into account the possibility of calling led_blink_setup() from atomic context. The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/led-fixes-for-5.2-rc3 for you to fetch changes up to 8c0f693c6effbc3f42f77a9e81209af9af20910c: leds: avoid flush_work in atomic context (2019-05-31 22:29:14 +0200) Thanks, Jacek Anaszewski LED fix for 5.2-rc3 Pavel Machek (1): leds: avoid flush_work in atomic context drivers/leds/led-core.c | 5 - drivers/leds/trigger/ledtrig-timer.c | 5 + 2 files changed, 5 insertions(+), 5 deletions(-)
RE: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
Hi syzbot, > > syzbot found the following crash on: > As per the link(https://syzkaller.appspot.com/bug?extid=dc4127f950da51639216), the issue is fixed; Is it OK? Let us know if we need to do something? Regards, Ganapathi
Re: [PATCH 2/2] gpio: max732x: use devm_gpiochip_add_data()
On Tue, May 21, 2019 at 11:03 AM Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > We can simplify the code a bit with a resource managed variant of > gpiochip_add_data(). > > Signed-off-by: Bartosz Golaszewski Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH 1/2] gpio: max732x: use i2c_new_dummy_device()
On Tue, May 28, 2019 at 5:53 PM Bartosz Golaszewski wrote: > wt., 21 maj 2019 o 11:03 Bartosz Golaszewski napisał(a): > > > > From: Bartosz Golaszewski > > > > We now have a resource managed version of i2c_new_dummy_device() that > > also returns an actual error code instead of a NULL-pointer. Use it > > in the max732x GPIO driver and simplify code in the process. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > If there are no objections I'll apply it by the end of this week. Reviewed-by: Linus Walleij Just include it in some pull request to me! Yours, Linus Walleij
Re: [PATCH v2 0/2] pinctrl: mediatek: mt8183: Add support for wake sources
On Wed, May 8, 2019 at 9:33 AM Nicolas Boichat wrote: > This adds support for wake sources in pinctrl-mtk-common-v2, and > pinctrl-mt8183. Without this patch, all interrupts that are left > enabled on suspend act as wake sources (and wake sources without > interrupt enabled do not). > > Changes since v1: > - Move changes from mtk-common-v2 to mtk-pinctrl-paris, as >recommended by Sean, to keep better separation between eint >and pinctrl-common features. Both patches applied with Sean's ACK! Yours, Linus Walleij
Re: [PATCH 0/5] pinctrl: meson: gpio: update with SPDX Licence identifier
On Mon, May 20, 2019 at 4:41 PM Neil Armstrong wrote: > Update the SPDX Licence identifier for the Amlogic Pinctrl drivers and > the corresponding GPIO dt-bindings headers. > > Neil Armstrong (5): All 5 patches applied, I took a quick look in mainline and it appears those files were not hit by the large scripted conversions to SPDX that tglx did recently. Yours, Linus Walleij
Re: [PATCH 1/5] pinctrl: meson: update with SPDX Licence identifier
On Mon, May 20, 2019 at 4:41 PM Neil Armstrong wrote: > Signed-off-by: Neil Armstrong Patch applied with Martin's review tag. Yours, Linus Walleij
RE: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
Hi Dan,
> > if (is_multicast_ether_addr(ra)) {
> > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > + if (!skb_uap)
> > + return -ENOMEM;
>
> I think we would want to free dev_kfree_skb_any(skb) before returning.
I think if the pointer is NULL, no need to free it;
Regards,
Ganapathi
Re: [PATCH V3 4/4] soc/tegra: select pinctrl for Tegra194
On Thu, May 16, 2019 at 1:53 PM Krishna Yarlagadda wrote: > Select PINCTRL_TEGRA194 by default for Tegra194 SOC needed > for dynamically controlling PCIe pins > > Signed-off-by: Krishna Yarlagadda Reviewed-by: Linus Walleij I guess this needs to be applied by the Tegra SoC maintainers and go upstream through the ARM SoC tree. If nothing happens and you lose patience, do not hesitate to poke me back and I might just apply it to the pinctrl tree. Yours, Linus Walleij
Re: [PATCH V3 3/4] pinctrl: tegra: Add Tegra194 pinmux driver
On Thu, May 16, 2019 at 1:54 PM Krishna Yarlagadda wrote: > Tegra194 has PCIE L5 rst and clkreq pins which need to be controlled > dynamically at runtime. This driver supports change pinmux for these > pins. Pinmux for rest of the pins is set statically by bootloader and > will not be changed by this driver > > Signed-off-by: Krishna Yarlagadda > Signed-off-by: Suresh Mangipudi > --- > Changes in V3: > Fix build issue observed with previous version Patch applied with Vidya's Test tag. If the maintainers have comments they had two weeks to answer to the patch and if there are still issues I am pretty sure they can be fixed with follow-up patches in that case. Yours, Linus Walleij
Re: [PATCH V3 2/4] pinctrl: tegra: Support 32 bit register access
On Thu, May 16, 2019 at 1:53 PM Krishna Yarlagadda wrote: > Tegra194 chip has 32 bit pinctrl registers. Existing register defines in > header are only 16 bit. > Modified common pinctrl-tegra driver to support 32 bit registers of > Tegra 194 and later chips. > > Signed-off-by: Krishna Yarlagadda Patch applied. Yours, Linus Walleij
Re: [PATCH V3 1/4] dt-binding: Tegra194 pinctrl support
On Thu, May 16, 2019 at 1:53 PM Krishna Yarlagadda wrote: > Add binding doc for Tegra 194 pinctrl driver > > Signed-off-by: Krishna Yarlagadda > --- > Changes in V3: > remove optional fields not supported by pins published here Patch applied with the tags. Yours, Linus Walleij
Re: KASAN: user-memory-access Read in ip6_hold_safe (3)
On 6/1/19 12:05 AM, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: dfb569f2 net: ll_temac: Fix compile error > git tree: net-next syzbot team: Is there any way to know the history of syzbot runs to determine that crash X did not happen at commit Y but does happen at commit Z? That narrows the window when trying to find where a regression occurs. Thanks,
Re: [PATCH 00/12] Secure Virtual Machine Enablement
Hello, Thiago Jung Bauermann writes: > This series enables Secure Virtual Machines (SVMs) on powerpc. SVMs use the > Protected Execution Facility (PEF) and request to be migrated to secure > memory during prom_init() so by default all of their memory is inaccessible > to the hypervisor. There is an Ultravisor call that the VM can use to > request certain pages to be made accessible to (or shared with) the > hypervisor. > > The objective of these patches is to have the guest perform this request > for buffers that need to be accessed by the hypervisor such as the LPPACAs, > the SWIOTLB memory and the Debug Trace Log. Ping? Any more comments on these patches? Or even acks? :-) -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH] treewide: fix typos of SPDX-License-Identifier
On Sat, Jun 01, 2019 at 12:22:42PM +0900, Masahiro Yamada wrote: > Prior to the adoption of SPDX, it was difficult for tools to determine > the correct license due to incomplete or badly formatted license text. > The SPDX solves this issue, assuming people can correctly spell > "SPDX-License-Identifier" although this assumption is broken in some > places. > > Since scripts/spdxcheck.py parses only lines that exactly matches to > the correct tag, it cannot (should not) detect this kind of error. > > If the correct tag is missing, scripts/checkpatch.pl warns like this: > > WARNING: Missing or malformed SPDX-License-Identifier tag in line * > > So, people should notice it before the patch submission, but in reality > broken tags sometimes slip in. The checkpatch warning is not useful for > checking the committed files globally since large number of files still > have no SPDX tag. > > Also, I am not sure about the legal effect when the SPDX tag is broken. > > Anyway, these typos are absolutely worth fixing. It is pretty easy to > find suspicious lines by grep. > > $ git grep --not -e SPDX-License-Identifier --and -e SPDX- -- \ > :^LICENSES :^scripts/spdxcheck.py :^*/license-rules.rst > arch/arm/kernel/bugs.c:// SPDX-Identifier: GPL-2.0 > drivers/phy/st/phy-stm32-usbphyc.c:// SPDX-Licence-Identifier: GPL-2.0 > drivers/pinctrl/sh-pfc/pfc-r8a77980.c:// SPDX-Lincense-Identifier: GPL 2.0 > lib/test_stackinit.c:// SPDX-Licenses: GPLv2 > sound/soc/codecs/max9759.c:// SPDX-Licence-Identifier: GPL-2.0 > > Signed-off-by: Masahiro Yamada Very nice catch, thanks! I'll go queue this up now. greg k-h
Re: [PATCH 08/16] sparc64: add the missing pgd_page definition
Both sparc64 and sh had this pattern, but now that I look at it more closely, I think your version is wrong, or at least nonoptimal. On Sat, Jun 1, 2019 at 12:50 AM Christoph Hellwig wrote: > > +#define pgd_page(pgd) virt_to_page(__va(pgd_val(pgd))) Going through the virtual address is potentially very inefficient, and might in some cases just be wrong (ie it's definitely wrong for HIGHMEM style setups). It would likely be much better to go through the physical address and use "pfn_to_page()". I realize that we don't have a "pgd to physical", but neither do we really have a "pgd to virtual", and your "__va(pgd_val(x))" thing is not at allguaranteed to work. You're basically assuming that "pgd_val(x)" is the physical address, which is likely not entirely incorrect, but it should be checked by the architecture people. The pgd value could easily have high bits with meaning, which would also potentially screw up the __va(x) model. So I thgink this would be better done with #define pgd_page(pgd)pfn_to_page(pgd_pfn(pgd)) where that "pgd_pfn()" would need to be a new (but likely very trivial) function. That's what we do for pte_pfn(). IOW, it would likely end up something like #define pgd_to_pfn(pgd) (pgd_val(x) >> PFN_PGD_SHIFT) David? Linus
Re: [PATCH AUTOSEL 4.4 50/56] tty: pty: Fix race condition between release_one_tty and pty_write
On Sat, Jun 01, 2019 at 09:25:54AM -0400, Sasha Levin wrote:
> From: Sahara
>
> [ Upstream commit b9ca5f8560af244489b4a1bc1ae88b341f24bc95 ]
>
> Especially when a linked tty is used such as pty, the linked tty
> port's buf works have not been cancelled while master tty port's
> buf work has been cancelled. Since release_one_tty and flush_to_ldisc
> run in workqueue threads separately, when pty_cleanup happens and
> link tty port is freed, flush_to_ldisc tries to access freed port
> and port->itty, eventually it causes a panic.
> This patch utilizes the magic value with holding the tty_mutex to
> check if the tty->link is valid.
>
> Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release")
> Signed-off-by: Sahara
> Cc: stable
> Signed-off-by: Greg Kroah-Hartman
> Signed-off-by: Sasha Levin
> ---
> drivers/tty/pty.c| 7 +++
> drivers/tty/tty_io.c | 3 +++
> 2 files changed, 10 insertions(+)
For some reason I did not apply this to the stable kernels, and this
shouldn't only be for 4.4.y, so please drop this.
thanks,
greg k-h
Re: [PATCH AUTOSEL 4.4 50/56] tty: pty: Fix race condition between release_one_tty and pty_write
On Sat, Jun 01, 2019 at 09:17:07AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 01, 2019 at 09:25:54AM -0400, Sasha Levin wrote:
> > From: Sahara
> >
> > [ Upstream commit b9ca5f8560af244489b4a1bc1ae88b341f24bc95 ]
> >
> > Especially when a linked tty is used such as pty, the linked tty
> > port's buf works have not been cancelled while master tty port's
> > buf work has been cancelled. Since release_one_tty and flush_to_ldisc
> > run in workqueue threads separately, when pty_cleanup happens and
> > link tty port is freed, flush_to_ldisc tries to access freed port
> > and port->itty, eventually it causes a panic.
> > This patch utilizes the magic value with holding the tty_mutex to
> > check if the tty->link is valid.
> >
> > Fixes: 2b022ab7542d ("pty: cancel pty slave port buf's work in tty_release")
> > Signed-off-by: Sahara
> > Cc: stable
> > Signed-off-by: Greg Kroah-Hartman
> > Signed-off-by: Sasha Levin
> > ---
> > drivers/tty/pty.c| 7 +++
> > drivers/tty/tty_io.c | 3 +++
> > 2 files changed, 10 insertions(+)
>
> For some reason I did not apply this to the stable kernels, and this
> shouldn't only be for 4.4.y, so please drop this.
Ah, I never applied it because it was later reverted, also upstream,
0eae4686a128 ("Revert "tty: pty: Fix race condition between
release_one_tty and pty_write""), so I didn't apply both of them to the
stable trees as that wouldn't have made sense.
thanks,
greg k-h
Re: [PATCH v3 16/16] fpga: dfl: fme: add performance reporting support
On Sat, Jun 01, 2019 at 05:11:47PM +0800, Wu Hao wrote: > On Thu, May 30, 2019 at 12:03:05PM -0700, Greg KH wrote: > > On Mon, May 27, 2019 at 01:22:26PM +0800, Wu Hao wrote: > > > --- /dev/null > > > +++ b/drivers/fpga/dfl-fme-perf.c > > > @@ -0,0 +1,962 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Driver for FPGA Management Engine (FME) Global Performance Reporting > > > + * > > > + * Copyright 2019 Intel Corporation, Inc. > > > + * > > > + * Authors: > > > + * Kang Luwei > > > + * Xiao Guangrong > > > + * Wu Hao > > > + * Joseph Grecco > > > + * Enno Luebbers > > > + * Tim Whisonant > > > + * Ananda Ravuri > > > + * Mitchel, Henry > > > + */ > > > + > > > +#include "dfl.h" > > > +#include "dfl-fme.h" > > > + > > > +/* > > > + * Performance Counter Registers for Cache. > > > + * > > > + * Cache Events are listed below as CACHE_EVNT_*. > > > + */ > > > +#define CACHE_CTRL 0x8 > > > +#define CACHE_RESET_CNTR BIT_ULL(0) > > > +#define CACHE_FREEZE_CNTRBIT_ULL(8) > > > +#define CACHE_CTRL_EVNT GENMASK_ULL(19, 16) > > > +#define CACHE_EVNT_RD_HIT0x0 > > > +#define CACHE_EVNT_WR_HIT0x1 > > > +#define CACHE_EVNT_RD_MISS 0x2 > > > +#define CACHE_EVNT_WR_MISS 0x3 > > > +#define CACHE_EVNT_RSVD 0x4 > > > +#define CACHE_EVNT_HOLD_REQ 0x5 > > > +#define CACHE_EVNT_DATA_WR_PORT_CONTEN 0x6 > > > +#define CACHE_EVNT_TAG_WR_PORT_CONTEN0x7 > > > +#define CACHE_EVNT_TX_REQ_STALL 0x8 > > > +#define CACHE_EVNT_RX_REQ_STALL 0x9 > > > +#define CACHE_EVNT_EVICTIONS 0xa > > > +#define CACHE_EVNT_MAX CACHE_EVNT_EVICTIONS > > > +#define CACHE_CHANNEL_SELBIT_ULL(20) > > > +#define CACHE_CHANNEL_RD 0 > > > +#define CACHE_CHANNEL_WR 1 > > > +#define CACHE_CHANNEL_MAX2 > > > +#define CACHE_CNTR0 0x10 > > > +#define CACHE_CNTR1 0x18 > > > +#define CACHE_CNTR_EVNT_CNTR GENMASK_ULL(47, 0) > > > +#define CACHE_CNTR_EVNT GENMASK_ULL(63, 60) > > > + > > > +/* > > > + * Performance Counter Registers for Fabric. > > > + * > > > + * Fabric Events are listed below as FAB_EVNT_* > > > + */ > > > +#define FAB_CTRL 0x20 > > > +#define FAB_RESET_CNTR BIT_ULL(0) > > > +#define FAB_FREEZE_CNTR BIT_ULL(8) > > > +#define FAB_CTRL_EVNTGENMASK_ULL(19, 16) > > > +#define FAB_EVNT_PCIE0_RD0x0 > > > +#define FAB_EVNT_PCIE0_WR0x1 > > > +#define FAB_EVNT_PCIE1_RD0x2 > > > +#define FAB_EVNT_PCIE1_WR0x3 > > > +#define FAB_EVNT_UPI_RD 0x4 > > > +#define FAB_EVNT_UPI_WR 0x5 > > > +#define FAB_EVNT_MMIO_RD 0x6 > > > +#define FAB_EVNT_MMIO_WR 0x7 > > > +#define FAB_EVNT_MAX FAB_EVNT_MMIO_WR > > > +#define FAB_PORT_ID GENMASK_ULL(21, 20) > > > +#define FAB_PORT_FILTER BIT_ULL(23) > > > +#define FAB_PORT_FILTER_DISABLE 0 > > > +#define FAB_PORT_FILTER_ENABLE 1 > > > +#define FAB_CNTR 0x28 > > > +#define FAB_CNTR_EVNT_CNTR GENMASK_ULL(59, 0) > > > +#define FAB_CNTR_EVNTGENMASK_ULL(63, 60) > > > + > > > +/* > > > + * Performance Counter Registers for Clock. > > > + * > > > + * Clock Counter can't be reset or frozen by SW. > > > + */ > > > +#define CLK_CNTR 0x30 > > > + > > > +/* > > > + * Performance Counter Registers for IOMMU / VT-D. > > > + * > > > + * VT-D Events are listed below as VTD_EVNT_* and VTD_SIP_EVNT_* > > > + */ > > > +#define VTD_CTRL 0x38 > > > +#define VTD_RESET_CNTR BIT_ULL(0) > > > +#define VTD_FREEZE_CNTR BIT_ULL(8) > > > +#define VTD_CTRL_EVNTGENMASK_ULL(19, 16) > > > +#define VTD_EVNT_AFU_MEM_RD_TRANS0x0 > > > +#define VTD_EVNT_AFU_MEM_WR_TRANS0x1 > > > +#define VTD_EVNT_AFU_DEVTLB_RD_HIT 0x2 > > > +#define VTD_EVNT_AFU_DEVTLB_WR_HIT 0x3 > > > +#define VTD_EVNT_DEVTLB_4K_FILL 0x4 > > > +#define VTD_EVNT_DEVTLB_2M_FILL 0x5 > > > +#define VTD_EVNT_DEVTLB_1G_FILL 0x6 > > > +#define VTD_EVNT_MAX VTD_EVNT_DEVTLB_1G_FILL > > > +#define VTD_CNTR 0x40 > > > +#define VTD_CNTR_EVNTGENMASK_ULL(63, 60) > > > +#define VTD_CNTR_EVNT_CNTR GENMASK_ULL(47, 0) > > > +#define VTD_SIP_CTRL 0x48 > > > +#define VTD_SIP_RESET_CNTR BIT_ULL(0) > > > +#define VTD_SIP_FREEZE_CNTR BIT_ULL(8) > > > +#define VTD_SIP_CTRL_EVNTGENMASK_ULL(19, 16) > > > +#define VTD_SIP_EVNT_IOTLB_4K_HIT0x0 > > > +#define
Re: [PATCH 03/16] mm: simplify gup_fast_permitted
On Sat, Jun 1, 2019 at 12:50 AM Christoph Hellwig wrote: > > Pass in the already calculated end value instead of recomputing it, and > leave the end > start check in the callers instead of duplicating them > in the arch code. Good cleanup, except it's wrong. > - if (nr_pages <= 0) > + if (end < start) > return 0; You moved the overflow test to generic code - good. You removed the sign and zero test on nr_pages - bad. The zero test in particular is _important_ - the GUP range operators know and depend on the fact that they are passed a non-empty range. The sign test it less so, but is definitely appropriate. It might be even better to check that the "<< PAGE_SHIFT" doesn't overflow in "long", of course, but with callers being supposed to be trusted, the sign test at least checks for stupid underflow issues. So at the very least that "(end < start)" needs to be "(end <= start)", but honestly, I think the sign of the nr_pages should be continued to be checked. Linus
Re: [PATCH 09/25] vfs: Allow mount information to be queried by fsinfo() [ver #13]
On Tue, May 28, 2019 at 04:12:15PM +0100, David Howells wrote:
[snip]
> +
> +/*
> + * Store a mount record into the fsinfo buffer.
> + */
> +static void store_mount_fsinfo(struct fsinfo_kparams *params,
> +struct fsinfo_mount_child *child)
> +{
> + unsigned int usage = params->usage;
> + unsigned int total = sizeof(*child);
> +
> + if (params->usage >= INT_MAX)
> + return;
> + params->usage = usage + total;
> + if (params->buffer && params->usage <= params->buf_size)
> + memcpy(params->buffer + usage, child, total);
> +}
> +
> +/*
> + * Return information about the submounts relative to path.
> + */
> +int fsinfo_generic_mount_children(struct path *path, struct fsinfo_kparams
> *params)
> +{
> + struct fsinfo_mount_child record;
> + struct mount *m, *child;
> +
> + if (!path->mnt)
> + return -ENODATA;
> +
> + rcu_read_lock();
> +
> + m = real_mount(path->mnt);
> + list_for_each_entry_rcu(child, >mnt_mounts, mnt_child) {
> + if (child->mnt_parent != m)
> + continue;
> + record.mnt_id = child->mnt_id;
> + record.notify_counter = atomic_read(>mnt_notify_counter);
> + store_mount_fsinfo(params, );
> + }
> +
> + record.mnt_id = m->mnt_id;
> + record.notify_counter = atomic_read(>mnt_notify_counter);
> + store_mount_fsinfo(params, );
> +
> + rcu_read_unlock();
Not super familiar with this code, but wanted to check with you:
Here, if the rcu_read_lock is supposed to protect the RCU list, can
rcu_read_lock() scope be reduced to just wrapping around the
list_for_each_entry_rcu?
rcu_read_lock();
list_for_each_entry_rcu(..) {
...
}
rcu_read_unlock();
(and similarly to other similar parts of this patch).
thanks,
- Joel
> + return params->usage;
> +}
> +
> +/*
> + * Return the path of the Nth submount relative to path. This is derived
> from
> + * d_path(), but the root determination is more complicated.
> + */
> +int fsinfo_generic_mount_submount(struct path *path, struct fsinfo_kparams
> *params)
> +{
> + struct mountpoint *mp;
> + struct mount *m, *child;
> + struct path mountpoint, root;
> + unsigned int n = params->Nth;
> + size_t len;
> + void *p;
> +
> + if (!path->mnt)
> + return -ENODATA;
> +
> + rcu_read_lock();
> +
> + m = real_mount(path->mnt);
> + list_for_each_entry_rcu(child, >mnt_mounts, mnt_child) {
> + mp = READ_ONCE(child->mnt_mp);
> + if (child->mnt_parent != m || !mp)
> + continue;
> + if (n-- == 0)
> + goto found;
> + }
> + rcu_read_unlock();
> + return -ENODATA;
> +
> +found:
> + mountpoint.mnt = path->mnt;
> + mountpoint.dentry = READ_ONCE(mp->m_dentry);
> +
> + get_fs_root_rcu(current->fs, );
> + if (root.mnt != path->mnt) {
> + root.mnt = path->mnt;
> + root.dentry = path->mnt->mnt_root;
> + }
> +
> + p = __d_path(, , params->buffer, params->buf_size);
> + rcu_read_unlock();
> +
> + if (IS_ERR(p))
> + return PTR_ERR(p);
> + if (!p)
> + return -EPERM;
> +
> + len = (params->buffer + params->buf_size) - p;
> + memmove(params->buffer, p, len);
> + return len;
> +}
> +#endif /* CONFIG_FSINFO */
> diff --git a/include/uapi/linux/fsinfo.h b/include/uapi/linux/fsinfo.h
> index dae2e8dd757e..7f7a75e9758a 100644
> --- a/include/uapi/linux/fsinfo.h
> +++ b/include/uapi/linux/fsinfo.h
> @@ -32,6 +32,10 @@ enum fsinfo_attribute {
> FSINFO_ATTR_PARAM_ENUM = 14, /* Nth enum-to-val */
> FSINFO_ATTR_PARAMETERS = 15, /* Mount parameters (large
> string) */
> FSINFO_ATTR_LSM_PARAMETERS = 16, /* LSM Mount parameters (large
> string) */
> + FSINFO_ATTR_MOUNT_INFO = 17, /* Mount object information */
> + FSINFO_ATTR_MOUNT_DEVNAME = 18, /* Mount object device name
> (string) */
> + FSINFO_ATTR_MOUNT_CHILDREN = 19, /* Submount list (array) */
> + FSINFO_ATTR_MOUNT_SUBMOUNT = 20, /* Relative path of Nth
> submount (string) */
> FSINFO_ATTR__NR
> };
>
> @@ -268,4 +272,28 @@ struct fsinfo_param_enum {
> charname[252]; /* Name of the enum value */
> };
>
> +/*
> + * Information struct for fsinfo(FSINFO_ATTR_MOUNT_INFO).
> + */
> +struct fsinfo_mount_info {
> + __u64 f_sb_id;/* Superblock ID */
> + __u32 mnt_id; /* Mount identifier (use with
> AT_FSINFO_MOUNTID_PATH) */
> + __u32 parent_id; /* Parent mount identifier */
> + __u32 group_id; /* Mount group ID */
> + __u32 master_id; /* Slave master group ID */
> + __u32 from_id;/* Slave propogated from ID */
> + __u32 attr; /*
Re: [PATCH -next] pwm: pca9685: Remove set but not used variable 'pwm'
Hello Sven,
On Sat, Jun 01, 2019 at 09:03:09AM -0400, Sven Van Asbroeck wrote:
> Hi YueHaibing,
>
> On Fri, May 31, 2019 at 11:49 PM YueHaibing wrote:
> >
> > mutex_lock(>lock);
> > - pwm = >chip.pwms[offset];
> > mutex_unlock(>lock);
>
> Thanks for noticing this issue. However it should be fixed differently.
>
> This was introduced by Uwe's clean-up patch:
> commit e926b12c611c2095c79 ("pwm: Clear chip_data in pwm_put()")
>
> But Uwe did not realize that in this case, the pwm chip_data is used as a
> synchronization mechanism between pwm and gpio. Moving the chip_data
> clear out of the mutex breaks this mechanism.
>
> I think the following would restore the mechanism:
>
> > mutex_lock(>lock);
> >pwm = >chip.pwms[offset];
> > + pwm_set_chip_data(pwm, NULL);
> > mutex_unlock(>lock);
I didn't look into the driver to try to understand that, but the
definitely needs a comment to explain for the next person to think they
can do a cleanup here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: memory leak in sctp_send_reset_streams
On Sat, Jun 01, 2019 at 08:26:15PM +0800, Hillf Danton wrote: > > Hi Hi, > > On Fri, May 31, 2019 at 02:18:06PM -0700, syzbot wrote: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:036e3431 Merge git://git.kernel.org/pub/scm/linux/kernel/g.. > > git tree: upstream > > console output: https://syzkaller.appspot.com/x/log.txt?x=153cff12a0 > > kernel config: https://syzkaller.appspot.com/x/.config?x=8f0f63a62bb5b13c > > dashboard link: https://syzkaller.appspot.com/bug?extid=6ad9c3bd0a218a2ab41d > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12561c86a0 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15b76fd8a0 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+6ad9c3bd0a218a2ab...@syzkaller.appspotmail.com > > > > executing program > > executing program > > executing program > > executing program > > executing program > > BUG: memory leak > > unreferenced object 0x888123894820 (size 32): > >comm "syz-executor045", pid 7267, jiffies 4294943559 (age 13.660s) > >hex dump (first 32 bytes): > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >backtrace: > > [] kmemleak_alloc_recursive > > include/linux/kmemleak.h:55 [inline] > > [ ] slab_post_alloc_hook mm/slab.h:439 [inline] > > [ ] slab_alloc mm/slab.c:3326 [inline] > > [ ] __do_kmalloc mm/slab.c:3658 [inline] > > [ ] __kmalloc+0x161/0x2c0 mm/slab.c:3669 > > [<3250ed8e>] kmalloc_array include/linux/slab.h:670 [inline] > > [<3250ed8e>] kcalloc include/linux/slab.h:681 [inline] > > [<3250ed8e>] sctp_send_reset_streams+0x1ab/0x5a0 > > net/sctp/stream.c:302 > > [ ] sctp_setsockopt_reset_streams > > net/sctp/socket.c:4314 [inline] > > [ ] sctp_setsockopt net/sctp/socket.c:4765 [inline] > > [ ] sctp_setsockopt+0xc23/0x2bf0 > > net/sctp/socket.c:4608 > > [ ] sock_common_setsockopt+0x38/0x50 > > net/core/sock.c:3130 > > [<9eb87ae7>] __sys_setsockopt+0x98/0x120 net/socket.c:2078 > > [ ] __do_sys_setsockopt net/socket.c:2089 [inline] > > [ ] __se_sys_setsockopt net/socket.c:2086 [inline] > > [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 > > [ ] do_syscall_64+0x76/0x1a0 > > arch/x86/entry/common.c:301 > > [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > BUG: memory leak > > unreferenced object 0x888123894980 (size 32): > >comm "syz-executor045", pid 7268, jiffies 4294944145 (age 7.800s) > >hex dump (first 32 bytes): > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >backtrace: > > [ ] kmemleak_alloc_recursive > > include/linux/kmemleak.h:55 [inline] > > [ ] slab_post_alloc_hook mm/slab.h:439 [inline] > > [ ] slab_alloc mm/slab.c:3326 [inline] > > [ ] __do_kmalloc mm/slab.c:3658 [inline] > > [ ] __kmalloc+0x161/0x2c0 mm/slab.c:3669 > > [<3250ed8e>] kmalloc_array include/linux/slab.h:670 [inline] > > [<3250ed8e>] kcalloc include/linux/slab.h:681 [inline] > > [<3250ed8e>] sctp_send_reset_streams+0x1ab/0x5a0 > > net/sctp/stream.c:302 > > [ ] sctp_setsockopt_reset_streams > > net/sctp/socket.c:4314 [inline] > > [ ] sctp_setsockopt net/sctp/socket.c:4765 [inline] > > [ ] sctp_setsockopt+0xc23/0x2bf0 > > net/sctp/socket.c:4608 > > [ ] sock_common_setsockopt+0x38/0x50 > > net/core/sock.c:3130 > > [<9eb87ae7>] __sys_setsockopt+0x98/0x120 net/socket.c:2078 > > [ ] __do_sys_setsockopt net/socket.c:2089 [inline] > > [ ] __se_sys_setsockopt net/socket.c:2086 [inline] > > [ ] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086 > > [ ] do_syscall_64+0x76/0x1a0 > > arch/x86/entry/common.c:301 > > [ ] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > --- > > This bug is generated by a bot. It may contain errors. > > See https://goo.gl/tpsmEJ for more information about syzbot. > > syzbot engineers can be reached at syzkal...@googlegroups.com. > > > > syzbot will keep track of this bug report. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > syzbot can test patches for this bug, for details see:
[PATCH] media: i2c: Fix Unnecessary Semicolon Warning Reported by coccicheck
Removed the warning from the following files: drivers/media/i2c/ov13858.c drivers/media/i2c/ov2685.c drivers/media/i2c/ov5695.c Signed-off-by: Shobhit Kukreti --- drivers/media/i2c/ov13858.c | 4 ++-- drivers/media/i2c/ov2685.c | 2 +- drivers/media/i2c/ov5695.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c index 45bb872..aac6f77 100644 --- a/drivers/media/i2c/ov13858.c +++ b/drivers/media/i2c/ov13858.c @@ -1224,7 +1224,7 @@ static int ov13858_set_ctrl(struct v4l2_ctrl *ctrl) ov13858->exposure->minimum, max, ov13858->exposure->step, max); break; - }; + } /* * Applying V4L2 control value only happens @@ -1262,7 +1262,7 @@ static int ov13858_set_ctrl(struct v4l2_ctrl *ctrl) "ctrl(id:0x%x,val:0x%x) is not handled\n", ctrl->id, ctrl->val); break; - }; + } pm_runtime_put(>dev); diff --git a/drivers/media/i2c/ov2685.c b/drivers/media/i2c/ov2685.c index 98a1f2e3..6814583 100644 --- a/drivers/media/i2c/ov2685.c +++ b/drivers/media/i2c/ov2685.c @@ -576,7 +576,7 @@ static int ov2685_set_ctrl(struct v4l2_ctrl *ctrl) __func__, ctrl->id, ctrl->val); ret = -EINVAL; break; - }; + } pm_runtime_put(>dev); diff --git a/drivers/media/i2c/ov5695.c b/drivers/media/i2c/ov5695.c index 5d107c5..e65a943 100644 --- a/drivers/media/i2c/ov5695.c +++ b/drivers/media/i2c/ov5695.c @@ -1143,7 +1143,7 @@ static int ov5695_set_ctrl(struct v4l2_ctrl *ctrl) dev_warn(>dev, "%s Unhandled id:0x%x, val:0x%x\n", __func__, ctrl->id, ctrl->val); break; - }; + } pm_runtime_put(>dev); -- 2.7.4
Re: [PATCH 4.19 130/276] block: fix use-after-free on gendisk
On 6/1/19 12:27 AM, Pavel Machek wrote:
> Hi!
>
>> +++ b/block/genhd.c
>> @@ -518,6 +518,18 @@ void blk_free_devt(dev_t devt)
>> }
>> }
>>
>> +/**
>> + * We invalidate devt by assigning NULL pointer for devt in idr.
>> + */
>> +void blk_invalidate_devt(dev_t devt)
>> +{
>> +if (MAJOR(devt) == BLOCK_EXT_MAJOR) {
>> +spin_lock_bh(_devt_lock);
>> +idr_replace(_devt_idr, NULL, blk_mangle_minor(MINOR(devt)));
>> +spin_unlock_bh(_devt_lock);
>> +}
>> +}
>> +
>
> AFAICT /** means linuxdoc, but the comment does not have required
> format. Probably should be just /*.
Agreed. A fix has been queued in Jens' tree. See also commit
33c826ef19df ("block: Convert blk_invalidate_devt() header into a
non-kernel-doc header").
Bart.
How to inject fwnode/oftree/acpi data by platform driver ?
Hi folks, I'm looking for a way to inject fwnode data from a platform driver, in order to initialize generic drivers w/ board specific configuration. The idea is getting rid of passing driver specific pdata structs (which, IIRC, seem to be deprecated). An example usecase is the APUv2/3 board, which have things like gpios wired to buttons and LEDs. The board can only be detected via DMI string, no way to probe the platform devices - have to be initialized explicitly (that's how I'm already doing it now). The nicest way, IMHO, would be if I could just write some piece of DTS and some fancy magic all the rest under the hood. Such thing doesn't seem to exist yet. Does it make sense to implement that ? How could we do it ? Which other options do we have ? Or should we just leave everything as it is and stick w/ pdata structs ? thx --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: [RESEND PATCH v4 6/6] leds: lm36274: Introduce the TI LM36274 LED driver
Dan,
On 6/1/19 12:41 AM, Dan Murphy wrote:
Jacek
On 5/31/19 4:57 PM, Jacek Anaszewski wrote:
Dan,
On 5/31/19 11:07 PM, Dan Murphy wrote:
Hello
On 5/31/19 2:44 PM, Jacek Anaszewski wrote:
On 5/31/19 8:23 AM, Lee Jones wrote:
On Thu, 30 May 2019, Jacek Anaszewski wrote:
On 5/30/19 9:38 AM, Lee Jones wrote:
On Wed, 29 May 2019, Jacek Anaszewski wrote:
On 5/29/19 3:58 PM, Lee Jones wrote:
On Fri, 24 May 2019, Jacek Anaszewski wrote:
Hi,
On 5/23/19 9:09 PM, Dan Murphy wrote:
Pavel
Thanks for the review
On 5/23/19 7:50 AM, Pavel Machek wrote:
Hi!
+++ b/drivers/leds/leds-lm36274.c
+static int lm36274_parse_dt(struct lm36274 *lm36274_data)
+{
+ struct fwnode_handle *child = NULL;
+ char label[LED_MAX_NAME_SIZE];
+ struct device *dev = _data->pdev->dev;
+ const char *name;
+ int child_cnt;
+ int ret = -EINVAL;
+
+ /* There should only be 1 node */
+ child_cnt = device_get_child_node_count(dev);
+ if (child_cnt != 1)
+ return ret;
I'd do explicit "return -EINVAL" here.
ACK
+static int lm36274_probe(struct platform_device *pdev)
+{
+ struct ti_lmu *lmu = dev_get_drvdata(pdev->dev.parent);
+ struct lm36274 *lm36274_data;
+ int ret;
+
+ lm36274_data = devm_kzalloc(>dev,
sizeof(*lm36274_data),
+ GFP_KERNEL);
+ if (!lm36274_data) {
+ ret = -ENOMEM;
+ return ret;
+ }
And certainly do "return -ENOMEM" explicitly here.
ACK
Acked-by: Pavel Machek
I've done all amendments requested by Pavel and updated branch
ib-leds-mfd-regulator on linux-leds.git, but in the same time
What do you mean by updated? You cannot update an 'ib' (immutable
branch). Immutable means that it cannot change, by definition.
We have already talked about that. Nobody has pulled so the branch
could have been safely updated.
You have no sure way to know that. And since I have no way to know,
or faith that you won't update it again, pulling it now/at all would
seem like a foolish thing to do.
Sorry, but you are simply unjust. You're pretending to portray the
situation as if I have been notoriously causing merge conflicts in
linux-next which did not take place.
Just to recap what this discussion is about:
On 7 Apr 2019:
1. I sent pull request [0].
2. 45 minutes later I updated it after discovering one omission [1].
It was rather small chance for it to be pulled as quickly as
that.
And even if it happened it wouldn't have been much harmful - we
wouldn't have lost e.g. weeks of testing in linux-next due to
that
fact.
On 21 May 2019:
3. I sent another pull request [2] to you and REGULATOR maintainers.
After it turned out that lack of feedback from REGULATOR
maintainers
was caused by failing to send them the exact copies of patches to
review, I informed you about possible need for updating the
branch.
Afterwards I received a reply from you saying that you hadn't
pulled
the branch anyway. At that point I was sure that neither MFD nor
REGULATOR tree contains the patches. And only after that I
updated
the branch.
Here are 2 examples where you have changed immutable branches, which
is 100% of the Pull Requests I have received from you. Using that
record as a benchmark, the situation hardly seems unjust.
Until you can provide me with an assurance that you will not keep
updating/changing the supposedly immutable pull-requests you send
out,
I won't be pulling any more in.
I can just uphold the assurance which is implicitly assumed for
anyone
who has never broken acclaimed rules. As justified above.
You have broken the rules every (100% of the) time.
Yes, I admit, I would lose in court.
[0] https://lore.kernel.org/patchwork/patch/1059075/
[1] https://lore.kernel.org/patchwork/patch/1059080/
[2] https://lore.kernel.org/patchwork/patch/1077066/
So we have 2 choices moving forward; you can either provide me with
assurance that you have learned from this experience and will never
change an *immutable* branch again, or I can continue to handle them,
which has been the preference for some years.
If you choose the former and adaptions need to be made in the future,
the correct thing to do is create a *new*, different pull-request
which has its own *new*, different tag, but uses the original tag as a
base.
I choose the former. That being said:
Hereby I solemnly declare never ever change an immutable branch again.
So how do I proceed with the requested change by Mark B on the
LM36274 driver.
Do I add a patch on top?
Or do I submit a patch to the regulator tree once the PR is pulled?
Won't the change be a dependency for [PATCH v4 1/6] ?
Yes thats why I am asking as we would need to change the branch.
I will need to send another pull request anyway - I haven't created
new one after updating the branch so far, so for now we are free
to change it.
--
Best regards,
Jacek Anaszewski
[PATCH AUTOSEL 5.1 008/186] drm/pl111: Initialize clock spinlock early
From: Guenter Roeck
[ Upstream commit 3e01ae2612bdd7975c74ec7123d7f8f5e6eed795 ]
The following warning is seen on systems with broken clock divider.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1
Hardware name: ARM Integrator/CP (Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x18)
[] (show_stack) from [] (dump_stack+0x18/0x24)
[] (dump_stack) from [] (register_lock_class+0x674/0x6f8)
[] (register_lock_class) from []
(__lock_acquire+0x68/0x2128)
[] (__lock_acquire) from [] (lock_acquire+0x110/0x21c)
[] (lock_acquire) from [] (_raw_spin_lock+0x34/0x48)
[] (_raw_spin_lock) from []
(pl111_display_enable+0xf8/0x5fc)
[] (pl111_display_enable) from []
(drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock
divider"), the spinlock is not initialized if the clock divider is broken.
Initialize it earlier to fix the problem.
Fixes: eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider")
Cc: Linus Walleij
Signed-off-by: Guenter Roeck
Signed-off-by: Linus Walleij
Link:
https://patchwork.freedesktop.org/patch/msgid/1557758781-23586-1-git-send-email-li...@roeck-us.net
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/pl111/pl111_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 754f6b25f2652..6d9f78612deeb 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -531,14 +531,15 @@ pl111_init_clock_divider(struct drm_device *drm)
dev_err(drm->dev, "CLCD: unable to get clcdclk.\n");
return PTR_ERR(parent);
}
+
+ spin_lock_init(>tim2_lock);
+
/* If the clock divider is broken, use the parent directly */
if (priv->variant->broken_clockdivider) {
priv->clk = parent;
return 0;
}
parent_name = __clk_get_name(parent);
-
- spin_lock_init(>tim2_lock);
div->init =
ret = devm_clk_hw_register(drm->dev, div);
--
2.20.1
[PATCH AUTOSEL 5.1 024/186] thermal: rcar_gen3_thermal: disable interrupt in .remove
From: Jiada Wang
[ Upstream commit 63f55fcea50c25ae5ad45af92d08dae3b84534c2 ]
Currently IRQ remains enabled after .remove, later if device is probed,
IRQ is requested before .thermal_init, this may cause IRQ function be
called before device is initialized.
this patch disables interrupt in .remove, to ensure irq function
only be called after device is fully initialized.
Signed-off-by: Jiada Wang
Reviewed-by: Simon Horman
Reviewed-by: Daniel Lezcano
Signed-off-by: Eduardo Valentin
Signed-off-by: Sasha Levin
---
drivers/thermal/rcar_gen3_thermal.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/rcar_gen3_thermal.c
b/drivers/thermal/rcar_gen3_thermal.c
index 88fa41cf16e83..0c9e7a5bacdf1 100644
--- a/drivers/thermal/rcar_gen3_thermal.c
+++ b/drivers/thermal/rcar_gen3_thermal.c
@@ -331,6 +331,9 @@ MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);
static int rcar_gen3_thermal_remove(struct platform_device *pdev)
{
struct device *dev = >dev;
+ struct rcar_gen3_thermal_priv *priv = dev_get_drvdata(dev);
+
+ rcar_thermal_irq_set(priv, false);
pm_runtime_put(dev);
pm_runtime_disable(dev);
--
2.20.1
[PATCH AUTOSEL 5.1 010/186] ARM: prevent tracing IPI_CPU_BACKTRACE
From: Arnd Bergmann
[ Upstream commit be167862ae7dd85c56d385209a4890678e1b0488 ]
Patch series "compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING", v3.
This patch (of 11):
When function tracing for IPIs is enabled, we get a warning for an
overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as
triggered by raise_nmi():
arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds
[-Werror=array-bounds]
trace_ipi_raise(target, ipi_types[ipinr]);
This is a correct warning as we actually overflow the array here.
This patch raise_nmi() to call __smp_cross_call() instead of
smp_cross_call(), to avoid calling into ftrace. For clarification, I'm
also adding a two new code comments describing how this one is special.
The warning appears to have shown up after commit e7273ff49acf ("ARM:
8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the
number assignment from '15' to '8', but as far as I can tell has existed
since the IPI tracepoints were first introduced. If we decide to
backport this patch to stable kernels, we probably need to backport
e7273ff49acf as well.
[yamada.masah...@socionext.com: rebase on v5.1-rc1]
Link:
http://lkml.kernel.org/r/20190423034959.13525-2-yamada.masah...@socionext.com
Fixes: e7273ff49acf ("ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI")
Fixes: 365ec7b17327 ("ARM: add IPI tracepoints") # v3.17
Signed-off-by: Arnd Bergmann
Signed-off-by: Masahiro Yamada
Cc: Heiko Carstens
Cc: Arnd Bergmann
Cc: Ingo Molnar
Cc: Christophe Leroy
Cc: Mathieu Malaterre
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Ralf Baechle
Cc: Stefan Agner
Cc: Boris Brezillon
Cc: Miquel Raynal
Cc: Richard Weinberger
Cc: David Woodhouse
Cc: Brian Norris
Cc: Marek Vasut
Cc: Russell King
Cc: Borislav Petkov
Cc: Mark Rutland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
arch/arm/include/asm/hardirq.h | 1 +
arch/arm/kernel/smp.c | 6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hardirq.h b/arch/arm/include/asm/hardirq.h
index cba23eaa60721..7a88f160b1fbe 100644
--- a/arch/arm/include/asm/hardirq.h
+++ b/arch/arm/include/asm/hardirq.h
@@ -6,6 +6,7 @@
#include
#include
+/* number of IPIS _not_ including IPI_CPU_BACKTRACE */
#define NR_IPI 7
typedef struct {
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index facd4240ca02c..c93fe0f256deb 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -70,6 +70,10 @@ enum ipi_msg_type {
IPI_CPU_STOP,
IPI_IRQ_WORK,
IPI_COMPLETION,
+ /*
+* CPU_BACKTRACE is special and not included in NR_IPI
+* or tracable with trace_ipi_*
+*/
IPI_CPU_BACKTRACE,
/*
* SGI8-15 can be reserved by secure firmware, and thus may
@@ -797,7 +801,7 @@ core_initcall(register_cpufreq_notifier);
static void raise_nmi(cpumask_t *mask)
{
- smp_cross_call(mask, IPI_CPU_BACKTRACE);
+ __smp_cross_call(mask, IPI_CPU_BACKTRACE);
}
void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool exclude_self)
--
2.20.1
[PATCH AUTOSEL 5.1 007/186] drm/msm: correct attempted NULL pointer dereference in debugfs
From: Brian Masney
[ Upstream commit 90f94660e53189755676543954101de78c26253b ]
msm_gem_describe() would attempt to dereference a NULL pointer via the
address space pointer when no IOMMU is present. Correct this by adding
the appropriate check.
Signed-off-by: Brian Masney
Fixes: 575f0485508b ("drm/msm: Clean up and enhance the output of the 'gem'
debugfs node")
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20190513234105.7531-2-masn...@onstation.org
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 18ca651ab942a..23de4d1b7b1ac 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -805,7 +805,8 @@ void msm_gem_describe(struct drm_gem_object *obj, struct
seq_file *m)
seq_puts(m, " vmas:");
list_for_each_entry(vma, _obj->vmas, list)
- seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
vma->aspace->name,
+ seq_printf(m, " [%s: %08llx,%s,inuse=%d]",
+ vma->aspace != NULL ? vma->aspace->name : NULL,
vma->iova, vma->mapped ? "mapped" : "unmapped",
vma->inuse);
--
2.20.1
[PATCH AUTOSEL 5.1 017/186] mm/compaction.c: fix an undefined behaviour
From: Qian Cai
[ Upstream commit dd7ef7bd14640f11763b54f55131000165f48321 ]
In a low-memory situation, cc->fast_search_fail can keep increasing as it
is unable to find an available page to isolate in
fast_isolate_freepages(). As the result, it could trigger an error below,
so just compare with the maximum bits can be shifted first.
UBSAN: Undefined behaviour in mm/compaction.c:1160:30
shift exponent 64 is too large for 64-bit type 'unsigned long'
CPU: 131 PID: 1308 Comm: kcompactd1 Kdump: loaded Tainted: G
WL5.0.0+ #17
Call trace:
dump_backtrace+0x0/0x450
show_stack+0x20/0x2c
dump_stack+0xc8/0x14c
__ubsan_handle_shift_out_of_bounds+0x7e8/0x8c4
compaction_alloc+0x2344/0x2484
unmap_and_move+0xdc/0x1dbc
migrate_pages+0x274/0x1310
compact_zone+0x26ec/0x43bc
kcompactd+0x15b8/0x1a24
kthread+0x374/0x390
ret_from_fork+0x10/0x18
[a...@linux-foundation.org: code cleanup]
Link: http://lkml.kernel.org/r/20190320203338.53367-1-...@lca.pw
Fixes: 70b44595eafe ("mm, compaction: use free lists to quickly locate a
migration source")
Signed-off-by: Qian Cai
Acked-by: Vlastimil Babka
Acked-by: Mel Gorman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
mm/compaction.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 444029da4e9d8..7b48ac9164a89 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1164,7 +1164,9 @@ static bool suitable_migration_target(struct
compact_control *cc,
static inline unsigned int
freelist_scan_limit(struct compact_control *cc)
{
- return (COMPACT_CLUSTER_MAX >> cc->fast_search_fail) + 1;
+ unsigned short shift = BITS_PER_LONG - 1;
+
+ return (COMPACT_CLUSTER_MAX >> min(shift, cc->fast_search_fail)) + 1;
}
/*
--
2.20.1
[PATCH AUTOSEL 5.1 016/186] initramfs: free initrd memory if opening /initrd.image fails
From: Christoph Hellwig
[ Upstream commit 54c7a8916a887f357088f99e9c3a7720cd57d2c8 ]
Patch series "initramfs tidyups".
I've spent some time chasing down behavior in initramfs and found
plenty of opportunity to improve the code. A first stab on that is
contained in this series.
This patch (of 7):
We free the initrd memory for all successful or error cases except for the
case where opening /initrd.image fails, which looks like an oversight.
Steven said:
: This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled
: - specifically it means that the initrd is freed (previously it was
: ignored and never freed). But that seems like reasonable behaviour and
: the previous behaviour looks like another oversight.
Link: http://lkml.kernel.org/r/20190213174621.29297-3-...@lst.de
Signed-off-by: Christoph Hellwig
Reviewed-by: Steven Price
Acked-by: Mike Rapoport
Cc: Catalin Marinas[arm64]
Cc: Geert Uytterhoeven[m68k]
Cc: Alexander Viro
Cc: Russell King
Cc: Will Deacon
Cc: Guan Xuetao
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
---
init/initramfs.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/init/initramfs.c b/init/initramfs.c
index 4749e1115eef3..c322e1099f435 100644
--- a/init/initramfs.c
+++ b/init/initramfs.c
@@ -612,13 +612,12 @@ static int __init populate_rootfs(void)
printk(KERN_INFO "Trying to unpack rootfs image as
initramfs...\n");
err = unpack_to_rootfs((char *)initrd_start,
initrd_end - initrd_start);
- if (!err) {
- free_initrd();
+ if (!err)
goto done;
- } else {
- clean_rootfs();
- unpack_to_rootfs(__initramfs_start, __initramfs_size);
- }
+
+ clean_rootfs();
+ unpack_to_rootfs(__initramfs_start, __initramfs_size);
+
printk(KERN_INFO "rootfs image is not initramfs (%s)"
"; looks like an initrd\n", err);
fd = ksys_open("/initrd.image",
@@ -632,7 +631,6 @@ static int __init populate_rootfs(void)
written, initrd_end - initrd_start);
ksys_close(fd);
- free_initrd();
}
done:
/* empty statement */;
@@ -642,9 +640,9 @@ static int __init populate_rootfs(void)
initrd_end - initrd_start);
if (err)
printk(KERN_EMERG "Initramfs unpacking failed: %s\n",
err);
- free_initrd();
#endif
}
+ free_initrd();
flush_delayed_fput();
return 0;
}
--
2.20.1
[PATCH AUTOSEL 5.1 026/186] mfd: tps65912-spi: Add missing of table registration
From: Daniel Gomez
[ Upstream commit 9e364e87ad7f2c636276c773d718cda29d62b741 ]
MODULE_DEVICE_TABLE(of, should be called to complete DT
OF mathing mechanism and register it.
Before this patch:
modinfo drivers/mfd/tps65912-spi.ko | grep alias
alias: spi:tps65912
After this patch:
modinfo drivers/mfd/tps65912-spi.ko | grep alias
alias: of:N*T*Cti,tps65912C*
alias: of:N*T*Cti,tps65912
alias: spi:tps65912
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
Signed-off-by: Lee Jones
Signed-off-by: Sasha Levin
---
drivers/mfd/tps65912-spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps65912-spi.c b/drivers/mfd/tps65912-spi.c
index 3bd75061f7776..f78be039e4637 100644
--- a/drivers/mfd/tps65912-spi.c
+++ b/drivers/mfd/tps65912-spi.c
@@ -27,6 +27,7 @@ static const struct of_device_id
tps65912_spi_of_match_table[] = {
{ .compatible = "ti,tps65912", },
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, tps65912_spi_of_match_table);
static int tps65912_spi_probe(struct spi_device *spi)
{
--
2.20.1
[PATCH AUTOSEL 5.1 034/186] objtool: Don't use ignore flag for fake jumps
From: Josh Poimboeuf
[ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ]
The ignore flag is set on fake jumps in order to keep
add_jump_destinations() from setting their jump_dest, since it already
got set when the fake jump was created.
But using the ignore flag is a bit of a hack. It's normally used to
skip validation of an instruction, which doesn't really make sense for
fake jumps.
Also, after the next patch, using the ignore flag for fake jumps can
trigger a false "why am I validating an ignored function?" warning.
Instead just add an explicit check in add_jump_destinations() to skip
fake jumps.
Signed-off-by: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/71abc072ff48b2feccc197723a9c52859476c068.1557766718.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
---
tools/objtool/check.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 2cd57730381b8..ecf5fc77f50b5 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -28,6 +28,8 @@
#include
#include
+#define FAKE_JUMP_OFFSET -1
+
struct alternative {
struct list_head list;
struct instruction *insn;
@@ -501,7 +503,7 @@ static int add_jump_destinations(struct objtool_file *file)
insn->type != INSN_JUMP_UNCONDITIONAL)
continue;
- if (insn->ignore)
+ if (insn->ignore || insn->offset == FAKE_JUMP_OFFSET)
continue;
rela = find_rela_by_dest_range(insn->sec, insn->offset,
@@ -670,10 +672,10 @@ static int handle_group_alt(struct objtool_file *file,
clear_insn_state(_jump->state);
fake_jump->sec = special_alt->new_sec;
- fake_jump->offset = -1;
+ fake_jump->offset = FAKE_JUMP_OFFSET;
fake_jump->type = INSN_JUMP_UNCONDITIONAL;
fake_jump->jump_dest = list_next_entry(last_orig_insn, list);
- fake_jump->ignore = true;
+ fake_jump->func = orig_insn->func;
}
if (!special_alt->new_len) {
--
2.20.1
