Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
On Mon, Aug 07 2017, Dominik Brodowski wrote: > Neil, Shaohua, > > following up on David R's bug message: I have observed something similar > on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare > metal partitions, /dev/sdaX and /dev/sdbY linked together). In case it > matters: Further upwards are cryptsetup, a DM volume group, then logical > volumes, and then filesystems (ext4, but also happened with xfs). > > In a tedious bisect (the bug wasn't as quickly reproducible as I would like, > but happened when I repeatedly created large lvs and filled them with some > content, while compiling kernels in parallel), I was able to track this > down to: > > > commit 4ad23a976413aa57fe5ba7a25953dc35ccca5b71 > Author: NeilBrown > Date: Wed Mar 15 14:05:14 2017 +1100 > > MD: use per-cpu counter for writes_pending > > The 'writes_pending' counter is used to determine when the > array is stable so that it can be marked in the superblock > as "Clean". Consequently it needs to be updated frequently > but only checked for zero occasionally. Recent changes to > raid5 cause the count to be updated even more often - once > per 4K rather than once per bio. This provided > justification for making the updates more efficient. > > ... Thanks for the report... and for bisecting and for re-sending... I believe I have found the problem, and have sent a patch separately. If mddev->safemode == 1 and mddev->in_sync != 0, md_check_recovery() causes the thread that calls it to spin. Prior to the patch you found, that couldn't happen. Now it can, so it needs to be handled more carefully. While I was examining the code, I found another bug - so that is a win! Thanks, NeilBrown signature.asc Description: PGP signature
Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
Ignore me. The increment and decrement of sync_checkers should protect
switch_to_percpu(). Sigh.
Quoting David R :
Quoting Shaohua Li :
Spent some time to check this one, unfortunately I can't find how that patch
makes rcu stall. the percpu part looks good to me too. Can you
double check if
reverting 4ad23a976413aa57 makes the issue go away? When the rcu
stall happens,
what the /sys/block/md/md0/array_state? please also attach
/proc/mdstat. When
you say the mdx_raid1 threads are in 'R' state, can you double check if the
/proc/pid/stack always 0xff?
Thanks,
Shaohua
I confess to knowing absolutely nothing about the md code, so please
don't be too hard on me. However
:-
static bool set_in_sync(struct mddev *mddev)
{
WARN_ON_ONCE(!spin_is_locked(&mddev->lock));
if (!mddev->in_sync) {
mddev->sync_checkers++;
spin_unlock(&mddev->lock);
percpu_ref_switch_to_atomic_sync(&mddev->writes_pending);
spin_lock(&mddev->lock);
if (!mddev->in_sync &&
percpu_ref_is_zero(&mddev->writes_pending)) {
mddev->in_sync = 1;
/*
* Ensure ->in_sync is visible before we clear
* ->sync_checkers.
*/
smp_mb();
set_bit(MD_SB_CHANGE_CLEAN, &mddev->sb_flags);
sysfs_notify_dirent_safe(mddev->sysfs_state);
}
if (--mddev->sync_checkers == 0)
percpu_ref_switch_to_percpu(&mddev->writes_pending);
The switch_to_percpu() takes place under mddev->lock however
switch_to_atomic_sync() does not. A thread can be in the middle of
(or about to execute) switch_to_atomic_sync() at the same time as
another is calling switch_to_percpu(). This can't be correct surely?
Cheers
David
Re: [PATCH v1 5/6] zram: remove zram_rw_page
On (08/08/17 15:50), Minchan Kim wrote: > With on-stack-bio, rw_page interface doesn't provide a clear performance > benefit for zram and surely has a maintenance burden, so remove the > last user to remove rw_page completely. OK, never really liked it, I think we had that conversation before. as far as I remember, zram_rw_page() was the reason we had to do some tricks with init_lock to make lockdep happy. may be now we can "simplify" the things back. > Cc: Sergey Senozhatsky > Signed-off-by: Minchan Kim Reviewed-by: Sergey Senozhatsky -ss
Re: [PATCH v3] xen: get rid of paravirt op adjust_exception_frame
On 07/08/17 22:56, Boris Ostrovsky wrote:
>
>> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
>> index 811e4ddb3f37..a3dcd83187ce 100644
>> --- a/arch/x86/xen/enlighten_pv.c
>> +++ b/arch/x86/xen/enlighten_pv.c
>> @@ -579,6 +579,71 @@ static void xen_write_ldt_entry(struct desc_struct *dt,
>> int entrynum,
>> preempt_enable();
>> }
>>
>> +#ifdef CONFIG_X86_64
>> +static struct {
>> +void (*orig)(void);
>> +void (*xen)(void);
>> +bool ist_okay;
>> +bool handle;
>> +} trap_array[] = {
>> +{ debug, xen_xendebug, true, true },
>> +{ int3, xen_xenint3, true, true },
>> +{ double_fault, xen_double_fault, true, false },
>
> Is it really worth adding 'handle' member to the structure because of a
> single special case? We don't expect to ever have another such vector.
Hmm, maybe you are right. We don't expect to ever see a double_fault in
a pv domain, so we could just drop that special case by handling it like
the other IST traps.
> (TBH, I think current implementation of cvt_gate_to_trap() is clearer,
> even if it is not as general as what is in this patch. I know that Andy
> disagrees).
I think being able to concentrate as much pv interface stuff as possible
to Xen specific sources is a win.
The less Xen modifications are needed in non-Xen sources the better.
Juergen
Re: [[PATCH v1] 02/37] [CIFS] SMBD: Add structure for SMBD transport
Hi Li,
thanks for providing this patchset, I guess it will be a huge win to
have SMBDirect support for the kernel client!
> Define a new structure for SMBD transport. This stucture will have all the
> information on the transport, and it will be stored in the current SMB
> session.
...
> +/*
> + * The context for the SMBDirect transport
> + * Everything related to the transport is here. It has several
logical parts
> + * 1. RDMA related structures
> + * 2. SMBDirect connection parameters
> + * 3. Reassembly queue for data receive path
> + * 4. mempools for allocating packets
> + */
> +struct cifs_rdma_info {
> + struct TCP_Server_Info *server_info;
> +
> + // for debug purposes
> + unsigned int count_receive_buffer;
> + unsigned int count_get_receive_buffer;
> + unsigned int count_put_receive_buffer;
> + unsigned int count_send_empty;
> +};
> +#endif
>
It seems that the new transport is tied to it's caller
regarding structures and naming conventions.
I think it would be better to strictly separate them,
as I'd like to use the SMBDirect transport also from the
userspace for the client side e.g. in Samba's '[lib]smbclient',
but also in Samba's server side code 'smbd'.
Would it be possible to isolate this in
smb_direct.c and smb_direct.h while using
smb_direct_* prefixes for structures and
functions? Also avoiding the usage of other headers
from fs/cifs/*.h, expect for something generic like
nterr.h.
I guess 'struct cifs_rdma_info' would then be
'struct smb_direct_connection'. And it won't
have a reference to struct TCP_Server_Info.
It the strict layering is too much change,
I'd at least like to have the name changes.
This should relatively easy to do by using somthing like
git format-patch --stdout -37 > before
cat before | sed \
-e 's!struct cifs_rdma_info!struct smb_direct_connection!g' \
-e 's!cifsrdma\.h!smb_direct.h!g' \
-e 's!cifsrdma\.c!smb_direct.c!g' \
> after
git reset --hard HEAD~37
git am after
metze
Re: [PATCH v2 00/13] mpt3sas driver NVMe support:
On Tue, Aug 8, 2017 at 9:34 AM, Keith Busch wrote: > On Mon, Aug 07, 2017 at 08:45:25AM -0700, James Bottomley wrote: >> On Mon, 2017-08-07 at 20:01 +0530, Kashyap Desai wrote: >> > >> > We have to attempt this use case and see how it behaves. I have not >> > tried this, so not sure if things are really bad or just some tuning >> > may be helpful. I will revert back to you on this. >> > >> > I understood request as - We need some udev rules to be working well >> > for *same* NVME drives if it is behind or native . >> > Example - If user has OS installed on NVME drive which is behind >> > driver as SCSI disk should be able to boot if he/she hooked >> > same NVME drive which is detected by native driver (and vice >> > versa.) >> >> It's not just the udev rules, it's the tools as well; possibly things >> like that nvme-cli toolkit Intel is doing. > > It looks like they can make existing nvme tooling work with little > effort if they have the driver implement NVME_IOCTL_ADMIN_COMMAND, and Precisely, I was thinking on the same line and you clarified. I will spend sometime on this and get back to you. > then have their driver build the MPI NVMe Encapsulated Request from that. Hi Everyone, Thanks for the discussion and feedback. We have noted this (i.e. will Encapsulate NVME_IOCTL_ADMIN_CMD received from nvme cli in to MPI NVMe Encapsulated Request message and will issue this request to firmware) as our next to-do item and I will post possible options (this may need some discussion with our FW group, so need time to get back with all the details). We will be posting next version of patch set i.e. v3, which will a accommodate below changes suggested by Hannes and Martin over v2 patch set. 1. In the MPI header files, we have reformatted headers to have type and variable on one line as suggested by Hannes, 2. As suggested by Martin, started using blk_queue_virt_boundary() API for NVMe drives and simplified the PRP formation. 3. Removed 'TODO' comments Thanks, Sreekanth
Re: [PATCH] i2c: imx: Remove a useless test in 'i2c_imx_init_recovery_info()'
On Tue, 8 Aug 2017, Christophe JAILLET wrote:
> Le 07/08/2017 à 09:16, Julia Lawall a écrit :
> >
> > On Mon, 7 Aug 2017, Uwe Kleine-König wrote:
> >
> > > On Mon, Aug 07, 2017 at 01:49:53AM +0200, Christophe JAILLET wrote:
> > > > 'devm_pinctrl_get()' never returns NULL, so this test can be simplified.
> > > That's wrong. If CONFIG_PINCTRL is disabled devm_pinctrl_get returns
> > > NULL. But I think this shouldn't be considered an error, so your change
> > > is right, just the commit log is not.
> > >
> > > > diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> > > > index 54a47b40546f..7e84662fe1c0 100644
> > > > --- a/drivers/i2c/busses/i2c-imx.c
> > > > +++ b/drivers/i2c/busses/i2c-imx.c
> > > > @@ -997,7 +997,7 @@ static int i2c_imx_init_recovery_info(struct
> > > > imx_i2c_struct *i2c_imx,
> > > > struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
> > > >
> > > > i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
> > > > - if (!i2c_imx->pinctrl || IS_ERR(i2c_imx->pinctrl)) {
> > > > + if (IS_ERR(i2c_imx->pinctrl)) {
> > > > dev_info(&pdev->dev, "can't get pinctrl, bus recovery
> > > > not supported\n");
> > > > return PTR_ERR(i2c_imx->pinctrl);
> > > > }
> > > Side note: I'm not sure, this construct is valid. IIRC PTR_ERR should
> > > only be called for values x where IS_ERR(x) is true. Here it is at least
> > > surprising that an message hints to a problem but the return code is 0.
> > >
> > > @Julia: I'm sure coccinelle can find more of those?!
> > I only found a few. Christophe, if you want to fix tem up, please go
> > ahead.
>
> Hi Julia,
>
> I've looked quickly at your output, and can't see what could/should be done in
> the spotted cases.
>e100.c: a comment says that 'If it's NULL, then no ucode is required', so,
> the behavior looks ok to me
>chcr_algo.c: function 'create_wr_fn' is passed as a parameter. I've no way
> to make sure of its behavior, so the code could be valid. I won't touch it.
>acl.c: by code inspection, the way the code is written looks valid to me.
> We have NULL if the a call in 'ocfs2_get_acl_nolock' returns -ENODATA. Not
> that strange to return success in this case
>
> So, personally, I won't propose anything on these files. Up to anyone to dig
> further than me.
OK, thanks for looking at them. I do find it odd to exploit PTR_ERR to
return a success value. Maybe I will check with the maintainers in the
uncommented cases.
julia
>
> CJ
> > julia
> >
> > diff -u -p /var/linuxes/linux-next/drivers/net/ethernet/intel/e100.c
> > /tmp/nothing/drivers/net/ethernet/intel/e100.c
> > --- /var/linuxes/linux-next/drivers/net/ethernet/intel/e100.c
> > +++ /tmp/nothing/drivers/net/ethernet/intel/e100.c
> > @@ -1370,8 +1370,6 @@ static inline int e100_load_ucode_wait(s
> >
> > fw = e100_request_firmware(nic);
> > /* If it's NULL, then no ucode is required */
> > - if (!fw || IS_ERR(fw))
> > - return PTR_ERR(fw);
> >
> > if ((err = e100_exec_cb(nic, (void *)fw, e100_setup_ucode)))
> > netif_err(nic, probe, nic->netdev,
> > diff -u -p /var/linuxes/linux-next/drivers/i2c/busses/i2c-imx.c
> > /tmp/nothing/drivers/i2c/busses/i2c-imx.c
> > --- /var/linuxes/linux-next/drivers/i2c/busses/i2c-imx.c
> > +++ /tmp/nothing/drivers/i2c/busses/i2c-imx.c
> > @@ -997,9 +997,7 @@ static int i2c_imx_init_recovery_info(st
> > struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
> >
> > i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
> > - if (!i2c_imx->pinctrl || IS_ERR(i2c_imx->pinctrl)) {
> > dev_info(&pdev->dev, "can't get pinctrl, bus recovery not
> > supported\n");
> > - return PTR_ERR(i2c_imx->pinctrl);
> > }
> >
> > i2c_imx->pinctrl_pins_default =
> > pinctrl_lookup_state(i2c_imx->pinctrl,
> > diff -u -p /var/linuxes/linux-next/drivers/crypto/chelsio/chcr_algo.c
> > /tmp/nothing/drivers/crypto/chelsio/chcr_algo.c
> > --- /var/linuxes/linux-next/drivers/crypto/chelsio/chcr_algo.c
> > +++ /tmp/nothing/drivers/crypto/chelsio/chcr_algo.c
> > @@ -3159,8 +3159,6 @@ static int chcr_aead_op(struct aead_requ
> > skb = create_wr_fn(req, u_ctx->lldi.rxq_ids[ctx->rx_qidx], size,
> > op_type);
> >
> > - if (IS_ERR(skb) || !skb)
> > - return PTR_ERR(skb);
> >
> > skb->dev = u_ctx->lldi.ports[0];
> > set_wr_txq(skb, CPL_PRIORITY_DATA, ctx->tx_qidx);
> > diff -u -p /var/linuxes/linux-next/fs/ocfs2/acl.c
> > /tmp/nothing/fs/ocfs2/acl.c
> > --- /var/linuxes/linux-next/fs/ocfs2/acl.c
> > +++ /tmp/nothing/fs/ocfs2/acl.c
> > @@ -331,8 +331,6 @@ int ocfs2_acl_chmod(struct inode *inode,
> > return 0;
> >
> > acl = ocfs2_get_acl_nolock(inode, ACL_TYPE_ACCESS, bh);
> > - if (IS_ERR(acl) || !acl)
> > - return PTR_ERR(acl);
> > ret = __posix_acl_chm
[PATCH v5] powerpc/mm: Only read faulting instruction when necessary in do_page_fault()
Commit a7a9dcd882a67 ("powerpc: Avoid taking a data miss on every
userspace instruction miss") has shown that limiting the read of
faulting instruction to likely cases improves performance.
This patch goes further into this direction by limiting the read
of the faulting instruction to the only cases where it is definitly
needed.
On an MPC885, with the same benchmark app as in the commit referred
above, we see a reduction of 4000 dTLB misses (approx 3%):
Before the patch:
Performance counter stats for './fault 500' (10 runs):
720495838 cpu-cycles ( +- 0.04% )
141769 dTLB-load-misses( +- 0.02% )
52722 iTLB-load-misses( +- 0.01% )
19611 faults ( +- 0.02% )
5.750535176 seconds time elapsed ( +- 0.16% )
With the patch:
Performance counter stats for './fault 500' (10 runs):
717669123 cpu-cycles ( +- 0.02% )
137344 dTLB-load-misses( +- 0.03% )
52731 iTLB-load-misses( +- 0.01% )
19614 faults ( +- 0.03% )
5.728423115 seconds time elapsed ( +- 0.14% )
The proper work of the huge stack expansion was tested with the
following app:
#include
#include
int main(int argc, char **argv)
{
char buf[1024 * 1025];
sprintf(buf, "Hello world !\n");
printf(buf);
exit(0);
}
Signed-off-by: Christophe Leroy
---
I'm wondering if it really worth it to do something so complex. Is there
really a chance that the
get_user() faults ? It would mean that an instruction that as just been
executed has been in the
meantime swapped out. Is that really a possibility ? I'd expect not, which
would mean that we
could limit it to __get_user_inatomic() and then not implement this complex
unlocking and retry stuff.
v5: Reworked to fit after Benh do_fault improvement and rebased on top of
powerpc/merge (65152902e43fef)
v4: Rebased on top of powerpc/next (f718d426d7e42e) and doing access_ok()
verification before __get_user_xxx()
v3: Do a first try with pagefault disabled before releasing the semaphore
v2: Changes 'if (cond1) if (cond2)' by 'if (cond1 && cond2)'
arch/powerpc/mm/fault.c | 90 +++--
1 file changed, 65 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index f88fac3d281b..7a218f69f956 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -68,26 +68,58 @@ static inline bool notify_page_fault(struct pt_regs *regs)
/*
* Check whether the instruction at regs->nip is a store using
* an update addressing form which will update r1.
+ * If no, returns STACK_EXPANSION_BAD
+ * If yes, returns STACK_EXPANSION_GOOD
+ * In addition, the result is ored with STACK_EXPANSION_UNLOCKED if the
+ * semaphore has been released
*/
-static bool store_updates_sp(struct pt_regs *regs)
+
+#define STACK_EXPANSION_BAD0
+#define STACK_EXPANSION_GOOD 1
+#define STACK_EXPANSION_LOCKED 0
+#define STACK_EXPANSION_UNLOCKED 2
+
+int store_updates_sp(struct pt_regs *regs)
{
unsigned int inst;
+ unsigned int __user *nip = (unsigned int __user *)regs->nip;
+ int ret;
+ int sema = STACK_EXPANSION_LOCKED;
+
+ /*
+* We want to do this outside mmap_sem, because reading code around nip
+* can result in fault, which will cause a deadlock when called with
+* mmap_sem held. However, we do a first try with pagefault disabled as
+* a fault here is very unlikely.
+*/
+ if (!access_ok(VERIFY_READ, nip, sizeof(inst)))
+ return STACK_EXPANSION_BAD | STACK_EXPANSION_LOCKED;
+
+ pagefault_disable();
+ ret = __get_user_inatomic(inst, nip);
+ pagefault_enable();
+ if (ret) {
+ up_read(¤t->mm->mmap_sem);
+ sema = STACK_EXPANSION_UNLOCKED;
+ if (__get_user(inst, nip))
+ return STACK_EXPANSION_BAD | STACK_EXPANSION_UNLOCKED;
+ }
- if (get_user(inst, (unsigned int __user *)regs->nip))
- return false;
/* check for 1 in the rA field */
if (((inst >> 16) & 0x1f) != 1)
- return false;
+ return STACK_EXPANSION_BAD | sema;
+
/* check major opcode */
switch (inst >> 26) {
+ case 62:/* std or stdu */
+ if ((inst & 3) == 0)
+ break;
case 37:/* stwu */
case 39:/* stbu */
case 45:/* sthu */
case 53:/* stfsu */
case 55:/* stfdu */
- return true;
- case 62:/* std or stdu */
- return (inst & 3) == 1;
+ return STACK_EXPANSION_GOOD | sema;
case 31:
/* check minor opcode */
Re: [PATCH v2 3/3] ARM: dts: at91: sama5d2: use sama5d2 compatible string for SMC
On Mon, 07 Aug 2017, Alexandre Belloni wrote:
> Hi Lee,
>
> On 07/08/2017 at 16:41:00 +0100, Lee Jones wrote:
> > On Tue, 18 Jul 2017, Ludovic Desroches wrote:
> >
> > > A new compatible string has been introduced for sama5d2 SMC to allow to
> > > manage the registers mapping change.
> > >
> > > Signed-off-by: Ludovic Desroches
> > > ---
> > > arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Applied, thanks.
> >
>
> I've already applied that one and sent it to arm-soc as a fix for 4.13
> (I think we agreed on that).
Okay, I just looked through my mail and remember the conversation.
So the question remains; why was the patch re-sent as part of this
set *after* it had already been applied?
Patch unapplied, thanks.
> > > diff --git a/arch/arm/boot/dts/sama5d2.dtsi
> > > b/arch/arm/boot/dts/sama5d2.dtsi
> > > index cc06da394366..3e6e2dbc2595 100644
> > > --- a/arch/arm/boot/dts/sama5d2.dtsi
> > > +++ b/arch/arm/boot/dts/sama5d2.dtsi
> > > @@ -1048,7 +1048,7 @@
> > > };
> > >
> > > hsmc: hsmc@f8014000 {
> > > - compatible = "atmel,sama5d3-smc", "syscon",
> > > "simple-mfd";
> > > + compatible = "atmel,sama5d2-smc", "syscon",
> > > "simple-mfd";
> > > reg = <0xf8014000 0x1000>;
> > > interrupts = <5 IRQ_TYPE_LEVEL_HIGH 6>;
> > > clocks = <&hsmc_clk>;
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
On Tue, Aug 08 2017, David R wrote:
> Quoting Shaohua Li :
>
>> Spent some time to check this one, unfortunately I can't find how that patch
>> makes rcu stall. the percpu part looks good to me too. Can you
>> double check if
>> reverting 4ad23a976413aa57 makes the issue go away? When the rcu
>> stall happens,
>> what the /sys/block/md/md0/array_state? please also attach /proc/mdstat. When
>> you say the mdx_raid1 threads are in 'R' state, can you double check if the
>> /proc/pid/stack always 0xff?
>>
>> Thanks,
>> Shaohua
>
> I confess to knowing absolutely nothing about the md code, so please
> don't be too hard on me. However
> :-
>
> static bool set_in_sync(struct mddev *mddev)
> {
> WARN_ON_ONCE(!spin_is_locked(&mddev->lock));
> if (!mddev->in_sync) {
> mddev->sync_checkers++;
> spin_unlock(&mddev->lock);
> percpu_ref_switch_to_atomic_sync(&mddev->writes_pending);
> spin_lock(&mddev->lock);
> if (!mddev->in_sync &&
> percpu_ref_is_zero(&mddev->writes_pending)) {
> mddev->in_sync = 1;
> /*
> * Ensure ->in_sync is visible before we clear
> * ->sync_checkers.
> */
> smp_mb();
> set_bit(MD_SB_CHANGE_CLEAN, &mddev->sb_flags);
> sysfs_notify_dirent_safe(mddev->sysfs_state);
> }
> if (--mddev->sync_checkers == 0)
> percpu_ref_switch_to_percpu(&mddev->writes_pending);
>
>
> The switch_to_percpu() takes place under mddev->lock however
> switch_to_atomic_sync() does not. A thread can be in the middle of (or
> about to execute) switch_to_atomic_sync() at the same time as another
> is calling switch_to_percpu(). This can't be correct surely?
No, that wouldn't be correct.
When switch_to_atomic_sync is called, ->sync_checkers > 0.
When switch_to_percpu is called ->sync_checkers == 0.
So they cannot happen at the same time.
Thanks for looking at the code!
NeilBrown
>
> Cheers
> David
signature.asc
Description: PGP signature
[PATCH v2] mmc: sunxi: fix support for new timings mode only SoCs
The A83T MMC support code introduces the timings mode switch, however
such a switch doesn't exist on new SoCs with only new timings mode.
Only execute the switch if the SoC really have the timings mode switch,
to fix the regression shown on new timings mode only SoCs (A64, H5,
etc).
Fixes: b0600daebf31 ("mmc: sunxi: Support controllers that can use
both old and new timings")
Signed-off-by: Icenowy Zheng
Reviewed-by: Chen-Yu Tsai
---
Changes in v2:
- Slightly adjusted the format of the Fixes: line/
- Added review tag from Chen-Yu.
drivers/mmc/host/sunxi-mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 020547e5fa45..7447d41833ee 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -789,7 +789,7 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host
*host,
clock <<= 1;
}
- if (host->use_new_timings) {
+ if (host->use_new_timings && host->cfg->has_timings_switch) {
ret = sunxi_ccu_set_mmc_timing_mode(host->clk_mmc, true);
if (ret) {
dev_err(mmc_dev(mmc),
--
2.13.0
Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
Shaouhua, ( really CC'ing Tejun now ) On Mon, Aug 07, 2017 at 09:51:03PM -0700, Shaohua Li wrote: > On Mon, Aug 07, 2017 at 01:20:25PM +0200, Dominik Brodowski wrote: > > Neil, Shaohua, > > > > following up on David R's bug message: I have observed something similar > > on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare > > metal partitions, /dev/sdaX and /dev/sdbY linked together). In case it > > matters: Further upwards are cryptsetup, a DM volume group, then logical > > volumes, and then filesystems (ext4, but also happened with xfs). > > > > In a tedious bisect (the bug wasn't as quickly reproducible as I would like, > > but happened when I repeatedly created large lvs and filled them with some > > content, while compiling kernels in parallel), I was able to track this > > down to: > > > > > > commit 4ad23a976413aa57fe5ba7a25953dc35ccca5b71 > > Author: NeilBrown > > Date: Wed Mar 15 14:05:14 2017 +1100 > > > > MD: use per-cpu counter for writes_pending > > > > The 'writes_pending' counter is used to determine when the > > array is stable so that it can be marked in the superblock > > as "Clean". Consequently it needs to be updated frequently > > but only checked for zero occasionally. Recent changes to > > raid5 cause the count to be updated even more often - once > > per 4K rather than once per bio. This provided > > justification for making the updates more efficient. > > > > ... > > > > > > CC'ing t...@kernel.org, as 4ad23a976413 is the first (and only?) user > > of percpu_ref_switch_to_atomic_sync() introduced in 210f7cdcf088. > > > > Applying a415c0f10627 on top of 4ad23a976413 does *not* fix the issue, but > > reverting all of a2bfc6753065, a415c0f10627 and 4ad23a976413 seems to fix > > the issue for v4.12.5. > > Spent some time to check this one, Thanks for taking a look at this issue! > unfortunately I can't find how that patch makes rcu stall. the percpu part > looks good to me too. Can you double check if reverting 4ad23a976413aa57 > makes the issue go away? v4.12.5 with the three patches reverted survived many hours of testing yesterday. Rebooted into 4ad23a976413aa57 (rebuilt with lockup detection), and got back traces for mdX_raid1 after a few minutes. The following test was done with plain v4.12.5, with the first stall after around ~1 minute: > When the rcu stall happens, what the /sys/block/md/md0/array_state? First, a "ps axf | grep 'md'" snippet: 498 ?S< 0:00 \_ [md] 1163 ?D 0:01 \_ [md0_raid1] 1172 ?D 0:07 \_ [md1_raid1] 1182 ?D 0:00 \_ [md2_raid1] 1192 ?R 1:35 \_ [md3_raid1] (why are md[012]_raid1 continuously in "D" state?) array_state for md0: active array_state for md1: active-idle array_state for md2: active-idle array_state for md3: clean > please also attach /proc/mdstat. Personalities : [raid1] md3 : active raid1 sda8[0] sdb5[1] 174981120 blocks super 1.2 [2/2] [UU] bitmap: 0/2 pages [0KB], 65536KB chunk md2 : active raid1 sda7[0] sdb6[1] 174981120 blocks super 1.2 [2/2] [UU] bitmap: 1/2 pages [4KB], 65536KB chunk md1 : active raid1 sda6[0] sdb7[1] 174981120 blocks super 1.2 [2/2] [UU] bitmap: 2/2 pages [8KB], 65536KB chunk md0 : active raid1 sda5[0] sdb8[1] 174981120 blocks super 1.2 [2/2] [UU] bitmap: 1/2 pages [4KB], 65536KB chunk unused devices: > When you say the mdx_raid1 threads are in 'R' state, can you double check > if the /proc/pid/stack always 0xff? root@i3test ~ # cat /proc/1192/stack # md3_raid1 [] 0x root@i3test ~ # cat /proc/1182/stack [] percpu_ref_switch_to_atomic_sync+0x3f/0x80 [] set_in_sync+0x68/0xe0 [] md_check_recovery+0x284/0x4c0 [] raid1d+0x4c/0x910 [] md_thread+0x12d/0x160 [] kthread+0x131/0x170 [] ret_from_fork+0x27/0x40 [] 0x root@i3test ~ # cat /proc/1172/stack [] percpu_ref_switch_to_atomic_sync+0x3f/0x80 [] set_in_sync+0x68/0xe0 [] md_check_recovery+0x284/0x4c0 [] raid1d+0x4c/0x910 [] md_thread+0x12d/0x160 [] kthread+0x131/0x170 [] ret_from_fork+0x27/0x40 [] 0x root@i3test ~ # cat /proc/1163/stack [] percpu_ref_switch_to_atomic_sync+0x3f/0x80 [] set_in_sync+0x68/0xe0 [] md_check_recovery+0x284/0x4c0 [] raid1d+0x4c/0x910 [] md_thread+0x12d/0x160 [] kthread+0x131/0x170 [] ret_from_fork+0x27/0x40 [] 0x So the other md[012]_raid1 threads are waiting in percpu_ref_switch_to_atomic_sync(). And md3_raid1 is, (according to NMI watchdog: BUG: soft lockup - CPU#4 stuck for 23s! [md3_raid1:1192], stuck somewhere in raid1d... [ 92.564717] task: 880234442e80 task.stack: c9000102c000 [ 92.564781] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50 [ 92.564843] RSP: 0018:c9000102fdb0 EFLAGS: 0246 ORIG_RAX: ff10 [ 92.564913] RAX: RBX: 0246 RCX: 8802321a1e00 [ 92.564995] RDX: 815cca08 RSI: 00
[PATCH v3 3/9] clk: rockchip: fix up the indentation stuff for RV1108 SoC
Make the code look better. Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/rv1108-cru.h | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/include/dt-bindings/clock/rv1108-cru.h b/include/dt-bindings/clock/rv1108-cru.h index e8aa6d56990a..f269d833e41a 100644 --- a/include/dt-bindings/clock/rv1108-cru.h +++ b/include/dt-bindings/clock/rv1108-cru.h @@ -173,16 +173,16 @@ #define CLK_NR_CLKS(HCLK_VPU + 1) /* reset id */ -#define SRST_CORE_PO_AD0 +#define SRST_CORE_PO_AD0 #define SRST_CORE_AD 1 #define SRST_L2_AD 2 -#define SRST_CPU_NIU_AD3 +#define SRST_CPU_NIU_AD3 #define SRST_CORE_PO 4 #define SRST_CORE 5 -#define SRST_L26 +#define SRST_L26 #define SRST_CORE_DBG 8 #define PRST_DBG 9 -#define RST_DAP10 +#define RST_DAP10 #define PRST_DBG_NIU 11 #define ARST_STRC_SYS_AD 15 @@ -249,9 +249,9 @@ #define HRST_SYSBUS75 #define PRST_USBGRF76 -#define ARST_PERIPH_NIU80 -#define HRST_PERIPH_NIU81 -#define PRST_PERIPH_NIU82 +#define ARST_PERIPH_NIU80 +#define HRST_PERIPH_NIU81 +#define PRST_PERIPH_NIU82 #define HRST_PERIPH83 #define HRST_SDMMC 84 #define HRST_SDIO 85 @@ -269,7 +269,7 @@ #define HRST_HOST0_AUX 96 #define HRST_HOST0_ARB 97 #define SRST_HOST0_EHCIPHY 98 -#define SRST_HOST0_UTMI99 +#define SRST_HOST0_UTMI99 #define SRST_USBPOR100 #define SRST_UTMI0 101 #define SRST_UTMI1 102 @@ -316,21 +316,21 @@ #define HRST_VPU_NIU 141 #define ARST_VPU 142 #define HRST_VPU 143 -#define ARST_RKVDEC_NIU144 -#define HRST_RKVDEC_NIU145 +#define ARST_RKVDEC_NIU144 +#define HRST_RKVDEC_NIU145 #define ARST_RKVDEC146 #define HRST_RKVDEC147 #define SRST_RKVDEC_CABAC 148 #define SRST_RKVDEC_CORE 149 -#define ARST_RKVENC_NIU150 -#define HRST_RKVENC_NIU151 +#define ARST_RKVENC_NIU150 +#define HRST_RKVENC_NIU151 #define ARST_RKVENC152 #define HRST_RKVENC153 #define SRST_RKVENC_CORE 154 #define SRST_DSP_CORE 156 #define SRST_DSP_SYS 157 -#define SRST_DSP_GLOBAL158 +#define SRST_DSP_GLOBAL158 #define SRST_DSP_OECM 159 #define PRST_DSP_IOP_NIU 160 #define ARST_DSP_EPP_NIU 161 @@ -348,7 +348,7 @@ #define SRST_PMU_I2C0 173 #define PRST_PMU_I2C0 174 #define PRST_PMU_GPIO0 175 -#define PRST_PMU_INTMEM176 +#define PRST_PMU_INTMEM176 #define PRST_PMU_PWM0 177 #define SRST_PMU_PWM0 178 #define PRST_PMU_GRF 179 -- 1.9.1
Re: [PATCH v2] drm: bridge: synopsys/dw-hdmi: Provide default configuration function for HDMI 2.0 PHY
On 2017年07月07日 23:47, Jose Abreu wrote:
Hi Archit,
Ping, Any update for this patch? Can it be landed?
This patch actually needed for rk3399 hdmi support
Best Regards
Mark
On 23-06-2017 10:36, Jose Abreu wrote:
Currently HDMI 2.0 PHYs do not have a default configuration function.
As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D
PHYs we can provide the same default configuration function for both
and still let user overwrite this with custom configuration function
if needed.
If, for some reason, the PHY is custom or has a register different
register layout then custom configuration function *must* be provided
in order for the system to work correctly. As we prefer the pdata
provided configuration function over the internal one this change
will not make any impact in custom platforms.
This patch is based on today's drm-misc-next branch.
Signed-off-by: Jose Abreu
Tested-by: Mark Yao
This is needed for RK3399 support. Can you please apply it?
Best regards,
Jose Miguel Abreu
Cc: Kieran Bingham
Cc: Laurent Pinchart
Cc: Archit Taneja
Cc: Andrzej Hajda
Cc: Mark Yao
Cc: Carlos Palminha
Cc: Heiko Stübner
Changes in v2:
- Rebased and refrased commit message
---
Hi All,
There as been a little confusion about dw-hdmi phys so I will expand a little
bit
here so that I can base my decision about this patch and why does it only works
in some platforms.
First, if you read dw-hdmi.c code, you will see that there is an identification
register for the phy type being used. Unfortunatelly, this only states the phy
type
and not the phy version.
Second, we have many HDMI 2.0 phys (so, same phy type: 0xf3) but, as you may
have guessed,
HW team decided to change regbank between some versions.
Third and last, each phy in a SoC has unique characteristics, so each phy
(event if
they are the same version) will have different PLL configuration parameters.
Given all this I managed to conclude that Mark's phy is still an HDMI 2.0 phy
but with
the same register layout as previous 3D PHY's. I found at least 2 phys with the
same
register layout and only 1 phy which has a different layout, so I think
majority wins
here and we should let the default configuration function for HDMI 2.0 phys be
the same
one as the 3D.
Short story: There is no way to correctly identify, at runtime, the phy version
being
used by the controller so we can't provide a default configuration function. We
can,
however assume that most of the HDMI 2.0 phys will have the 3D layout BUT each
developer
must confirm that the layout in its SoC is the expected one and if not, provide
a custom
configuration function.
Best regards,
Jose Miguel Abreu
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index ead1124..10c8d8c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2170,6 +2170,7 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
.name = "DWC HDMI 2.0 TX PHY",
.gen = 2,
.has_svsret = true,
+ .configure = hdmi_phy_configure_dwc_hdmi_3d_tx,
}, {
.type = DW_HDMI_PHY_VENDOR_PHY,
.name = "Vendor PHY",
[PATCH v3 1/9] clk: rockchip: add more clk ids for rv1108
add new clk ids. Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/rv1108-cru.h | 93 +- 1 file changed, 92 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/rv1108-cru.h b/include/dt-bindings/clock/rv1108-cru.h index ae26f8105914..fe013cf51e2b 100644 --- a/include/dt-bindings/clock/rv1108-cru.h +++ b/include/dt-bindings/clock/rv1108-cru.h @@ -43,12 +43,73 @@ #define SCLK_SDMMC_SAMPLE 84 #define SCLK_SDIO_SAMPLE 85 #define SCLK_EMMC_SAMPLE 86 +#define SCLK_VENC_CORE 87 +#define SCLK_HEVC_CORE 88 +#define SCLK_HEVC_CABAC89 +#define SCLK_PWM0_PMU 90 +#define SCLK_I2C0_PMU 91 +#define SCLK_WIFI 92 +#define SCLK_CIFOUT93 +#define SCLK_MIPI_CSI_OUT 94 +#define SCLK_CIF0 95 +#define SCLK_CIF1 96 +#define SCLK_CIF2 97 +#define SCLK_CIF3 98 +#define SCLK_DSP 99 +#define SCLK_DSP_IOP 100 +#define SCLK_DSP_EPP 101 +#define SCLK_DSP_EDP 102 +#define SCLK_DSP_EDAP 103 +#define SCLK_CVBS_HOST 104 +#define SCLK_HDMI_SFR 105 +#define SCLK_HDMI_CEC 106 +#define SCLK_CRYPTO107 +#define SCLK_SPI 108 +#define SCLK_SARADC109 +#define SCLK_TSADC 110 +#define SCLK_MACPHY_PRE111 +#define SCLK_MACPHY112 +#define SCLK_MACPHY_RX 113 +#define SCLK_MAC_REF 114 +#define SCLK_MAC_REFOUT115 +#define SCLK_DSP_PFM 116 +#define SCLK_RGA 117 +#define SCLK_I2C1 118 +#define SCLK_I2C2 119 +#define SCLK_I2C3 120 +#define SCLK_PWM 121 +#define SCLK_ISP 122 +#define SCLK_USBPHY123 +#define SCLK_I2S0_SRC 124 +#define SCLK_I2S1_SRC 125 +#define SCLK_I2S2_SRC 126 +#define SCLK_UART0_SRC 127 +#define SCLK_UART1_SRC 128 +#define SCLK_UART2_SRC 129 + +#define DCLK_VOP_SRC 185 +#define DCLK_HDMIPHY 186 +#define DCLK_VOP 187 /* aclk gates */ #define ACLK_DMAC 192 #define ACLK_PRE 193 #define ACLK_CORE 194 #define ACLK_ENMCORE 195 +#define ACLK_RKVENC196 +#define ACLK_RKVDEC197 +#define ACLK_VPU 198 +#define ACLK_CIF0 199 +#define ACLK_VIO0 200 +#define ACLK_VIO1 201 +#define ACLK_VOP 202 +#define ACLK_IEP 203 +#define ACLK_RGA 204 +#define ACLK_ISP 205 +#define ACLK_CIF1 206 +#define ACLK_CIF2 207 +#define ACLK_CIF3 208 +#define ACLK_PERI 209 /* pclk gates */ #define PCLK_GPIO1 256 @@ -67,6 +128,19 @@ #define PCLK_PWM 269 #define PCLK_TIMER 270 #define PCLK_PERI 271 +#define PCLK_GPIO0_PMU 272 +#define PCLK_I2C0_PMU 273 +#define PCLK_PWM0_PMU 274 +#define PCLK_ISP 275 +#define PCLK_VIO 276 +#define PCLK_MIPI_DSI 277 +#define PCLK_HDMI_CTRL 278 +#define PCLK_SARADC279 +#define PCLK_DSP_CFG 280 +#define PCLK_BUS 281 +#define PCLK_EFUSE0282 +#define PCLK_EFUSE1283 +#define PCLK_WDT 284 /* hclk gates */ #define HCLK_I2S0_8CH 320 @@ -78,8 +152,25 @@ #define HCLK_EMMC 326 #define HCLK_PERI 327 #define HCLK_SFC 328 +#define HCLK_RKVENC329 +#define HCLK_RKVDEC330 +#define HCLK_CIF0 331 +#define HCLK_VIO 332 +#define HCLK_VOP 333 +#define HCLK_IEP 334 +#define HCLK_RGA 335 +#define HCLK_ISP 336 +#define HCLK_CRYPTO_MST337 +#define HCLK_CRYPTO_SLV338 +#define HCLK_HOST0 339 +#define HCLK_OTG 340 +#define HCLK_CIF1 341 +#de
[PATCH v3 4/9] clk: rockchip: support more rates for cpuclk
fix up the cpuclk rates table for support more freqs.
fix up the mux_core_mask describe error.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index 7c05ab366348..3c670db16e18 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -93,9 +93,24 @@ enum rv1108_plls {
}
static struct rockchip_cpuclk_rate_table rv1108_cpuclk_rates[] __initdata = {
- RV1108_CPUCLK_RATE(81600, 4),
- RV1108_CPUCLK_RATE(6, 4),
- RV1108_CPUCLK_RATE(31200, 4),
+ RV1108_CPUCLK_RATE(160800, 7),
+ RV1108_CPUCLK_RATE(151200, 7),
+ RV1108_CPUCLK_RATE(148800, 5),
+ RV1108_CPUCLK_RATE(141600, 5),
+ RV1108_CPUCLK_RATE(139200, 5),
+ RV1108_CPUCLK_RATE(129600, 5),
+ RV1108_CPUCLK_RATE(12, 5),
+ RV1108_CPUCLK_RATE(110400, 5),
+ RV1108_CPUCLK_RATE(100800, 5),
+ RV1108_CPUCLK_RATE(91200, 5),
+ RV1108_CPUCLK_RATE(81600, 3),
+ RV1108_CPUCLK_RATE(69600, 3),
+ RV1108_CPUCLK_RATE(6, 3),
+ RV1108_CPUCLK_RATE(5, 3),
+ RV1108_CPUCLK_RATE(40800, 1),
+ RV1108_CPUCLK_RATE(31200, 1),
+ RV1108_CPUCLK_RATE(21600, 1),
+ RV1108_CPUCLK_RATE(9600, 1),
};
static const struct rockchip_cpuclk_reg_data rv1108_cpuclk_data = {
@@ -105,7 +120,7 @@ enum rv1108_plls {
.mux_core_alt = 1,
.mux_core_main = 0,
.mux_core_shift = 8,
- .mux_core_mask = 0x1,
+ .mux_core_mask = 0x3,
};
PNAME(mux_pll_p) = { "xin24m", "xin24m"};
--
1.9.1
[PATCH v3 2/9] clk: rockchip: rename the clk id for HCLK_I2S1_2CH
i2s1 has 2 channels but not 8 channels. Signed-off-by: Elaine Zhang --- include/dt-bindings/clock/rv1108-cru.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/rv1108-cru.h b/include/dt-bindings/clock/rv1108-cru.h index fe013cf51e2b..e8aa6d56990a 100644 --- a/include/dt-bindings/clock/rv1108-cru.h +++ b/include/dt-bindings/clock/rv1108-cru.h @@ -144,7 +144,7 @@ /* hclk gates */ #define HCLK_I2S0_8CH 320 -#define HCLK_I2S1_8CH 321 +#define HCLK_I2S1_2CH 321 #define HCLK_I2S2_2CH 322 #define HCLK_NANDC 323 #define HCLK_SDMMC 324 -- 1.9.1
[PATCH v3 0/9] clk: rockchip: support clk for RV1108 Soc
RV1108 submit is too much, make the CLK part out to review alone. Changes in v3: [PATCH v3 1/9] None [PATCH v3 2/9] None [PATCH v3 3/9] None [PATCH v3 4/9] None [PATCH v3 5/9] None [PATCH v3 6/9] fix up the structure patch-contents [PATCH v3 7/9] fix up the structure patch-contents [PATCH v3 8/9] fix up the structure patch-contents [PATCH v3 8/9] None Changes in v2: [PATCH v2 1/9] split the rename and intentation fix part [PATCH v2 2/9] None [PATCH v2 3/9] None [PATCH v2 4/9] split the new added clks and rename. [PATCH v2 5/9] None [PATCH v2 6/9] None [PATCH v2 7/9] None [PATCH v2 8/9] None [PATCH v3 9/9] None Elaine Zhang (9): clk: rockchip: add more clk ids for rv1108 clk: rockchip: rename the clk id for HCLK_I2S1_2CH clk: rockchip: fix up the indentation stuff for RV1108 SoC clk: rockchip: support more rates for cpuclk clk: rockchip: fix up the pll clks error for rv1108 SoC clk: rockchip: support more clks for rv1108 clk: rockchip: fix up some clks describe error for rv1108 SoC clk: rockchip: rename some of clks for rv1108 SoC clk: rockchip: add some critical clocks for rv1108 SoC drivers/clk/rockchip/clk-rv1108.c | 476 +++-- include/dt-bindings/clock/rv1108-cru.h | 123 +++-- 2 files changed, 494 insertions(+), 105 deletions(-) -- 1.9.1
[PATCH v3 5/9] clk: rockchip: fix up the pll clks error for rv1108 SoC
fix up the lock_shift describe error.
remove the ROCKCHIP_PLL_SYNC_RATE flag for gpll.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index 3c670db16e18..9c6bad0da140 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -148,11 +148,11 @@ enum rv1108_plls {
static struct rockchip_pll_clock rv1108_pll_clks[] __initdata = {
[apll] = PLL(pll_rk3399, PLL_APLL, "apll", mux_pll_p, 0,
RV1108_PLL_CON(0),
-RV1108_PLL_CON(3), 8, 31, 0, rv1108_pll_rates),
+RV1108_PLL_CON(3), 8, 0, 0, rv1108_pll_rates),
[dpll] = PLL(pll_rk3399, PLL_DPLL, "dpll", mux_pll_p, 0,
RV1108_PLL_CON(8),
-RV1108_PLL_CON(11), 8, 31, 0, NULL),
+RV1108_PLL_CON(11), 8, 1, 0, NULL),
[gpll] = PLL(pll_rk3399, PLL_GPLL, "gpll", mux_pll_p, 0,
RV1108_PLL_CON(16),
-RV1108_PLL_CON(19), 8, 31, ROCKCHIP_PLL_SYNC_RATE,
rv1108_pll_rates),
+RV1108_PLL_CON(19), 8, 2, 0, rv1108_pll_rates),
};
#define MFLAGS CLK_MUX_HIWORD_MASK
--
1.9.1
[PATCH v3 7/9] clk: rockchip: fix up some clks describe error for rv1108 SoC
1. fix up the parent name
2. remove the CLK_IGNORE_UNUSED flag for some clk not need to always on.
3. fix up some clks regs describe error.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 122 --
1 file changed, 63 insertions(+), 59 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index 5cb7699305f5..829beef82cff 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -129,22 +129,22 @@ enum rv1108_plls {
PNAME(mux_usb480m_pre_p) = { "usbphy", "xin24m" };
PNAME(mux_hdmiphy_phy_p) = { "hdmiphy", "xin24m" };
PNAME(mux_dclk_hdmiphy_pre_p) = { "dclk_hdmiphy_src_gpll",
"dclk_hdmiphy_src_dpll" };
-PNAME(mux_pll_src_4plls_p) = { "dpll", "hdmiphy", "gpll", "usb480m" };
+PNAME(mux_pll_src_4plls_p) = { "dpll", "gpll", "hdmiphy", "usb480m" };
PNAME(mux_pll_src_3plls_p) = { "apll", "gpll", "dpll" };
PNAME(mux_pll_src_2plls_p) = { "dpll", "gpll" };
PNAME(mux_pll_src_apll_gpll_p) = { "apll", "gpll" };
-PNAME(mux_aclk_peri_src_p) = { "aclk_peri_src_dpll", "aclk_peri_src_gpll"
};
+PNAME(mux_aclk_peri_src_p) = { "aclk_peri_src_gpll", "aclk_peri_src_dpll"
};
PNAME(mux_aclk_bus_src_p) = { "aclk_bus_src_gpll", "aclk_bus_src_apll",
"aclk_bus_src_dpll" };
PNAME(mux_mmc_src_p) = { "dpll", "gpll", "xin24m", "usb480m" };
PNAME(mux_pll_src_dpll_gpll_usb480m_p) = { "dpll", "gpll", "usb480m" };
PNAME(mux_uart0_p) = { "uart0_src", "uart0_frac", "xin24m" };
PNAME(mux_uart1_p) = { "uart1_src", "uart1_frac", "xin24m" };
PNAME(mux_uart2_p) = { "uart2_src", "uart2_frac", "xin24m" };
-PNAME(mux_sclk_macphy_p) = { "sclk_macphy_pre", "ext_gmac" };
+PNAME(mux_sclk_macphy_p) = { "ext_gmac", "sclk_macphy_pre" };
PNAME(mux_i2s0_pre_p) = { "i2s0_src", "i2s0_frac", "ext_i2s",
"xin12m" };
PNAME(mux_i2s_out_p) = { "i2s0_pre", "xin12m" };
-PNAME(mux_i2s1_p) = { "i2s1_src", "i2s1_frac", "xin12m" };
-PNAME(mux_i2s2_p) = { "i2s2_src", "i2s2_frac", "xin12m" };
+PNAME(mux_i2s1_p) = { "i2s1_src", "i2s1_frac", "dummy", "xin12m"
};
+PNAME(mux_i2s2_p) = { "i2s2_src", "i2s2_frac", "dummy", "xin12m"
};
PNAME(mux_wifi_src_p) = { "gpll", "xin24m" };
PNAME(mux_cifout_src_p)= { "hdmiphy", "gpll" };
PNAME(mux_cifout_p)= { "sclk_cifout_src", "xin24m" };
@@ -197,10 +197,10 @@ enum rv1108_plls {
RV1108_CLKSEL_CON(7), 12, 2, MFLAGS);
static struct rockchip_clk_branch rv1108_clk_branches[] __initdata = {
- MUX(0, "hdmi_phy", mux_hdmiphy_phy_p, CLK_SET_RATE_PARENT,
- RV1108_MISC_CON, 13, 2, MFLAGS),
+ MUX(0, "hdmiphy", mux_hdmiphy_phy_p, CLK_SET_RATE_PARENT,
+ RV1108_MISC_CON, 13, 1, MFLAGS),
MUX(0, "usb480m", mux_usb480m_pre_p, CLK_SET_RATE_PARENT,
- RV1108_MISC_CON, 15, 2, MFLAGS),
+ RV1108_MISC_CON, 15, 1, MFLAGS),
/*
* Clock-Architecture Diagram 2
*/
@@ -442,7 +442,7 @@ enum rv1108_plls {
GATE(0, "dclk_hdmiphy_src_dpll", "dpll", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(6), 4, GFLAGS),
COMPOSITE_NOGATE(0, "dclk_hdmiphy_pre", mux_dclk_hdmiphy_pre_p, 0,
- RV1108_CLKSEL_CON(32), 6, 2, MFLAGS, 8, 6, DFLAGS),
+ RV1108_CLKSEL_CON(32), 6, 1, MFLAGS, 8, 6, DFLAGS),
COMPOSITE_NOGATE(DCLK_VOP_SRC, "dclk_vop_src", mux_dclk_hdmiphy_pre_p,
0,
RV1108_CLKSEL_CON(32), 6, 1, MFLAGS, 0, 6, DFLAGS),
MUX(DCLK_HDMIPHY, "dclk_hdmiphy", mux_dclk_hdmiphy_p,
CLK_SET_RATE_PARENT,
@@ -498,6 +498,7 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(14), 11, GFLAGS),
GATE(0, "pclk_mipi_csiphy", "pclk_top_pre", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(14), 12, GFLAGS),
+
/*
* Clock-Architecture Diagram 5
*/
@@ -508,7 +509,7 @@ enum rv1108_plls {
COMPOSITE(SCLK_I2S0_SRC, "i2s0_src", mux_pll_src_2plls_p, 0,
RV1108_CLKSEL_CON(5), 8, 1, MFLAGS, 0, 7, DFLAGS,
RV1108_CLKGATE_CON(2), 0, GFLAGS),
- COMPOSITE_FRACMUX(0, "i2s1_frac", "i2s1_src", CLK_SET_RATE_PARENT,
+ COMPOSITE_FRACMUX(0, "i2s0_frac", "i2s0_src", CLK_SET_RATE_PARENT,
RV1108_CLKSEL_CON(8), 0,
RV1108_CLKGATE_CON(2), 1, GFLAGS,
&rv1108_i2s0_fracmux),
@@ -518,7 +519,7 @@ enum rv1108_plls {
RV1108_CLKSEL_CON(5), 15, 1, MFLAGS,
RV1108_CLKGATE_CON(2), 3, GFLAGS),
- COMPOSITE(0, "i2s1_src", mux_pll_src_2plls_p, 0,
+ COMPOSITE(SCLK_I2S1_SRC, "i2s1_src", mux_pll_src_2plls_p, 0,
RV1108_CLKSEL_CON(6), 8, 1, MFLAGS, 0, 7, DFLAGS,
[PATCH v3 6/9] clk: rockchip: support more clks for rv1108
Add the description of the missing clock,
make the clock more complete.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 279 +-
1 file changed, 276 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index 9c6bad0da140..5cb7699305f5 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -145,6 +145,18 @@ enum rv1108_plls {
PNAME(mux_i2s_out_p) = { "i2s0_pre", "xin12m" };
PNAME(mux_i2s1_p) = { "i2s1_src", "i2s1_frac", "xin12m" };
PNAME(mux_i2s2_p) = { "i2s2_src", "i2s2_frac", "xin12m" };
+PNAME(mux_wifi_src_p) = { "gpll", "xin24m" };
+PNAME(mux_cifout_src_p)= { "hdmiphy", "gpll" };
+PNAME(mux_cifout_p)= { "sclk_cifout_src", "xin24m" };
+PNAME(mux_sclk_cif0_src_p) = { "pclk_vip", "clk_cif0_chn_out",
"pclkin_cvbs2cif" };
+PNAME(mux_sclk_cif1_src_p) = { "pclk_vip", "clk_cif1_chn_out",
"pclkin_cvbs2cif" };
+PNAME(mux_sclk_cif2_src_p) = { "pclk_vip", "clk_cif2_chn_out",
"pclkin_cvbs2cif" };
+PNAME(mux_sclk_cif3_src_p) = { "pclk_vip", "clk_cif3_chn_out",
"pclkin_cvbs2cif" };
+PNAME(mux_dsp_src_p) = { "dpll", "gpll", "apll", "usb480m" };
+PNAME(mux_dclk_hdmiphy_p) = { "hdmiphy", "xin24m" };
+PNAME(mux_dclk_vop_p) = { "dclk_hdmiphy", "dclk_vop_src" };
+PNAME(mux_hdmi_cec_src_p) = { "dpll", "gpll", "xin24m" };
+PNAME(mux_cvbs_src_p) = { "apll", "io_cvbs_clkin", "hdmiphy", "gpll"
};
static struct rockchip_pll_clock rv1108_pll_clks[] __initdata = {
[apll] = PLL(pll_rk3399, PLL_APLL, "apll", mux_pll_p, 0,
RV1108_PLL_CON(0),
@@ -212,8 +224,53 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(11), 1, GFLAGS),
/* PD_RKVENC */
+ COMPOSITE(0, "aclk_rkvenc_pre", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(37), 6, 2, MFLAGS, 0, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 8, GFLAGS),
+ FACTOR_GATE(0, "hclk_rkvenc_pre", "aclk_rkvenc_pre", 0, 1, 4,
+ RV1108_CLKGATE_CON(8), 10, GFLAGS),
+ COMPOSITE(SCLK_VENC_CORE, "clk_venc_core", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(37), 14, 2, MFLAGS, 8, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 9, GFLAGS),
+ GATE(ACLK_RKVENC, "aclk_rkvenc", "aclk_rkvenc_pre", 0,
+ RV1108_CLKGATE_CON(19), 8, GFLAGS),
+ GATE(HCLK_RKVENC, "hclk_rkvenc", "hclk_rkvenc_pre", 0,
+ RV1108_CLKGATE_CON(19), 9, GFLAGS),
+ GATE(0, "aclk_rkvenc_niu", "aclk_rkvenc_pre", CLK_IGNORE_UNUSED,
+ RV1108_CLKGATE_CON(19), 11, GFLAGS),
+ GATE(0, "hclk_rkvenc_niu", "hclk_rkvenc_pre", CLK_IGNORE_UNUSED,
+ RV1108_CLKGATE_CON(19), 10, GFLAGS),
/* PD_RKVDEC */
+ COMPOSITE(SCLK_HEVC_CORE, "sclk_hevc_core", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(36), 6, 2, MFLAGS, 0, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 2, GFLAGS),
+ FACTOR_GATE(0, "hclk_rkvdec_pre", "sclk_hevc_core", 0, 1, 4,
+ RV1108_CLKGATE_CON(8), 10, GFLAGS),
+ COMPOSITE(SCLK_HEVC_CABAC, "clk_hevc_cabac", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(35), 14, 2, MFLAGS, 8, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 1, GFLAGS),
+
+ COMPOSITE(0, "aclk_rkvdec_pre", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(35), 6, 2, MFLAGS, 0, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 0, GFLAGS),
+ COMPOSITE(0, "aclk_vpu_pre", mux_pll_src_4plls_p, 0,
+ RV1108_CLKSEL_CON(36), 14, 2, MFLAGS, 8, 5, DFLAGS,
+ RV1108_CLKGATE_CON(8), 3, GFLAGS),
+ GATE(ACLK_RKVDEC, "aclk_rkvdec", "aclk_rkvdec_pre", 0,
+ RV1108_CLKGATE_CON(19), 0, GFLAGS),
+ GATE(ACLK_VPU, "aclk_vpu", "aclk_vpu_pre", 0,
+ RV1108_CLKGATE_CON(19), 1, GFLAGS),
+ GATE(HCLK_RKVDEC, "hclk_rkvdec", "hclk_rkvdec_pre", 0,
+ RV1108_CLKGATE_CON(19), 2, GFLAGS),
+ GATE(HCLK_VPU, "hclk_vpu", "hclk_rkvdec_pre", 0,
+ RV1108_CLKGATE_CON(19), 3, GFLAGS),
+ GATE(0, "aclk_rkvdec_niu", "aclk_rkvdec_pre", CLK_IGNORE_UNUSED,
+ RV1108_CLKGATE_CON(19), 4, GFLAGS),
+ GATE(0, "hclk_rkvdec_niu", "hclk_rkvdec_pre", CLK_IGNORE_UNUSED,
+ RV1108_CLKGATE_CON(19), 5, GFLAGS),
+ GATE(0, "aclk_vpu_niu", "aclk_vpu_pre", CLK_IGNORE_UNUSED,
+ RV1108_CLKGATE_CON(19), 6, GFLAGS),
/* PD_PMU_wrapper */
COMPOSITE_NOMUX(0, "pmu_24m_ena", "gpll", CLK_IGNORE_UNUSED,
@@ -243,6 +300,114 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(8), 13, GFLAGS),
/*
+* Clock-
[PATCH v3 8/9] clk: rockchip: rename some of clks for rv1108 SoC
Rename some of clks to keep the consistency with the TRM.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index 829beef82cff..b845c5d8e792 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -276,24 +276,24 @@ enum rv1108_plls {
COMPOSITE_NOMUX(0, "pmu_24m_ena", "gpll", CLK_IGNORE_UNUSED,
RV1108_CLKSEL_CON(38), 0, 5, DFLAGS,
RV1108_CLKGATE_CON(8), 12, GFLAGS),
- GATE(0, "pmu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_pmu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(10), 0, GFLAGS),
- GATE(0, "intmem1", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_intmem1", "pmu_24m_ena", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(10), 1, GFLAGS),
- GATE(0, "gpio0_pmu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(PCLK_GPIO0_PMU, "pclk_gpio0_pmu", "pmu_24m_ena", 0,
RV1108_CLKGATE_CON(10), 2, GFLAGS),
- GATE(0, "pmugrf", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_pmugrf", "pmu_24m_ena", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(10), 3, GFLAGS),
- GATE(0, "pmu_noc", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(0, "pclk_pmu_niu", "pmu_24m_ena", CLK_IGNORE_UNUSED,
RV1108_CLKGATE_CON(10), 4, GFLAGS),
- GATE(0, "i2c0_pmu_pclk", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(PCLK_I2C0_PMU, "pclk_i2c0_pmu", "pmu_24m_ena", 0,
RV1108_CLKGATE_CON(10), 5, GFLAGS),
- GATE(0, "pwm0_pmu_pclk", "pmu_24m_ena", CLK_IGNORE_UNUSED,
+ GATE(PCLK_PWM0_PMU, "pclk_pwm0_pmu", "pmu_24m_ena", 0,
RV1108_CLKGATE_CON(10), 6, GFLAGS),
- COMPOSITE(0, "pwm0_pmu_clk", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ COMPOSITE(SCLK_PWM0_PMU, "sclk_pwm0_pmu", mux_pll_src_2plls_p, 0,
RV1108_CLKSEL_CON(12), 7, 1, MFLAGS, 0, 7, DFLAGS,
RV1108_CLKGATE_CON(8), 15, GFLAGS),
- COMPOSITE(0, "i2c0_pmu_clk", mux_pll_src_2plls_p, CLK_IGNORE_UNUSED,
+ COMPOSITE(SCLK_I2C0_PMU, "sclk_i2c0_pmu", mux_pll_src_2plls_p, 0,
RV1108_CLKSEL_CON(19), 7, 1, MFLAGS, 0, 7, DFLAGS,
RV1108_CLKGATE_CON(8), 14, GFLAGS),
GATE(0, "pvtm_pmu", "xin24m", CLK_IGNORE_UNUSED,
@@ -410,10 +410,10 @@ enum rv1108_plls {
/*
* Clock-Architecture Diagram 4
*/
- COMPOSITE(0, "aclk_vio0_2wrap_occ", mux_pll_src_4plls_p,
CLK_IGNORE_UNUSED,
+ COMPOSITE(0, "aclk_vio0_pre", mux_pll_src_4plls_p, CLK_IGNORE_UNUSED,
RV1108_CLKSEL_CON(28), 6, 2, MFLAGS, 0, 5, DFLAGS,
RV1108_CLKGATE_CON(6), 0, GFLAGS),
- GATE(0, "aclk_vio0_pre", "aclk_vio0_2wrap_occ", CLK_IGNORE_UNUSED,
+ GATE(ACLK_VIO0, "aclk_vio0", "aclk_vio0_pre", 0,
RV1108_CLKGATE_CON(17), 0, GFLAGS),
COMPOSITE_NOMUX(0, "hclk_vio_pre", "aclk_vio0_pre", 0,
RV1108_CLKSEL_CON(29), 0, 5, DFLAGS,
@@ -632,10 +632,10 @@ enum rv1108_plls {
RV1108_CLKGATE_CON(13), 1, GFLAGS),
GATE(PCLK_I2C3, "pclk_i2c3", "pclk_bus_pre", 0,
RV1108_CLKGATE_CON(13), 2, GFLAGS),
- COMPOSITE(SCLK_PWM, "clk_pwm1", mux_pll_src_2plls_p, 0,
+ COMPOSITE(SCLK_PWM, "clk_pwm", mux_pll_src_2plls_p, 0,
RV1108_CLKSEL_CON(12), 15, 2, MFLAGS, 8, 7, DFLAGS,
RV1108_CLKGATE_CON(3), 10, GFLAGS),
- GATE(PCLK_PWM, "pclk_pwm1", "pclk_bus_pre", 0,
+ GATE(PCLK_PWM, "pclk_pwm", "pclk_bus_pre", 0,
RV1108_CLKGATE_CON(13), 6, GFLAGS),
GATE(PCLK_WDT, "pclk_wdt", "pclk_bus_pre", 0,
RV1108_CLKGATE_CON(13), 3, GFLAGS),
@@ -720,7 +720,7 @@ enum rv1108_plls {
RV1108_CLKSEL_CON(23), 15, 1, MFLAGS, 0, 5, DFLAGS,
RV1108_CLKGATE_CON(15), 11, GFLAGS),
- COMPOSITE(SCLK_SDMMC, "sclk_sdmmc0", mux_mmc_src_p, 0,
+ COMPOSITE(SCLK_SDMMC, "sclk_sdmmc", mux_mmc_src_p, 0,
RV1108_CLKSEL_CON(25), 8, 2, MFLAGS, 0, 8, DFLAGS,
RV1108_CLKGATE_CON(5), 0, GFLAGS),
--
1.9.1
[PATCH v3 9/9] clk: rockchip: add some critical clocks for rv1108 SoC
the bus/periph/nclk_ddrupctl/pclk_ddrmon/pclk_acodecphy/pclk_pmu
no driver to handle them,
Chip design requirements for these clock to always on.
Signed-off-by: Elaine Zhang
---
drivers/clk/rockchip/clk-rv1108.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rv1108.c
b/drivers/clk/rockchip/clk-rv1108.c
index b845c5d8e792..e3101d8dae08 100644
--- a/drivers/clk/rockchip/clk-rv1108.c
+++ b/drivers/clk/rockchip/clk-rv1108.c
@@ -776,10 +776,16 @@ enum rv1108_plls {
static const char *const rv1108_critical_clocks[] __initconst = {
"aclk_core",
- "aclk_bus_src_gpll",
+ "aclk_bus",
+ "hclk_bus",
+ "pclk_bus",
"aclk_periph",
"hclk_periph",
"pclk_periph",
+ "nclk_ddrupctl",
+ "pclk_ddrmon",
+ "pclk_acodecphy",
+ "pclk_pmu",
};
static void __init rv1108_clk_init(struct device_node *np)
--
1.9.1
Re: f7dd250789 ("gcc-plugins: structleak: add option to init all .."): kmodloader/112 is trying to release lock (module_mutex) at:
This appears to be something related to randstruct, not structleak
(which is entirely disabled for this build):
CONFIG_GCC_PLUGINS=y
# CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is not set
# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set
# CONFIG_GCC_PLUGIN_STRUCTLEAK is not set
CONFIG_GCC_PLUGIN_RANDSTRUCT=y
CONFIG_GCC_PLUGIN_RANDSTRUCT_PERFORMANCE=y
-Kees
On Mon, Aug 7, 2017 at 8:20 PM, kernel test robot
wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git
> for-next/gcc-plugin/structleak
>
> commit f7dd2507893cc3425d3ffc2369559619960befb0
> Author: Ard Biesheuvel
> AuthorDate: Sun Aug 6 12:06:27 2017 +0100
> Commit: Kees Cook
> CommitDate: Mon Aug 7 11:20:57 2017 -0700
>
> gcc-plugins: structleak: add option to init all vars used as byref args
>
> In the Linux kernel, struct type variables are rarely passed by-value,
> and so functions that initialize such variables typically take an input
> reference to the variable rather than returning a value that can
> subsequently be used in an assignment.
>
> If the initalization function is not part of the same compilation unit,
> the lack of an assignment operation defeats any analysis the compiler
> can perform as to whether the variable may be used before having been
> initialized. This means we may end up passing on such variables
> uninitialized, resulting in potential information leaks.
>
> So extend the existing structleak GCC plugin so it will [optionally]
> apply to all struct type variables that have their address taken at any
> point, rather than only to variables of struct types that have a __user
> annotation.
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Kees Cook
>
> 520eccdfe1 Linux 4.13-rc2
> f7dd250789 gcc-plugins: structleak: add option to init all vars used as
> byref args
> f7dd250789 gcc-plugins: structleak: add option to init all vars used as
> byref args
> +---+---+++
> | | v4.13-rc2 | f7dd250789 |
> f7dd250789 |
> +---+---+++
> | boot_successes| 163 | 0 | 0
> |
> | boot_failures | 0 | 32 | 32
> |
> | is_trying_to_release_lock(module_mutex)at | 0 | 32 | 32
> |
> | BUG:unable_to_handle_kernel | 0 | 32 | 32
> |
> | Oops:#[##]| 0 | 32 | 32
> |
> | EIP:m_start | 0 | 32 | 32
> |
> | Kernel_panic-not_syncing:Fatal_exception | 0 | 32 | 32
> |
> +---+---+++
>
> [7.063335]
> [7.063494] =
> [7.063922] WARNING: bad unlock balance detected!
> [7.064351] 4.13.0-rc2-1-gf7dd2507 #191 Not tainted
> [7.064830] -
> [7.065259] kmodloader/112 is trying to release lock (module_mutex) at:
> [7.065865] [<7909ed9a>] m_stop+0xd/0xf
> [7.066216] but there are no more locks to release!
> [7.03]
> [7.03] other info that might help us debug this:
> [7.03]
> [7.03] other info that might help us debug this:
> [7.067257] 1 lock held by kmodloader/112:
> [7.067635] #0: (&p->lock){+.+.+.}, at: [<791311b2>] seq_read+0x27/0x368
> [7.068264]
> [7.068264] stack backtrace:
> [7.068264]
> [7.068264] stack backtrace:
> [7.068668] CPU: 0 PID: 112 Comm: kmodloader Not tainted
> 4.13.0-rc2-1-gf7dd2507 #191
> [7.069408] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.9.3-20161025_171302-gandalf 04/01/2014
> [7.070338] Call Trace:
> [7.070569] dump_stack+0x74/0xa7
> [7.070874] ? m_stop+0xd/0xf
> [7.071149] print_unlock_imbalance_bug+0xb1/0xbe
> [7.071582] ? m_stop+0xd/0xf
> [7.071855] ? m_stop+0xd/0xf
> [7.072128] lock_release+0x11c/0x24d
> [7.072464] ? m_stop+0xd/0xf
> [7.072747] __mutex_unlock_slowpath+0x27/0x1bf
> [7.073163] ? __kmalloc+0x5e/0x66
> [7.073477] mutex_unlock+0xb/0xd
> [7.073786] m_stop+0xd/0xf
> [7.074044] seq_read+0x187/0x368
> [7.074349] ? seq_lseek+0x13f/0x13f
> [7.074681] proc_reg_read+0x47/0x64
> [7.075011] ? proc_reg_mmap+0x54/0x54
> [7.075356] __vfs_read+0x22/0x109
> [7.075673] ? find_held_lock+0x29/0x6c
> [7.076027] ? __do_page_fault+0x302/0x378
> [7.076402] vfs_read+0x83/0xf4
> [7.076694] SyS_read+0x3d/0x82
> [7.076984] do_int80_syscall_32+0x4c/0xd9
> [7.077359] entry_INT80_32+0x2c/0x2c
> [7.077697] EIP: 0x
Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem
On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote: > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote: > > > > On newer imx SOCs accessing OCOTP directly is wrong because the > > ocotp clock > > needs to be enabled first. Add support for reading those same > > values through > > the nvmem API instead. > > > > The older path is preserved for compatibility with older dts and > > because it > > works correctly on imx6qdl chips. > > > > Signed-off-by: Leonard Crestez > Acked-by: Shawn Guo I'm okay with the thermal change. We still need ACK for the nvmem changes in this patch series. thanks, rui
Re: [PATCH v2 00/13] mpt3sas driver NVMe support:
On Tue, Aug 08, 2017 at 12:33:40PM +0530, Sreekanth Reddy wrote: > On Tue, Aug 8, 2017 at 9:34 AM, Keith Busch wrote: > > > > It looks like they can make existing nvme tooling work with little > > effort if they have the driver implement NVME_IOCTL_ADMIN_COMMAND, and > > Precisely, I was thinking on the same line and you clarified. I will > spend sometime on this and get back to you. Sounds good. Just note that while the majority of NVMe management should be reachable with just that IOCTL, some tooling features may not work correctly since they look for /dev/nvmeX, and I assume this driver will create /dev/sdX instead.
Re: [PATCH] mfd: lpc_ich: Do not touch SPI-NOR write protection bit on Haswell/Broadwell
On Fri, 28 Jul 2017, Mika Westerberg wrote:
> At least on Lenovo Thinkpad Yoga, the BIOS seems to monitor the SPI-NOR
> write protection bit and if it is flipped to read/write it assumes the
> BIOS configuration was changed on next reboot. It then, for unknown
> reasons, resets the BIOS settings back to default.
>
> We can prevent this by just leaving the write protection bit intact and
> let the SPI-NOR driver know whether the device is writable or not. In
> case of this particular Lenovo the SPI-NOR flash will be exposed as
> read-only.
>
> Fixes: ff00d7a32a1b ("mfd: lpc_ich: Add support for SPI serial flash host
> controller")
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=195951
> Reported-by: Abdó Roig-Marange
> Signed-off-by: Mika Westerberg
> ---
> drivers/mfd/lpc_ich.c | 10 --
> 1 file changed, 10 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> index 773f1554d2f9..450ae36645aa 100644
> --- a/drivers/mfd/lpc_ich.c
> +++ b/drivers/mfd/lpc_ich.c
> @@ -1119,17 +1119,7 @@ static int lpc_ich_init_spi(struct pci_dev *dev)
> res->start = spi_base + SPIBASE_LPT;
> res->end = res->start + SPIBASE_LPT_SZ - 1;
>
> - /*
> - * Try to make the flash chip writeable now by
> - * setting BCR_WPD. It it fails we tell the driver
> - * that it can only read the chip.
> - */
> pci_read_config_dword(dev, BCR, &bcr);
> - if (!(bcr & BCR_WPD)) {
> - bcr |= BCR_WPD;
> - pci_write_config_dword(dev, BCR, bcr);
> - pci_read_config_dword(dev, BCR, &bcr);
> - }
> info->writeable = !!(bcr & BCR_WPD);
> }
> break;
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v2 2/4] KVM: X86: implement the logic for spinlock optimization
On 08/08/2017 06:05, Longpeng(Mike) wrote:
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index cd0e6e6..dec5e8a 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -1268,7 +1268,7 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>
> switch (code) {
> case HVCALL_NOTIFY_LONG_SPIN_WAIT:
> - kvm_vcpu_on_spin(vcpu, kvm_arch_vcpu_in_kernel(vcpu));
> + kvm_vcpu_on_spin(vcpu, kvm_x86_ops->spin_in_kernel(vcpu));
> break;
> case HVCALL_POST_MESSAGE:
> case HVCALL_SIGNAL_EVENT:
This can be true as well. I can change this on commit.
Paolo
Re: [PATCH v2 1/4] KVM: add spinlock optimization framework
On 08/08/2017 06:05, Longpeng(Mike) wrote:
> return 1;
> diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c
> index ce865bd..4ea8c38 100644
> --- a/arch/s390/kvm/diag.c
> +++ b/arch/s390/kvm/diag.c
> @@ -150,7 +150,7 @@ static int __diag_time_slice_end(struct kvm_vcpu *vcpu)
> {
> VCPU_EVENT(vcpu, 5, "%s", "diag time slice end");
> vcpu->stat.diagnose_44++;
> - kvm_vcpu_on_spin(vcpu);
> + kvm_vcpu_on_spin(vcpu, kvm_arch_vcpu_in_kernel(vcpu));
> return 0;
> }
>
IIUC, diag is a privileged instruction so this an also be "true".
Paolo
Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
On Tue, Aug 08, 2017 at 05:01:28PM +1000, NeilBrown wrote: > On Mon, Aug 07 2017, Dominik Brodowski wrote: > > > Neil, Shaohua, > > > > following up on David R's bug message: I have observed something similar > > on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare > > metal partitions, /dev/sdaX and /dev/sdbY linked together). In case it > > matters: Further upwards are cryptsetup, a DM volume group, then logical > > volumes, and then filesystems (ext4, but also happened with xfs). > > > > In a tedious bisect (the bug wasn't as quickly reproducible as I would like, > > but happened when I repeatedly created large lvs and filled them with some > > content, while compiling kernels in parallel), I was able to track this > > down to: > > > > > > commit 4ad23a976413aa57fe5ba7a25953dc35ccca5b71 > > Author: NeilBrown > > Date: Wed Mar 15 14:05:14 2017 +1100 > > > > MD: use per-cpu counter for writes_pending > > > > The 'writes_pending' counter is used to determine when the > > array is stable so that it can be marked in the superblock > > as "Clean". Consequently it needs to be updated frequently > > but only checked for zero occasionally. Recent changes to > > raid5 cause the count to be updated even more often - once > > per 4K rather than once per bio. This provided > > justification for making the updates more efficient. > > > > ... > > Thanks for the report... and for bisecting and for re-sending... > > I believe I have found the problem, and have sent a patch separately. > > If mddev->safemode == 1 and mddev->in_sync != 0, md_check_recovery() > causes the thread that calls it to spin. > Prior to the patch you found, that couldn't happen. Now it can, > so it needs to be handled more carefully. > > While I was examining the code, I found another bug - so that is a win! > > Thanks, > NeilBrown Nice catch. Thanks! Will give it (both patches at once) a try on the test system immediately. Thanks, Dominik signature.asc Description: PGP signature
Re: [PATCH] arm64: KVM: Reject non-compliant HVC calls from guest kernel
Hi Shanker,
On Mon, Aug 07, 2017 at 02:03:28PM -0500, Shanker Donthineni wrote:
> The SMC/HVC instructions with an immediate value non-zero are not compliant
> according to 'SMC calling convention system software document'. Add a
> validation check in handle_hvc() to avoid malicious HVC calls from VM, and
Why do the HVC calls become malicious if they have non-zero immediate
values --- can it actually break something today?
> inject an undefined instruction for those calls.
>
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
>
> Signed-off-by: Shanker Donthineni
> ---
> arch/arm64/include/asm/esr.h | 4
> arch/arm64/kvm/handle_exit.c | 12 +++-
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 8cabd57..fa988e5 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -107,6 +107,9 @@
> #define ESR_ELx_AR (UL(1) << 14)
> #define ESR_ELx_CM (UL(1) << 8)
>
> +/* ISS field definitions for HVC/SVC instruction execution traps */
> +#define ESR_HVC_IMMEDIATE(esr) ((esr) & 0x)
> +
> /* ISS field definitions for exceptions taken in to Hyp */
> #define ESR_ELx_CV (UL(1) << 24)
> #define ESR_ELx_COND_SHIFT (20)
> @@ -114,6 +117,7 @@
> #define ESR_ELx_WFx_ISS_WFE (UL(1) << 0)
> #define ESR_ELx_xVC_IMM_MASK ((1UL << 16) - 1)
>
> +
> /* ESR value templates for specific events */
>
> /* BRK instruction trap from AArch64 state */
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 17d8a16..a900dcd 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -42,13 +42,15 @@ static int handle_hvc(struct kvm_vcpu *vcpu, struct
> kvm_run *run)
> kvm_vcpu_hvc_get_imm(vcpu));
> vcpu->stat.hvc_exit_stat++;
>
> - ret = kvm_psci_call(vcpu);
> - if (ret < 0) {
> - kvm_inject_undefined(vcpu);
> - return 1;
> + /* HVC immediate value must be zero for all compliant calls */
> + if (!ESR_HVC_IMMEDIATE(kvm_vcpu_get_hsr(vcpu))) {
> + ret = kvm_psci_call(vcpu);
> + if (ret >= 0)
> + return ret;
Out of curiosity, have you seen guests or any bad behavior with a
non-zero PSCI value, or are we just making sure we only support callers
that follow the SMC calling convention?
I hope we don't break any existing guests out there with this change,
including UEFI, old versions of Linux, etc.
(I do have this feeling that this check should be inside kvm_psci_call
instead, but it really doesn't matter at this point and we can always
move things around later if we start using other types of hypercalls
for anything.)
Thanks,
-Christoffer
> }
>
> - return ret;
> + kvm_inject_undefined(vcpu);
> + return 1;
> }
>
> static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
> Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
> Foundation Collaborative Project.
>
Re: [PATCH v2 3/4] KVM: s390: implements the kvm_arch_vcpu_in_kernel()
On Tue, 8 Aug 2017 12:05:34 +0800
"Longpeng(Mike)" wrote:
> This implements the kvm_arch_vcpu_in_kernel() for s390.
>
> Signed-off-by: Longpeng(Mike)
> ---
> arch/s390/kvm/kvm-s390.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 0b0c689..e46177b 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2449,7 +2449,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>
> bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> {
> - return false;
> + return !(vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE);
> }
> EXPORT_SYMBOL_GPL(kvm_arch_vcpu_in_kernel);
>
Acked-by: Cornelia Huck
Re: [PATCH v2 4/4] KVM: arm: implements the kvm_arch_vcpu_in_kernel()
On Tue, Aug 08, 2017 at 12:05:35PM +0800, Longpeng(Mike) wrote:
> This implements the kvm_arch_vcpu_in_kernel() for ARM.
>
> Signed-off-by: Longpeng(Mike)
> ---
> virt/kvm/arm/arm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 862f820..b9f68e4 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -418,7 +418,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
>
> bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> {
> - return false;
> + return vcpu_mode_priv(vcpu);
> }
>
> /* Just ensure a guest exit from a particular CPU */
> --
> 1.8.3.1
>
>
I'm not taking any position on whether this series makes sense overall
or not (it's a bit concerning to do this without having measured a
benefit), but for the arm/arm64 change:
Acked-by: Christoffer Dall
Re: Suspend-resume failure on Intel Eagle Lake Core2Duo
On 08/08/17 02:30, Masahiro Yamada wrote:
> Hi Marc,
>
> 2017-08-07 17:17 GMT+09:00 Marc Zyngier :
>> On 07/08/17 05:45, Masahiro Yamada wrote:
>>> Hi Marc,
>>>
>>>
>>> 2017-08-03 22:30 GMT+09:00 Marc Zyngier :
On 03/08/17 13:52, Masahiro Yamada wrote:
> Hi Marc,
>
> 2017-08-03 17:41 GMT+09:00 Marc Zyngier :
>> Hi Masahiro,
>>
>> On 03/08/17 08:32, Masahiro Yamada wrote:
>>> Hi.
>>>
>>> 2017-08-01 0:55 GMT+09:00 Thomas Gleixner :
On Mon, 31 Jul 2017, Tomi Sarvela wrote:
> On 31/07/17 18:06, Thomas Gleixner wrote:
>> Can you please remove the patch. And try the following:
>>
>> # echo N > /sys/module/printk/parameters/console_suspend
>>
>> # echo mem > /sys/power/state
>>
>> and log the output of the serial console. That way we might get a
>> clue
>> where it gets stuck.
>
> I'm afraid it hangs right away. No response from SSH, no output to
> serial.
What means hangs right away? Is there no output at all on the serial
console? Or does it just stop at some point?
Thanks,
tglx
>>>
>>> Sorry for jumping in.
>>> Finally, I found this thread.
>>>
>>>
>>> My environment is completely different (ARM64 board),
>>> I am also suffering from a hibernation problem
>>> since this commit.
>>>
>>>
>>> I get no response on the serial console
>>> after "Restarting tasks ... done." log message.
>>>
>>>
>>> By reverting bf22ff45bed6 ("genirq: Avoid unnecessary low level
>>> irq function calls", I can get hibernation working again.
>>>
>>>
>>> SW info:
>>> defconfig: arch/arm64/configs/defconfig
>>> DT : arch/arm64/boot/dts/socionext/uniphier-ld20-ref.dts
>>> PSCI : ARM Trusted Firmware
>>>
>>>
>>> SoC info:
>>> CPU : Cortex-A72 * 2 + Cortex-A53 * 2
>>> irqchip : GICv3 (drivers/irq/irq-gic-v3.c)
>>
>> Let me take an educated guess: It feels like your firmware doesn't
>> save/restore the GIC context across suspend/resume. Is that something
>> you could check, assuming you have access to the firmware source code?
>
> Thanks for your comments.
>
>
> I do not know much about the manner of preserving GICv3 context.
>
> I can see this patch (rejected?) :
> https://patchwork.kernel.org/patch/9343061/
>
>
> Is it something that should be completely cared by firmware
> instead of kernel?
That was definitely the intention, but it looks like something that ATF
has only started supporting very recently:
https://github.com/ARM-software/arm-trusted-firmware/pull/1047
> ARM Trusted Firmware
> (https://github.com/ARM-software/arm-trusted-firmware)
> is open source software, and I pushed my platform code to the upstream.
>
> So, yes, I (and everybody) can have access to the firmware source code.
>
>
> I am not sure how ATF saves the context during hibernation, though.
See the above link. Is there any chance of you trying this into your
firmware?
Thanks,
>>>
>>> Thanks for the pointer.
>>>
>>>
>>> Yes. I will try that once GIC-v3 context save/restore is supported in ATF.
>>>
>>> I think that will basically work for suspend-to-ram
>>> because all contexts including both non-secure and secure worlds will
>>> be retained in the main memory.
>>>
>>> However, I still do not understand how the context is preserved during
>>> the hibernation (suspend-to-disk).
>>>
>>>
>>> If my understanding is correct, hibernation on Linux works like follows:
>>>
>>> [1] Freeze all tasks
>>> [2] CPU_OFF for non-boot CPUs
>>> [3] Create a hibernation image
>>> [4] CPU_ON for non-boot CPUs
>>> [5] Write the hibernation image to the disk (=swap area)
>>> [6] SYSTEM_OFF
>>>
>>>
>>> IIUC, [5] only writes the context Linux takes care of (only non-secure).
>>>
>>> If so, where and how does the firmware write the GIC-v3 context
>>> to the disk?
>>
>> Gah, I completely missed the fact that you were talking about suspend to
>> disk, sorry about that.
>>
>> It is likely that some driver doesn't restore its state properly. Is
>> there any chance that you could pinpoint which device creates the issue?
>>
>
> I use eMMC to store the hibernation image, but
> I do not think eMMC driver is the cause of the issue.
>
> I guess the cause of the issue is GIC-v3 context is lost.
It is not lost. The boot kernel has re-initialized its state. What is
missing is that one driver in your system fails to restore its own state
correctly, and relies on doing something such as enabling/disabling the
interrupt in its PM handler, things will start working again (probably
because they use the same PM callbacks functions for both suspend/resume
and hibernation). This is in no way a guarant
Re: [PATCH -mm] mm: Clear to access sub-page last when clearing huge page
"Huang, Ying" writes: > "Kirill A. Shutemov" writes: > >> On Mon, Aug 07, 2017 at 03:21:31PM +0800, Huang, Ying wrote: >>> From: Huang Ying >>> >>> Huge page helps to reduce TLB miss rate, but it has higher cache >>> footprint, sometimes this may cause some issue. For example, when >>> clearing huge page on x86_64 platform, the cache footprint is 2M. But >>> on a Xeon E5 v3 2699 CPU, there are 18 cores, 36 threads, and only 45M >>> LLC (last level cache). That is, in average, there are 2.5M LLC for >>> each core and 1.25M LLC for each thread. If the cache pressure is >>> heavy when clearing the huge page, and we clear the huge page from the >>> begin to the end, it is possible that the begin of huge page is >>> evicted from the cache after we finishing clearing the end of the huge >>> page. And it is possible for the application to access the begin of >>> the huge page after clearing the huge page. >>> >>> To help the above situation, in this patch, when we clear a huge page, >>> the order to clear sub-pages is changed. In quite some situation, we >>> can get the address that the application will access after we clear >>> the huge page, for example, in a page fault handler. Instead of >>> clearing the huge page from begin to end, we will clear the sub-pages >>> farthest from the the sub-page to access firstly, and clear the >>> sub-page to access last. This will make the sub-page to access most >>> cache-hot and sub-pages around it more cache-hot too. If we cannot >>> know the address the application will access, the begin of the huge >>> page is assumed to be the the address the application will access. >>> >>> With this patch, the throughput increases ~28.3% in vm-scalability >>> anon-w-seq test case with 72 processes on a 2 socket Xeon E5 v3 2699 >>> system (36 cores, 72 threads). The test case creates 72 processes, >>> each process mmap a big anonymous memory area and writes to it from >>> the begin to the end. For each process, other processes could be seen >>> as other workload which generates heavy cache pressure. At the same >>> time, the cache miss rate reduced from ~33.4% to ~31.7%, the >>> IPC (instruction per cycle) increased from 0.56 to 0.74, and the time >>> spent in user space is reduced ~7.9% >> >> That's impressive. >> >> But what about the case when we are not bounded that much by the size of >> LLC? What about running the same test on the same hardware, but with 4 >> processes instead of 72. >> >> I just want to make sure we don't regress on more realistic tast case. > > Sure. I will test it. Tested with 4 processes, there is no visible changes for benchmark result. Best Regards, Huang, Ying
Re: [PATCH v6 1/3] mfd: Add new mfd device TPS68470
On Fri, 28 Jul 2017, Rajmohan Mani wrote: > The TPS68470 device is an advanced power management > unit that powers a Compact Camera Module (CCM), > generates clocks for image sensors, drives a dual > LED for Flash and incorporates two LED drivers for > general purpose indicators. > > This patch adds support for TPS68470 mfd device. > > Signed-off-by: Rajmohan Mani > --- > drivers/mfd/Kconfig | 18 > drivers/mfd/Makefile | 1 + > drivers/mfd/tps68470.c | 106 > +++ > include/linux/mfd/tps68470.h | 97 +++ > 4 files changed, 222 insertions(+) > create mode 100644 drivers/mfd/tps68470.c > create mode 100644 include/linux/mfd/tps68470.h Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH] i2c: imx: Remove a useless test in 'i2c_imx_init_recovery_info()'
Le 07/08/2017 à 08:36, Uwe Kleine-König a écrit :
On Mon, Aug 07, 2017 at 01:49:53AM +0200, Christophe JAILLET wrote:
'devm_pinctrl_get()' never returns NULL, so this test can be simplified.
That's wrong. If CONFIG_PINCTRL is disabled devm_pinctrl_get returns
NULL. But I think this shouldn't be considered an error, so your change
is right, just the commit log is not.
With that said, in fact, I think that the test is correct as is.
If CONFIG_PINCTRL is disabled, we will display an info about a missing
functionality, but would still continue normally without it (i.e. return
PTR_ERR(NULL) = 0 = success), as stated in the comment in front of
'i2c_imx_init_recovery_info':
"These alternative pinmux settings can be described in the device
tree by
a separate pinctrl state "gpio". If this is missing this is not a big
problem, the only implication is that we can't do bus recovery."
So, I won't propose any v2 patch with an updated commit log.
Feel free to update it yourself and apply it if you don't share my
analysis above.
Sorry for the noise.
CJ
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 54a47b40546f..7e84662fe1c0 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -997,7 +997,7 @@ static int i2c_imx_init_recovery_info(struct imx_i2c_struct
*i2c_imx,
struct i2c_bus_recovery_info *rinfo = &i2c_imx->rinfo;
i2c_imx->pinctrl = devm_pinctrl_get(&pdev->dev);
- if (!i2c_imx->pinctrl || IS_ERR(i2c_imx->pinctrl)) {
+ if (IS_ERR(i2c_imx->pinctrl)) {
dev_info(&pdev->dev, "can't get pinctrl, bus recovery not
supported\n");
return PTR_ERR(i2c_imx->pinctrl);
}
Side note: I'm not sure, this construct is valid. IIRC PTR_ERR should
only be called for values x where IS_ERR(x) is true. Here it is at least
surprising that an message hints to a problem but the return code is 0.
@Julia: I'm sure coccinelle can find more of those?!
Best regards
Uwe
Re: [PATCH v2 4/4] KVM: arm: implements the kvm_arch_vcpu_in_kernel()
On Tue, Aug 8, 2017 at 9:39 AM, Christoffer Dall wrote:
> On Tue, Aug 08, 2017 at 12:05:35PM +0800, Longpeng(Mike) wrote:
>> This implements the kvm_arch_vcpu_in_kernel() for ARM.
>>
>> Signed-off-by: Longpeng(Mike)
>> ---
>> virt/kvm/arm/arm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index 862f820..b9f68e4 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -418,7 +418,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *v)
>>
>> bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
>> {
>> - return false;
>> + return vcpu_mode_priv(vcpu);
>> }
>>
>> /* Just ensure a guest exit from a particular CPU */
>> --
>> 1.8.3.1
>>
>>
> I'm not taking any position on whether this series makes sense overall
> or not (it's a bit concerning to do this without having measured a
> benefit), but for the arm/arm64 change:
oh, sorry, strike that, I didn't notice you had added performance
results in the cover letter.
Thanks,
-Christoffer
>
> Acked-by: Christoffer Dall
Re: [PATCH v2 0/4] KVM: optimize the kvm_vcpu_on_spin
On Tue, 8 Aug 2017 12:05:31 +0800 "Longpeng(Mike)" wrote: > This is a simple optimization for kvm_vcpu_on_spin, the > main idea is described in patch-1's commit msg. I think this generally looks good now. > > I did some tests base on the RFC version, the result shows > that it can improves the performance slightly. Did you re-run tests on this version? I would also like to see some s390 numbers; unfortunately I only have a z/VM environment and any performance numbers would be nearly useless there. Maybe somebody within IBM with a better setup can run a quick test?
Re: [PATCH v2 1/4] KVM: add spinlock optimization framework
On Tue, 8 Aug 2017 09:34:14 +0200
Paolo Bonzini wrote:
> On 08/08/2017 06:05, Longpeng(Mike) wrote:
> > return 1;
> > diff --git a/arch/s390/kvm/diag.c b/arch/s390/kvm/diag.c
> > index ce865bd..4ea8c38 100644
> > --- a/arch/s390/kvm/diag.c
> > +++ b/arch/s390/kvm/diag.c
> > @@ -150,7 +150,7 @@ static int __diag_time_slice_end(struct kvm_vcpu *vcpu)
> > {
> > VCPU_EVENT(vcpu, 5, "%s", "diag time slice end");
> > vcpu->stat.diagnose_44++;
> > - kvm_vcpu_on_spin(vcpu);
> > + kvm_vcpu_on_spin(vcpu, kvm_arch_vcpu_in_kernel(vcpu));
> > return 0;
> > }
> >
>
> IIUC, diag is a privileged instruction so this an also be "true".
>
> Paolo
Yes, indeed.
Re: [PATCH] ACPI / Sleep: Check low power idle constraints for debug only
On Mon, Aug 07, 2017 at 04:53:57PM -0700, Srinivas Pandruvada wrote:
> + out_obj = acpi_evaluate_dsm(lps0_device_handle, &lps0_dsm_guid,
> + 1, ACPI_LPS0_GET_DEVICE_CONSTRAINTS,
> + NULL);
> +
> + acpi_handle_debug(lps0_device_handle, "_DSM function 1 eval %s\n",
> + out_obj ? "successful" : "failed");
> +
> + if (!out_obj)
> + return;
> +
> + if (out_obj->type != ACPI_TYPE_PACKAGE)
> + goto free_acpi_buffer;
Using acpi_evaluate_dsm_typed() would avoid having to check the type here.
> + for (i = 0; i < out_obj->package.count; i++) {
> + union acpi_object *package = &out_obj->package.elements[i];
> + struct lpi_device_info info;
> + int package_count = 0, j;
> +
> + if (!package)
> + continue;
> +
> + info.enabled = 0;
> + info.package = NULL;
> + info.name = NULL;
Using a declaration such as
struct lpi_device_info info = { };
would avoid having to zero the struct elements here.
Thanks,
Lukas
Re: [PATCH] arm64: KVM: Reject non-compliant HVC calls from guest kernel
On 08/08/17 08:36, Christoffer Dall wrote:
> Hi Shanker,
>
> On Mon, Aug 07, 2017 at 02:03:28PM -0500, Shanker Donthineni wrote:
>> The SMC/HVC instructions with an immediate value non-zero are not compliant
>> according to 'SMC calling convention system software document'. Add a
>> validation check in handle_hvc() to avoid malicious HVC calls from VM, and
>
>
> Why do the HVC calls become malicious if they have non-zero immediate
> values --- can it actually break something today?
More importantly, the *architecture* allows non-zero values. The SMCCC
is a *convention*, and not part of the architecture (which is what KVM
is concerned about).
>
>
>> inject an undefined instruction for those calls.
>>
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
>>
>> Signed-off-by: Shanker Donthineni
>> ---
>> arch/arm64/include/asm/esr.h | 4
>> arch/arm64/kvm/handle_exit.c | 12 +++-
>> 2 files changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
>> index 8cabd57..fa988e5 100644
>> --- a/arch/arm64/include/asm/esr.h
>> +++ b/arch/arm64/include/asm/esr.h
>> @@ -107,6 +107,9 @@
>> #define ESR_ELx_AR (UL(1) << 14)
>> #define ESR_ELx_CM (UL(1) << 8)
>>
>> +/* ISS field definitions for HVC/SVC instruction execution traps */
>> +#define ESR_HVC_IMMEDIATE(esr) ((esr) & 0x)
>> +
>> /* ISS field definitions for exceptions taken in to Hyp */
>> #define ESR_ELx_CV (UL(1) << 24)
>> #define ESR_ELx_COND_SHIFT (20)
>> @@ -114,6 +117,7 @@
>> #define ESR_ELx_WFx_ISS_WFE (UL(1) << 0)
>> #define ESR_ELx_xVC_IMM_MASK((1UL << 16) - 1)
>>
>> +
>> /* ESR value templates for specific events */
>>
>> /* BRK instruction trap from AArch64 state */
>> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
>> index 17d8a16..a900dcd 100644
>> --- a/arch/arm64/kvm/handle_exit.c
>> +++ b/arch/arm64/kvm/handle_exit.c
>> @@ -42,13 +42,15 @@ static int handle_hvc(struct kvm_vcpu *vcpu, struct
>> kvm_run *run)
>> kvm_vcpu_hvc_get_imm(vcpu));
>> vcpu->stat.hvc_exit_stat++;
>>
>> -ret = kvm_psci_call(vcpu);
>> -if (ret < 0) {
>> -kvm_inject_undefined(vcpu);
>> -return 1;
>> +/* HVC immediate value must be zero for all compliant calls */
>> +if (!ESR_HVC_IMMEDIATE(kvm_vcpu_get_hsr(vcpu))) {
>> +ret = kvm_psci_call(vcpu);
>> +if (ret >= 0)
>> +return ret;
>
> Out of curiosity, have you seen guests or any bad behavior with a
> non-zero PSCI value, or are we just making sure we only support callers
> that follow the SMC calling convention?
>
> I hope we don't break any existing guests out there with this change,
> including UEFI, old versions of Linux, etc.
>
> (I do have this feeling that this check should be inside kvm_psci_call
> instead, but it really doesn't matter at this point and we can always
> move things around later if we start using other types of hypercalls
> for anything.)
Exactly. PSCI doesn't rely on SMCCC (the initial version pre-dates it),
though it mandates the HVC immediate to be zero. So let's check it
there, and not as a blanket statement forbidding a reasonable use of the
architecture.
Eventually, I'd like to be able to forward such HVC/SMC calls to
userspace (and ultimately deprecate PSCI in the kernel), so that it can
apply whatever policy it decides.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Re: [PATCH] thermal/drivers/hisi: Remove confusing error message
On Fri, 2017-07-07 at 17:03 +0200, Daniel Lezcano wrote:
> The sensor id is unknown at init time and we use all id in the
> authorized
> MAX_SENSORS interval to register the sensor. On this SoC there is one
> thermal-zone with one sensor on it. No need to spit on the console
> everytime we
> failed to register thermal sensors, information which is deliberaly
> known as it
> is part of the discovery process.
>
> hisi_thermal f7030700.tsensor: failed to register sensor id 0: -19
> hisi_thermal f7030700.tsensor: failed to register thermal sensor:
> -19
> hisi_thermal f7030700.tsensor: failed to register sensor id 1: -19
> hisi_thermal f7030700.tsensor: failed to register thermal sensor:
> -19
> hisi_thermal f7030700.tsensor: failed to register sensor id 3: -19
> hisi_thermal f7030700.tsensor: failed to register thermal sensor:
> -19
>
> Remove the error messages.
>
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c
> b/drivers/thermal/hisi_thermal.c
> index f642966..2cc98c6 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -187,6 +187,9 @@ static int hisi_thermal_get_temp(void *_sensor,
> int *temp)
>
> dev_dbg(&data->pdev->dev, "id=%d, irq=%d, temp=%d,
> thres=%d\n",
> sensor->id, data->irq_enabled, *temp, sensor-
> >thres_temp);
> +
> + printk("id=%d, irq=%d, temp=%d, thres=%d\n",
> + sensor->id, data->irq_enabled, *temp, sensor-
> >thres_temp);
what's this printk for?
> /*
> * Bind irq to sensor for two cases:
> * Reenable alarm IRQ if temperature below threshold;
> @@ -260,8 +263,6 @@ static int hisi_thermal_register_sensor(struct
> platform_device *pdev,
> if (IS_ERR(sensor->tzd)) {
> ret = PTR_ERR(sensor->tzd);
> sensor->tzd = NULL;
> - dev_err(&pdev->dev, "failed to register sensor id
> %d: %d\n",
> - sensor->id, ret);
> return ret;
> }
>
> @@ -352,10 +353,9 @@ static int hisi_thermal_probe(struct
> platform_device *pdev)
> ret = hisi_thermal_register_sensor(pdev, data,
> &data-
> >sensors[i], i);
> if (ret)
> - dev_err(&pdev->dev,
> - "failed to register thermal sensor:
> %d\n", ret);
> - else
> - hisi_thermal_toggle_sensor(&data-
> >sensors[i], true);
> + continue;
> +
> + hisi_thermal_toggle_sensor(&data->sensors[i], true);
> }
>
> return 0;
With these removed, is there any other information in dmesg that
suggests this failure?
thanks,
rui
[PATCH v2 1/2] remoteproc: dt: Provide bindings for iMX6SX/7D Remote Processor Controller driver
Signed-off-by: Oleksij Rempel
---
.../devicetree/bindings/remoteproc/imx-rproc.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
b/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
new file mode 100644
index ..faf30ef3d6cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
@@ -0,0 +1,33 @@
+NXP iMX6SX/iMX7D Co-Processor Bindings
+
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+NXP iMX SoCs.
+
+Required properties:
+- compatible Should be one of:
+ "fsl,imx7d-rproc"
+ "fsl,imx6sx-rproc"
+- clocks Clock for co-processor (See:
../clock/clock-bindings.txt)
+- syscon Phandle to syscon block which provide access to
+ System Reset Controller
+
+Optional properties:
+- memory-regionlist of phandels to the reserved memory regions.
+ (See: ../reserved-memory/reserved-memory.txt)
+
+Example:
+ m4_reserved_sysmem1: rproc@8000 {
+ reg = <0x8000 0x8>;
+ };
+
+ m4_reserved_sysmem2: rproc@8100 {
+ reg = <0x8100 0x8>;
+ };
+
+ imx7d-rproc {
+ compatible = "fsl,imx7d-rproc";
+ memory-region = <&m4_reserved_sysmem1>,
<&m4_reserved_sysmem2>;
+ syscon = <&src>;
+ clocks = <&clks IMX7D_ARM_M4_ROOT_CLK>;
+ };
--
2.11.0
[PATCH v2 2/2] remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver
Provide a basic driver to control Cortex M4 co-processor found
on NXP i.MX7D and i.MX6SX.
Currently it is able to resolve addresses between M4 and main CPU,
start and stop the co-processor. Other functionality is not provided
or test.
This driver was tested on NXP i.MX7D and expected to work on
i.MX6SX as well.
Signed-off-by: Oleksij Rempel
---
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/imx_rproc.c | 426 +
3 files changed, 437 insertions(+)
create mode 100644 drivers/remoteproc/imx_rproc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index faad69a1a597..1f6644908629 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -13,6 +13,16 @@ config REMOTEPROC
if REMOTEPROC
+config IMX_REMOTEPROC
+ tristate "IMX6/7 remoteproc support"
+ depends on SOC_IMX6SX || SOC_IMX7D
+ depends on REMOTEPROC
+ help
+ Say y here to support iMX's remote processors (Cortex M4
+ on iMX7D) via the remote processor framework.
+
+ It's safe to say N here.
+
config OMAP_REMOTEPROC
tristate "OMAP remoteproc support"
depends on HAS_DMA
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index ffc5e430df27..d351c25cdb4e 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -19,3 +19,4 @@ qcom_wcnss_pil-y += qcom_wcnss.o
qcom_wcnss_pil-y += qcom_wcnss_iris.o
obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
obj-$(CONFIG_ST_SLIM_REMOTEPROC) += st_slim_rproc.o
+obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
new file mode 100644
index ..87d1e670dda7
--- /dev/null
+++ b/drivers/remoteproc/imx_rproc.c
@@ -0,0 +1,426 @@
+/*
+ * Copyright (c) 2017 Pengutronix, Oleksij Rempel
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IMX7D_SRC_SCR 0x0C
+#define IMX7D_ENABLE_M4BIT(3)
+#define IMX7D_SW_M4P_RST BIT(2)
+#define IMX7D_SW_M4C_RST BIT(1)
+#define IMX7D_SW_M4C_NON_SCLR_RST BIT(0)
+
+#define IMX7D_M4_RST_MASK (IMX7D_ENABLE_M4 | IMX7D_SW_M4P_RST \
+| IMX7D_SW_M4C_RST \
+| IMX7D_SW_M4C_NON_SCLR_RST)
+
+#define IMX7D_M4_START (IMX7D_ENABLE_M4 | IMX7D_SW_M4P_RST \
+| IMX7D_SW_M4C_RST)
+#define IMX7D_M4_STOP IMX7D_SW_M4C_NON_SCLR_RST
+
+/* Address: 0x020D8000 */
+#define IMX6SX_SRC_SCR 0x00
+#define IMX6SX_ENABLE_M4 BIT(22)
+#define IMX6SX_SW_M4P_RST BIT(12)
+#define IMX6SX_SW_M4C_NON_SCLR_RST BIT(4)
+#define IMX6SX_SW_M4C_RST BIT(3)
+
+#define IMX6SX_M4_START(IMX6SX_ENABLE_M4 |
IMX6SX_SW_M4P_RST \
+| IMX6SX_SW_M4C_RST)
+#define IMX6SX_M4_STOP IMX6SX_SW_M4C_NON_SCLR_RST
+#define IMX6SX_M4_RST_MASK (IMX6SX_ENABLE_M4 | IMX6SX_SW_M4P_RST \
+| IMX6SX_SW_M4C_NON_SCLR_RST \
+| IMX6SX_SW_M4C_RST)
+
+#define IMX7D_RPROC_MEM_MAX8
+
+/**
+ * struct imx_rproc_mem - slim internal memory structure
+ * @cpu_addr: MPU virtual address of the memory region
+ * @sys_addr: Bus address used to access the memory region
+ * @size: Size of the memory region
+ */
+struct imx_rproc_mem {
+ void __iomem *cpu_addr;
+ phys_addr_t sys_addr;
+ size_t size;
+};
+
+/* att flags */
+/* M4 own area. Can be mapped at probe */
+#define ATT_OWNBIT(1)
+
+/* address translation table */
+struct imx_rproc_att {
+ u32 da; /* device address (From Cortex M4 view)*/
+ u32 sa; /* system bus address */
+ u32 size; /* size of reg range */
+ int flags;
+};
+
+struct imx_rproc_dcfg {
+ u32 src_reg;
+ u32 src_mask;
+ u32 src_start;
+ u32 src_stop;
+ const struct imx_rproc_att *att;
+ size_t att_size;
+};
+
+struct imx_rproc {
+ struct device *dev;
+ struct regmap *regmap;
+ struct rproc*rproc;
+ const struct imx_rproc_dcfg *dcfg;
+ struct imx_rproc_memmem[IMX7D_RPROC_MEM_MAX];
+ struct clk
[PATCH v2 0/2] provide imx rproc driver
this patch set to provide remoteproc functionality on
i.MX7D SoC.
For testing I used this simple counter written in ASM:
==
.syntax unified
.text
.thumb
.int 0x1002 @ Initial SP value
.int reset + 1
reset:
mov r0, #0x55
ldr r1, =(0x40)
1:
str r0, [r1]
add r0, 1
b 1b
/* Dummy data, required by remoteproc loader */
/* Please FIXME, this part seem to be incorrect */
.data
.section .resource_table, "aw"
.word 1, 0, 0, 0 /* struct resource_table base */
.word 0 /* uint32_t offset[1] */
compiled with:
${CROSS}as -o imx7m4.o imx7m4.S
${CROSS}ld -Ttext=0x0 -o imx7m4.elf imx7m4.o
cp imx7m4.elf /srv/nfs/sid-armhf/lib/firmware/rproc-imx_rproc-fw
Functionality was confirmed with current OpenOCD master.
OpenOCD cfg file can be found here:
https://github.com/olerem/openocd/blob/imx7-2017.06.14/tcl/target/imx7.cfg
changes:
v2:
- use memory-region instead of reg property
- remove memory ranges from documentation
Oleksij Rempel (2):
remoteproc: dt: Provide bindings for iMX6SX/7D Remote Processor
Controller driver
remoteproc: imx_rproc: add a NXP/Freescale imx_rproc driver
.../devicetree/bindings/remoteproc/imx-rproc.txt | 33 ++
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile| 1 +
drivers/remoteproc/imx_rproc.c | 426 +
4 files changed, 470 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/imx-rproc.txt
create mode 100644 drivers/remoteproc/imx_rproc.c
--
2.11.0
Re: [MD] Crash with 4.12+ kernel and high disk load -- bisected to 4ad23a976413: MD: use per-cpu counter for writes_pending
I will apply this to my home server this evening (BST) and set off a check. Will have results tomorrow. Thanks for the fix! David Quoting NeilBrown : On Mon, Aug 07 2017, Dominik Brodowski wrote: Neil, Shaohua, following up on David R's bug message: I have observed something similar on v4.12.[345] and v4.13-rc4, but not on v4.11. This is a RAID1 (on bare metal partitions, /dev/sdaX and /dev/sdbY linked together). In case it matters: Further upwards are cryptsetup, a DM volume group, then logical volumes, and then filesystems (ext4, but also happened with xfs). In a tedious bisect (the bug wasn't as quickly reproducible as I would like, but happened when I repeatedly created large lvs and filled them with some content, while compiling kernels in parallel), I was able to track this down to: commit 4ad23a976413aa57fe5ba7a25953dc35ccca5b71 Author: NeilBrown Date: Wed Mar 15 14:05:14 2017 +1100 MD: use per-cpu counter for writes_pending The 'writes_pending' counter is used to determine when the array is stable so that it can be marked in the superblock as "Clean". Consequently it needs to be updated frequently but only checked for zero occasionally. Recent changes to raid5 cause the count to be updated even more often - once per 4K rather than once per bio. This provided justification for making the updates more efficient. ... Thanks for the report... and for bisecting and for re-sending... I believe I have found the problem, and have sent a patch separately. If mddev->safemode == 1 and mddev->in_sync != 0, md_check_recovery() causes the thread that calls it to spin. Prior to the patch you found, that couldn't happen. Now it can, so it needs to be handled more carefully. While I was examining the code, I found another bug - so that is a win! Thanks, NeilBrown
RE: [v5] wlcore: add missing nvs file name info for wilink8
> Subject: Re: [v5] wlcore: add missing nvs file name info for wilink8 > > * Reizer, Eyal [170807 00:47]: > > Hi Tony, > > > > > > * Reizer, Eyal [170807 00:32]: > > > > The following commits: > > > > c815fde wlcore: spi: Populate config firmware data > > > > d776fc8 wlcore: sdio: Populate config firmware data > > > > > > > > Populated the nvs entry for wilink6 and wilink7 only while it is > > > > still needed for wilink8 as well. > > > > This broke user space backward compatibility when upgrading from > older > > > > kernels, as the alternate mac address would not be read from the nvs > that > > > is > > > > present in the file system (lib/firmware/ti-connectivity/wl1271-nvs.bin) > > > > causing mac address change of the wlan interface. > > > > > > > > This patch fix this and update the structure field with the same default > > > > nvs file name that has been used before. > > > > > > > > In addition, some distros hold a default wl1271-nvs.bin in the file > > > > system with a bogus mac address (deadbeef...) that for a wl18xx device > > > > also overrides the mac address that is stored inside the device. > > > > Warn users about this bogus mac address and use a random mac > instead > > > > > > Hmm looks pretty good to me except for one more thing I just noticed. > > > > > > Why don't you just use the hardware mac address instead of a random > > > mac address on wl18xx device when you see a bogus nvs file? > > > > > > > I agree that this would have been better but the problem is that hardware > > mac address is available for wilink8 onlyWilink6/7 don't have one stored. > > The wlcore code responsible for handling mac address is common code > > and there is method for detecting between them in this module. > > Care to clarify a bit.. Are you saying wilink8 will use the hardware > mac address in case of bogus nvs file? > With present implementation it will not. It will use the random one for both wilink6/7 as well as wilink8. I need to get a hold of a wilink6/7 module and see if reverting to an internal mac address is working. Will try to look around as it has been a while since I used one. Best Regards, Eyal
Re: Switching to MQ by default may generate some bug reports
> Il giorno 07 ago 2017, alle ore 20:42, Paolo Valente > ha scritto: > >> >> Il giorno 07 ago 2017, alle ore 19:32, Paolo Valente >> ha scritto: >> >>> >>> Il giorno 05 ago 2017, alle ore 00:05, Paolo Valente >>> ha scritto: >>> Il giorno 04 ago 2017, alle ore 13:01, Mel Gorman ha scritto: On Fri, Aug 04, 2017 at 09:26:20AM +0200, Paolo Valente wrote: >> I took that into account BFQ with low-latency was also tested and the >> impact was not a universal improvement although it can be a noticable >> improvement. From the same machine; >> >> dbench4 Loadfile Execution Time >> 4.12.0 4.12.0 >> 4.12.0 >> legacy-cfq mq-bfq >> mq-bfq-tput >> Amean 180.67 ( 0.00%) 83.68 ( -3.74%) 84.70 ( >> -5.00%) >> Amean 292.87 ( 0.00%) 121.63 ( -30.96%) 88.74 ( >> 4.45%) >> Amean 4 102.72 ( 0.00%) 474.33 (-361.77%) 113.97 ( >> -10.95%) >> Amean 32 2543.93 ( 0.00%) 1927.65 ( 24.23%) 2038.74 ( >> 19.86%) >> > > Thanks for trying with low_latency disabled. If I read numbers > correctly, we move from a worst case of 361% higher execution time to > a worst case of 11%. With a best case of 20% of lower execution time. > Yes. > I asked you about none and mq-deadline in a previous email, because > actually we have a double change here: change of the I/O stack, and > change of the scheduler, with the first change probably not irrelevant > with respect to the second one. > True. However, the difference between legacy-deadline mq-deadline is roughly around the 5-10% mark across workloads for SSD. It's not universally true but the impact is not as severe. While this is not proof that the stack change is the sole root cause, it makes it less likely. >>> >>> I'm getting a little lost here. If I'm not mistaken, you are saying, >>> since the difference between two virtually identical schedulers >>> (legacy-deadline and mq-deadline) is only around 5-10%, while the >>> difference between cfq and mq-bfq-tput is higher, then in the latter >>> case it is not the stack's fault. Yet the loss of mq-bfq-tput in the >>> above test is exactly in the 5-10% range? What am I missing? Other >>> tests with mq-bfq-tput not yet reported? >>> > By chance, according to what you have measured so far, is there any > test where, instead, you expect or have seen bfq-mq-tput to always > lose? I could start from there. > global-dhp__io-fio-randread-async-randwrite-xfs but marginal enough that it could be the stack change. global-dhp__io-dbench4-fsync-ext4 was a universal loss across any machine tested. This is global-dhp__io-dbench4-fsync from mmtests using ext4 as a filesystem. The same is not true for XFS so the filesystem matters. >>> >>> Ok, then I will try to repeat global-dhp__io-dbench4-fsync-ext4 as >>> soon as I can, thanks. >>> >>> >> >> I've run this test and tried to further investigate this regression. >> For the moment, the gist seems to be that blk-mq plays an important >> role, not only with bfq (unless I'm considering the wrong numbers). >> Even if your main purpose in this thread was just to give a heads-up, >> I guess it may be useful to share what I have found out. In addition, >> I want to ask for some help, to try to get closer to the possible >> causes of at least this regression. If you think it would be better >> to open a new thread on this stuff, I'll do it. >> >> First, I got mixed results on my system. I'll focus only on the the >> case where mq-bfq-tput achieves its worst relative performance w.r.t. >> to cfq, which happens with 64 clients. Still, also in this case >> mq-bfq is better than cfq in all average values, but Flush. I don't >> know which are the best/right values to look at, so, here's the final >> report for both schedulers: >> >> CFQ >> >> OperationCountAvgLatMaxLat >> -- >> Flush1312020.069 348.594 >> Close 133696 0.00814.642 >> LockX 512 0.009 0.059 >> Rename7552 1.857 415.418 >> ReadX 270720 0.141 535.632 >> WriteX 89591 421.961 6363.271 >> Unlink 34048 1.281 662.467 >> UnlockX512 0.007 0.057 >> FIND_FIRST 62016 0.08625.060 >> SET_FILE_INFORMATION 15616 0.995 176.621 >> QUERY_FILE_INFORMATION 28734 0.004 1.372 >> QUERY_PATH_INFORMATION 170240 0.163 820.292 >> QUERY_FS_INFORMATION 28736 0.017 4.110
[PATCH v1] arm64: dts: rockchip: add rk805 node for rk3328-evb
Signed-off-by: Joseph Chen
---
arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 137
1 file changed, 137 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index cf27239..e8705fd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -50,8 +50,145 @@
chosen {
stdout-path = "serial2:150n8";
};
+
+ dc_12v: dc-12v {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <&dc_12v>;
+ };
};
&uart2 {
status = "okay";
};
+
+&i2c1 {
+ status = "okay";
+
+ rk805: rk805@18 {
+ compatible = "rockchip,rk805";
+ reg = <0x18>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk805-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc5-supply = <&vcc_io>;
+ vcc6-supply = <&vcc_io>;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <145>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <100>;
+ };
+ };
+
+ vdd_arm: DCDC_REG2 {
+ regulator-name = "vdd_arm";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <145>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <95>;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_io: DCDC_REG4 {
+ regulator-name = "vcc_io";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <330>;
+ };
+ };
+
+ vcc_18: LDO_REG1 {
+ regulator-name = "vcc_18";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <180>;
+ };
+ };
+
+ vcc18_emmc: LDO_REG2 {
+ regulator-name = "vcc18_emmc";
+
Re: [lkp-robot] [mm] 7674270022: will-it-scale.per_process_ops -19.3% regression
On Mon, Aug 07, 2017 at 10:51:00PM -0700, Nadav Amit wrote:
> Nadav Amit wrote:
>
> > Minchan Kim wrote:
> >
> >> Hi,
> >>
> >> On Tue, Aug 08, 2017 at 09:19:23AM +0800, kernel test robot wrote:
> >>> Greeting,
> >>>
> >>> FYI, we noticed a -19.3% regression of will-it-scale.per_process_ops due
> >>> to commit:
> >>>
> >>>
> >>> commit: 76742700225cad9df49f05399381ac3f1ec3dc60 ("mm: fix
> >>> MADV_[FREE|DONTNEED] TLB flush miss problem")
> >>> url:
> >>> https://github.com/0day-ci/linux/commits/Nadav-Amit/mm-migrate-prevent-racy-access-to-tlb_flush_pending/20170802-205715
> >>>
> >>>
> >>> in testcase: will-it-scale
> >>> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> >>> with 64G memory
> >>> with following parameters:
> >>>
> >>> nr_task: 16
> >>> mode: process
> >>> test: brk1
> >>> cpufreq_governor: performance
> >>>
> >>> test-description: Will It Scale takes a testcase and runs it from 1
> >>> through to n parallel copies to see if the testcase will scale. It builds
> >>> both a process and threads based test in order to see any differences
> >>> between the two.
> >>> test-url: https://github.com/antonblanchard/will-it-scale
> >>
> >> Thanks for the report.
> >> Could you explain what kinds of workload you are testing?
> >>
> >> Does it calls frequently madvise(MADV_DONTNEED) in parallel on multiple
> >> threads?
> >
> > According to the description it is "testcase:brk increase/decrease of one
> > page”. According to the mode it spawns multiple processes, not threads.
> >
> > Since a single page is unmapped each time, and the iTLB-loads increase
> > dramatically, I would suspect that for some reason a full TLB flush is
> > caused during do_munmap().
> >
> > If I find some free time, I’ll try to profile the workload - but feel free
> > to beat me to it.
>
> The root-cause appears to be that tlb_finish_mmu() does not call
> dec_tlb_flush_pending() - as it should. Any chance you can take care of it?
Oops, but with second looking, it seems it's not my fault. ;-)
https://marc.info/?l=linux-mm&m=150156699114088&w=2
Anyway, thanks for the pointing out.
xiaolong.ye, could you retest with this fix?
>From 83012114c9cd9304f0d55d899bb4b9329d0e22ac Mon Sep 17 00:00:00 2001
From: Minchan Kim
Date: Tue, 8 Aug 2017 17:05:19 +0900
Subject: [PATCH] mm: decrease tlb flush pending count in tlb_finish_mmu
The tlb pending count increased by tlb_gather_mmu should be decreased
at tlb_finish_mmu. Otherwise, A lot of TLB happens which makes
performance regression.
Signed-off-by: Minchan Kim
---
mm/memory.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory.c b/mm/memory.c
index 34b1fcb829e4..ad2617552f55 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -423,6 +423,7 @@ void tlb_finish_mmu(struct mmu_gather *tlb,
bool force = mm_tlb_flush_nested(tlb->mm);
arch_tlb_finish_mmu(tlb, start, end, force);
+ dec_tlb_flush_pending(tlb->mm);
}
/*
--
2.7.4
Re: [PATCH] leds: Convert to using %pOF instead of full_name
On Tue 2017-07-18 16:43:11, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc: Richard Purdie > Cc: Jacek Anaszewski Acked-by: Pavel Machek -- (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: Fwd: struct pt_regs missing in /usr/include/ tree for eBPF program compile
On 08/04/2017 05:28 PM, Daniel Borkmann wrote:
> From: Thomas-Mich Richter
> Date: Wed, Aug 2, 2017 at 1:22 AM
> [...]
>> I work on the perf tool and its bpf support for IBM s390 and came across a
>> strange issue compiling tools/testing/selftests/bpf/test_verifier.c on s390x.
>>
>> This is the compile error:
>> gcc -Wall -O2 -I../../../include/uapi -I../../../lib
>> -I../../../../include/generated
>>-DHAVE_GENHDR -I../../../includetest_verifier.c
>>/root/linux-devel/tools/testing/selftests/bpf/libbpf.a -lcap -lelf -o
>>/root/linux-devel/tools/testing/selftests/bpf/test_verifier
>> In file included from test_verifier.c:63:0:
>> ../../../include/uapi/linux/bpf_perf_event.h:14:17: error: field ‘regs’ has
>>incomplete type struct pt_regs regs;
>
> I actually came across the same issue today on s390
> while testing for something else.
>
>> This shows up in test case "unpriv: spill/fill of different pointers ldx"
>> at line 1811.
>> This issue is located in file /usr/include/linux/bpf_perf_event.h which is a
>> copy of the linux kernels include/uapi/linux/bpf_perf_event.h.
>>
>> It contains:
>> struct bpf_perf_event_data {
>> struct pt_regs regs;
>> __u64 sample_period;
>> };
>
> Yeah, correct.
>
>> On s390 struct pt_regs is not exported to user space and does not appear
>> anywhere in /usr/include.
>> How about other architectures beside Intel?
>> As far as I know
>> 1. the struct pt_regs contains only kernel registers, no user space
>> registers?
>> 2. Is part of the kernel API and should not be exported at all?
>
> Looking into the tree, it appears that the following archs
> export a definition of struct pt_regs as uapi typically in
> arch/*/include/uapi/asm/ptrace.h: x86, sparc, power, mips,
> microblaze, alpha, unicore32, parisc, score, sh, mn10300,
> tile, m68k, m32r, ia64, hexagon, h8300, frv, cris, c6x.
> And for these I couldn't find it: s390, arc, arm64, nios2.
>
> Anyone knows if there's any guidance on whether they must
> be exported or not? It appears at least the majority of
> archs is exporting them in one way or another.
>
> Looking at 2dbb4c05d048 ("bpf/samples: Fix PT_REGS_IP on
> s390x and use it") and d912557b3460 ("samples: bpf: enable
> trace samples for s390x"), this was added by Michael for
> the programs themselves, which were using kernel headers
> for walking structs in BPF tracing programs, so a bit
> unrelated to the uapi issue actually, but given the
> test_verifier has couple of test cases containing pt_regs,
> they should probably do the same thing and be using kernel
> headers given tracing programs inspect kernel-internal
> data structures typically (see BPF tracing samples).
I have looked at 2dbb4c05d048 ("bpf/samples: Fix PT_REGS_IP on
> s390x and use it"). This usage scenario is a bit different.
True it requires access to individual registers via context
pointer stored in register R1. The context pointer is
of type struct bpf_perf_event_data and the first member
is of type struct pt_regs.
The big difference is the compilation of samples/bpf/sampleip_kern.c.
It is built inside the kernel root directory .../linux and includes
./arch/s390/include/asm/ptrace.h (which defines struct pt_regs).
This is different from compiling
tools/testing/selftests/bpf/test_verifier.c. This compilation
does not happen inside the kernel root directory /linux
and thus needs some type of struct pt_regs definition in
user space.
Interestingly the test_verifier.c only needs the
size of the struct pt_regs. Both failing lines of code use
offset_of:
BPF_ALU64_IMM(BPF_ADD, BPF_REG_2,
-(__s32)offsetof(struct bpf_perf_event_data,
sample_period) - 8)),
which in fact subtracts the sizeof (struct pt_regs) from R2.
>
> Now, I would like to avoid going down that road to pull
> in kernel internal headers into test_verifier.c, could
> we instead add a bpf_ptregs.h helper in tools/testing/selftests/bpf/,
> where s390 and arm64 would put a definition to fallback when
> otherwise not available? Admittedly, it's a bit of a hack
> if exporting them is not an option, but 'normal' tracing
> progs would consult kernel headers anyway. Thoughts?
>
--
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB
243294
[PATCH 1/2] video: fbdev: Fix multiple style issues in xilinxfb
From: Hyun Kwon
All reported by from checkpatch
./scripts/checkpatch.pl --max-line-length 120 -strict -f
drivers/video/fbdev/xilinxfb.c
WARNING: Block comments should align the * on each line
WARNING: Block comments use a trailing */ on a separate line
WARNING: Block comments use * on subsequent lines
WARNING: please, no space before tabs
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: braces {} are not necessary for single statement blocks
WARNING: Missing a blank line after declarations
WARNING: struct of_device_id should normally be const
CHECK: Please don't use multiple blank lines
CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Alignment should match open parenthesis
CHECK: 'Endianess' may be misspelled - perhaps 'Endianness'?
CHECK: spaces preferred around that '*' (ctx:VxV)
ERROR: that open brace { should be on the previous line
Signed-off-by: Hyun Kwon
Signed-off-by: Michal Simek
---
drivers/video/fbdev/xilinxfb.c | 56 +-
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
index 17dc119c7a98..0d828e46d704 100644
--- a/drivers/video/fbdev/xilinxfb.c
+++ b/drivers/video/fbdev/xilinxfb.c
@@ -41,7 +41,6 @@
#define DRIVER_NAME"xilinxfb"
-
/*
* Xilinx calls it "TFT LCD Controller" though it can also be used for
* the VGA port on the Xilinx ML40x board. This is a hardware display
@@ -92,8 +91,9 @@ struct xilinxfb_platform_data {
u32 xvirt, yvirt; /* resolution of memory buffer */
/* Physical address of framebuffer memory; If non-zero, driver
- * will use provided memory address instead of allocating one from
- * the consistent pool. */
+* will use provided memory address instead of allocating one from
+* the consistent pool.
+*/
u32 fb_phys;
};
@@ -128,18 +128,18 @@ struct xilinxfb_platform_data {
.activate = FB_ACTIVATE_NOW
};
-
#define BUS_ACCESS_FLAG0x1 /* 1 = BUS, 0 = DCR */
#define LITTLE_ENDIAN_ACCESS 0x2 /* LITTLE ENDIAN IO functions */
struct xilinxfb_drvdata {
-
struct fb_info info; /* FB driver info record */
phys_addr_t regs_phys; /* phys. address of the control
- registers */
+* registers
+*/
void __iomem*regs; /* virt. address of the control
- registers */
+* registers
+*/
#ifdef CONFIG_PPC_DCR
dcr_host_t dcr_host;
unsigned intdcr_len;
@@ -148,7 +148,7 @@ struct xilinxfb_drvdata {
dma_addr_t fb_phys;/* phys. address of the frame buffer */
int fb_alloced; /* Flag, was the fb memory alloced? */
- u8 flags; /* features of the driver */
+ u8 flags; /* features of the driver */
u32 reg_ctrl_default;
@@ -165,7 +165,7 @@ struct xilinxfb_drvdata {
* which bus its connected and call the appropriate write API.
*/
static void xilinx_fb_out32(struct xilinxfb_drvdata *drvdata, u32 offset,
- u32 val)
+ u32 val)
{
if (drvdata->flags & BUS_ACCESS_FLAG) {
if (drvdata->flags & LITTLE_ENDIAN_ACCESS)
@@ -195,8 +195,8 @@ static u32 xilinx_fb_in32(struct xilinxfb_drvdata *drvdata,
u32 offset)
}
static int
-xilinx_fb_setcolreg(unsigned regno, unsigned red, unsigned green, unsigned
blue,
- unsigned transp, struct fb_info *fbi)
+xilinx_fb_setcolreg(unsigned int regno, unsigned int red, unsigned int green,
+ unsigned int blue, unsigned int transp, struct fb_info *fbi)
{
u32 *palette = fbi->pseudo_palette;
@@ -205,9 +205,11 @@ static u32 xilinx_fb_in32(struct xilinxfb_drvdata
*drvdata, u32 offset)
if (fbi->var.grayscale) {
/* Convert color to grayscale.
-* grayscale = 0.30*R + 0.59*G + 0.11*B */
- red = green = blue =
- (red * 77 + green * 151 + blue * 28 + 127) >> 8;
+* grayscale = 0.30*R + 0.59*G + 0.11*B
+*/
+ blue = (red * 77 + green * 151 + blue * 28 + 127) >> 8;
+ green = blue;
+ red = green;
}
/* fbi->fix.visual is always FB_VISUAL_TRUECOLOR */
@@ -241,13 +243,11 @@ static u32 xilinx_fb_in32(struct xilinxfb_drvdata
*drvdata, u32 offset)
xilinx_fb_out32(drvdata, REG_CTRL, 0);
default:
break;
-
}
return 0; /* success */
}
-static struct fb_ops xilinxfb_ops =
-{
+static struct fb_ops xilinxfb_ops = {
.owner
[PATCH 2/2] video: fbdev: Enable Xilinx FB for ZynqMP
Enable this driver for Xilinx ZynqMP. Signed-off-by: Michal Simek --- drivers/video/fbdev/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 5c6696bb56da..5e58f5ec0a28 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2173,7 +2173,7 @@ config FB_PS3_DEFAULT_SIZE_M config FB_XILINX tristate "Xilinx frame buffer support" - depends on FB && (XILINX_VIRTEX || MICROBLAZE || ARCH_ZYNQ) + depends on FB && (XILINX_VIRTEX || MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.9.1
Re: [PATCH v3 3/5] pwm-backlight: add support for PWM delays proprieties.
On Thu 2017-07-20 11:37:17, Daniel Thompson wrote:
> On 20/07/17 09:06, Pavel Machek wrote:
> >Hi!
> >
> >>>--- a/drivers/video/backlight/pwm_bl.c
> >>>+++ b/drivers/video/backlight/pwm_bl.c
> >>>@@ -10,6 +10,7 @@
> >>> * published by the Free Software Foundation.
> >>> */
> >>>+#include
> >>> #include
> >>> #include
> >>> #include
> >>>@@ -35,6 +36,7 @@ struct pwm_bl_data {
> >>> struct gpio_desc*enable_gpio;
> >>> unsigned intscale;
> >>> boollegacy;
> >>>+ unsigned intpwm_delay[2];
> >>
> >>Two named members would be better here (eliminating the "magic" 0
> >>and 1).
> >
> >My thought, too.
> >
> >>>@@ -56,6 +58,9 @@ static void pwm_backlight_power_on(struct pwm_bl_data
> >>>*pb, int brightness)
> >>> pwm_enable(pb->pwm);
> >>>+ if (pb->pwm_delay[0])
> >>>+ usleep_range(pb->pwm_delay[0], pb->pwm_delay[0] * 2);
> >
> >Plus I'd just do the delay unconditionally :-).
>
> ... does this still apply if this code is switched to msleep()?
No.
> msleep() has no wait avoidance[1] and if lots of drivers are reckless about
> sleeping for 10ms it soon starts to show up in the boot time (especially
> optimized ones).
...
> [1] As it happens I can't see that many early bail out paths in
> usleep_range() either.
Well, in usleep_range(1,2) should be fast enough operation, and
usleep_range(0,0) should be similar to usleep_range(1,2) at worst :-).
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] ata: make ata_port_operations const
On Mon, Aug 7, 2017 at 10:04 PM, Joe Perches wrote: > On Mon, 2017-08-07 at 09:29 -0700, Tejun Heo wrote: >> Hello, >> >> On Mon, Aug 07, 2017 at 08:54:21PM +0530, Bhumika Goyal wrote: >> > I compiled the .o files and checked the size before and after >> > compilation. After making the structure const, bytes should move from >> > data to text segment of the memory and this is what happened. So, this >> > is how I tested it. >> >> Ah, I see, so the port_operations is never used directly. I'm not >> sure whether it'd be a good idea to selectively pick these and makr >> them const. Let's just leave them be. > > Why? > > Things that are never accessed as other than const should > be const no? > I think it would be better to leave them as in most situations the ata_port_operations structures cannot be const as they are only used in the port_ops field of an ata_port_info structure and this field is not const. Having two ata_port_operations const and others non-const will cause code inconsistency. Thanks, Bhumika > Why leave unnecessary exposure for muckery?
Re: [PATCH V1] thermal: qcom-spmi-temp-alarm: add support for GEN2 PMIC peripherals
On Thu, 2017-07-13 at 17:39 +0530, Kiran Gunda wrote:
> From: David Collins
>
> Add support for the TEMP_ALARM GEN2 PMIC peripheral subtype. The
> GEN2 subtype defines an over temperature state with hysteresis
> instead of stage in the status register. There are two GEN2
> states corresponding to stages 1 and 2.
>
> Signed-off-by: David Collins
> Signed-off-by: Kiran Gunda
Ivan,
can you please review this patch and let me know your opinion?
thanks,
rui
> ---
> drivers/thermal/qcom-spmi-temp-alarm.c | 92
> ++
> 1 file changed, 71 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/thermal/qcom-spmi-temp-alarm.c
> b/drivers/thermal/qcom-spmi-temp-alarm.c
> index f502419..a5e17ba 100644
> --- a/drivers/thermal/qcom-spmi-temp-alarm.c
> +++ b/drivers/thermal/qcom-spmi-temp-alarm.c
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2011-2015, The Linux Foundation. All rights
> reserved.
> + * Copyright (c) 2011-2015, 2017, The Linux Foundation. All rights
> reserved.
> *
> * This program is free software; you can redistribute it and/or
> modify
> * it under the terms of the GNU General Public License version 2
> and
> @@ -11,6 +11,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -29,13 +30,17 @@
> #define QPNP_TM_REG_ALARM_CTRL 0x46
>
> #define QPNP_TM_TYPE 0x09
> -#define QPNP_TM_SUBTYPE 0x08
> +#define QPNP_TM_SUBTYPE_GEN1 0x08
> +#define QPNP_TM_SUBTYPE_GEN2 0x09
>
> -#define STATUS_STAGE_MASK0x03
> +#define STATUS_GEN1_STAGE_MASK GENMASK(1, 0)
> +#define STATUS_GEN2_STATE_MASK GENMASK(6, 4)
> +#define STATUS_GEN2_STATE_SHIFT 4
>
> -#define SHUTDOWN_CTRL1_THRESHOLD_MASK0x03
> +#define SHUTDOWN_CTRL1_OVERRIDE_MASK GENMASK(7, 6)
> +#define SHUTDOWN_CTRL1_THRESHOLD_MASKGENMASK(1, 0)
>
> -#define ALARM_CTRL_FORCE_ENABLE 0x80
> +#define ALARM_CTRL_FORCE_ENABLE BIT(7)
>
> /*
> * Trip point values based on threshold control
> @@ -58,6 +63,7 @@
> struct qpnp_tm_chip {
> struct regmap *map;
> struct thermal_zone_device *tz_dev;
> + unsigned intsubtype;
> longtemp;
> unsigned intthresh;
> unsigned intstage;
> @@ -66,6 +72,9 @@ struct qpnp_tm_chip {
> struct iio_channel *adc;
> };
>
> +/* This array maps from GEN2 alarm state to GEN1 alarm stage */
> +static const unsigned int alarm_state_map[8] = {0, 1, 1, 2, 2, 3, 3,
> 3};
> +
> static int qpnp_tm_read(struct qpnp_tm_chip *chip, u16 addr, u8
> *data)
> {
> unsigned int val;
> @@ -84,30 +93,59 @@ static int qpnp_tm_write(struct qpnp_tm_chip
> *chip, u16 addr, u8 data)
> return regmap_write(chip->map, chip->base + addr, data);
> }
>
> +/**
> + * qpnp_tm_get_temp_stage() - return over-temperature stage
> + * @chip:Pointer to the qpnp_tm chip
> + *
> + * Return: stage (GEN1) or state (GEN2) on success, or errno on
> failure.
> + */
> +static int qpnp_tm_get_temp_stage(struct qpnp_tm_chip *chip)
> +{
> + int ret;
> + u8 reg = 0;
> +
> + ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, ®);
> + if (ret < 0)
> + return ret;
> +
> + if (chip->subtype == QPNP_TM_SUBTYPE_GEN1)
> + ret = reg & STATUS_GEN1_STAGE_MASK;
> + else
> + ret = (reg & STATUS_GEN2_STATE_MASK) >>
> STATUS_GEN2_STATE_SHIFT;
> +
> + return ret;
> +}
> +
> /*
> * This function updates the internal temp value based on the
> * current thermal stage and threshold as well as the previous stage
> */
> static int qpnp_tm_update_temp_no_adc(struct qpnp_tm_chip *chip)
> {
> - unsigned int stage;
> + unsigned int stage, stage_new, stage_old;
> int ret;
> - u8 reg = 0;
>
> - ret = qpnp_tm_read(chip, QPNP_TM_REG_STATUS, ®);
> + ret = qpnp_tm_get_temp_stage(chip);
> if (ret < 0)
> return ret;
> + stage = ret;
>
> - stage = reg & STATUS_STAGE_MASK;
> + if (chip->subtype == QPNP_TM_SUBTYPE_GEN1) {
> + stage_new = stage;
> + stage_old = chip->stage;
> + } else {
> + stage_new = alarm_state_map[stage];
> + stage_old = alarm_state_map[chip->stage];
> + }
>
> - if (stage > chip->stage) {
> + if (stage_new > stage_old) {
> /* increasing stage, use lower bound */
> - chip->temp = (stage - 1) * TEMP_STAGE_STEP +
> + chip->temp = (stage_new - 1) * TEMP_STAGE_STEP +
> chip->thresh * TEMP_THRESH_STEP +
> TEMP_STAGE_HYSTERESIS +
> TEMP_THRESH_MIN;
> - } else if (stage < chip->stage) {
> + } else if (stage_new < stage_old) {
> /* decreasing st
Re: [PATCH v1 5/6] zram: remove zram_rw_page
Hi Sergey, On Tue, Aug 08, 2017 at 04:02:26PM +0900, Sergey Senozhatsky wrote: > On (08/08/17 15:50), Minchan Kim wrote: > > With on-stack-bio, rw_page interface doesn't provide a clear performance > > benefit for zram and surely has a maintenance burden, so remove the > > last user to remove rw_page completely. > > OK, never really liked it, I think we had that conversation before. > > as far as I remember, zram_rw_page() was the reason we had to do some > tricks with init_lock to make lockdep happy. may be now we can "simplify" > the things back. I cannot remember. Blame my brain. ;-) Anyway, it's always welcome to make thing simple. Could you send a patch after settle down this patchset? > > > > Cc: Sergey Senozhatsky > > Signed-off-by: Minchan Kim > > Reviewed-by: Sergey Senozhatsky Thanks for the review!
[PATCH v1 5/5] soc: mediatek: add MT6755 scpsys support
This adds scpsys support for MT6755
Signed-off-by: Mars Cheng
---
drivers/soc/mediatek/mtk-scpsys.c| 116 ++
include/dt-bindings/power/mt6755-power.h | 26 +++
2 files changed, 142 insertions(+)
create mode 100644 include/dt-bindings/power/mt6755-power.h
diff --git a/drivers/soc/mediatek/mtk-scpsys.c
b/drivers/soc/mediatek/mtk-scpsys.c
index ceb2cc4..a745d23 100644
--- a/drivers/soc/mediatek/mtk-scpsys.c
+++ b/drivers/soc/mediatek/mtk-scpsys.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include
#include
@@ -586,6 +587,118 @@ static int __init scpsys_probe_mt2701(struct
platform_device *pdev)
}
/*
+ * MT6755 power domain support
+ */
+
+static const struct scp_domain_data scp_domain_data_mt6755[] = {
+ [MT6755_POWER_DOMAIN_VDEC] = {
+ .name = "vdec",
+ .sta_mask = PWR_STATUS_VDEC,
+ .ctl_offs = 0x300,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_VDEC},
+ },
+ [MT6755_POWER_DOMAIN_VENC] = {
+ .name = "venc",
+ .sta_mask = PWR_STATUS_VENC,
+ .ctl_offs = 0x304,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_MM},
+ },
+ [MT6755_POWER_DOMAIN_ISP] = {
+ .name = "isp",
+ .sta_mask = PWR_STATUS_ISP,
+ .ctl_offs = 0x308,
+ .sram_pdn_bits = GENMASK(9, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ .clk_id = {CLK_MM},
+ },
+ [MT6755_POWER_DOMAIN_MM] = {
+ .name = "mm",
+ .sta_mask = PWR_STATUS_DISP,
+ .ctl_offs = 0x30C,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ .clk_id = {CLK_MM},
+ .bus_prot_mask = BIT(1),
+ },
+ [MT6755_POWER_DOMAIN_AUDIO] = {
+ .name = "audio",
+ .sta_mask = PWR_STATUS_AUDIO,
+ .ctl_offs = 0x314,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .clk_id = {CLK_NONE},
+ },
+ [MT6755_POWER_DOMAIN_MFG_ASYNC] = {
+ .name = "mfg_async",
+ .sta_mask = PWR_STATUS_MFG_ASYNC,
+ .ctl_offs = 0x334,
+ .sram_pdn_bits = 0,
+ .sram_pdn_ack_bits = 0,
+ .clk_id = {CLK_MFG},
+ },
+ [MT6755_POWER_DOMAIN_MFG] = {
+ .name = "mfg",
+ .sta_mask = PWR_STATUS_MFG,
+ .ctl_offs = 0x338,
+ .sram_pdn_bits = GENMASK(8, 8),
+ .sram_pdn_ack_bits = GENMASK(16, 16),
+ .clk_id = {CLK_NONE},
+ .bus_prot_mask = BIT(21),
+ },
+};
+
+#define NUM_DOMAINS_MT6755 ARRAY_SIZE(scp_domain_data_mt6755)
+#define SPM_PWR_STATUS_MT6755 0x0180
+#define SPM_PWR_STATUS_2ND_MT6755 0x0184
+
+static int __init scpsys_probe_mt6755(struct platform_device *pdev)
+{
+ struct scp *scp;
+ struct genpd_onecell_data *pd_data;
+ int ret;
+ struct scp_ctrl_reg scp_reg;
+
+ scp_reg.pwr_sta_offs = SPM_PWR_STATUS_MT6755;
+ scp_reg.pwr_sta2nd_offs = SPM_PWR_STATUS_2ND_MT6755;
+
+ scp = init_scp(pdev, scp_domain_data_mt6755, NUM_DOMAINS_MT6755,
+ &scp_reg);
+ if (IS_ERR(scp))
+ return PTR_ERR(scp);
+
+ mtk_register_power_domains(pdev, scp, NUM_DOMAINS_MT6755);
+
+ pd_data = &scp->pd_data;
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6755_POWER_DOMAIN_MM],
+
pd_data->domains[MT6755_POWER_DOMAIN_VDEC]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6755_POWER_DOMAIN_MM],
+pd_data->domains[MT6755_POWER_DOMAIN_ISP]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(pd_data->domains[MT6755_POWER_DOMAIN_MM],
+
pd_data->domains[MT6797_POWER_DOMAIN_VENC]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ ret = pm_genpd_add_subdomain(
+ pd_data->domains[MT6755_POWER_DOMAIN_MFG_ASYNC],
+ pd_data->domains[MT6755_POWER_DOMAIN_MFG]);
+ if (ret && IS_ENABLED(CONFIG_PM))
+ dev_err(&pdev->dev, "Failed to add subdomain: %d\n", ret);
+
+ return 0;
+}
+
+/*
* MT6797 power domain support
*/
@@ -832,6 +945,9 @@ static int __init scpsys_probe_mt8173(struct
platform_device *pdev)
Re: [PATCH] f2fs: fix some cases with reserved_blocks
On 2017/8/8 14:33, Yunlong Song wrote:
> Does this means the reserved_blocks cannot be used by users by can be
> used by filesystem?
Yup.
> If it can be used by filesystem, then this cannot ensure the flash
> device really reserve the
> reserved_blocks space, right? The reserved_blocks is just for users?
No, only if we didn't issue any discards, otherwise we can benefit from less GC
overhead in device due to higher over-provision rate.
Thanks,
>
> On 2017/8/8 14:08, Chao Yu wrote:
>> On 2017/8/8 12:12, Yunlong Song wrote:
>>> Signed-off-by: Yunlong Song
>>> ---
>>> fs/f2fs/recovery.c | 3 ++-
>>> fs/f2fs/super.c| 9 +
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/fs/f2fs/recovery.c b/fs/f2fs/recovery.c
>>> index a3d0261..e288319 100644
>>> --- a/fs/f2fs/recovery.c
>>> +++ b/fs/f2fs/recovery.c
>>> @@ -51,7 +51,8 @@ bool space_for_roll_forward(struct f2fs_sb_info *sbi)
>>> {
>>> s64 nalloc = percpu_counter_sum_positive(&sbi->alloc_valid_block_count);
>>>
>>> - if (sbi->last_valid_block_count + nalloc > sbi->user_block_count)
>>> + if (sbi->last_valid_block_count + nalloc +
>>> + sbi->reserved_blocks > sbi->user_block_count)
>> I think we can treat reserved blocks as over-provision space in f2fs, so it
>> would be safe to store invalid data (may become valid during recovery) there.
>> Anyway, it OK to remain old condition judgment.
>>
>>> return false;
>>> return true;
>>> }
>>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>>> index 4c1bdcb..c644bf5 100644
>>> --- a/fs/f2fs/super.c
>>> +++ b/fs/f2fs/super.c
>>> @@ -946,6 +946,7 @@ static int f2fs_statfs(struct dentry *dentry, struct
>>> kstatfs *buf)
>>> u64 id = huge_encode_dev(sb->s_bdev->bd_dev);
>>> block_t total_count, user_block_count, start_count, ovp_count;
>>> u64 avail_node_count;
>>> + block_t avail_user_block_count;
>>>
>>> total_count = le64_to_cpu(sbi->raw_super->block_count);
>>> user_block_count = sbi->user_block_count;
>>> @@ -953,16 +954,16 @@ static int f2fs_statfs(struct dentry *dentry, struct
>>> kstatfs *buf)
>>> ovp_count = SM_I(sbi)->ovp_segments << sbi->log_blocks_per_seg;
>>> buf->f_type = F2FS_SUPER_MAGIC;
>>> buf->f_bsize = sbi->blocksize;
>>> + avail_user_block_count = user_block_count - sbi->reserved_blocks;
>>>
>>> buf->f_blocks = total_count - start_count;
>>> buf->f_bfree = user_block_count - valid_user_blocks(sbi) + ovp_count;
>>> - buf->f_bavail = user_block_count - valid_user_blocks(sbi) -
>>> - sbi->reserved_blocks;
>>> + buf->f_bavail = avail_user_block_count - valid_user_blocks(sbi);
>>>
>>> avail_node_count = sbi->total_node_count - F2FS_RESERVED_NODE_NUM;
>>>
>>> - if (avail_node_count > user_block_count) {
>>> - buf->f_files = user_block_count;
>>> + if (avail_node_count > avail_user_block_count) {
>> Likewise f_blocks calculation, the f_files one doesn't need to consider
>> reserved_blocks.
>>
>> Thanks,
>>
>>> + buf->f_files = avail_user_block_count;
>>> buf->f_ffree = buf->f_bavail;
>>> } else {
>>> buf->f_files = avail_node_count;
>>>
>>
>> .
>>
>
[PATCH v1 4/5] clk: mediatek: add clk support for MT6755
Add MT6755 clock support, include topckgen, apmixedsys, infracfg,
and subsystem clocks
Signed-off-by: Mars Cheng
---
drivers/clk/mediatek/Kconfig | 32 ++
drivers/clk/mediatek/Makefile |5 +
drivers/clk/mediatek/clk-mt6755-img.c | 81
drivers/clk/mediatek/clk-mt6755-mm.c | 148 +++
drivers/clk/mediatek/clk-mt6755-vdec.c | 91 +
drivers/clk/mediatek/clk-mt6755-venc.c | 78
drivers/clk/mediatek/clk-mt6755.c | 666
7 files changed, 1101 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt6755-img.c
create mode 100644 drivers/clk/mediatek/clk-mt6755-mm.c
create mode 100644 drivers/clk/mediatek/clk-mt6755-vdec.c
create mode 100644 drivers/clk/mediatek/clk-mt6755-venc.c
create mode 100644 drivers/clk/mediatek/clk-mt6755.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 28739a9..1cc7061 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -50,6 +50,38 @@ config COMMON_CLK_MT2701_BDPSYS
---help---
This driver supports Mediatek MT2701 bdpsys clocks.
+config COMMON_CLK_MT6755
+ bool "Clock driver for Mediatek MT6755"
+ depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
+ select COMMON_CLK_MEDIATEK
+ default ARCH_MEDIATEK && ARM64
+ ---help---
+ This driver supports Mediatek MT6755 basic clocks.
+
+config COMMON_CLK_MT6755_MMSYS
+ bool "Clock driver for Mediatek MT6755 mmsys"
+ depends on COMMON_CLK_MT6755
+ ---help---
+ This driver supports Mediatek MT6755 mmsys clocks.
+
+config COMMON_CLK_MT6755_IMGSYS
+ bool "Clock driver for Mediatek MT6755 imgsys"
+ depends on COMMON_CLK_MT6755
+ ---help---
+ This driver supports Mediatek MT6755 imgsys clocks.
+
+config COMMON_CLK_MT6755_VDECSYS
+ bool "Clock driver for Mediatek MT6755 vdecsys"
+ depends on COMMON_CLK_MT6755
+ ---help---
+ This driver supports Mediatek MT6755 vdecsys clocks.
+
+config COMMON_CLK_MT6755_VENCSYS
+ bool "Clock driver for Mediatek MT6755 vencsys"
+ depends on COMMON_CLK_MT6755
+ ---help---
+ This driver supports Mediatek MT6755 vencsys clocks.
+
config COMMON_CLK_MT6797
bool "Clock driver for Mediatek MT6797"
depends on (ARCH_MEDIATEK && ARM64) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 2a755b5..ed680fc 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,5 +1,10 @@
obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o
clk-apmixed.o clk-cpumux.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT6755) += clk-mt6755.o
+obj-$(CONFIG_COMMON_CLK_MT6755_IMGSYS) += clk-mt6755-img.o
+obj-$(CONFIG_COMMON_CLK_MT6755_MMSYS) += clk-mt6755-mm.o
+obj-$(CONFIG_COMMON_CLK_MT6755_VDECSYS) += clk-mt6755-vdec.o
+obj-$(CONFIG_COMMON_CLK_MT6755_VENCSYS) += clk-mt6755-venc.o
obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
diff --git a/drivers/clk/mediatek/clk-mt6755-img.c
b/drivers/clk/mediatek/clk-mt6755-img.c
new file mode 100644
index 000..b9e6832
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt6755-img.c
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2017 MediaTek Inc.
+ * Author: Wendell Lin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+#include "clk-gate.h"
+
+static const struct mtk_gate_regs img_cg_regs = {
+ .set_ofs = 0x0004,
+ .clr_ofs = 0x0008,
+ .sta_ofs = 0x,
+};
+
+#define GATE_IMG(_id, _name, _parent, _shift) {\
+ .id = _id, \
+ .name = _name, \
+ .parent_name = _parent, \
+ .regs = &img_cg_regs, \
+ .shift = _shift,\
+ .ops = &mtk_clk_gate_ops_setclr,\
+ }
+
+static const struct mtk_gate img_clks[] = {
+ GATE_IMG(CLK_IMG_IMAGE_LARB2_SMI, "img_image_larb2_smi", "mm_sel", 0),
+ GATE_IMG(CLK_IMG_IMAGE_CAM_SMI, "img_image_cam_smi", "mm_sel", 5),
+ GATE_IMG(CLK_IMG_IMAGE_CAM_CAM, "img_image_cam_cam", "mm_sel", 6),
+ GATE_IMG(CLK_IMG_IMAGE_SEN_TG, "img_image_sen_tg", "mm_sel", 7),
+ GATE_IMG(CLK_IMG_IMAGE_SEN_CAM, "img_image_sen_cam", "camtg_sel", 8),
+
[PATCH 0/5] Add clk and scpsys support for MT6755
Mars Cheng (3): clk: mediatek: add mt6755 clock ID clk: mediatek: add clk support for MT6755 soc: mediatek: add MT6755 scpsys support wendell.lin (2): dt-bindings: mediatek: add MT6755 power dt-bindings dt-bindings: arm: mediatek: document clk bindings for MT6755 .../bindings/arm/mediatek/mediatek,apmixedsys.txt |1 + .../bindings/arm/mediatek/mediatek,imgsys.txt |1 + .../bindings/arm/mediatek/mediatek,infracfg.txt|1 + .../bindings/arm/mediatek/mediatek,mmsys.txt |1 + .../bindings/arm/mediatek/mediatek,topckgen.txt|1 + .../bindings/arm/mediatek/mediatek,vdecsys.txt |1 + .../bindings/arm/mediatek/mediatek,vencsys.txt |1 + .../devicetree/bindings/soc/mediatek/scpsys.txt|3 + drivers/clk/mediatek/Kconfig | 32 + drivers/clk/mediatek/Makefile |5 + drivers/clk/mediatek/clk-mt6755-img.c | 81 +++ drivers/clk/mediatek/clk-mt6755-mm.c | 148 + drivers/clk/mediatek/clk-mt6755-vdec.c | 91 +++ drivers/clk/mediatek/clk-mt6755-venc.c | 78 +++ drivers/clk/mediatek/clk-mt6755.c | 666 drivers/soc/mediatek/mtk-scpsys.c | 116 include/dt-bindings/clock/mt6755-clk.h | 293 + include/dt-bindings/power/mt6755-power.h | 26 + 18 files changed, 1546 insertions(+) create mode 100644 drivers/clk/mediatek/clk-mt6755-img.c create mode 100644 drivers/clk/mediatek/clk-mt6755-mm.c create mode 100644 drivers/clk/mediatek/clk-mt6755-vdec.c create mode 100644 drivers/clk/mediatek/clk-mt6755-venc.c create mode 100644 drivers/clk/mediatek/clk-mt6755.c create mode 100644 include/dt-bindings/clock/mt6755-clk.h create mode 100644 include/dt-bindings/power/mt6755-power.h
[PATCH v1 3/5] clk: mediatek: add mt6755 clock ID
Signed-off-by: Mars Cheng --- include/dt-bindings/clock/mt6755-clk.h | 293 1 file changed, 293 insertions(+) create mode 100644 include/dt-bindings/clock/mt6755-clk.h diff --git a/include/dt-bindings/clock/mt6755-clk.h b/include/dt-bindings/clock/mt6755-clk.h new file mode 100644 index 000..b1ec860 --- /dev/null +++ b/include/dt-bindings/clock/mt6755-clk.h @@ -0,0 +1,293 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * Author: Wendell Lin + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef _DT_BINDINGS_CLK_MT6755_H +#define _DT_BINDINGS_CLK_MT6755_H + +/* TOPCKGEN */ +#define CLK_TOP_MUX_AXI1 +#define CLK_TOP_MUX_MEM2 +#define CLK_TOP_MUX_DDRPHY 3 +#define CLK_TOP_MUX_MM 4 +#define CLK_TOP_MUX_PWM5 +#define CLK_TOP_MUX_VDEC 6 +#define CLK_TOP_MUX_MFG7 +#define CLK_TOP_MUX_CAMTG 8 +#define CLK_TOP_MUX_UART 9 +#define CLK_TOP_MUX_SPI10 +#define CLK_TOP_MUX_MSDC50_0_HCLK 11 +#define CLK_TOP_MUX_MSDC50_0 12 +#define CLK_TOP_MUX_MSDC30_1 14 +#define CLK_TOP_MUX_MSDC30_2 15 +#define CLK_TOP_MUX_MSDC30_3 16 +#define CLK_TOP_MUX_AUDIO 17 +#define CLK_TOP_MUX_AUDINTBUS 18 +#define CLK_TOP_MUX_PMICSPI19 +#define CLK_TOP_MUX_ATB20 +#define CLK_TOP_MUX_DPI0 21 +#define CLK_TOP_MUX_SCAM 22 +#define CLK_TOP_MUX_AUD1 24 +#define CLK_TOP_MUX_AUD2 25 +#define CLK_TOP_MUX_DISPPWM26 +#define CLK_TOP_MUX_SSUSBTOPSYS27 +#define CLK_TOP_MUX_USBTOP 28 +#define CLK_TOP_MUX_SPM29 +#define CLK_TOP_MUX_BSISPI 30 +#define CLK_TOP_MUX_I2C31 +#define CLK_TOP_MUX_DVFSP 32 +#define CLK_TOP_AD_APLL1_CK33 +#define CLK_TOP_AD_APLL2_CK34 +#define CLK_TOP_MMPLL_CK 35 +#define CLK_TOP_DDRX1_CK 36 +#define CLK_TOP_DMPLL_CK 37 +#define CLK_TOP_MPLL_208M_CK 38 +#define CLK_TOP_MSDCPLL_CK 39 +#define CLK_TOP_MSDCPLL_D1640 +#define CLK_TOP_MSDCPLL_D2 41 +#define CLK_TOP_MSDCPLL_D4 42 +#define CLK_TOP_MSDCPLL_D8 43 +#define CLK_TOP_OSC_D2 44 +#define CLK_TOP_OSC_D4 45 +#define CLK_TOP_OSC_D8 46 +#define CLK_TOP_SYSPLL_D3 47 +#define CLK_TOP_SYSPLL_D3_D3 48 +#define CLK_TOP_SYSPLL_D5 49 +#define CLK_TOP_SYSPLL_D7 50 +#define CLK_TOP_SYSPLL1_D2 51 +#define CLK_TOP_SYSPLL1_D4 52 +#define CLK_TOP_SYSPLL1_D8 53 +#define CLK_TOP_SYSPLL1_D1654 +#define CLK_TOP_SYSPLL2_D2 55 +#define CLK_TOP_SYSPLL2_D4 56 +#define CLK_TOP_SYSPLL3_D2 57 +#define CLK_TOP_SYSPLL3_D4 58 +#define CLK_TOP_SYSPLL4_D2 59 +#define CLK_TOP_SYSPLL4_D4 60 +#define CLK_TOP_TVDPLL_D2 61 +#define CLK_TOP_TVDPLL_D4 62 +#define CLK_TOP_TVDPLL_D8 63 +#define CLK_TOP_TVDPLL_D16 64 +#define CLK_TOP_UNIVPLL_D2 65 +#define CLK_TOP_UNIVPLL_D3 66 +#define CLK_TOP_UNIVPLL_D5 67 +#define CLK_TOP_UNIVPLL_D7 68 +#define CLK_TOP_UNIVPLL_D2669 +#define CLK_TOP_UNIVPLL1_D270 +#define CLK_TOP_UNIVPLL1_D471 +#define CLK_TOP_UNIVPLL1_D872 +#define CLK_TOP_UNIVPLL2_D273 +#define CLK_TOP_UNIVPLL2_D474 +#define CLK_TOP_UNIVPLL2_D875 +#define CLK_TOP_UNIVPLL3_D276 +#define CLK_TOP_UNIVPLL3_D477 +#define CLK_TOP_VENCPLL_CK 78 +#define CLK_TOP_WHPLL_AUDIO_CK 79 +#define CLK_TOP_CLKPH_MCK_O80 +#define CLK_TOP_DPI_CK 81 +#define CLK_TOP_MUX_USB20 82 +#define CLK_TOP_MUX_SCP83 +#define CLK_TOP_MUX_IRDA 84 +#define CLK_TOP_MUX_IRTX 85 +#define CLK_TOP_AD_SYS_26M_CK 86 +#define CLK_TOP_AD_SYS_26M_D2 87 +#define CLK_TOP_DMPLL_D2 88 +#define CLK_TOP_DMPLL_D4 89 +#define CLK_TOP_DMPLL_D8 90 +#define CLK_TOP_SYSPLL_D2 91 +#define CLK_TOP_SYSPLL4_D2_D8 92 +#define CLK_TOP_TVDPLL_CK 93 +#define CLK_TOP_VENCPLL_D3 94 +#define CLK_TOP_SYSPL
Re: [PATCH v2 0/4] KVM: optimize the kvm_vcpu_on_spin
On 2017/8/8 15:41, Cornelia Huck wrote: > On Tue, 8 Aug 2017 12:05:31 +0800 > "Longpeng(Mike)" wrote: > >> This is a simple optimization for kvm_vcpu_on_spin, the >> main idea is described in patch-1's commit msg. > > I think this generally looks good now. > >> >> I did some tests base on the RFC version, the result shows >> that it can improves the performance slightly. > > Did you re-run tests on this version? Hi Cornelia, I didn't re-run tests on V2. But the major difference between RFC and V2 is that V2 only cache result for X86 (s390/arm needn't) and V2 saves a expensive operation ( 440-1400 cycles on my test machine ) for X86/VMX. So I think V2's performance is at least the same as RFC or even slightly better. :) > > I would also like to see some s390 numbers; unfortunately I only have a > z/VM environment and any performance numbers would be nearly useless > there. Maybe somebody within IBM with a better setup can run a quick > test? > > . > -- Regards, Longpeng(Mike)
Re: [PATCH] i2c: imx: Remove a useless test in 'i2c_imx_init_recovery_info()'
On Tue, Aug 08, 2017 at 09:40:59AM +0200, Christophe JAILLET wrote: > Le 07/08/2017 à 08:36, Uwe Kleine-König a écrit : > > On Mon, Aug 07, 2017 at 01:49:53AM +0200, Christophe JAILLET wrote: > > > 'devm_pinctrl_get()' never returns NULL, so this test can be simplified. > > That's wrong. If CONFIG_PINCTRL is disabled devm_pinctrl_get returns > > NULL. But I think this shouldn't be considered an error, so your change > > is right, just the commit log is not. > With that said, in fact, I think that the test is correct as is. > If CONFIG_PINCTRL is disabled, we will display an info about a missing > functionality, but would still continue normally without it (i.e. return > PTR_ERR(NULL) = 0 = success), as stated in the comment in front of > 'i2c_imx_init_recovery_info': > "These alternative pinmux settings can be described in the device tree > by > a separate pinctrl state "gpio". If this is missing this is not a big > problem, the only implication is that we can't do bus recovery." > > So, I won't propose any v2 patch with an updated commit log. > Feel free to update it yourself and apply it if you don't share my analysis > above. Then the only issue (maybe?) is that the driver makes use of PTR_ERR(NULL) == 0 which I'm not sure is explicitly allowed. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v3] iwlwifi: Demote messages about fw flags size to info
On Thu, 2017-08-03 at 07:47 -0700, João Paulo Rechi Vita wrote: > These messages are not reporting a real error, just the fact that the > firmware knows about more flags than the driver. > > Currently these messages are presented to the user during boot if there > is no bootsplash covering the console, even when booting the kernel with > "quiet". > > Demoting it to the warn level helps having a clean boot process. > > Signed-off-by: João Paulo Rechi Vita > --- > > v2 changes: > - Set to warn level instead of info > > v3 changes: > - Fix commit message typo Thanks, João Paulo! I pushed this to our internal tree and it will eventually reach the mainline following our normal upstreaming process. -- Cheers, Luca.
Re: [PATCH v1 5/6] zram: remove zram_rw_page
Hello Minchan, On (08/08/17 17:13), Minchan Kim wrote: > Hi Sergey, > > On Tue, Aug 08, 2017 at 04:02:26PM +0900, Sergey Senozhatsky wrote: > > On (08/08/17 15:50), Minchan Kim wrote: > > > With on-stack-bio, rw_page interface doesn't provide a clear performance > > > benefit for zram and surely has a maintenance burden, so remove the > > > last user to remove rw_page completely. > > > > OK, never really liked it, I think we had that conversation before. > > > > as far as I remember, zram_rw_page() was the reason we had to do some > > tricks with init_lock to make lockdep happy. may be now we can "simplify" > > the things back. > > I cannot remember. Blame my brain. ;-) no worries. I didn't remember it clearly as well, hence the "may be" part. commit 08eee69fcf6baea543a2b4d2a2fcba0e61aa3160 Author: Minchan Kim zram: remove init_lock in zram_make_request Admin could reset zram during I/O operation going on so we have used zram->init_lock as read-side lock in I/O path to prevent sudden zram meta freeing. However, the init_lock is really troublesome. We can't do call zram_meta_alloc under init_lock due to lockdep splat because zram_rw_page is one of the function under reclaim path and hold it as read_lock while other places in process context hold it as write_lock. So, we have used allocation out of the lock to avoid lockdep warn but it's not good for readability and fainally, I met another lockdep splat between init_lock and cpu_hotplug from kmem_cache_destroy during working zsmalloc compaction. :( Yes, the ideal is to remove horrible init_lock of zram in rw path. This patch removes it in rw path and instead, add atomic refcount for meta lifetime management and completion to free meta in process context. It's important to free meta in process context because some of resource destruction needs mutex lock, which could be held if we releases the resource in reclaim context so it's deadlock, again. As a bonus, we could remove init_done check in rw path because zram_meta_get will do a role for it, instead. > Anyway, it's always welcome to make thing simple. > Could you send a patch after settle down this patchset? well, if it will improve anything after all :) -ss
Re: [PATCH 15/18] power: supply: bq24190_charger: Get input_current_limit from our supplier
Hallo Hans :-)
On Sun, Aug 6, 2017 at 5:35 AM, Hans de Goede wrote:
> On some devices the USB Type-C port power (USB PD 2.0) negotiation is
> done by a separate port-controller IC, while the current limit is
> controlled through another (charger) IC.
>
> It has been decided to model this by modelling the external Type-C
> power brick (adapter/charger) as a power-supply class device which
> supplies the charger-IC, with its voltage-now and current-max representing
> the negotiated voltage and max current draw.
>
> This commit adds support for this to the bq24190_charger driver by calling
> power_supply_set_input_current_limit_from_supplier helper if the
> "input-current-limit-from-supplier" device-property is set.
>
> Note this replaces the functionality to get the current-limit from an
> extcon device, which will be removed in a follow-up commit.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/power/supply/bq24190_charger.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/power/supply/bq24190_charger.c
> b/drivers/power/supply/bq24190_charger.c
> index d78e2c6dc127..1f6424f0772f 100644
> --- a/drivers/power/supply/bq24190_charger.c
> +++ b/drivers/power/supply/bq24190_charger.c
> @@ -161,6 +161,7 @@ struct bq24190_dev_info {
> charmodel_name[I2C_NAME_SIZE];
> boolinitialized;
> boolirq_event;
> + boolinput_current_limit_from_supplier;
> struct mutexf_reg_lock;
> u8 f_reg;
> u8 ss_reg;
> @@ -1137,6 +1138,14 @@ static int
> bq24190_charger_property_is_writeable(struct power_supply *psy,
> return ret;
> }
>
> +static void bq24190_charger_external_power_changed(struct power_supply *psy)
> +{
> + struct bq24190_dev_info *bdi = power_supply_get_drvdata(psy);
> +
> + if (bdi->input_current_limit_from_supplier)
> + power_supply_set_input_current_limit_from_supplier(psy);
> +}
> +
> static enum power_supply_property bq24190_charger_properties[] = {
> POWER_SUPPLY_PROP_CHARGE_TYPE,
> POWER_SUPPLY_PROP_HEALTH,
> @@ -1165,6 +1174,7 @@ static const struct power_supply_desc
> bq24190_charger_desc = {
> .get_property = bq24190_charger_get_property,
> .set_property = bq24190_charger_set_property,
> .property_is_writeable = bq24190_charger_property_is_writeable,
> + .external_power_changed = bq24190_charger_external_power_changed,
> };
>
> /* Battery power supply property routines */
> @@ -1654,6 +1664,10 @@ static int bq24190_probe(struct i2c_client *client,
> return -EINVAL;
> }
>
> + bdi->input_current_limit_from_supplier =
> + device_property_read_bool(dev,
> +
> "input-current-limit-from-supplier");
Since this invokes the new power_supply_class function, should this be
a devicetree property, not just a driver-to-driver switch? If so, the
property name should probably be defined in
Doc...bindings/power/supply/power_supply.txt.
My latest bq24190 series has a new DT doc, which should ref a new DT property.
Re: [PATCH 16/18] power: supply: bq24190_charger: Remove extcon handling
Hi Hans,
On Sun, Aug 6, 2017 at 5:35 AM, Hans de Goede wrote:
> Now that drivers/i2c/busses/i2c-cht-wc.c uses
> "input-current-limit-from-supplier" instead of "extcon-name" the last
> user of the bq24190 extcon code is gone, remove it.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/power/supply/bq24190_charger.c | 107
> -
> 1 file changed, 107 deletions(-)
>
> diff --git a/drivers/power/supply/bq24190_charger.c
> b/drivers/power/supply/bq24190_charger.c
> index 1f6424f0772f..0376de6d8e70 100644
> --- a/drivers/power/supply/bq24190_charger.c
> +++ b/drivers/power/supply/bq24190_charger.c
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -155,9 +154,6 @@ struct bq24190_dev_info {
> struct device *dev;
> struct power_supply *charger;
> struct power_supply *battery;
> - struct extcon_dev *extcon;
> - struct notifier_block extcon_nb;
> - struct delayed_work extcon_work;
> charmodel_name[I2C_NAME_SIZE];
> boolinitialized;
> boolirq_event;
> @@ -1530,75 +1526,6 @@ static irqreturn_t bq24190_irq_handler_thread(int irq,
> void *data)
> return IRQ_HANDLED;
> }
>
> -static void bq24190_extcon_work(struct work_struct *work)
> -{
> - struct bq24190_dev_info *bdi =
> - container_of(work, struct bq24190_dev_info, extcon_work.work);
> - int error, iinlim = 0;
> - u8 v;
> -
> - error = pm_runtime_get_sync(bdi->dev);
> - if (error < 0) {
> - dev_warn(bdi->dev, "pm_runtime_get failed: %i\n", error);
> - pm_runtime_put_noidle(bdi->dev);
> - return;
> - }
> -
> - if (extcon_get_state(bdi->extcon, EXTCON_CHG_USB_SDP) == 1)
> - iinlim = 50;
> - else if (extcon_get_state(bdi->extcon, EXTCON_CHG_USB_CDP) == 1 ||
> -extcon_get_state(bdi->extcon, EXTCON_CHG_USB_ACA) == 1)
> - iinlim = 150;
> - else if (extcon_get_state(bdi->extcon, EXTCON_CHG_USB_DCP) == 1)
> - iinlim = 200;
> -
> - if (iinlim) {
> - error = bq24190_set_field_val(bdi, BQ24190_REG_ISC,
> - BQ24190_REG_ISC_IINLIM_MASK,
> - BQ24190_REG_ISC_IINLIM_SHIFT,
> - bq24190_isc_iinlim_values,
> -
> ARRAY_SIZE(bq24190_isc_iinlim_values),
> - iinlim);
> - if (error < 0)
> - dev_err(bdi->dev, "Can't set IINLIM: %d\n", error);
> - }
> -
> - /* if no charger found and in USB host mode, set OTG 5V boost, else
> normal */
> - if (!iinlim && extcon_get_state(bdi->extcon, EXTCON_USB_HOST) == 1)
> - v = BQ24190_REG_POC_CHG_CONFIG_OTG;
> - else
> - v = BQ24190_REG_POC_CHG_CONFIG_CHARGE;
> -
> - error = bq24190_write_mask(bdi, BQ24190_REG_POC,
> - BQ24190_REG_POC_CHG_CONFIG_MASK,
> - BQ24190_REG_POC_CHG_CONFIG_SHIFT,
> - v);
> - if (error < 0)
> - dev_err(bdi->dev, "Can't set CHG_CONFIG: %d\n", error);
> -
> - pm_runtime_mark_last_busy(bdi->dev);
> - pm_runtime_put_autosuspend(bdi->dev);
> -}
> -
> -static int bq24190_extcon_event(struct notifier_block *nb, unsigned long
> event,
> - void *param)
> -{
> - struct bq24190_dev_info *bdi =
> - container_of(nb, struct bq24190_dev_info, extcon_nb);
> -
> - /*
> -* The Power-Good detection may take up to 220ms, sometimes
> -* the external charger detection is quicker, and the bq24190 will
> -* reset to iinlim based on its own charger detection (which is not
> -* hooked up when using external charger detection) resulting in
> -* a too low default 500mA iinlim. Delay applying the extcon value
> -* for 300ms to avoid this.
> -*/
> - queue_delayed_work(system_wq, &bdi->extcon_work,
> msecs_to_jiffies(300));
> -
> - return NOTIFY_OK;
> -}
> -
> static int bq24190_hw_init(struct bq24190_dev_info *bdi)
> {
> u8 v;
> @@ -1636,7 +1563,6 @@ static int bq24190_probe(struct i2c_client *client,
> struct device *dev = &client->dev;
> struct power_supply_config charger_cfg = {}, battery_cfg = {};
> struct bq24190_dev_info *bdi;
> - const char *name;
> int ret;
>
> if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
> @@ -1668,25 +1594,6 @@ static int bq24190_probe(struct i2c_client *client
Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps
On Mon, Aug 07, 2017 at 01:36:39PM -0700, Paul E. McKenney wrote: > On Mon, Aug 07, 2017 at 04:06:09PM -0400, Prarit Bhargava wrote: > > peterz? Want to offer a suggestion? The issue is that I'm changing a bool > > config option to an int and that impacts all the arch's defconfigs. John > > points > > out that this is a lot of churn and we're both wondering if there's a > > better way > > to do the configs. > > The usual approach is to keep the old bool Kconfig option, and add another > int Kconfig option that depends on the original one. The tests for > the int value get a bit more complex, but one way to handle this is to > define a cpp macro something like the following: > > #ifdef CONFIG_OLD_OPTION > #define CPP_NEW_OPTION 0 > #else > #define CPP_NEW_OPTION CONFIG_NEW_OPTION > #endif > > Then use CPP_NEW_OPTION, where zero means disabled and other numbers > select the available options. > > Adjust to suit depending on what values mean what. > > Another approach is to make the range of the new Kconfig option > depend on the old option: > > config NEW_OPTION > int "your description here" > range 1 5 if OLD_OPTION > range 0 0 if !OLD_OPTION > default 0 > help > your help here > > Again, adjust to suit depending on what values mean what. Right this. Except I don't see the !OLD_OPTION working as expected. A 'new' config will not include the old one, so the !OLD_OPTION thing will 'always' be true. So your: > @@ -1,8 +1,46 @@ > menu "printk and dmesg options" > > +choice > + prompt "printk default clock" > + config PRINTK_TIME_DISABLE > + bool "Disabled" > + help > +Selecting this option disables the time stamps of printk(). > + > + config PRINTK_TIME_LOCAL > + bool "Local Clock" > + help > + Selecting this option causes the time stamps of printk() to be > + stamped with the unadjusted hardware clock. > + > + config PRINTK_TIME_BOOT > + bool "CLOCK_BOOTTIME" > + help > + Selecting this option causes the time stamps of printk() to be > + stamped with the adjusted boottime clock. > + > + config PRINTK_TIME_MONO > + bool "CLOCK_MONOTONIC" > + help > + Selecting this option causes the time stamps of printk() to be > + stamped with the adjusted monotonic clock. > + > + config PRINTK_TIME_REAL > + bool "CLOCK_REALTIME" > + help > + Selecting this option causes the time stamps of printk() to be > + stamped with the adjusted realtime clock. > + > +endchoice > + > config PRINTK_TIME Change that into something like: config PRINTK_CLOCK > - bool "Show timing information on printks" > + int "Show time stamp information on printks" > depends on PRINTK > + default 0 if PRINTK_TIME_DISABLE > + default 1 if PRINTK_TIME_LOCAL And that into: default 1 if PRINTK_TIME_LOCAL || PRINTK_TIME > + default 2 if PRINTK_TIME_BOOT > + default 3 if PRINTK_TIME_MONO > + default 4 if PRINTK_TIME_REAL > help > Selecting this option causes time stamps of the printk() Then the old PRINTK_TIME symbol will auto-convert into the new equivalent.
Re: block/ps3vram: Delete an error message for a failed memory allocation in ps3vram_cache_init()
>> https://patchwork.ozlabs.org/patch/798575/ > > I submitted your patch Thanks for your constructive feedback. https://patchwork.ozlabs.org/patch/798850/ > and a fix to ps3vram_probe() with the other patches in my queue. I find it nice that you picked this change opportunity up after a bit of discussion (before an other developer would eventually have tackled it also). “Check return of ps3vram_cache_init” https://patchwork.ozlabs.org/patch/798853/ 1. Unfortunately, I find that this specific update suggestion does not fit to the Linux coding style convention. “… Do not unnecessarily use braces where a single statement will do. …” 2. How do you think about to use the check “if (error)” instead? 3. Will an additional commit description be useful? Regards, Markus
RE: [U-Boot] [PATCH] config: ls1012aqds: Add USB EHCI support for ls1012aqds
> -Original Message- > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of > yinbo@nxp.com > Sent: Thursday, July 27, 2017 3:19 PM > To: u-b...@lists.denx.de > Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS > ; Mihai Emilian Bantea ; > Horia Geantă ; Marc Zyngier > ; Gang Liu ; open list ker...@vger.kernel.org>; Scott Wood ; Rajat Srivastava > ; Yinbo Zhu ; moderated > list:ARM64 PORT (AARCH64 ARCHITECTURE) ker...@lists.infradead.org> > Subject: [U-Boot] [PATCH] config: ls1012aqds: Add USB EHCI support for > ls1012aqds > > From: Rajesh Bhagat > > Add USB EHCI support for ls1012aqds platform > > Signed-off-by: Rajat Srivastava > Signed-off-by: Rajesh Bhagat > Signed-off-by: yinbo.zhu > --- > arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h | 1 + > include/configs/ls1012aqds.h | 2 ++ > include/usb/ehci-ci.h | 2 +- > 3 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h > index 8ad199f..4afc338 100644 > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h > @@ -35,6 +35,7 @@ > #define CONFIG_SYS_XHCI_USB1_ADDR(CONFIG_SYS_IMMR + > 0x01f0) > #define CONFIG_SYS_XHCI_USB2_ADDR(CONFIG_SYS_IMMR + > 0x0200) > #define CONFIG_SYS_XHCI_USB3_ADDR(CONFIG_SYS_IMMR + > 0x0210) > +#define CONFIG_SYS_EHCI_USB1_ADDR(CONFIG_SYS_IMMR + > 0x0760) > #define CONFIG_SYS_PCIE1_ADDR(CONFIG_SYS_IMMR + > 0x240) > #define CONFIG_SYS_PCIE2_ADDR(CONFIG_SYS_IMMR + > 0x250) > #define CONFIG_SYS_PCIE3_ADDR(CONFIG_SYS_IMMR + > 0x260) > diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h > index 5b8500b..55f2578 100644 > --- a/include/configs/ls1012aqds.h > +++ b/include/configs/ls1012aqds.h > @@ -115,6 +115,8 @@ > > #ifdef CONFIG_HAS_FSL_DR_USB > #define CONFIG_USB_EHCI_FSL > +#define CONFIG_USB_ULPI > +#define CONFIG_USB_ULPI_VIEWPORT > #define CONFIG_EHCI_HCD_INIT_AFTER_RESET > #endif > > diff --git a/include/usb/ehci-ci.h b/include/usb/ehci-ci.h > index 847b698..cd3eb47 100644 > --- a/include/usb/ehci-ci.h > +++ b/include/usb/ehci-ci.h > @@ -156,7 +156,7 @@ > #elif defined(CONFIG_MPC85xx) > #define CONFIG_SYS_FSL_USB1_ADDR CONFIG_SYS_MPC85xx_USB1_ADDR > #define CONFIG_SYS_FSL_USB2_ADDR CONFIG_SYS_MPC85xx_USB2_ADDR > -#elif defined(CONFIG_ARCH_LS1021A) > +#elif defined(CONFIG_LS102XA) || defined(CONFIG_ARCH_LS1012A) Why CONFIG_ARCH_LS1021A has been replaced by CONFIG_LS102XA? -prabhakar
Re: [PATCH v2] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter
Am Dienstag, den 08.08.2017, 14:32 +0800 schrieb Kai-Heng Feng:
> Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
> connect to Realtek r8153.
>
> The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
> can make it work.
>
> Since another r8153 dongle at my hand does not have the issue, so add
> the quirk to the hub instead.
But in the comment you say you add it to the device!
This makes no sense.
[..]
> + /* Moshi USB to Ethernet Adapter */
> + { USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
> +
Now is this a hub or a device? If this is a Genesys Logic hub,
you need to say that clearly and state that it is an internal hub.
Regards
Oliver
Re: [PATCH v2] scheduler: enhancement to show_state_filter
On Tue, Aug 08, 2017 at 08:53:10PM +0800, Yafang Shao wrote: > Sometimes we want to get tasks in TASK_RUNNING sepcifically, > instead of dump all tasks. > For example, when the loadavg are high, we want to dump > tasks in TASK_RUNNING and TASK_UNINTERRUPTIBLE, which contribute > to system load. But mostly there're lots of tasks in Sleep state, > which occupies almost all of the kernel log buffer, even overflows > it, that causes the useful messages get lost. Although we can > enlarge the kernel log buffer, but that's not a good idea. > > So I made this change to make the show_state_filter more flexible, > and then we can dump the tasks in TASK_RUNNING specifically. It reads like magic and I really don't see the point.
Re: [PATCH v2 2/4] KVM: X86: implement the logic for spinlock optimization
On 2017/8/8 15:30, Paolo Bonzini wrote:
> On 08/08/2017 06:05, Longpeng(Mike) wrote:
>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>> index cd0e6e6..dec5e8a 100644
>> --- a/arch/x86/kvm/hyperv.c
>> +++ b/arch/x86/kvm/hyperv.c
>> @@ -1268,7 +1268,7 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>>
>> switch (code) {
>> case HVCALL_NOTIFY_LONG_SPIN_WAIT:
>> -kvm_vcpu_on_spin(vcpu, kvm_arch_vcpu_in_kernel(vcpu));
>> +kvm_vcpu_on_spin(vcpu, kvm_x86_ops->spin_in_kernel(vcpu));
>> break;
>> case HVCALL_POST_MESSAGE:
>> case HVCALL_SIGNAL_EVENT:
>
> This can be true as well. I can change this on commit.
>
Thanks,
hope you could help me to fix the same problem in patch-1(s390) too.
> Paolo
>
> .
>
--
Regards,
Longpeng(Mike)
Re: [PATCH] memory: mtk-smi: Handle return value of clk_prepare_enable
On Tue, 2017-08-08 at 11:06 +0530, Arvind Yadav wrote: > clk_prepare_enable() can fail here and we must check its return value. > > Signed-off-by: Arvind Yadav > --- Hi, Arvind, please rebase this to my latest patchset[1], it's been applied by Joerg. And please send this one to Joerg and iommu mail list. otherwise: Acked-by: Honghui Zhang [1]https://lkml.org/lkml/2017/8/3/968 Thanks. > drivers/memory/mtk-smi.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c > index 4afbc41..edf36f0 100644 > --- a/drivers/memory/mtk-smi.c > +++ b/drivers/memory/mtk-smi.c > @@ -321,6 +321,7 @@ static int mtk_smi_common_probe(struct platform_device > *pdev) > struct resource *res; > const struct of_device_id *of_id; > enum mtk_smi_gen smi_gen; > + int ret; > > if (!dev->pm_domain) > return -EPROBE_DEFER; > @@ -359,7 +360,9 @@ static int mtk_smi_common_probe(struct platform_device > *pdev) > if (IS_ERR(common->clk_async)) > return PTR_ERR(common->clk_async); > > - clk_prepare_enable(common->clk_async); > + ret = clk_prepare_enable(common->clk_async); > + if (ret) > + return ret; > } > pm_runtime_enable(dev); > platform_set_drvdata(pdev, common);
Re: [PATCH v2 3/4] KVM: s390: implements the kvm_arch_vcpu_in_kernel()
On 08.08.2017 06:05, Longpeng(Mike) wrote:
> This implements the kvm_arch_vcpu_in_kernel() for s390.
>
> Signed-off-by: Longpeng(Mike)
> ---
> arch/s390/kvm/kvm-s390.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 0b0c689..e46177b 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -2449,7 +2449,7 @@ int kvm_arch_vcpu_runnable(struct kvm_vcpu *vcpu)
>
> bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> {
> - return false;
> + return !(vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE);
> }
> EXPORT_SYMBOL_GPL(kvm_arch_vcpu_in_kernel);
>
>
Reviewed-by: David Hildenbrand
--
Thanks,
David
Re: [PATCH 1/3] thermal: core: Fix a memory leak in 'thermal_zone_device_register()' error handling path
On Sun, 2017-07-16 at 08:59 +0200, Christophe JAILLET wrote: > 'tz' is freed in some error handling paths but not in the main one. > So free it also here to avoid a memory leak. > After device registered, tz is freed in thermal_release(). thanks, rui > Signed-off-by: Christophe JAILLET > --- > drivers/thermal/thermal_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/thermal/thermal_core.c > b/drivers/thermal/thermal_core.c > index 5a51c740e372..9743f3e65eb0 100644 > --- a/drivers/thermal/thermal_core.c > +++ b/drivers/thermal/thermal_core.c > @@ -1296,6 +1296,7 @@ thermal_zone_device_register(const char *type, > int trips, int mask, > unregister: > ida_simple_remove(&thermal_tz_ida, tz->id); > device_unregister(&tz->device); > + kfree(tz); > return ERR_PTR(result); > } > EXPORT_SYMBOL_GPL(thermal_zone_device_register);
Re: [PATCH v2 2/4] KVM: X86: implement the logic for spinlock optimization
On 08/08/2017 10:31, Longpeng (Mike) wrote:
>
>
> On 2017/8/8 15:30, Paolo Bonzini wrote:
>
>> On 08/08/2017 06:05, Longpeng(Mike) wrote:
>>> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
>>> index cd0e6e6..dec5e8a 100644
>>> --- a/arch/x86/kvm/hyperv.c
>>> +++ b/arch/x86/kvm/hyperv.c
>>> @@ -1268,7 +1268,7 @@ int kvm_hv_hypercall(struct kvm_vcpu *vcpu)
>>>
>>> switch (code) {
>>> case HVCALL_NOTIFY_LONG_SPIN_WAIT:
>>> - kvm_vcpu_on_spin(vcpu, kvm_arch_vcpu_in_kernel(vcpu));
>>> + kvm_vcpu_on_spin(vcpu, kvm_x86_ops->spin_in_kernel(vcpu));
>>> break;
>>> case HVCALL_POST_MESSAGE:
>>> case HVCALL_SIGNAL_EVENT:
>>
>> This can be true as well. I can change this on commit.
>
> Thanks,
> hope you could help me to fix the same problem in patch-1(s390) too.
Yes. Another possibility is to always pass false in patch 1 to
kvm_vcpu_on_spin. Then the parameter can be adjusted in patches 3 and 4
(passing true for s390 and vcpu_mode_priv(vcpu) for ARM).
Paolo
Re: [PATCH 13/18] power: supply: bq24190_charger: Export 5V boost converter as regulator
Hi Hans, On Sun, Aug 6, 2017 at 5:35 AM, Hans de Goede wrote: > Register the 5V boost converter as a regulator named > "regulator-bq24190-usb-vbus". Note the name includes "bq24190" because > the bq24190 family is also used on ACPI devices where there are no > device-tree phandles, so regulator_get will fallback to the name and thus > it must be unique on the system. What we're enabling here is 5V boost for otg host mode, not vbus generally, so maybe the name should indicate that... regulator-bq24190-usb-5volt regulator-bq24190-usb-host regulator-bq24190-usb-otg-5v Tony, thoughts?
Re: [PATCH v2 1/4] KVM: add spinlock optimization framework
> +bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
> +{
> + return false;
> +}
why don't we need an EXPORT_SYMBOL here?
> +
> /* Just ensure a guest exit from a particular CPU */
> static void exit_vm_noop(void *info)
> {
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 15252d7..e7720d2 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2317,7 +2317,7 @@ static bool kvm_vcpu_eligible_for_directed_yield(struct
> kvm_vcpu *vcpu)
> #endif
> }
>
> -void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> +void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool me_in_kern)
> {
> struct kvm *kvm = me->kvm;
> struct kvm_vcpu *vcpu;
> @@ -2348,6 +2348,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
> continue;
> if (swait_active(&vcpu->wq) &&
> !kvm_arch_vcpu_runnable(vcpu))
> continue;
> + if (me_in_kern && !kvm_arch_vcpu_in_kernel(vcpu))
> + continue;
hm, does this patch compile? (me_in_kern)
I would even move this to an other patch.
Maybe even split into
a) introducing kvm_arch_vcpu_in_kernel() for all archs
b) modifying kvm_vcpu_on_spin(), passing the result from
kvm_arch_vcpu_in_kernel()
c) filling kvm_arch_vcpu_in_kernel() with life for different archs
(multiple patches)
d) pimping kvm_vcpu_on_spin()
> if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
> continue;
>
>
--
Thanks,
David
[v2 PATCH] powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT states when stop-api fails
From: "Gautham R. Shenoy"
Currently, we use the opal call opal_slw_set_reg() to inform the
Sleep-Winkle Engine (SLW) to restore the contents of some of the
Hypervisor state on wakeup from deep idle states that lose full
hypervisor context (characterized by the flag
OPAL_PM_LOSE_FULL_CONTEXT).
However, the current code has a bug in that if opal_slw_set_reg()
fails, we don't disable the use of these deep states (winkle on
POWER8, stop4 onwards on POWER9).
This patch fixes this bug by ensuring that if programing the
sleep-winkle engine to restore the hypervisor states in
pnv_save_sprs_for_deep_states() fails, then we exclude such states by
clearing the OPAL_PM_LOSE_FULL_CONTEXT flag from
supported_cpuidle_states. As a result POWER8 will be prevented from
using winkle for CPU-Hotplug, and POWER9 will put the offlined CPUs to
the default stop state when available.
Further, we ensure in the initialization of the cpuidle-powernv driver
to only include those states whose flags are present in
supported_cpuidle_states, thereby skipping OPAL_PM_LOSE_FULL_CONTEXT
states when they have been disabled due to stop-api failure.
Fixes: 1e1601b38e6 ("powerpc/powernv/idle: Restore SPRs for deep idle
states via stop API.")
Signed-off-by: Gautham R. Shenoy
---
v2 --> v1:
Do the bare minimum required to exclude the LOSE_FULL_CONTEXT
states.
arch/powerpc/platforms/powernv/idle.c | 41 ---
drivers/cpuidle/cpuidle-powernv.c | 10 +
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c
b/arch/powerpc/platforms/powernv/idle.c
index 2abee07..a553aee 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -56,6 +56,7 @@
*/
static u64 pnv_deepest_stop_psscr_val;
static u64 pnv_deepest_stop_psscr_mask;
+static u64 pnv_deepest_stop_flag;
static bool deepest_stop_found;
static int pnv_save_sprs_for_deep_states(void)
@@ -185,8 +186,40 @@ static void pnv_alloc_idle_core_states(void)
update_subcore_sibling_mask();
- if (supported_cpuidle_states & OPAL_PM_LOSE_FULL_CONTEXT)
- pnv_save_sprs_for_deep_states();
+ if (supported_cpuidle_states & OPAL_PM_LOSE_FULL_CONTEXT) {
+ int rc = pnv_save_sprs_for_deep_states();
+
+ if (likely(!rc))
+ return;
+
+ /*
+* The stop-api is unable to restore hypervisor
+* resources on wakeup from platform idle states which
+* lose full context. So disable such states.
+*/
+ supported_cpuidle_states &= ~OPAL_PM_LOSE_FULL_CONTEXT;
+ pr_warn("cpuidle-powernv: Disabling idle states that lose full
context\n");
+ pr_warn("cpuidle-powernv: Idle power-savings, CPU-Hotplug
affected\n");
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (pnv_deepest_stop_flag & OPAL_PM_LOSE_FULL_CONTEXT)) {
+ /*
+* Use the default stop state for CPU-Hotplug
+* if available.
+*/
+ if (default_stop_found) {
+ pnv_deepest_stop_psscr_val =
+ pnv_default_stop_val;
+ pnv_deepest_stop_psscr_mask =
+ pnv_default_stop_mask;
+ pr_warn("cpuidle-powernv: Offlined CPUs will
stop with psscr = 0x%016llx\n",
+ pnv_deepest_stop_psscr_val);
+ } else { /* Fallback to snooze loop for CPU-Hotplug */
+ deepest_stop_found = false;
+ pr_warn("cpuidle-powernv: Offlined CPUs will
busy wait\n");
+ }
+ }
+ }
}
u32 pnv_get_supported_cpuidle_states(void)
@@ -375,7 +408,8 @@ unsigned long pnv_cpu_offline(unsigned int cpu)
pnv_deepest_stop_psscr_val;
srr1 = power9_idle_stop(psscr);
- } else if (idle_states & OPAL_PM_WINKLE_ENABLED) {
+ } else if ((idle_states & OPAL_PM_WINKLE_ENABLED) &&
+ (idle_states & OPAL_PM_LOSE_FULL_CONTEXT)) {
srr1 = power7_idle_insn(PNV_THREAD_WINKLE);
} else if ((idle_states & OPAL_PM_SLEEP_ENABLED) ||
(idle_states & OPAL_PM_SLEEP_ENABLED_ER1)) {
@@ -553,6 +587,7 @@ static int __init pnv_power9_idle_init(struct device_node
*np, u32 *flags,
max_residency_ns = residency_ns[i];
pnv_deepest_stop_psscr_val = psscr_val[i];
pnv_deepest_stop_psscr_mask = psscr_mask[i];
+ pnv_deepest_stop_flag = flags[i];
deepest_stop_found = true;
}
diff --git a/dri
Re: [PATCH 2/2] sched/debug: intruduce task_state_to_char helper function
Hi,
On 2017/8/8 14:42, kbuild test robot wrote:
> Hi Xie,
>
> [auto build test ERROR on tip/sched/core]
> [also build test ERROR on v4.13-rc4 next-20170807]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
Thanks for your testing, I'll fix it in v2.
--
Xie XiuQi
>
> url:
> https://github.com/0day-ci/linux/commits/Xie-XiuQi/sched-debug-show-task-state-on-proc-sched_debug/20170808-135825
> config: i386-randconfig-x019-201732 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>kernel/sched/core.c: In function 'sched_show_task':
>>> kernel/sched/core.c:5114:64: error: expected ')' before ';' token
> printk(KERN_INFO "%-15.15s %c", p->comm, task_state_to_char(p);
>^
>>> kernel/sched/core.c:5133:1: error: expected ';' before '}' token
> }
> ^
>kernel/sched/core.c:5109:6: warning: unused variable 'ppid'
> [-Wunused-variable]
> int ppid;
> ^~~~
>kernel/sched/core.c:5108:16: warning: unused variable 'free'
> [-Wunused-variable]
> unsigned long free = 0;
>^~~~
>In file included from arch/x86/include/asm/current.h:4:0,
> from include/linux/sched.h:11,
> from kernel/sched/core.c:8:
>kernel/sched/core.c: At top level:
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'strcpy' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:390:2: note: in expansion of macro 'if'
> if (p_size == (size_t)-1 && q_size == (size_t)-1)
> ^~
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'kmemdup' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:380:2: note: in expansion of macro 'if'
> if (p_size < size)
> ^~
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'kmemdup' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:378:2: note: in expansion of macro 'if'
> if (__builtin_constant_p(size) && p_size < size)
> ^~
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'memchr_inv' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:369:2: note: in expansion of macro 'if'
> if (p_size < size)
> ^~
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'memchr_inv' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:367:2: note: in expansion of macro 'if'
> if (__builtin_constant_p(size) && p_size < size)
> ^~
>include/linux/compiler.h:162:4: warning: '__f' is static but declared
> in inline function 'memchr' which is not static
>__f = { \
>^
>include/linux/compiler.h:154:23: note: in expansion of macro '__trace_if'
> #define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
> ^~
>include/linux/string.h:358:2: note: in expansion of macro &#
Re: [PATCH v2 1/4] KVM: add spinlock optimization framework
On 08.08.2017 10:42, David Hildenbrand wrote:
>
>> +bool kvm_arch_vcpu_in_kernel(struct kvm_vcpu *vcpu)
>> +{
>> +return false;
>> +}
>
> why don't we need an EXPORT_SYMBOL here?
>
>> +
>> /* Just ensure a guest exit from a particular CPU */
>> static void exit_vm_noop(void *info)
>> {
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 15252d7..e7720d2 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -2317,7 +2317,7 @@ static bool
>> kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
>> #endif
>> }
>>
>> -void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>> +void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool me_in_kern)
>> {
>> struct kvm *kvm = me->kvm;
>> struct kvm_vcpu *vcpu;
>> @@ -2348,6 +2348,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me)
>> continue;
>> if (swait_active(&vcpu->wq) &&
>> !kvm_arch_vcpu_runnable(vcpu))
>> continue;
>> +if (me_in_kern && !kvm_arch_vcpu_in_kernel(vcpu))
>> +continue;
>
>
> hm, does this patch compile? (me_in_kern)
pardon me, missed the parameter, so ignore this comment. comment
regarding splitting up below still holds :)
>
> I would even move this to an other patch.
>
> Maybe even split into
>
> a) introducing kvm_arch_vcpu_in_kernel() for all archs
> b) modifying kvm_vcpu_on_spin(), passing the result from
> kvm_arch_vcpu_in_kernel()
> c) filling kvm_arch_vcpu_in_kernel() with life for different archs
> (multiple patches)
> d) pimping kvm_vcpu_on_spin()
>
>> if (!kvm_vcpu_eligible_for_directed_yield(vcpu))
>> continue;
>>
>>
>
>
--
Thanks,
David
Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook
Johan Hovold writes:
> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>> Toughbook
>
> Please use
>
> USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook
>
> as Subject (patch summary), and also add a commit message here (e.g.
> your current summary).
>
>> Signed-off-by: Oleg Kokorin
>> ---
>> drivers/usb/serial/qcserial.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
>> index ebc0bee..53786ce 100644
>> --- a/drivers/usb/serial/qcserial.c
>> +++ b/drivers/usb/serial/qcserial.c
>> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
>> {DEVICE_G1K(0x1bc7, 0x900e)}, /* Telit Gobi QDL device */
>>
>> /* Gobi 2000 devices */
>> + {USB_DEVICE(0x04da, 0x250e)}, /* Panasonic Gobi 2000 QDL device */
>> + {USB_DEVICE(0x04da, 0x250f)}, /* Panasonic Gobi 2000 Modem device
>> */
>
> This patch is whitespace-damaged and does not apply. Please try sending
> the patch to yourself first (e.g. using git-send-email) and make sure
> you can apply it it with git am. Running checkpatch on the result is
> also a good idea.
And please send a patch for qmi_wwan too, assuming this really is a Gobi
2000 modem. Thanks.
Bjørn
[PATCH v3 00/49] block: support multipage bvec
Hi, This patchset brings multipage bvec into block layer: 1) what is multipage bvec? Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages which are physically contiguous instead of one single page used in linux kernel for long time. 2) why is multipage bvec introduced? Kent proposed the idea[1] first. As system's RAM becomes much bigger than before, and at the same time huge page, transparent huge page and memory compaction are widely used, it is a bit easy now to see physically contiguous pages from fs in I/O. On the other hand, from block layer's view, it isn't necessary to store intermediate pages into bvec, and it is enough to just store the physicallly contiguous 'segment' in each io vector. Also huge pages are being brought to filesystem and swap [2][6], we can do IO on a hugepage each time[3], which requires that one bio can transfer at least one huge page one time. Turns out it isn't flexiable to change BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. With multipage bvec: - segment handling in block layer can be improved much in future since it should be quite easy to convert multipage bvec into segment easily. For example, we might just store segment in each bvec directly in future. - bio size can be increased and it should improve some high-bandwidth IO case in theory[4]. - Inside block layer, both bio splitting and sg map can become more efficient than before by just traversing the physically contiguous 'segment' instead of each page. - there is opportunity in future to improve memory footprint of bvecs. 3) how is multipage bvec implemented in this patchset? The 1st 17 patches comment on some special cases and deal with some special cases of direct access to bvec table. The 2nd part(18~29) implements multipage bvec in block layer: - put all tricks into bvec/bio/rq iterators, and as far as drivers and fs use these standard iterators, they are happy with multipage bvec - use multipage bvec to split bio and map sg - bio_for_each_segment_all() changes this helper pass pointer of each bvec directly to user, and it has to be changed. Two new helpers(bio_for_each_segment_all_sp() and bio_for_each_segment_all_mp()) are introduced. The 3rd part(32~47) convert current users of bio_for_each_segment_all() to bio_for_each_segment_all_sp()/bio_for_each_segment_all_mp(). The last part(48~49) enables multipage bvec. These patches can be found in the following git tree: https://github.com/ming1/linux/commits/v4.13-rc3-block-next-mp-bvec-V3 Thanks Christoph for looking at the early version and providing very good suggestions, such as: introduce bio_init_with_vec_table(), remove another unnecessary helpers for cleanup and so on. Any comments are welcome! BTW, I will be on a trip in the following week, so may not reply in time. V3: - rebase on v4.13-rc3 with for-next of block tree - run more xfstests: xfs/ext4 over NVMe, Sata, DM(linear), MD(raid1), and not see regressions triggered - add Reviewed-by on some btrfs patches - remove two MD patches because both are merged to linus tree already V2: - bvec table direct access in raid has been cleaned, so NO_MP flag is dropped - rebase on recent Neil Brown's change on bio and bounce code - reorganize the patchset V1: - against v4.10-rc1 and some cleanup in V0 are in -linus already - handle queue_virt_boundary() in mp bvec change and make NVMe happy - further BTRFS cleanup - remove QUEUE_FLAG_SPLIT_MP - rename for two new helpers of bio_for_each_segment_all() - fix bounce convertion - address comments in V0 [1], http://marc.info/?l=linux-kernel&m=141680246629547&w=2 [2], https://patchwork.kernel.org/patch/9451523/ [3], http://marc.info/?t=14773544711&r=1&w=2 [4], http://marc.info/?l=linux-mm&m=147745525801433&w=2 [5], http://marc.info/?t=14956948457&r=1&w=2 [6], http://marc.info/?t=14982021534&r=1&w=2 Ming Lei (49): block: drbd: comment on direct access bvec table block: loop: comment on direct access to bvec table kernel/power/swap.c: comment on direct access to bvec table mm: page_io.c: comment on direct access to bvec table fs/buffer: comment on direct access to bvec table f2fs: f2fs_read_end_io: comment on direct access to bvec table bcache: comment on direct access to bvec table block: comment on bio_alloc_pages() block: comment on bio_iov_iter_get_pages() dm: limit the max bio size as BIO_MAX_PAGES * PAGE_SIZE btrfs: avoid access to .bi_vcnt directly btrfs: avoid to access bvec table directly for a cloned bio btrfs: comment on direct access bvec table block: bounce: avoid direct access to bvec table bvec_iter: introduce BVEC_ITER_ALL_INIT block: bounce: don't access bio->bi_io_vec in copy_to_high_bio_irq block: comments on bio_for_each
[PATCH v3 01/49] block: drbd: comment on direct access bvec table
Signed-off-by: Ming Lei --- drivers/block/drbd/drbd_bitmap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/block/drbd/drbd_bitmap.c b/drivers/block/drbd/drbd_bitmap.c index 809fd245c3dc..70890d950dc9 100644 --- a/drivers/block/drbd/drbd_bitmap.c +++ b/drivers/block/drbd/drbd_bitmap.c @@ -953,6 +953,7 @@ static void drbd_bm_endio(struct bio *bio) struct drbd_bm_aio_ctx *ctx = bio->bi_private; struct drbd_device *device = ctx->device; struct drbd_bitmap *b = device->bitmap; + /* single page bio, safe for multipage bvec */ unsigned int idx = bm_page_to_idx(bio->bi_io_vec[0].bv_page); if ((ctx->flags & BM_AIO_COPY_PAGES) == 0 && -- 2.9.4
[PATCH v3 02/49] block: loop: comment on direct access to bvec table
Signed-off-by: Ming Lei --- drivers/block/loop.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index ef8334949b42..58df9ed70328 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c @@ -487,6 +487,11 @@ static int lo_rw_aio(struct loop_device *lo, struct loop_cmd *cmd, /* nomerge for loop request queue */ WARN_ON(cmd->rq->bio != cmd->rq->biotail); + /* +* For multipage bvec support, it is safe to pass the bvec +* table to iov iterator, because iov iter still uses bvec +* iter helpers to travese bvec. +*/ bvec = __bvec_iter_bvec(bio->bi_io_vec, bio->bi_iter); iov_iter_bvec(&iter, ITER_BVEC | rw, bvec, bio_segments(bio), blk_rq_bytes(cmd->rq)); -- 2.9.4
Re: [RFC PATCH 2/2] bpf: Initialise mod[] in bpf_trace_printk
On 08/08/2017 12:25 AM, James Hogan wrote:
In bpf_trace_printk(), the elements in mod[] are left uninitialised, but
they are then incremented to track the width of the formats. Zero
initialise the array just in case the memory contains non-zero values on
entry.
Fixes: 9c959c863f82 ("tracing: Allow BPF programs to call bpf_trace_printk()")
Signed-off-by: James Hogan
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Steven Rostedt
Cc: Ingo Molnar
Cc: net...@vger.kernel.org
---
When I checked (on MIPS32), the elements tended to have the value zero
anyway (does BPF zero the stack or something clever?), so this is a
purely theoretical fix.
---
kernel/trace/bpf_trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 32dcbe1b48f2..86a52857d941 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -129,7 +129,7 @@ BPF_CALL_5(bpf_trace_printk, char *, fmt, u32, fmt_size,
u64, arg1,
u64, arg2, u64, arg3)
{
bool str_seen = false;
- int mod[3] = {};
+ int mod[3] = { 0, 0, 0 };
I'm probably missing something, but is the behavior of gcc wrt
above initializers different on mips (it zeroes just fine on x86
at least)? If yes, we'd probably need a cocci script to also check
rest of the kernel given this is used in a number of places. Hm,
could you elaborate?
int fmt_cnt = 0;
u64 unsafe_addr;
char buf[64];
[PATCH v3 06/49] f2fs: f2fs_read_end_io: comment on direct access to bvec table
Cc: Jaegeuk Kim
Cc: Chao Yu
Cc: linux-f2fs-de...@lists.sourceforge.net
Signed-off-by: Ming Lei
---
fs/f2fs/data.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 87c1f4150c64..99fa8e9780e8 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -56,6 +56,10 @@ static void f2fs_read_end_io(struct bio *bio)
int i;
#ifdef CONFIG_F2FS_FAULT_INJECTION
+ /*
+* It is still safe to retrieve the 1st page of the bio
+* in this way after supporting multipage bvec.
+*/
if (time_to_inject(F2FS_P_SB(bio->bi_io_vec->bv_page), FAULT_IO)) {
f2fs_show_injection_info(FAULT_IO);
bio->bi_status = BLK_STS_IOERR;
--
2.9.4
[PATCH v3 03/49] kernel/power/swap.c: comment on direct access to bvec table
Cc: "Rafael J. Wysocki"
Cc: linux...@vger.kernel.org
Signed-off-by: Ming Lei
---
kernel/power/swap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 57d22571f306..aa52ccc03fcc 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -238,6 +238,8 @@ static void hib_init_batch(struct hib_bio_batch *hb)
static void hib_end_io(struct bio *bio)
{
struct hib_bio_batch *hb = bio->bi_private;
+
+ /* single page bio, safe for multipage bvec */
struct page *page = bio->bi_io_vec[0].bv_page;
if (bio->bi_status) {
--
2.9.4
[PATCH v3 05/49] fs/buffer: comment on direct access to bvec table
Signed-off-by: Ming Lei
---
fs/buffer.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 5715dac7821f..c821ed6a6f0e 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -3054,8 +3054,13 @@ static void end_bio_bh_io_sync(struct bio *bio)
void guard_bio_eod(int op, struct bio *bio)
{
sector_t maxsector;
- struct bio_vec *bvec = &bio->bi_io_vec[bio->bi_vcnt - 1];
unsigned truncated_bytes;
+ /*
+* It is safe to truncate the last bvec in the following way
+* even though multipage bvec is supported, but we need to
+* fix the parameters passed to zero_user().
+*/
+ struct bio_vec *bvec = &bio->bi_io_vec[bio->bi_vcnt - 1];
maxsector = i_size_read(bio->bi_bdev->bd_inode) >> 9;
if (!maxsector)
--
2.9.4
[PATCH v3 08/49] block: comment on bio_alloc_pages()
This patch adds comment on usage of bio_alloc_pages(). Signed-off-by: Ming Lei --- block/bio.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/block/bio.c b/block/bio.c index e241bbc49f14..826b5d173416 100644 --- a/block/bio.c +++ b/block/bio.c @@ -981,7 +981,9 @@ EXPORT_SYMBOL(bio_advance); * @bio: bio to allocate pages for * @gfp_mask: flags for allocation * - * Allocates pages up to @bio->bi_vcnt. + * Allocates pages up to @bio->bi_vcnt, and this function should only + * be called on a new initialized bio, which means all pages aren't added + * to the bio via bio_add_page() yet. * * Returns 0 on success, -ENOMEM on failure. On failure, any allocated pages are * freed. -- 2.9.4
[PATCH v3 07/49] bcache: comment on direct access to bvec table
Looks all are safe after multipage bvec is supported.
Cc: linux-bca...@vger.kernel.org
Signed-off-by: Ming Lei
---
drivers/md/bcache/btree.c | 1 +
drivers/md/bcache/super.c | 6 ++
drivers/md/bcache/util.c | 7 +++
3 files changed, 14 insertions(+)
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index 866dcf78ff8e..3da595ae565b 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -431,6 +431,7 @@ static void do_btree_node_write(struct btree *b)
continue_at(cl, btree_node_write_done, NULL);
} else {
+ /* No harm for multipage bvec since the new is just allocated */
b->bio->bi_vcnt = 0;
bch_bio_map(b->bio, i);
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 8352fad765f6..6808f548cd13 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -208,6 +208,7 @@ static void write_bdev_super_endio(struct bio *bio)
static void __write_super(struct cache_sb *sb, struct bio *bio)
{
+ /* single page bio, safe for multipage bvec */
struct cache_sb *out = page_address(bio->bi_io_vec[0].bv_page);
unsigned i;
@@ -1154,6 +1155,8 @@ static void register_bdev(struct cache_sb *sb, struct
page *sb_page,
dc->bdev->bd_holder = dc;
bio_init(&dc->sb_bio, dc->sb_bio.bi_inline_vecs, 1);
+
+ /* single page bio, safe for multipage bvec */
dc->sb_bio.bi_io_vec[0].bv_page = sb_page;
get_page(sb_page);
@@ -1799,6 +1802,7 @@ void bch_cache_release(struct kobject *kobj)
for (i = 0; i < RESERVE_NR; i++)
free_fifo(&ca->free[i]);
+ /* single page bio, safe for multipage bvec */
if (ca->sb_bio.bi_inline_vecs[0].bv_page)
put_page(ca->sb_bio.bi_io_vec[0].bv_page);
@@ -1854,6 +1858,8 @@ static int register_cache(struct cache_sb *sb, struct
page *sb_page,
ca->bdev->bd_holder = ca;
bio_init(&ca->sb_bio, ca->sb_bio.bi_inline_vecs, 1);
+
+ /* single page bio, safe for multipage bvec */
ca->sb_bio.bi_io_vec[0].bv_page = sb_page;
get_page(sb_page);
diff --git a/drivers/md/bcache/util.c b/drivers/md/bcache/util.c
index 8c3a938f4bf0..11b4230ea6ad 100644
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -223,6 +223,13 @@ uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t
done)
: 0;
}
+/*
+ * Generally it isn't good to access .bi_io_vec and .bi_vcnt
+ * directly, the preferred way is bio_add_page, but in
+ * this case, bch_bio_map() supposes that the bvec table
+ * is empty, so it is safe to access .bi_vcnt & .bi_io_vec
+ * in this way even after multipage bvec is supported.
+ */
void bch_bio_map(struct bio *bio, void *base)
{
size_t size = bio->bi_iter.bi_size;
--
2.9.4
[PATCH v3 09/49] block: comment on bio_iov_iter_get_pages()
bio_iov_iter_get_pages() used unused bvec spaces for
storing page pointer array temporarily, and this patch
comments on this usage wrt. multipage bvec support.
Signed-off-by: Ming Lei
---
block/bio.c | 4
1 file changed, 4 insertions(+)
diff --git a/block/bio.c b/block/bio.c
index 826b5d173416..28697e3c8ce3 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -875,6 +875,10 @@ EXPORT_SYMBOL(bio_add_page);
*
* Pins as many pages from *iter and appends them to @bio's bvec array. The
* pages will have to be released using put_page() when done.
+ *
+ * The hacking way of using bvec table as page pointer array is safe
+ * even after multipage bvec is introduced because that space can be
+ * thought as unused by bio_add_page().
*/
int bio_iov_iter_get_pages(struct bio *bio, struct iov_iter *iter)
{
--
2.9.4
[PATCH v3 11/49] btrfs: avoid access to .bi_vcnt directly
BTRFS uses bio->bi_vcnt to figure out page numbers, this
way becomes not correct once we start to enable multipage
bvec.
So use bio_for_each_segment_all() to do that instead.
Cc: Chris Mason
Cc: Josef Bacik
Cc: David Sterba
Cc: linux-bt...@vger.kernel.org
Acked-by: David Sterba
Signed-off-by: Ming Lei
---
fs/btrfs/extent_io.c | 20
fs/btrfs/extent_io.h | 2 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 0aff9b278c19..0e7367817b92 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2258,7 +2258,7 @@ int btrfs_get_io_failure_record(struct inode *inode, u64
start, u64 end,
return 0;
}
-bool btrfs_check_repairable(struct inode *inode, struct bio *failed_bio,
+bool btrfs_check_repairable(struct inode *inode, unsigned failed_bio_pages,
struct io_failure_record *failrec, int failed_mirror)
{
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
@@ -2282,7 +2282,7 @@ bool btrfs_check_repairable(struct inode *inode, struct
bio *failed_bio,
* a) deliver good data to the caller
* b) correct the bad sectors on disk
*/
- if (failed_bio->bi_vcnt > 1) {
+ if (failed_bio_pages > 1) {
/*
* to fulfill b), we need to know the exact failing sectors, as
* we don't want to rewrite any more than the failed ones. thus,
@@ -2355,6 +2355,17 @@ struct bio *btrfs_create_repair_bio(struct inode *inode,
struct bio *failed_bio,
return bio;
}
+static unsigned int get_bio_pages(struct bio *bio)
+{
+ unsigned i;
+ struct bio_vec *bv;
+
+ bio_for_each_segment_all(bv, bio, i)
+ ;
+
+ return i;
+}
+
/*
* this is a generic handler for readpage errors (default
* readpage_io_failed_hook). if other copies exist, read those and write back
@@ -2375,6 +2386,7 @@ static int bio_readpage_error(struct bio *failed_bio, u64
phy_offset,
int read_mode = 0;
blk_status_t status;
int ret;
+ unsigned failed_bio_pages = get_bio_pages(failed_bio);
BUG_ON(bio_op(failed_bio) == REQ_OP_WRITE);
@@ -2382,13 +2394,13 @@ static int bio_readpage_error(struct bio *failed_bio,
u64 phy_offset,
if (ret)
return ret;
- if (!btrfs_check_repairable(inode, failed_bio, failrec,
+ if (!btrfs_check_repairable(inode, failed_bio_pages, failrec,
failed_mirror)) {
free_io_failure(failure_tree, tree, failrec);
return -EIO;
}
- if (failed_bio->bi_vcnt > 1)
+ if (failed_bio_pages > 1)
read_mode |= REQ_FAILFAST_DEV;
phy_offset >>= inode->i_sb->s_blocksize_bits;
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 4f030912f3ef..300ee10f39f2 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -539,7 +539,7 @@ void btrfs_free_io_failure_record(struct btrfs_inode
*inode, u64 start,
u64 end);
int btrfs_get_io_failure_record(struct inode *inode, u64 start, u64 end,
struct io_failure_record **failrec_ret);
-bool btrfs_check_repairable(struct inode *inode, struct bio *failed_bio,
+bool btrfs_check_repairable(struct inode *inode, unsigned failed_bio_pages,
struct io_failure_record *failrec, int fail_mirror);
struct bio *btrfs_create_repair_bio(struct inode *inode, struct bio
*failed_bio,
struct io_failure_record *failrec,
--
2.9.4
[PATCH v3 13/49] btrfs: comment on direct access bvec table
Cc: Chris Mason Cc: Josef Bacik Cc: David Sterba Cc: linux-bt...@vger.kernel.org Acked: David Sterba Signed-off-by: Ming Lei --- fs/btrfs/compression.c | 4 fs/btrfs/inode.c | 12 2 files changed, 16 insertions(+) diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c index d2ef9ac2a630..f795d0a6d176 100644 --- a/fs/btrfs/compression.c +++ b/fs/btrfs/compression.c @@ -542,6 +542,10 @@ blk_status_t btrfs_submit_compressed_read(struct inode *inode, struct bio *bio, /* we need the actual starting offset of this extent in the file */ read_lock(&em_tree->lock); + /* +* It is still safe to retrieve the 1st page of the bio +* in this way after supporting multipage bvec. +*/ em = lookup_extent_mapping(em_tree, page_offset(bio->bi_io_vec->bv_page), PAGE_SIZE); diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 5cf320ee7ea0..084ed99dd308 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -8051,6 +8051,12 @@ static void btrfs_retry_endio_nocsum(struct bio *bio) if (bio->bi_status) goto end; + /* +* WARNING: +* +* With multipage bvec, the following way of direct access to +* bvec table is only safe if the bio includes single page. +*/ ASSERT(bio->bi_vcnt == 1); io_tree = &BTRFS_I(inode)->io_tree; failure_tree = &BTRFS_I(inode)->io_failure_tree; @@ -8143,6 +8149,12 @@ static void btrfs_retry_endio(struct bio *bio) uptodate = 1; + /* +* WARNING: +* +* With multipage bvec, the following way of direct access to +* bvec table is only safe if the bio includes single page. +*/ ASSERT(bio->bi_vcnt == 1); ASSERT(bio->bi_io_vec->bv_len == btrfs_inode_sectorsize(done->inode)); -- 2.9.4
[PATCH v3 15/49] bvec_iter: introduce BVEC_ITER_ALL_INIT
Introduce BVEC_ITER_ALL_INIT for iterating one bio
from start to end.
Signed-off-by: Ming Lei
---
include/linux/bvec.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/bvec.h b/include/linux/bvec.h
index ec8a4d7af6bd..fe7a22dd133b 100644
--- a/include/linux/bvec.h
+++ b/include/linux/bvec.h
@@ -125,4 +125,13 @@ static inline bool bvec_iter_rewind(const struct bio_vec
*bv,
((bvl = bvec_iter_bvec((bio_vec), (iter))), 1); \
bvec_iter_advance((bio_vec), &(iter), (bvl).bv_len))
+/* for iterating one bio from start to end */
+#define BVEC_ITER_ALL_INIT (struct bvec_iter) \
+{ \
+ .bi_sector = 0,\
+ .bi_size= UINT_MAX, \
+ .bi_idx = 0,\
+ .bi_bvec_done = 0,\
+}
+
#endif /* __LINUX_BVEC_ITER_H */
--
2.9.4
[PATCH v3 14/49] block: bounce: avoid direct access to bvec table
We will support multipage bvecs in the future, so change to
iterator way for getting bv_page of bvec from original bio.
Cc: Matthew Wilcox
Signed-off-by: Ming Lei
---
block/bounce.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/block/bounce.c b/block/bounce.c
index 5793c2dc1a15..e57cf2bdcd27 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -136,21 +136,20 @@ static void copy_to_high_bio_irq(struct bio *to, struct
bio *from)
static void bounce_end_io(struct bio *bio, mempool_t *pool)
{
struct bio *bio_orig = bio->bi_private;
- struct bio_vec *bvec, *org_vec;
+ struct bio_vec *bvec, orig_vec;
int i;
- int start = bio_orig->bi_iter.bi_idx;
+ struct bvec_iter orig_iter = bio_orig->bi_iter;
/*
* free up bounce indirect pages used
*/
bio_for_each_segment_all(bvec, bio, i) {
- org_vec = bio_orig->bi_io_vec + i + start;
-
- if (bvec->bv_page == org_vec->bv_page)
- continue;
-
- dec_zone_page_state(bvec->bv_page, NR_BOUNCE);
- mempool_free(bvec->bv_page, pool);
+ orig_vec = bio_iter_iovec(bio_orig, orig_iter);
+ if (bvec->bv_page != orig_vec.bv_page) {
+ dec_zone_page_state(bvec->bv_page, NR_BOUNCE);
+ mempool_free(bvec->bv_page, pool);
+ }
+ bio_advance_iter(bio_orig, &orig_iter, orig_vec.bv_len);
}
bio_orig->bi_status = bio->bi_status;
--
2.9.4
