Re: [PATCH v1 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
On Sat, Jan 14, 2017 at 03:05:30PM +0800, Baoyou Xie wrote:
> +static int zx2967_reset_assert(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + struct zx2967_reset *reset = NULL;
> + int bank = id / 32;
> + int offset = id % 32;
> + unsigned int reg;
u32 is probably better for register value.
> + unsigned long flags;
> +
> + reset = container_of(rcdev, struct zx2967_reset, rcdev);
> +
> + spin_lock_irqsave(&reset->lock, flags);
> +
> + reg = readl(reset->reg_base + (bank * 4));
> + writel(reg & ~BIT(offset), reset->reg_base + (bank * 4));
> + reg = readl(reset->reg_base + (bank * 4));
Is this read on the register is necessary? If so, we should probably
have a comment for that.
> +
> + spin_unlock_irqrestore(&reset->lock, flags);
> +
> + return 0;
> +}
> +
> +static int zx2967_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
Please indent the line right after parentheses.
> +{
> + struct zx2967_reset *reset = NULL;
> + int bank = id / 32;
> + int offset = id % 32;
> + unsigned int reg;
> + unsigned long flags;
> +
> + reset = container_of(rcdev, struct zx2967_reset, rcdev);
> +
> + spin_lock_irqsave(&reset->lock, flags);
> +
> + reg = readl(reset->reg_base + (bank * 4));
> + writel(reg | BIT(offset), reset->reg_base + (bank * 4));
> + reg = readl(reset->reg_base + (bank * 4));
> +
> + spin_unlock_irqrestore(&reset->lock, flags);
> +
> + return 0;
> +}
Only difference between these two functions is only one line. Should we
consolidate them a bit?
Shawn
Re: [PATCH tip/core/rcu 10/20] rcu: Add functions to test for trivial grace periods
On Sat, Jan 14, 2017 at 01:13:11AM -0800, Paul E. McKenney wrote:
> Under some circumstances, RCU grace periods are zero cost. For
> RCU-preempt, this is the case during boot, and for RCU-bh and RCU-sched,
> this is the case if there is only one CPU. This means that RCU users
> might wish to dispense with grace-period-avoidance strategies when
> grace periods are zero cost, so this commit adds rcu_trivial_gp(),
> rcu_bh_trivial_gp(), and rcu_sched_trivial_gp() to test for these
> conditions. Because the conditions leading to zero-cost grace periods
> can change at any time (for example, when a second CPU is onlined), these
> functions should be used as performance hints, and must not be relied
> on for correctness. For example, even if rcu_trivial_gp() returns true,
> you are required to invoke synchronize_rcu().
>
> Signed-off-by: Paul E. McKenney
Do you have anything planned that uses these functions?
Exposing this information, rather than just letting callers call
synchronize_rcu() and sometimes get "free" grace periods, seems
potentially error-prone.
If you keep these functions, please expand the comments above them to
explicitly include the explanation in the commit message, and
specifically that you must always call the corresponding synchronize
function even if these functions return true.
> include/linux/rcupdate.h | 8
> include/linux/rcutiny.h | 10 ++
> include/linux/rcutree.h | 2 ++
> kernel/rcu/tree.c| 24
> kernel/rcu/tree_plugin.h | 11 +++
> 5 files changed, 55 insertions(+)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 01f71e1d2e94..a6222478b87d 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -293,6 +293,7 @@ void __rcu_read_lock(void);
> void __rcu_read_unlock(void);
> void rcu_read_unlock_special(struct task_struct *t);
> void synchronize_rcu(void);
> +bool rcu_trivial_gp(void);
>
> /*
> * Defined as a macro as it is a very low level header included from
> @@ -448,6 +449,13 @@ bool __rcu_is_watching(void);
> #define RCU_SCHEDULER_INIT 1
> #define RCU_SCHEDULER_RUNNING2
>
> +#ifndef CONFIG_PREEMPT_RCU
> +static inline bool rcu_trivial_gp(void)
> +{
> + return rcu_sched_trivial_gp();
> +}
> +#endif /* #ifndef CONFIG_PREEMPT_RCU */
> +
> /*
> * init_rcu_head_on_stack()/destroy_rcu_head_on_stack() are needed for
> dynamic
> * initialization and destruction of rcu_head on the stack. rcu_head
> structures
> diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
> index ac81e4063b40..a77dafe79813 100644
> --- a/include/linux/rcutiny.h
> +++ b/include/linux/rcutiny.h
> @@ -82,6 +82,16 @@ static inline void synchronize_sched_expedited(void)
> synchronize_sched();
> }
>
> +static inline bool rcu_sched_trivial_gp(void)
> +{
> + return true;
> +}
> +
> +static inline bool rcu_bh_trivial_gp(void)
> +{
> + return true;
> +}
> +
> static inline void kfree_call_rcu(struct rcu_head *head,
> rcu_callback_t func)
> {
> diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
> index 63a4e4cf40a5..fcd61cb08851 100644
> --- a/include/linux/rcutree.h
> +++ b/include/linux/rcutree.h
> @@ -47,6 +47,8 @@ static inline void rcu_virt_note_context_switch(int cpu)
> void synchronize_rcu_bh(void);
> void synchronize_sched_expedited(void);
> void synchronize_rcu_expedited(void);
> +bool rcu_sched_trivial_gp(void);
> +bool rcu_bh_trivial_gp(void);
>
> void kfree_call_rcu(struct rcu_head *head, rcu_callback_t func);
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index d7b63b88434b..ed5a17aca281 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3293,6 +3293,18 @@ void synchronize_sched(void)
> EXPORT_SYMBOL_GPL(synchronize_sched);
>
> /**
> + * rcu_sched_trivial_gp - Are RCU-sched grace periods trivially zero cost?
> + *
> + * Returns true if RCU-sched grace periods are currently zero cost, which
> + * they are if there is only one CPU. Note that unless you take steps to
> + * prevent it, the number of CPUs might change at any time.
> + */
> +bool rcu_sched_trivial_gp(void)
> +{
> + return rcu_blocking_is_gp();
> +}
> +
> +/**
> * synchronize_rcu_bh - wait until an rcu_bh grace period has elapsed.
> *
> * Control will return to the caller some time after a full rcu_bh grace
> @@ -3320,6 +3332,18 @@ void synchronize_rcu_bh(void)
> EXPORT_SYMBOL_GPL(synchronize_rcu_bh);
>
> /**
> + * rcu_bh_trivial_gp - Are RCU-bh grace periods trivially zero cost?
> + *
> + * Returns true if RCU-bh grace periods are currently zero cost, which
> + * they are if there is only one CPU. Note that unless you take steps to
> + * prevent it, the number of CPUs might change at any time.
> + */
> +bool rcu_bh_trivial_gp(void)
> +{
> + return rcu_blocking_is_gp();
> +}
> +
> +/**
> * get_state_synchronize_rcu - Snapshot current RCU state
> *
> * Returns a c
Re: [PATCH] fbdev: ssd1307fb: allow reset-gpios is missing
On Sun, Jan 15, 2017 at 07:21:46PM +0800, Icenowy Zheng wrote: > Currently some SSD1306 OLED modules are sold without a reset pin (only > VCC, GND, SCK, SDA four pins). > > Add support for missing reset-gpios property. > > Signed-off-by: Icenowy Zheng Unfortunately, a similar patch has been sent a couple of times already: https://www.spinics.net/lists/devicetree/msg158330.html Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state
On Sat, Jan 14, 2017 at 01:13:12AM -0800, Paul E. McKenney wrote:
> There is some confusion as to which of cond_resched() or
> cond_resched_rcu_qs() should be added to long in-kernel loops.
> This commit therefore eliminates the decision by adding RCU
> quiescent states to cond_resched().
>
> Warning: This is a prototype. For example, it does not correctly
> handle Tasks RCU. Which is OK for the moment, given that no one
> actually uses Tasks RCU yet.
>
> Reported-by: Michal Hocko
> Not-yet-signed-off-by: Paul E. McKenney
> Cc: Peter Zijlstra
Do you intend to merge this patch, or have you just posted it for
review?
You may want to remove it from this 20-patch series and post it as a
separate RFC PATCH, to ensure that it doesn't get merged while still a
prototype.
> include/linux/sched.h | 3 ++-
> kernel/sched/core.c | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 4d1905245c7a..1531c48f56e2 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -3352,10 +3352,11 @@ static inline int signal_pending_state(long state,
> struct task_struct *p)
> * cond_resched_lock() will drop the spinlock before scheduling,
> * cond_resched_softirq() will enable bhs before scheduling.
> */
> +void rcu_all_qs(void);
> #ifndef CONFIG_PREEMPT
> extern int _cond_resched(void);
> #else
> -static inline int _cond_resched(void) { return 0; }
> +static inline int _cond_resched(void) { rcu_all_qs(); return 0; }
> #endif
>
> #define cond_resched() ({\
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c56fb57f2991..b442f8918eb9 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4907,6 +4907,7 @@ int __sched _cond_resched(void)
> preempt_schedule_common();
> return 1;
> }
> + rcu_all_qs();
> return 0;
> }
> EXPORT_SYMBOL(_cond_resched);
> --
> 2.5.2
>
Re: [PATCH tip/core/rcu 0/20] Miscellaneous fixes for 4.11
On Sat, Jan 14, 2017 at 01:12:55AM -0800, Paul E. McKenney wrote: > Hello! > > This series provides miscellaneous fixes: > > 1.Make RCU_EXPEDITE_BOOT be the default in order to speed up > boot, courtesy of Sebastian Andrzej Siewior. > > 2.Make RCU suspicious-access lockdep splats use pr_err(). > > 3.Disable sys_membarrier when nohz_full is enabled, courtesy > of Mathieu Desnoyers. > > 4.Only dump stalled-tasks stacks if there was a real stall, courtesy > of Byungchul Park. > > 5.Remove unneeded rcu_process_callbacks() declarations. > > 6.Remove unused but set "mask" variable, courtesy of Tobias Klauser. > > 7.Remove short-term CPU kicking. > > 8.Add long-term CPU kicking. > > 9.Once again use NMI-based stack traces in stall warnings. > > 10. Add functions to test for trivial grace periods. > > 11. Make cond_resched() provide RCU quiescent state, which will > hopefully lead to the removal of cond_resched_rcu_qs(). > > 12. Re-enable TASKS_RCU for User Mode Linux. > > 13. Don't wake rcuc/X kthreads on NOCB CPUs. > > 14. Add comment headers to expedited-grace-period counter functions. > > 15. Make rcu_cpu_starting() use its "cpu" argument. > > 16. Enable RCU tracepoints by default to aid in debugging, courtesy > of Matt Fleming. > > 17. Fix comment in rcu_organize_nocb_kthreads(), which no longer > spawns kthreads. > > 18. Clarify comments about when llist locking is needed, courtesy > of Joel Fernandes. > > 19. Eliminate unused expedited_normal counter. > > 20. Add lockdep checks to synchronous expedited primitives. I replied to patches 2, 8, 10, and 11 with comments. For the rest: Reviewed-by: Josh Triplett
Re: [PATCH perf/core v2 0/4] perf-probe: Fix and improve module probe events
Ping? Arnaldo, could you merge it if it is acceptable? Thank you, On Wed, 11 Jan 2017 14:58:25 +0900 Masami Hiramatsu wrote: > Hello, > > This is the 2nd version of the series for fixing offline/online > module probe support and improving perf-probe to probe module > without -m option (Thanks Arnaldo!). > This includes below patches. > > - [1/4] Fix perf-probe --list to show correct probe location > in module. > - [2/4] Improve error checking for the probes for offline > kernel. > - [3/4] Fix perf-probe to probe correctly on gcc generated > functions in module. > - [4/4] Improve perf-probe to find probe events in module > without -m option. > > In this version, I updated the patch description of 1/4 > and fix a bug in 4/4. > > Thank you, > > --- > > Masami Hiramatsu (4): > perf-probe: Fix to show correct locations for events on modules > perf-probe: Add error checks to offline probe post-processing > perf-probe: Fix to probe on gcc generated functions in modules > perf-probe: Find probe events without target module > > > tools/perf/util/probe-event.c | 160 > > tools/perf/util/probe-finder.c | 15 ++-- > tools/perf/util/probe-finder.h |3 + > 3 files changed, 121 insertions(+), 57 deletions(-) > > -- > Masami Hiramatsu (Linaro) -- Masami Hiramatsu
Re: [PATCHSET v6] blk-mq scheduling framework
On 01/13/2017 05:02 PM, Jens Axboe wrote:
> On 01/13/2017 09:00 AM, Jens Axboe wrote:
>> On 01/13/2017 08:59 AM, Hannes Reinecke wrote:
>>> On 01/13/2017 04:34 PM, Jens Axboe wrote:
On 01/13/2017 08:33 AM, Hannes Reinecke wrote:
>>> [ .. ]
> Ah, indeed.
> There is an ominous udev rule here, trying to switch to 'deadline'.
>
> # cat 60-ssd-scheduler.rules
> # do not edit this file, it will be overwritten on update
>
> ACTION!="add", GOTO="ssd_scheduler_end"
> SUBSYSTEM!="block", GOTO="ssd_scheduler_end"
>
> IMPORT{cmdline}="elevator"
> ENV{elevator}=="*?", GOTO="ssd_scheduler_end"
>
> KERNEL=="sd*[!0-9]", ATTR{queue/rotational}=="0",
> ATTR{queue/scheduler}="deadline"
>
> LABEL="ssd_scheduler_end"
>
> Still shouldn't crash the kernel, though ...
Of course not, and it's not a given that it does, it could just be
triggering after the device load and failing like expected. But just in
case, can you try and disable that rule and see if it still crashes with
MQ_DEADLINE set as the default?
>>> Yes, it does.
>>> Same stacktrace as before.
>>
>> Alright, that's as expected. I've tried with your rule and making
>> everything modular, but it still boots fine for me. Very odd. Can you
>> send me your .config? And are all the SCSI disks hanging off ahci? Or
>> sdb specifically, is that ahci or something else?
>
> Also, would be great if you could pull:
>
> git://git.kernel.dk/linux-block blk-mq-sched
>
> into current 'master' and see if it still reproduces. I expect that it
> will, but just want to ensure that it's a problem in the current code
> base as well.
>
Actually, it doesn't. Seems to have resolved itself with the latest drop.
However, not I've got a lockdep splat:
Jan 16 09:05:02 lammermuir kernel: [ cut here ]
Jan 16 09:05:02 lammermuir kernel: WARNING: CPU: 29 PID: 5860 at
kernel/locking/lockdep.c:3514 lock_release+0x2a7/0x490
Jan 16 09:05:02 lammermuir kernel: DEBUG_LOCKS_WARN_ON(depth <= 0)
Jan 16 09:05:02 lammermuir kernel: Modules linked in: raid0 mpt3sas
raid_class rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace fscache e
Jan 16 09:05:02 lammermuir kernel: fb_sys_fops ahci uhci_hcd ttm
ehci_pci libahci ehci_hcd serio_raw crc32c_intel drm libata usbcore hpsa
Jan 16 09:05:02 lammermuir kernel: CPU: 29 PID: 5860 Comm: fio Not
tainted 4.10.0-rc3+ #540
Jan 16 09:05:02 lammermuir kernel: Hardware name: HP ProLiant ML350p
Gen8, BIOS P72 09/08/2013
Jan 16 09:05:02 lammermuir kernel: Call Trace:
Jan 16 09:05:02 lammermuir kernel: dump_stack+0x85/0xc9
Jan 16 09:05:02 lammermuir kernel: __warn+0xd1/0xf0
Jan 16 09:05:02 lammermuir kernel: ? aio_write+0x118/0x170
Jan 16 09:05:02 lammermuir kernel: warn_slowpath_fmt+0x4f/0x60
Jan 16 09:05:02 lammermuir kernel: lock_release+0x2a7/0x490
Jan 16 09:05:02 lammermuir kernel: ? blkdev_write_iter+0x89/0xd0
Jan 16 09:05:02 lammermuir kernel: aio_write+0x138/0x170
Jan 16 09:05:02 lammermuir kernel: do_io_submit+0x4d2/0x8f0
Jan 16 09:05:02 lammermuir kernel: ? do_io_submit+0x413/0x8f0
Jan 16 09:05:02 lammermuir kernel: SyS_io_submit+0x10/0x20
Jan 16 09:05:02 lammermuir kernel: entry_SYSCALL_64_fastpath+0x23/0xc6
Cheers,
Hannes
--
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
Hi Łukasz,
On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
> Hi Kishon,
>
>> Hi,
>>
>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>> Some devices (due to e.g. bad PCIe signal integrity) require to run
>>> with forced GEN1 speed on PCIe bus.
>>>
>>> This patch changes the speed explicitly on dra7 based devices when
>>> proper device tree attribute is defined for the PCIe controller.
>>>
>>> Signed-off-by: Lukasz Majewski
>>
>> Bjorn has already queued a patch to do the same thing
>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xx
>
> It seems like Bjorn only modifies CAP registers.
The patch also modifies the LNKCTL2 register.
>
> He also needs to change register with 0x080C offset to actually
> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
This bit is used to initiate speed change (after the link is initialized in
GEN1). Resetting the bit (like what you have done here) prevents speed change.
IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking the IP
register.
Thanks
Kishon
>
> Best regards,
> Łukasz
>
>>
>> Thanks
>> Kishon
>>
>>> ---
>>>
>>> Patch applies on newest origin/master
>>> SHA1: f4d3935e4f4884ba80561db5549394afb8eef8f7
>>>
>>> Tested at AM5728
>>>
>>> ---
>>> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
>>> drivers/pci/host/pci-dra7xx.c| 23
>>> +++
>>> drivers/pci/host/pcie-designware.h | 1 + 3 files
>>> changed, 25 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
>>> b/Documentation/devicetree/bindings/pci/ti-pci.txt index
>>> 60e2516..9f97409 100644 ---
>>> a/Documentation/devicetree/bindings/pci/ti-pci.txt +++
>>> b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -25,6 +25,7
>>> @@ PCIe Designware Controller
>>> Optional Property:
>>> - gpios : Should be added if a gpio line is required to drive
>>> PERST# line
>>> + - to,pcie-is-gen1: Indicates that forced gen1 port operation is
>>> needed.
>>> Example:
>>> axi {
>>> diff --git a/drivers/pci/host/pci-dra7xx.c
>>> b/drivers/pci/host/pci-dra7xx.c index 9595fad..eec5fae 100644
>>> --- a/drivers/pci/host/pci-dra7xx.c
>>> +++
>>> b/drivers/pci/host/pci-https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xxdra7xx.c
>>> @@ -63,6 +63,13 @@ #define
>>> LINK_UP BIT(16)
>>> #define
>>> DRA7XX_CPU_TO_BUS_ADDR 0x0FFF
>>> +#define PCIECTRL_EP_DBICS_LNK_CAP
>>> 0x007C +#define
>>> MAX_LINK_SPEEDS_MASKGENMASK(3, 0)
>>> +#define MAX_LINK_SPEEDS_GEN1
>>> BIT(0) + +#define
>>> PCIECTRL_PL_WIDTH_SPEED_CTL 0x080C
>>> +#define CFG_DIRECTED_SPEED_CHANGE
>>> BIT(17) + struct dra7xx_pcie { struct pcie_port pp;
>>> void __iomem*base; /* DT
>>> ti_conf */ @@ -270,6 +277,7 @@ static int __init
>>> dra7xx_add_pcie_port(struct dra7xx_pcie *dra7xx, struct pcie_port
>>> *pp = &dra7xx->pp; struct device *dev = pp->dev;
>>> struct resource *res;
>>> + u32 val;
>>>
>>> pp->irq = platform_get_irq(pdev, 1);
>>> if (pp->irq < 0) {
>>> @@ -296,6 +304,18 @@ static int __init dra7xx_add_pcie_port(struct
>>> dra7xx_pcie *dra7xx, if (!pp->dbi_base)
>>> return -ENOMEM;
>>>
>>> + if (pp->is_gen1) {
>>> + dev_info(dev, "GEN1 forced\n");
>>> +
>>> + val = readl(pp->dbi_base +
>>> PCIECTRL_EP_DBICS_LNK_CAP);
>>> + set_mask_bits(&val, MAX_LINK_SPEEDS_MASK,
>>> MAX_LINK_SPEEDS_GEN1);
>>> + writel(val, pp->dbi_base +
>>> PCIECTRL_EP_DBICS_LNK_CAP); +
>>> + val = readl(pp->dbi_base +
>>> PCIECTRL_PL_WIDTH_SPEED_CTL);
>>> + val &= ~CFG_DIRECTED_SPEED_CHANGE;
>>> + writel(val, pp->dbi_base +
>>> PCIECTRL_PL_WIDTH_SPEED_CTL);
>>> + }
>>> +
>>> ret = dw_pcie_host_init(pp);
>>> if (ret) {
>>> dev_err(dev, "failed to initialize host\n");
>>> @@ -404,6 +424,9 @@ static int __init dra7xx_pcie_probe(struct
>>> platform_device *pdev) goto err_gpio;
>>> }
>>>
>>> + if (of_property_read_bool(np, "ti,pcie-is-gen1"))
>>> + pp->is_gen1 = true;
>>> +
>>> reg = dra7xx_pcie_readl(dra7xx,
>>> PCIECTRL_DRA7XX_CONF_DEVICE_CMD); reg &= ~LTSSM_EN;
>>> dra7xx_pcie_writel(dra7xx,
>>> PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg); diff --git
>>> a/drivers/pci/host/pcie-designware.h
>>> b/drivers/pci/host/pcie-designware.h index a567ea2..2fb0b18 100644
>>> --- a/drivers/pci/host/pcie-designware.h +++
>>> b/drivers/pci/host/pcie-designware.h @@ -50,6 +50,7 @@ struct
>>> pcie_port { struct irq_domain *irq_domain;
>>> unsigned long msi_data;
>>> u8 iatu_unroll_enabled;
>>> + u8 is_gen1;
>>> DECLARE_BITMAP(msi_irq_in_use, MAX_MSI_IRQS);
>>> };
>>>
>>>
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DE
Re: [PATCH] mm, page_alloc: don't check cpuset allowed twice in fast-path
On 01/06/2017 04:10 PM, Michal Hocko wrote:
> On Fri 06-01-17 09:18:05, Vlastimil Babka wrote:
>> Since commit 682a3385e773 ("mm, page_alloc: inline the fast path of the
>> zonelist iterator") we replace a NULL nodemask with
>> cpuset_current_mems_allowed
>> in the fast path, so that get_page_from_freelist() filters nodes allowed by
>> the
>> cpuset via for_next_zone_zonelist_nodemask(). In that case it's pointless to
>> also check __cpuset_zone_allowed(), which we can avoid by not using
>> ALLOC_CPUSET in that scenario.
>
> OK, this seems to be really worth it as most allocations go via
> __alloc_pages so we can save __cpuset_zone_allowed in the fast path.
>
> I was about to object how fragile this might be wrt. other ALLOC_CPUSET
> checks but then I've realized this is only for the hotpath as the
> slowpath goes through gfp_to_alloc_flags() which sets it back on.
>
> Maybe all that could be added to the changelog?
Agreed, all these should be added into the change log as the effect
of cpuset based nodemask during fast path and slow path is little
bit confusing.
>
>> Signed-off-by: Vlastimil Babka
>
> Acked-by: Michal Hocko
Reviewed-by: Anshuman Khandual
RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
> -Original Message- > From: Jerry Huang > Sent: Wednesday, January 04, 2017 10:25 AM > To: 'Rob Herring' > Cc: ba...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com; > will.dea...@arm.com; li...@armlinux.org.uk; devicet...@vger.kernel.org; > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst- > type-adjustment" for INCR burst type > > Hi, Rob, > > > -Original Message- > > From: Rob Herring [mailto:r...@kernel.org] > > Sent: Wednesday, January 04, 2017 5:24 AM > > To: Jerry Huang > > Cc: ba...@kernel.org; mark.rutl...@arm.com; catalin.mari...@arm.com; > > will.dea...@arm.com; li...@armlinux.org.uk; > > devicet...@vger.kernel.org; linux-...@vger.kernel.org; > > linux-kernel@vger.kernel.org; linux-arm- ker...@lists.infradead.org > > Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst- > > type-adjustment" for INCR burst type > > > > On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang > wrote: > > > Hi, Rob, > > >> -Original Message- > > >> From: Rob Herring [mailto:r...@kernel.org] > > >> Sent: Friday, December 23, 2016 2:45 AM > > >> To: Jerry Huang > > >> Cc: ba...@kernel.org; mark.rutl...@arm.com; > > >> catalin.mari...@arm.com; will.dea...@arm.com; > > >> li...@armlinux.org.uk; devicet...@vger.kernel.org; > > >> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- > > >> ker...@lists.infradead.org > > >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, > > >> incr-burst- type-adjustment" for INCR burst type > > >> > > >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote: > > >> > New property "snps,incr-burst-type-adjustment = , " for > > >> > USB3.0 > > >> DWC3. > > >> > Field "x": 1/0 - undefined length INCR burst type enable or not; > > >> > Field > > >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst > type. > > >> > > > >> > While enabling undefined length INCR burst type and INCR16 burst > > >> > type, get better write performance on NXP Layerscape platform: > > >> > around 3% improvement (from 364MB/s to 375MB/s). > > >> > > > >> > Signed-off-by: Changming Huang > > >> > --- > > >> > Changes in v3: > > >> > - add new property for INCR burst in usb node. > > >> > > > >> > Documentation/devicetree/bindings/usb/dwc3.txt |5 + > > >> > arch/arm/boot/dts/ls1021a.dtsi |1 + > > >> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++ > > >> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |2 ++ > > >> > 4 files changed, 11 insertions(+) > > >> > > > >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt > > >> > b/Documentation/devicetree/bindings/usb/dwc3.txt > > >> > index e3e6983..8c405a3 100644 > > >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt > > >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt > > >> > @@ -55,6 +55,10 @@ Optional properties: > > >> > fladj_30mhz_sdbnd signal is invalid or incorrect. > > >> > > > >> > - tx-fifo-resize: determines if the FIFO *has* to > > >> > be > > >> reallocated. > > >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of > > >> GSBUSCFG0 > > >> > + register, undefined length INCR burst type enable and INCRx type. > > >> > + First field is for undefined length INCR burst type enable or not. > > >> > + Second field is for largest INCRx type enabled. > > >> > > >> Why do you need the first field? Is the 2nd field used if the 1st is 0? > > >> If not, then just use the presence of the property to enable or not. > > > The first field is one switch. > > > When it is 1, means undefined length INCR burst type enabled, we can > > > use > > any length less than or equal to the largest-enabled burst length of > > INCR4/8/16/32/64/128/256. > > > When it is zero, means INCRx burst mode enabled, we can use one > > > fixed > > burst length of 1/4/8/16/32/64/128/256 byte. > > > So, the 2nd field is used if the 1st is 0, we need to select one > > > largest burst > > length the USB controller can support. > > > If we don't want to change the value of this register (use the > > > default value), > > we don't need to add this property to usb node. > > > > Just make this a single value with 0 meaning INCR and 4/8/16/etc being > INCRx. > Maybe, I didn't describe it clearly. > According to DWC3 spec, the value "0" of field INCRBrstEna means INCRx > burst mode, 1 means INCR burst mode. > Regardless of the value of INCRBrstEna [bit0], we need to modify the other > field bit[1,2,3,4,5,6,7] to one INCR burst type for the platform supported. > Ad you mentioned, if we just use a single value with 0 meaning INCR and > 4/8/16/etc being INCRx. > I understand totally that when it is none-zero, we can use it for INCR burst > mode. > Then, when it is 0, how to select the INCRx value? > > So, I think we still need two vaue to specify INCRBrstEna and INCRx burst > type. Hi, Balb
Re: [PATCH 1/2] ns: Allow ns_entries to have custom symlink content
On Sat, Jan 14, 2017 at 05:14:48PM +0300, Kirill Tkhai wrote: > Make possible to have link content prefix yyy > different from the link name xxx: > > $ readlink /proc/[pid]/ns/xxx > yyy:[4026531838] > > This will be used in next patch. > > Signed-off-by: Kirill Tkhai I don't like much @real_ns_name variable naming, but it's just personal opinion. The rest looks good to me (for both patches). If only I didn't miss something obvious. Reviewed-by: Cyrill Gorcunov
Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
On 12/01/2017 5:37 PM, Michal Hocko wrote: From: Michal Hocko There are many code paths opencoding kvmalloc. Let's use the helper instead. The main difference to kvmalloc is that those users are usually not considering all the aspects of the memory allocator. E.g. allocation requests < 64kB are basically never failing and invoke OOM killer to satisfy the allocation. This sounds too disruptive for something that has a reasonable fallback - the vmalloc. On the other hand those requests might fallback to vmalloc even when the memory allocator would succeed after several more reclaim/compaction attempts previously. There is no guarantee something like that happens though. This patch converts many of those places to kv[mz]alloc* helpers because they are more conservative. Cc: Martin Schwidefsky Cc: Heiko Carstens Cc: Herbert Xu Cc: Anton Vorontsov Cc: Colin Cross Cc: Kees Cook Cc: Tony Luck Cc: "Rafael J. Wysocki" Cc: Ben Skeggs Cc: Kent Overstreet Cc: Santosh Raspatur Cc: Hariprasad S Cc: Tariq Toukan Cc: Yishai Hadas Cc: Dan Williams Cc: Oleg Drokin Cc: Andreas Dilger Cc: Boris Ostrovsky Cc: David Sterba Cc: "Yan, Zheng" Cc: Ilya Dryomov Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Eric Dumazet Cc: net...@vger.kernel.org Signed-off-by: Michal Hocko --- Acked-by: Tariq Toukan For the mlx4 parts. Regards. Tariq
Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
On Mon, Jan 16, 2017 at 08:33:11AM +0100, Michal Hocko wrote:
> On Sat 14-01-17 12:56:32, Leon Romanovsky wrote:
> [...]
> > Hi Michal,
> >
> > I don't see mlx5_vzalloc in the changed list. Any reason why did you skip
> > it?
> >
> > 881 static inline void *mlx5_vzalloc(unsigned long size)
> > 882 {
> > 883 void *rtn;
> > 884
> > 885 rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
> > 886 if (!rtn)
> > 887 rtn = vzalloc(size);
> > 888 return rtn;
> > 889 }
>
> No reason to skip it, I just didn't see it. I will fold the following in
> if you are OK with it
Sure, no problem.
Once, the patch set is accepted, we (Mellanox) will get rid of mlx5_vzalloc().
Thanks
> ---
> diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h
> index cdd2bd62f86d..5e6063170e48 100644
> --- a/include/linux/mlx5/driver.h
> +++ b/include/linux/mlx5/driver.h
> @@ -874,12 +874,7 @@ static inline u16 cmdif_rev(struct mlx5_core_dev *dev)
>
> static inline void *mlx5_vzalloc(unsigned long size)
> {
> - void *rtn;
> -
> - rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
> - if (!rtn)
> - rtn = vzalloc(size);
> - return rtn;
> + return kvzalloc(GFP_KERNEL, size);
> }
>
> static inline u32 mlx5_base_mkey(const u32 key)
>
> --
> Michal Hocko
> SUSE Labs
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
signature.asc
Description: PGP signature
Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote: > Hi Peter, Laurent! > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote: > > On 04 January, 2017 21:39 CET, Rob Herring wrote: > > > On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin wrote: > > >> On 03 January, 2017 23:51 CET, Rob Herring wrote: > > >>> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote: > > Devicetree bindings documentation for the GE B850v3 LVDS/DP++ > > display bridge. > > > > Cc: Martyn Welch > > Cc: Martin Donnelly > > Cc: Javier Martinez Canillas > > Cc: Enric Balletbo i Serra > > Cc: Philipp Zabel > > Cc: Rob Herring > > Cc: Fabio Estevam > > Signed-off-by: Peter Senna Tschudin > > --- > > There was an Acked-by from Rob Herring for V6, but > > I changed the bindings to use i2c_new_secondary_device() so I > > removed it from the commit message. > > > > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++ > > >>> Generally, bindings are not organized by vendor. Put in > > >>> bindings/display/bridge/... instead. > > >> > > >> Will change that. > > >> > > 1 file changed, 39 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt > > > > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt > > b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt new file > > mode 100644 > > index 000..1bc6ebf > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt > > @@ -0,0 +1,39 @@ > > +Driver for GE B850v3 LVDS/DP++ display bridge > > + > > +Required properties: > > + - compatible : should be "ge,b850v3-lvds-dp". > > >>> > > >>> Isn't '-lvds-dp' redundant? The part# should be enough. > > >> > > >> b850v3 is the name of the product, this is why the proposed name. What > > >> about, b850v3-dp2 dp2 indicating the second DP output? > > > > > > Humm, b850v3 is the board name? This node should be the name of the bridge > > > chip. > > > > From the cover letter: > > > > -- // -- > > There are two physical bridges on the video signal pipeline: a STDP4028(LVDS > > to DP) and a STDP2690(DP to DP++). The hardware and firmware made it > > complicated for this binding to comprise two device tree nodes, as the > > design goal is to configure both bridges based on the LVDS signal, which > > leave the driver powerless to control the video processing pipeline. The > > two bridges behaves as a single bridge, and the driver is only needed for > > telling the host about EDID / HPD, and for giving the host powers to ack > > interrupts. The video signal pipeline is as follows: > > > > Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output > > -- // -- > > You forgot to prefix your patch series with [HACK] ;-) > > How about fixing the issues that make the two DT nodes solution difficult ? > What are they ? The Firmware and the hardware design. Both bridges, with stock firmware, are fully capable of providig EDID information and handling interrupts. But on this specific design, with this specific firmware, I need to read EDID from one bridge, and handle interrupts on the other. Back when I was starting the development I could not come up with a proper way to split EDID and interrupts between two bridges in a way that would result in a fully functional connector. Did I miss something? > > -- > Regards, > > Laurent Pinchart >
Re: [PATCH V2 2/5] phy: phy-exynos-pcie: Add support for Exynos PCIe phy
Hi, On Wednesday 04 January 2017 06:04 PM, Jaehoon Chung wrote: > This patch supports to use Generic Phy framework for Exynos PCIe phy. > When Exynos that supported the pcie want to use the PCIe, > it needs to control the phy resgister. > But it should be more complex to control in their own PCIe device drivers. > > Currently, there is an exynos5440 case to support the pcie. > So this driver is based on Exynos5440 PCIe. > In future, will support the Other exynos SoCs likes exynos5433, exynos7. please re-write the commit message. > > Signed-off-by: Jaehoon Chung > --- > Changelog on V2: > - Not include the codes relevant to pci-exynos. > - Remove the getting child node. > > drivers/phy/Kconfig | 9 ++ > drivers/phy/Makefile | 1 + > drivers/phy/phy-exynos-pcie.c | 280 > ++ > 3 files changed, 290 insertions(+) > create mode 100644 drivers/phy/phy-exynos-pcie.c > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index e8eb7f2..2dddef4 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -331,6 +331,15 @@ config PHY_EXYNOS5_USBDRD > This driver provides PHY interface for USB 3.0 DRD controller > present on Exynos5 SoC series. > > +config PHY_EXYNOS_PCIE > + bool "Exynos PCIe PHY driver" > + depends on ARCH_EXYNOS && OF include COMPILE_TEST > + depends on PCI_EXYNOS PCI_EXYNOS should depend on PHY_EXYNOS_PCIE if at all required. Or else do away with this dependency. > + select GENERIC_PHY > + help > + Enable PCIe PHY support for Exynos SoC series. > + This driver provides PHY interface for Exynos PCIe controller. > + > config PHY_PISTACHIO_USB > tristate "IMG Pistachio USB2.0 PHY driver" > depends on MACH_PISTACHIO > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 65eb2f4..081aeb4 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -37,6 +37,7 @@ phy-exynos-usb2-$(CONFIG_PHY_EXYNOS4X12_USB2) += > phy-exynos4x12-usb2.o > phy-exynos-usb2-$(CONFIG_PHY_EXYNOS5250_USB2)+= phy-exynos5250-usb2.o > phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2) += phy-s5pv210-usb2.o > obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o > +obj-$(CONFIG_PHY_EXYNOS_PCIE)+= phy-exynos-pcie.o > obj-$(CONFIG_PHY_QCOM_APQ8064_SATA) += phy-qcom-apq8064-sata.o > obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o > obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o > diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c > new file mode 100644 > index 000..b57f49b > --- /dev/null > +++ b/drivers/phy/phy-exynos-pcie.c > @@ -0,0 +1,280 @@ > +/* > + * Samsung EXYNOS SoC series PCIe PHY driver > + * > + * Phy provider for PCIe controller on Exynos SoC series > + * > + * Copyright (C) 2016 Samsung Electronics Co., Ltd. 2017? > + * Jaehoon Chung > + * > + * 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 > + > +/* PCIe Purple registers */ > +#define PCIE_PHY_GLOBAL_RESET0x000 > +#define PCIE_PHY_COMMON_RESET0x004 > +#define PCIE_PHY_CMN_REG 0x008 > +#define PCIE_PHY_MAC_RESET 0x00c > +#define PCIE_PHY_PLL_LOCKED 0x010 > +#define PCIE_PHY_TRSVREG_RESET 0x020 > +#define PCIE_PHY_TRSV_RESET 0x024 Please use BIT() macro for bit definitions. > + > +/* PCIe PHY registers */ > +#define PCIE_PHY_IMPEDANCE 0x004 > +#define PCIE_PHY_PLL_DIV_0 0x008 > +#define PCIE_PHY_PLL_BIAS0x00c > +#define PCIE_PHY_DCC_FEEDBACK0x014 > +#define PCIE_PHY_PLL_DIV_1 0x05c > +#define PCIE_PHY_COMMON_POWER0x064 > +#define PCIE_PHY_COMMON_PD_CMN BIT(3) > +#define PCIE_PHY_TRSV0_EMP_LVL 0x084 > +#define PCIE_PHY_TRSV0_DRV_LVL 0x088 > +#define PCIE_PHY_TRSV0_RXCDR 0x0ac > +#define PCIE_PHY_TRSV0_POWER 0x0c4 > +#define PCIE_PHY_TRSV0_PD_TSVBIT(7) > +#define PCIE_PHY_TRSV0_LVCC 0x0dc > +#define PCIE_PHY_TRSV1_EMP_LVL 0x144 > +#define PCIE_PHY_TRSV1_RXCDR 0x16c > +#define PCIE_PHY_TRSV1_POWER 0x184 > +#define PCIE_PHY_TRSV1_PD_TSVBIT(7) > +#define PCIE_PHY_TRSV1_LVCC 0x19c > +#define PCIE_PHY_TRSV2_EMP_LVL 0x204 > +#define PCIE_PHY_TRSV2_RXCDR 0x22c > +#define PCIE_PHY_TRSV2_POWER 0x244 > +#define PCIE_PHY_TRSV2_PD_TSVBIT(7) > +#define PCIE_PHY_TRSV2_LVCC 0x25c > +#define PCIE_PHY_TRSV3_EMP_LVL 0x2c4 > +#define PCIE_PHY_TRSV3_RXCDR 0x2ec > +#define PCIE_PHY_TRSV3_POWER
Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
On Sun, 15 Jan 2017 01:23:48 +0100
Marek Vasut wrote:
> On 01/14/2017 09:29 AM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 18:33:40 +0100
> > Marek Vasut wrote:
> >
> >> On 01/13/2017 05:56 PM, Boris Brezillon wrote:
> >>> On Fri, 13 Jan 2017 17:44:12 +0100
> >>> Marek Vasut wrote:
> >>>
> On 01/13/2017 05:28 PM, Boris Brezillon wrote:
> > On Fri, 13 Jan 2017 17:13:55 +0100
> > Marek Vasut wrote:
> >
> >> On 01/13/2017 04:12 PM, Matthias Brugger wrote:
> >>>
> >>>
> >>> On 13/01/17 15:17, Boris Brezillon wrote:
> On Fri, 13 Jan 2017 15:13:29 +0800
> Guochun Mao wrote:
>
> > Add Mediatek nor flash node.
> >
> > Signed-off-by: Guochun Mao
> > ---
> > arch/arm/boot/dts/mt2701-evb.dts | 25 +
> > arch/arm/boot/dts/mt2701.dtsi| 12
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/mt2701-evb.dts
> > b/arch/arm/boot/dts/mt2701-evb.dts
> > index 082ca88..85e5ae8 100644
> > --- a/arch/arm/boot/dts/mt2701-evb.dts
> > +++ b/arch/arm/boot/dts/mt2701-evb.dts
> > @@ -24,6 +24,31 @@
> > };
> > };
> >
> > +&nor_flash {
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&nor_pins_default>;
> > +status = "okay";
> > +flash@0 {
> > +compatible = "jedec,spi-nor";
> > +reg = <0>;
> > +};
> > +};
> > +
> > +&pio {
> > +nor_pins_default: nor {
> > +pins1 {
> > +pinmux = ,
> > + ,
> > + ,
> > + ,
> > + ,
> > + ;
> > +drive-strength = ;
> > +bias-pull-up;
> > +};
> > +};
> > +};
> > +
> > &uart0 {
> > status = "okay";
> > };
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi
> > b/arch/arm/boot/dts/mt2701.dtsi
> > index bdf8954..1eefce4 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -227,6 +227,18 @@
> > status = "disabled";
> > };
> >
> > +nor_flash: spi@11014000 {
> > +compatible = "mediatek,mt2701-nor",
> > + "mediatek,mt8173-nor";
>
> Why define both here? Is "mediatek,mt8173-nor" really providing a
> subset of the features supported by "mediatek,mt2701-nor"?
>
> >>>
> >>> I think even if the ip block is the same, we should provide both
> >>> bindings, just in case in the future we find out that mt2701 has some
> >>> hidden bug, feature or bug-feature. This way even if we update the
> >>> driver, we stay compatible with older device tree blobs in the wild.
> >>>
> >>> We can drop the mt2701-nor in the bindings definition if you want.
> >>>
> >
> > Oh, sorry, I misunderstood. What I meant is that if you want to
> > list/support all possible compatibles, maybe you should just put one
> > compatible in your DT and patch your driver (+ binding doc) to define
> > all of them.
>
> Uh, what ? I lost you here :-)
> >
> > I mean adding a new entry in the mtk_nor_of_ids table (in
> > mtk-quadspi.c) so that the mediatek,mt2701-nor compatible string can be
> > matched directly, and you won't need to define 2 compatible strings in
> > your device tree.
>
> But then you grow the table in the driver, is that what we want if we
> can avoid that ?
The space you save by not growing the mtk_nor_of_ids table is lost in
your dtbs, so I'm not sure the size argument is relevant here. Also,
note that distros are shipping a lot of dtbs, and you're likely to have
several boards based on the mt2701 SoC, so, for this specific use case,
it's better to make the in-driver of-id table grow than specifying 2
compatibles in the DT. But as I said, I'm not sure we should rely on
this argument to decide which approach to choose (we're talking about a
few bytes here).
>
>
> >> This exactly. We should have a DT compat in the form:
> >> compatible = "vendor,-block", "vendor,-block";
> >> Then if we find a problem in the future, we can match on the
> >> "vendor,-block" and still support the old DTs.
> >
> > Not sure it's only in term of whose IP appeared first. My understanding
> > is that it's a way to provide inheritance. For example:
> >
> > ",", ",";
> >
> > or
> >
> >
> > ",",",";
> >
> > BTW, which one is the oldest between mt8173 an
Re: [PATCH v4 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
Hi, On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote: > PHY transceiver driver for QUSB2 phy controller that provides > HighSpeed functionality for DWC3 controller present on > Qualcomm chipsets. > > Signed-off-by: Vivek Gautam > Reviewed-by: Stephen Boyd > --- > > Changes since v3: > - Added 'Reviewed-by' from Stephen. > - Fixed debug message for qusb2_phy_set_tune2_param(). > - Replaced devm_reset_control_get() with devm_reset_control_get_by_index() >since we are requesting only one reset. > - Updated devm_nvmem_cell_get() with a NULL cell id. > - Made error labels more idiomatic. > - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept >base address and register offset as two separate arguments. > > Changes since v2: > - Removed selecting 'RESET_CONTROLLER' config. > - Added error handling for clk_prepare_enable paths. > - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to >do that since 'xo' is modeled as parent to this clock. > - Removed 'ref_clk_src' handling. Driver doesn't need to request and >handle this clock. > - Moved nvmem_cell_get() to probe function. > - Simplified phy pll status handling. > - Using of_device_get_match_data() to get match data. > - Uniformly using lowercase for hex numbers. > - Fixed sparse warnings. > - Using shorter variable names in structure and in functions. > - Handling various comment style shortcomings. > > Changes since v1: > - removed reference to clk_enabled/pwr_enabled. > - moved clock and regulator enable code to phy_power_on/off() callbacks. > - fixed return on EPROBE_DEFER in qusb2_phy_probe(). > - fixed phy create and phy register ordering. > - removed references to non-lkml links from commit message. > - took care of other minor nits. > - Fixed coccinelle warnings - >'PTR_ERR applied after initialization to constant' > - Addressed review comment, regarding qfprom access for tune2 param value. >This driver is now based on qfprom patch[1] that allows byte access now. > > drivers/phy/Kconfig | 10 + > drivers/phy/Makefile | 1 + > drivers/phy/phy-qcom-qusb2.c | 539 > +++ > 3 files changed, 550 insertions(+) > create mode 100644 drivers/phy/phy-qcom-qusb2.c > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index e8eb7f225a88..0ed53d018b23 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -430,6 +430,16 @@ config PHY_STIH407_USB > Enable this support to enable the picoPHY device used by USB2 > and USB3 controllers on STMicroelectronics STiH407 SoC families. > > +config PHY_QCOM_QUSB2 > + tristate "Qualcomm QUSB2 PHY Driver" > + depends on OF && (ARCH_QCOM || COMPILE_TEST) > + select GENERIC_PHY > + help > + Enable this to support the HighSpeed QUSB2 PHY transceiver for USB > + controllers on Qualcomm chips. This driver supports the high-speed > + PHY which is usually paired with either the ChipIdea or Synopsys DWC3 > + USB IPs on MSM SOCs. > + > config PHY_QCOM_UFS > tristate "Qualcomm UFS PHY driver" > depends on OF && ARCH_QCOM > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 65eb2f436a41..dad1682b80e3 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -49,6 +49,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)+= > phy-spear1310-miphy.o > obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY) += phy-spear1340-miphy.o > obj-$(CONFIG_PHY_XGENE) += phy-xgene.o > obj-$(CONFIG_PHY_STIH407_USB)+= phy-stih407-usb.o > +obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o > obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o > diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c > new file mode 100644 > index ..c69118610164 > --- /dev/null > +++ b/drivers/phy/phy-qcom-qusb2.c > @@ -0,0 +1,539 @@ > +/* > + * Copyright (c) 2016, 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 > + * only 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 > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define QUSB2PHY_PLL_TEST0x04 > +#define CLK_REF_SEL BIT(7) > + > +#define QUSB2PHY_PLL_TUNE0x08 > +#d
drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function
Hi Dave,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 49def1853334396f948dcb4cedb9347abb318df5
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new
lightweight SGL iterators
date: 8 months ago
config: x86_64-randconfig-a0-01161431 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All errors (new ones prefixed by >>):
cc1: warnings being treated as errors
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used
>> uninitialized in this function
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used
uninitialized in this function
vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c
2361 enum i915_cache_level level, u32
unused)
2362 {
2363 struct drm_i915_private *dev_priv = to_i915(vm->dev);
2364 struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
2365 struct sgt_iter sgt_iter;
2366 gen8_pte_t __iomem *gtt_entries;
> 2367 gen8_pte_t gtt_entry;
2368 dma_addr_t addr;
2369 int rpm_atomic_seq;
2370 int i = 0;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 1/6] mm: introduce kv[mz]alloc helpers
On Sun 15-01-17 20:34:13, John Hubbard wrote:
>
>
> On 01/12/2017 07:37 AM, Michal Hocko wrote:
[...]
> > diff --git a/mm/util.c b/mm/util.c
> > index 3cb2164f4099..7e0c240b5760 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -324,6 +324,48 @@ unsigned long vm_mmap(struct file *file, unsigned long
> > addr,
> > }
> > EXPORT_SYMBOL(vm_mmap);
> >
> > +/**
> > + * kvmalloc_node - allocate contiguous memory from SLAB with vmalloc
> > fallback
>
> Hi Michal,
>
> How about this wording instead:
>
> kvmalloc_node - attempt to allocate physically contiguous memory, but upon
> failure, fall back to non-contiguous (vmalloc) allocation.
OK, why not.
> > + * @size: size of the request.
> > + * @flags: gfp mask for the allocation - must be compatible (superset)
> > with GFP_KERNEL.
> > + * @node: numa node to allocate from
> > + *
> > + * Uses kmalloc to get the memory but if the allocation fails then falls
> > back
> > + * to the vmalloc allocator. Use kvfree for freeing the memory.
> > + *
> > + * Reclaim modifiers - __GFP_NORETRY, __GFP_REPEAT and __GFP_NOFAIL are
> > not supported
>
> Is that "Reclaim modifiers" line still true, or is it a leftover from an
> earlier approach? I am having trouble reconciling it with rest of the
> patchset, because:
>
> a) the flags argument below is effectively passed on to either kmalloc_node
> (possibly adding, but not removing flags), or to __vmalloc_node_flags.
The above only says thos are _unsupported_ - in other words the behavior
is not defined. Even if flags are passed down to kmalloc resp. vmalloc
it doesn't mean they are used that way. Remember that vmalloc uses
some hardcoded GFP_KERNEL allocations. So while I could be really
strict about this and mask away these flags I doubt this is worth the
additional code.
> b) In patch 6/6, you are in fact passing in __GFP_REPEAT to the wrappers
> (kvzalloc, for example), and again, only adding, not removing flags.
Patch 2 adds a support for __GFP_REPEAT and updates the above line as
well.
> > + */
> > +void *kvmalloc_node(size_t size, gfp_t flags, int node)
> > +{
> > + gfp_t kmalloc_flags = flags;
> > + void *ret;
> > +
> > + /*
> > +* vmalloc uses GFP_KERNEL for some internal allocations (e.g page
> > tables)
> > +* so the given set of flags has to be compatible.
> > +*/
> > + WARN_ON_ONCE((flags & GFP_KERNEL) != GFP_KERNEL);
> > +
> > + /*
> > +* Make sure that larger requests are not too disruptive - no OOM
> > +* killer and no allocation failure warnings as we have a fallback
> > +*/
> > + if (size > PAGE_SIZE)
> > + kmalloc_flags |= __GFP_NORETRY | __GFP_NOWARN;
> > +
> > + ret = kmalloc_node(size, kmalloc_flags, node);
>
> Along those lines (dealing with larger requests), is there any value in
> picking some threshold value, and going straight to vmalloc if size is
> greater than that threshold?
I am not a fan of thresholds. PAGE_ALLOC_COSTLY_ORDER which is
internally used by the page allocator has turned out to be a major pain.
I do not want to repeat the same mistake again here. Besides that you
could hard find a "one suits all" value so it would have to be a part of
the API. If we ever grow users who would really like to do something
like that then a specialized API should be added.
> It's less flexible and might even require
> occasional maintenance over the years, but it would save some time on *some*
> systems in some cases...OK, I think I just talked myself out of the whole
> idea. But I still want to put the question out there, because I think others
> may also ask it, and I'd like to hear a more experienced opinion.
--
Michal Hocko
SUSE Labs
Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
Hi,
On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:
> Qualcomm chipsets have QMP phy controller that provides
> support to a number of controller, viz. PCIe, UFS, and USB.
> Adding dt binding information for the same.
>
> Signed-off-by: Vivek Gautam
> Acked-by: Rob Herring
> ---
>
> Changes since v3:
> - Added #clock-cells = <1>, indicating that phy is a clock provider.
>
> Changes since v2:
> - Removed binding for "ref_clk_src" since we don't request this
>clock in the driver.
> - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
> - Using 'phy' for the node name.
>
> Changes since v1:
> - New patch, forked out of the original driver patch:
>"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
> - Added 'Acked-by' from Rob.
> - Updated bindings to include mem resource as a list of
>offset - length pair for serdes block and for each lane.
> - Added a new binding for 'lane-offsets' that contains offsets
>to tx, rx and pcs blocks from each lane base address.
>
> .../devicetree/bindings/phy/qcom-qmp-phy.txt | 76
> ++
> 1 file changed, 76 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> new file mode 100644
> index ..6f510fe48f46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
> @@ -0,0 +1,76 @@
> +Qualcomm QMP PHY controller
> +===
> +
> +QMP phy controller supports physical layer functionality for a number of
> +controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
> +
> +Required properties:
> + - compatible: compatible list, contains:
> +"qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
> +"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
> + - reg: list of offset and length pair of the PHY register sets.
> + at index 0: offset and length of register set for PHY common
> + serdes block.
> + from index 1 - N: offset and length of register set for each lane,
> + for N number of phy lanes (ports).
> + - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
> + - #phy-cells: must be 1
> +- Cell after phy phandle should be the port (lane) number.
> + - #clock-cells: must be 1
> +- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
> + interface (for pipe based PHYs). These clock are then gate-controlled
> + by gcc.
> + - clocks: a list of phandles and clock-specifier pairs,
> +one for each entry in clock-names.
> + - clock-names: must be "cfg_ahb" for phy config clock,
> + "aux" for phy aux clock,
> + "ref" for 19.2 MHz ref clk,
> + "pipe" for pipe clock specific to
> + each port/lane (Optional).
> + - resets: a list of phandles and reset controller specifier pairs,
> +one for each entry in reset-names.
> + - reset-names: must be "phy" for reset of phy block,
> + "common" for phy common block reset,
> + "cfg" for phy's ahb cfg block reset (Optional).
> + "port" for reset specific to
> + each port/lane (Optional).
> + - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
> + - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
> +
> +Optional properties:
> + - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
> + pll block.
> +
> +Example:
> + pcie_phy: phy@34000 {
> + compatible = "qcom,msm8996-qmp-pcie-phy";
> + reg = <0x034000 0x48f>,
> + <0x035000 0x5bf>,
> + <0x036000 0x5bf>,
> + <0x037000 0x5bf>;
> + /* tx, rx, pcs */
> + lane-offsets = <0x0 0x200 0x400>;
> + #phy-cells = <1>;
> + #clock-cells = <1>;
> +
> + clocks = <&gcc GCC_PCIE_PHY_AUX_CLK>,
> + <&gcc GCC_PCIE_PHY_CFG_AHB_CLK>,
> + <&gcc GCC_PCIE_CLKREF_CLK>,
> + <&gcc GCC_PCIE_0_PIPE_CLK>,
> + <&gcc GCC_PCIE_1_PIPE_CLK>,
> + <&gcc GCC_PCIE_2_PIPE_CLK>;
> + clock-names = "aux", "cfg_ahb", "ref",
> + "pipe0", "pipe1", "pipe2";
> +
> + vdda-phy-supply = <&pm8994_l28>;
> + vdda-pll-supply = <&pm8994_l12>;
> +
> + resets = <&gcc GCC_PCIE_PHY_BCR>,
> + <&gcc GCC_PCIE_PHY_COM_BCR>,
> + <&gcc GCC_PCIE_PHY_COM_NOCSR_BCR>,
> + <&gcc GCC_PCIE_0_PHY_BCR>,
> + <&gcc GCC_PCIE_1_PHY_BCR>,
> + <&gcc GCC_PCIE_2_PHY_BCR>;
RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
Hi, Jerry Huang writes: >> > On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang >> wrote: >> > > Hi, Rob, >> > >> -Original Message- >> > >> From: Rob Herring [mailto:r...@kernel.org] >> > >> Sent: Friday, December 23, 2016 2:45 AM >> > >> To: Jerry Huang >> > >> Cc: ba...@kernel.org; mark.rutl...@arm.com; >> > >> catalin.mari...@arm.com; will.dea...@arm.com; >> > >> li...@armlinux.org.uk; devicet...@vger.kernel.org; >> > >> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm- >> > >> ker...@lists.infradead.org >> > >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps, >> > >> incr-burst- type-adjustment" for INCR burst type >> > >> >> > >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote: >> > >> > New property "snps,incr-burst-type-adjustment = , " for >> > >> > USB3.0 >> > >> DWC3. >> > >> > Field "x": 1/0 - undefined length INCR burst type enable or not; >> > >> > Field >> > >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst >> type. >> > >> > >> > >> > While enabling undefined length INCR burst type and INCR16 burst >> > >> > type, get better write performance on NXP Layerscape platform: >> > >> > around 3% improvement (from 364MB/s to 375MB/s). >> > >> > >> > >> > Signed-off-by: Changming Huang >> > >> > --- >> > >> > Changes in v3: >> > >> > - add new property for INCR burst in usb node. >> > >> > >> > >> > Documentation/devicetree/bindings/usb/dwc3.txt |5 + >> > >> > arch/arm/boot/dts/ls1021a.dtsi |1 + >> > >> > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |3 +++ >> > >> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |2 ++ >> > >> > 4 files changed, 11 insertions(+) >> > >> > >> > >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt >> > >> > b/Documentation/devicetree/bindings/usb/dwc3.txt >> > >> > index e3e6983..8c405a3 100644 >> > >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt >> > >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt >> > >> > @@ -55,6 +55,10 @@ Optional properties: >> > >> > fladj_30mhz_sdbnd signal is invalid or incorrect. >> > >> > >> > >> > - tx-fifo-resize: determines if the FIFO *has* to >> > >> > be >> > >> reallocated. >> > >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type of >> > >> GSBUSCFG0 >> > >> > + register, undefined length INCR burst type enable and INCRx type. >> > >> > + First field is for undefined length INCR burst type enable or not. >> > >> > + Second field is for largest INCRx type enabled. >> > >> >> > >> Why do you need the first field? Is the 2nd field used if the 1st is 0? >> > >> If not, then just use the presence of the property to enable or not. >> > > The first field is one switch. >> > > When it is 1, means undefined length INCR burst type enabled, we can >> > > use >> > any length less than or equal to the largest-enabled burst length of >> > INCR4/8/16/32/64/128/256. >> > > When it is zero, means INCRx burst mode enabled, we can use one >> > > fixed >> > burst length of 1/4/8/16/32/64/128/256 byte. >> > > So, the 2nd field is used if the 1st is 0, we need to select one >> > > largest burst >> > length the USB controller can support. >> > > If we don't want to change the value of this register (use the >> > > default value), >> > we don't need to add this property to usb node. >> > >> > Just make this a single value with 0 meaning INCR and 4/8/16/etc being >> INCRx. >> Maybe, I didn't describe it clearly. >> According to DWC3 spec, the value "0" of field INCRBrstEna means INCRx >> burst mode, 1 means INCR burst mode. >> Regardless of the value of INCRBrstEna [bit0], we need to modify the other >> field bit[1,2,3,4,5,6,7] to one INCR burst type for the platform supported. >> Ad you mentioned, if we just use a single value with 0 meaning INCR and >> 4/8/16/etc being INCRx. >> I understand totally that when it is none-zero, we can use it for INCR burst >> mode. >> Then, when it is 0, how to select the INCRx value? >> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx burst >> type. > Hi, Balbi, > It seems there is no feedback for my comment, so these patches can be > accepted? probably not, we need to really understand what information we need so it can be described properly. The last thing we want is unnecessary DT properties. It seems to me that we can extrapolate INCRBrstEna based on which burst modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any other size is passed, then that bit should be 0, no? -- balbi signature.asc Description: PGP signature
Re: [PATCH] net_sched: use kvmalloc rather than opencoded variant
On Sun 15-01-17 07:43:01, kbuild test robot wrote: > Hi Michal, > > [auto build test ERROR on net-next/master] > [also build test ERROR on v4.10-rc3 next-20170113] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Michal-Hocko/net_sched-use-kvmalloc-rather-than-opencoded-variant/20170107-120926 This depends on kvmalloc patch. But I have rebased this patch on top of others in http://lkml.kernel.org/r/20170112153717.28943-1-mho...@kernel.org -- Michal Hocko SUSE Labs
Re: [v2 2/3] ARM: dts: STM32 Add USB FS host mode support
Hi Bruno,
On 01/16/2017 03:09 AM, Bruno Herrera wrote:
This patch adds the USB pins and nodes for USB HS/FS cores working at FS speed,
using embedded PHY.
Signed-off-by: Bruno Herrera
Sorry, but what is patch 1 & pacth 3 status ?
For this one, can split it in 3 patches (one patch for SOC and one for
each board) please.
---
arch/arm/boot/dts/stm32f429-disco.dts | 30 ++
arch/arm/boot/dts/stm32f429.dtsi | 35 ++-
arch/arm/boot/dts/stm32f469-disco.dts | 30 ++
3 files changed, 94 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts
b/arch/arm/boot/dts/stm32f429-disco.dts
index 7d0415e..374c5ed 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -88,6 +88,16 @@
gpios = <&gpioa 0 0>;
};
};
+
+ /* This turns on vbus for otg for host mode (dwc2) */
+ vcc5v_otg: vcc5v-otg-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpioc 4 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbotg_pwren_h>;
+ regulator-name = "vcc5_host1";
+ regulator-always-on;
+ };
};
&clk_hse {
@@ -99,3 +109,23 @@
pinctrl-names = "default";
status = "okay";
};
+
+&usbotg_hs {
+ compatible = "st,stm32-fsotg", "snps,dwc2";
+ dr_mode = "host";
+ pinctrl-0 = <&usbotg_fs_pins_b>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&pinctrl {
+ usb-host {
+ usbotg_pwren_h: usbotg-pwren-h {
+ pins {
+ pinmux = ;
+ bias-disable;
+ drive-push-pull;
+ };
+ };
+ };
+};
Pinctrl muxing has to be defined/declared in stm32f429.dtsi
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..bc07aa8 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -206,7 +206,7 @@
reg = <0x40007000 0x400>;
};
- pin-controller {
+ pinctrl: pin-controller {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,stm32f429-pinctrl";
@@ -316,6 +316,30 @@
};
};
+ usbotg_fs_pins_a: usbotg_fs@0 {
+ pins {
+ pinmux =
,
+
,
+
;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ };
+
+ usbotg_fs_pins_b: usbotg_fs@1 {
+ pins {
+ pinmux =
,
+
,
+
;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <2>;
+ };
+ };
+
+
+
usbotg_hs_pins_a: usbotg_hs@0 {
pins {
pinmux =
,
@@ -420,6 +444,15 @@
status = "disabled";
};
+ usbotg_fs: usb@5000 {
+ compatible = "st,stm32f4xx-fsotg", "snps,dwc2";
+ reg = <0x5000 0x4>;
+ interrupts = <67>;
+ clocks = <&rcc 0 39>;
+ clock-names = "otg";
+ status = "disabled";
+ };
+
rng: rng@50060800 {
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
b/arch/arm/boot/dts/stm32f469-disco.dts
index 8877c00..8ae6763 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -68,6 +68,17 @@
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
+
+ /* This turns on vbus for otg for host mode (dwc2) */
+ vcc5v_otg: vcc5v-otg-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpiob 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbotg_pwren_h>;
+ regulator-name = "vcc5_host1";
+ regulator-always-on;
+ };
};
[PATCH] rtc: stm32: use 0 instead of ~PWR_CR_DBP in regmap_update_bits
Using the ~ operator on a BIT() constant results in a large 'unsigned long'
constant that won't fit into an 'unsigned int' function argument on 64-bit
architectures, resulting in a harmless build warning in x86 allmodconfig:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated to
unsigned type [-Werror=overflow]
regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
As PWR_CR_DBP mask prevents other bits to be cleared, replace all
~PWR_CR_DBP by 0.
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Arnd Bergmann
Signed-off-by: Amelie Delaunay
---
drivers/rtc/rtc-stm32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index 8c599f5..03c97c1 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -648,7 +648,7 @@ static int stm32_rtc_probe(struct platform_device *pdev)
err:
clk_disable_unprepare(rtc->ck_rtc);
- regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
+ regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, 0);
device_init_wakeup(&pdev->dev, false);
@@ -670,7 +670,7 @@ static int stm32_rtc_remove(struct platform_device *pdev)
clk_disable_unprepare(rtc->ck_rtc);
/* Enable backup domain write protection */
- regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
+ regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, 0);
device_init_wakeup(&pdev->dev, false);
--
1.9.1
[PATCH RFC] powerpc/32: fix handling of stack protector with recent GCC
Since 2005, powerpc GCC doesn't manage anymore __stack_chk_guard as
a global variable but as some value located at -0x7008(r2)
In the Linux kernel, r2 is used as a pointer to current task struct.
This patch changes the meaning of r2 when stack protector
is activated:
- current is taken from thread_info and not kept in r2 anymore
- r2 is set to current + offset of stack canary + 0x7008 so
that -0x7008(r2) directly points to current->stack_canary
current could have been more efficiently calculated from r2
but some circular inclusion prevent inserting struct task_struct
into arch/powerpc/include/asm/current.h so it is not possible
to get offset of stack_canary within current task_struct from there.
fixes: 6533b7c16ee57 ("powerpc: Initial stack protector
(-fstack-protector) support")
Reported-by: Christian Kujau
Signed-off-by: Christophe Leroy
---
Christian, can you test it ?
arch/powerpc/include/asm/current.h| 12 +++-
arch/powerpc/include/asm/stackprotector.h | 13 +
arch/powerpc/kernel/entry_32.S| 19 +++
arch/powerpc/kernel/head_32.S | 7 +++
arch/powerpc/kernel/head_40x.S| 4
arch/powerpc/kernel/head_44x.S| 4
arch/powerpc/kernel/head_8xx.S| 4
arch/powerpc/kernel/head_fsl_booke.S | 7 +++
arch/powerpc/kernel/process.c | 6 --
9 files changed, 61 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/current.h
b/arch/powerpc/include/asm/current.h
index e2c7f06..2f67f02 100644
--- a/arch/powerpc/include/asm/current.h
+++ b/arch/powerpc/include/asm/current.h
@@ -27,8 +27,16 @@ static inline struct task_struct *get_current(void)
}
#define currentget_current()
-#else
+#else /* __powerpc64__ */
+#if defined(CONFIG_CC_STACKPROTECTOR)
+#include
+static inline struct task_struct *get_current(void)
+{
+ return current_thread_info()->task;
+}
+#define currentget_current()
+#else
/*
* We keep `current' in r2 for speed.
*/
@@ -36,5 +44,7 @@ register struct task_struct *current asm ("r2");
#endif
+#endif /* __powerpc64__ */
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_CURRENT_H */
diff --git a/arch/powerpc/include/asm/stackprotector.h
b/arch/powerpc/include/asm/stackprotector.h
index 6720190..bf30509 100644
--- a/arch/powerpc/include/asm/stackprotector.h
+++ b/arch/powerpc/include/asm/stackprotector.h
@@ -12,12 +12,18 @@
#ifndef _ASM_STACKPROTECTOR_H
#define _ASM_STACKPROTECTOR_H
+#ifdef CONFIG_PPC64
+#define SSP_OFFSET 0x7010
+#else
+#define SSP_OFFSET 0x7008
+#endif
+
+#ifndef __ASSEMBLY__
+
#include
#include
#include
-extern unsigned long __stack_chk_guard;
-
/*
* Initialize the stackprotector canary value.
*
@@ -34,7 +40,6 @@ static __always_inline void boot_init_stack_canary(void)
canary ^= LINUX_VERSION_CODE;
current->stack_canary = canary;
- __stack_chk_guard = current->stack_canary;
}
-
+#endif /* __ASSEMBLY__ */
#endif /* _ASM_STACKPROTECTOR_H */
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 5742dbd..b3a363c 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
/*
* MSR_KERNEL is > 0x1 on 4xx/Book-E since it include MSR_CE.
@@ -149,6 +150,9 @@ transfer_to_handler:
mfspr r12,SPRN_SPRG_THREAD
addir2,r12,-THREAD
tovirt(r2,r2) /* set r2 to current */
+#if defined(CONFIG_CC_STACKPROTECTOR)
+ addir2,r2,TSK_STACK_CANARY+SSP_OFFSET
+#endif
beq 2f /* if from user, fix up THREAD.regs */
addir11,r1,STACK_FRAME_OVERHEAD
stw r11,PT_REGS(r12)
@@ -385,6 +389,9 @@ syscall_exit_cont:
lwz r3,GPR3(r1)
1:
#endif /* CONFIG_TRACE_IRQFLAGS */
+#if defined(CONFIG_CC_STACKPROTECTOR)
+ subir2,r2,TSK_STACK_CANARY+SSP_OFFSET
+#endif
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
/* If the process has its own DBCR0 value, load it up. The internal
debug mode bit tells us that dbcr0 should be loaded. */
@@ -617,6 +624,9 @@ _GLOBAL(_switch)
stwur1,-INT_FRAME_SIZE(r1)
mflrr0
stw r0,INT_FRAME_SIZE+4(r1)
+#if defined(CONFIG_CC_STACKPROTECTOR)
+ subir2,r2,TSK_STACK_CANARY+SSP_OFFSET
+#endif
/* r3-r12 are caller saved -- Cort */
SAVE_NVGPRS(r1)
stw r0,_NIP(r1) /* Return to switch caller */
@@ -674,10 +684,8 @@ BEGIN_FTR_SECTION
mtspr SPRN_SPEFSCR,r0 /* restore SPEFSCR reg */
END_FTR_SECTION_IFSET(CPU_FTR_SPE)
#endif /* CONFIG_SPE */
-#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
- lwz r0,TSK_STACK_CANARY(r2)
- lis r4,__stack_chk_guard@ha
- stw r0,__stack_chk_guard@l(r4)
+#if defined(CONFIG_CC_STACKPROTECTOR)
+ addir2,r2,TSK_STACK_C
Re: [PATCH v1 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
On Mon, Jan 16, 2017 at 12:19:53PM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family
> watchdog controller.
>
> Signed-off-by: Baoyou Xie
> ---
> .../bindings/watchdog/zte,zx2967-wdt.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
> new file mode 100644
> index 000..0fe0d40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
> @@ -0,0 +1,29 @@
> +ZTE zx2967 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be one of the following.
> + * zte,zx296718-wdt
> +- reg : Specifies base physical address and size of the registers.
> +- clocks : Pairs of phandle and specifier referencing the controller's
> clocks.
> +- clock-names: "wdtclk" for the watchdog clock.
clock-names only makes sense when there are multiple clock phandles in
'clocks' property. When clock-names is not present, the driver code
calls devm_clk_get() with the second parameter being NULL.
> +- resets : Reference to the reset controller controlling the watchdog
> + controller.
> +- reset-names : Must include the following entries:
> + * wdtrst
Same as clock-names.
> +
> +Optional properties:
> +
> +- reset-mask-config : Mask and configuare value that be wrote to aon-sysctrl.
First of all, for vendor specific properties, we should have a vendor
prefix, something like "zte,reset-mask-config".
Secondly, we should really have more comments to explain why this
property is optional, i.e. in which cases it should be present, and in
which cases it can be missing. Also, the relationship between this
reset and 'resets = <&toprst 35>' should be explained a bit as well.
Shawn
> +
> +Example:
> +
> +wdt_ares: watchdog@1465000 {
> + compatible = "zte,zx296718-wdt";
> + reg = <0x1465000 0x1000>;
> + clocks = <&topcrm WDT_WCLK>;
> + clock-names = "wdtclk";
> + resets = <&toprst 35>;
> + reset-names = "wdtrst";
> + reset-mask-config = <1 0x115>;
> +};
> --
> 2.7.4
>
Build regressions/improvements in v4.10-rc4
Below is the list of build error/warning regressions/improvements in
v4.10-rc4[1] compared to v4.9[2].
Summarized:
- build errors: +10/-8
- build warnings: +1067/-470
JFYI, when comparing v4.10-rc4[1] to v4.10-rc3[3], the summaries are:
- build errors: +10/-1
- build warnings: +634/-375
Happy fixing! ;-)
Thanks to the linux-next team for providing the build service.
[1]
http://kisskb.ellerman.id.au/kisskb/head/49def1853334396f948dcb4cedb9347abb318df5/
(all 267 configs)
[2]
http://kisskb.ellerman.id.au/kisskb/head/69973b830859bc6529a7a0468ba0d80ee5117826/
(all 267 configs)
[3]
http://kisskb.ellerman.id.au/kisskb/head/a121103c922847ba5010819a3f250f1f7fc84ab8/
(all 267 configs)
*** ERRORS ***
10 error regressions:
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: 'REQ_OP_WRITE' undeclared
(first use in this function): => 363:25
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: dereferencing pointer to
incomplete type: => 361:6, 360:6, 374:24
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: expected ';' before '{'
token: => 457:39
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'bio_add_page' [-Werror=implicit-function-declaration]: => 364:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'bio_alloc' [-Werror=implicit-function-declaration]: => 355:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'bio_for_each_segment_all' [-Werror=implicit-function-declaration]:
=> 457:2
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'bio_put' [-Werror=implicit-function-declaration]: => 369:4
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'bio_set_op_attrs' [-Werror=implicit-function-declaration]: => 363:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit declaration of
function 'submit_bio_wait' [-Werror=implicit-function-declaration]: => 373:3
+ error: rtnetlink.c: relocation truncated to fit: R_AVR32_11H_PCREL against
`.text'+217b8: => (.text+0x21bc8)
8 error improvements:
- /home/kisskb/slave/src/drivers/usb/serial/cp210x.c: error: passing argument
2 of 'cp210x_get_termios_port' from incompatible pointer type
[-Werror=incompatible-pointer-types]: 719:4 =>
- /home/kisskb/slave/tmp/ccZFNWVe.s: Error: pcrel too far BFD_RELOC_BFIN_10:
912 =>
- error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!: N/A =>
- error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference to
`__ucmpdi2': .text+0x2ef6c), .text+0x2ef78), .text+0x3) =>
- error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to
`__ucmpdi2': .text+0x36dc0), .text+0x38804) =>
- error: page_ext.c: undefined reference to `__end_data_ro_after_init':
.text+0x19860) =>
- error: page_ext.c: undefined reference to `__start_data_ro_after_init':
.text+0x1985c) =>
- error: trace.c: relocation truncated to fit: R_PPC64_REL24 against symbol
`.trace_event_buffer_reserve' defined in .text section in kernel/built-in.o:
(.text+0x1ff892c), (.text+0x1ff8150), (.text+0x1ff8b7c), (.text+0x1ff86e0),
(.text+0x1ff84d0), (.text+0x1ff7ee4), (.text+0x1ff85d0), (.text+0x1ff834c),
(.text+0x1ff8240), (.text+0x1ff8050) =>
*** WARNINGS ***
1067 warning regressions:
[Deleted 834 lines about "warning: -ffunction-sections disabled; it makes
profiling impossible [enabled by default]" on parisc-allmodconfig]
+ /home/kisskb/slave/src/arch/sh/kernel/cpu/sh2a/../../entry-common.S:
Warning: overflow in branch to __restore_all; converted into longer instruction
sequence: => 89
+ /home/kisskb/slave/src/arch/sh/kernel/cpu/sh2a/../../entry-common.S:
Warning: overflow in branch to syscall_call; converted into longer instruction
sequence: => 208
+ /home/kisskb/slave/src/arch/sh/kernel/cpu/sh2a/../../entry-common.S:
Warning: overflow in branch to syscall_trace_entry; converted into longer
instruction sequence: => 356, 358
+ /home/kisskb/slave/src/arch/sh/math-emu/sfp-util.h: warning:
"__LITTLE_ENDIAN" is not defined [-Wundef]: => 70:22
+ /home/kisskb/slave/src/arch/x86/kernel/cpu/mcheck/mce-inject.c: warning:
'mce_irq_ipi' defined but not used [-Wunused-function]: => 97:13
+ /home/kisskb/slave/src/crypto/cbc.c: warning: 'crypto_cbc_decrypt' uses
dynamic stack allocation [enabled by default]: => 78:1
+ /home/kisskb/slave/src/crypto/cryptd.c: warning: 'cryptd_skcipher_decrypt'
uses dynamic stack allocation [enabled by default]: => 532:1
+ /home/kisskb/slave/src/crypto/cryptd.c: warning: 'cryptd_skcipher_encrypt'
uses dynamic stack allocation [enabled by default]: => 504:1
+ /home/kisskb/slave/src/drivers/ata/libata-scsi.c: warning:
'ncq_prio_enable' may be used uninitialized in this function: => 281
+ /home/kisskb/slave/src/drivers/crypto/chelsio/chcr_algo.c: warning:
'chcr_ahash_setkey' uses dynamic stack allocation [enabled by default]: =>
Re: [PATCH] fix race caused by hyperthreads when online an offline cpu
On Mon, 16 Jan 2017, Zhou Chengming wrote: Can you please stop sending the same patch over and over every other day? Granted, things get forgotten, but sending a polite reminder after a week is definitely enough. Maintainers are not machines responding within a split second on every mail they get. And that patch is not so substantial that it justifies that kind of spam. Thanks, tglx
Re: llist code relies on undefined behaviour, upsets llvm/clang
On Mon, Jan 16, 2017 at 08:36:00AM +1100, Anton Blanchard wrote: > Hi, > > I was debugging a hang on a ppc64le kernel built with clang, and it > looks to be undefined behaviour with pointer wrapping in the llist code. > > A test case is below. llist_for_each_entry() does container_of() on a > NULL pointer, which wraps our pointer negative, then adds the same > offset back in and expects to get back to NULL. Unfortunately clang > decides that this can never be NULL and optimises it into an infinite > loop. > > Build with -DFIX, such that the llist_node has a zero offset from the > start of the struct, and things work. > > Is anyone other than ppc64le building kernels with llvm/clang these > days? This should reproduce on ARM64 and x86-64. Last I checked I couldn't build a x86_64 kernel with llvm. So no, not something I've ever ran into. Also, I would argue that this is broken in llvm, the kernel very much relies on things like this all over the place. Sure, we're way outside of what the C language spec says, but who bloody cares ;-) If llvm wants to compile the kernel, it needs to learn the C dialect the kernel uses.
Re: [PATCH v2 3/3] phy: rockchip-inno-usb2: Set EXTCON_USB when EXTCON_CHG_USB_SDP was set
On Wednesday 21 December 2016 01:42 PM, Baolin Wang wrote:
> According to the documentation, we should set the EXTCON_USB when
> one SDP charger connector was reported.
>
> Signed-off-by: Baolin Wang
> Reviewed-by: Chanwoo Choi
merged, thanks!
-Kishon
> ---
> Changes since v1:
> - Change extcon_set_cable_state_() to extcon_set_state_sync().
> - Add reviewed tag by Chanwoo Choi.
> ---
> drivers/phy/phy-rockchip-inno-usb2.c |7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c
> b/drivers/phy/phy-rockchip-inno-usb2.c
> index 2f99ec9..4ea95c2 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -595,9 +595,14 @@ static void rockchip_usb2phy_otg_sm_work(struct
> work_struct *work)
> if (rport->vbus_attached != vbus_attach) {
> rport->vbus_attached = vbus_attach;
>
> - if (notify_charger && rphy->edev)
> + if (notify_charger && rphy->edev) {
> extcon_set_cable_state_(rphy->edev,
> cable, vbus_attach);
> + if (cable == EXTCON_CHG_USB_SDP)
> + extcon_set_state_sync(rphy->edev,
> + EXTCON_USB,
> + vbus_attach);
> + }
> }
> break;
> case OTG_STATE_B_PERIPHERAL:
>
Re: [RFC PATCH v2 05/10] genirq: export irq_get_percpu_devid_partition to modules
On Fri, 13 Jan 2017, Will Deacon wrote: > Any modular driver using cluster-affine PPIs needs to be able to call > irq_get_percpu_devid_partition so that it can enable the IRQ on the > correct subset of CPUs. > > This patch exports the symbol so that it can be called from within a > module. > > Cc: Marc Zyngier > Cc: Thomas Gleixner > Signed-off-by: Will Deacon > --- > kernel/irq/irqdesc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c > index 00bb0aeea1d0..1e6ae73eae59 100644 > --- a/kernel/irq/irqdesc.c > +++ b/kernel/irq/irqdesc.c > @@ -856,6 +856,7 @@ int irq_get_percpu_devid_partition(unsigned int irq, > struct cpumask *affinity) > > return 0; > } > +EXPORT_SYMBOL_GPL(irq_get_percpu_devid_partition); Acked-by: Thomas Gleixner
[PATCH 2/2] spi: pca2xx-pci: Allow MSI
Now that the core is ready for edge-triggered interrupts, we can safely
allow the PCI versions that provide this to enable the feature and,
thus, have less shared interrupts.
Signed-off-by: Jan Kiszka
---
drivers/spi/spi-pxa2xx-pci.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 58d2d48..e7e5b08 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -203,16 +203,24 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
ssp = &spi_pdata.ssp;
ssp->phys_base = pci_resource_start(dev, 0);
ssp->mmio_base = pcim_iomap_table(dev)[0];
- ssp->irq = dev->irq;
ssp->port_id = (c->port_id >= 0) ? c->port_id : dev->devfn;
ssp->type = c->type;
snprintf(buf, sizeof(buf), "pxa2xx-spi.%d", ssp->port_id);
ssp->clk = clk_register_fixed_rate(&dev->dev, buf , NULL, 0,
c->max_clk_rate);
-if (IS_ERR(ssp->clk))
+ if (IS_ERR(ssp->clk))
return PTR_ERR(ssp->clk);
+ pci_set_master(dev);
+
+ ret = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
+ if (ret < 0) {
+ clk_unregister(ssp->clk);
+ return ret;
+ }
+ ssp->irq = pci_irq_vector(dev, 0);
+
memset(&pi, 0, sizeof(pi));
pi.fwnode = dev->dev.fwnode;
pi.parent = &dev->dev;
@@ -224,6 +232,7 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
pdev = platform_device_register_full(&pi);
if (IS_ERR(pdev)) {
clk_unregister(ssp->clk);
+ pci_free_irq_vectors(dev);
return PTR_ERR(pdev);
}
@@ -241,6 +250,7 @@ static void pxa2xx_spi_pci_remove(struct pci_dev *dev)
platform_device_unregister(pdev);
clk_unregister(spi_pdata->ssp.clk);
+ pci_free_irq_vectors(dev);
}
static const struct pci_device_id pxa2xx_spi_pci_devices[] = {
--
2.1.4
[PATCH 1/2] spi: pxa2xx: Prepare for edge-triggered interrupts
When using the a device with edge-triggered interrupts, such as MSIs,
the interrupt handler has to ensure that there is a point in time during
its execution where all interrupts sources are silent so that a new
event can trigger a new interrupt again.
This is achieved here by looping over SSSR evaluation. We need to take
into account that SSCR1 may be changed by the transfer handler, thus we
need to redo the mask calculation, at least regarding the volatile
interrupt enable bit (TIE).
Signed-off-by: Jan Kiszka
---
drivers/spi/spi-pxa2xx.c | 50 +++-
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index dd7b5b4..24bf549 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -737,6 +737,7 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
struct driver_data *drv_data = dev_id;
u32 sccr1_reg;
u32 mask = drv_data->mask_sr;
+ irqreturn_t ret = IRQ_NONE;
u32 status;
/*
@@ -760,37 +761,42 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
- /* Ignore possible writes if we don't need to write */
- if (!(sccr1_reg & SSCR1_TIE))
- mask &= ~SSSR_TFS;
-
/* Ignore RX timeout interrupt if it is disabled */
if (!(sccr1_reg & SSCR1_TINTE))
mask &= ~SSSR_TINT;
- if (!(status & mask))
- return IRQ_NONE;
+ while (1) {
+ /* Ignore possible writes if we don't need to write */
+ if (!(sccr1_reg & SSCR1_TIE))
+ mask &= ~SSSR_TFS;
- if (!drv_data->master->cur_msg) {
+ if (!(status & mask))
+ return ret;
- pxa2xx_spi_write(drv_data, SSCR0,
-pxa2xx_spi_read(drv_data, SSCR0)
-& ~SSCR0_SSE);
- pxa2xx_spi_write(drv_data, SSCR1,
-pxa2xx_spi_read(drv_data, SSCR1)
-& ~drv_data->int_cr1);
- if (!pxa25x_ssp_comp(drv_data))
- pxa2xx_spi_write(drv_data, SSTO, 0);
- write_SSSR_CS(drv_data, drv_data->clear_sr);
+ if (!drv_data->master->cur_msg) {
- dev_err(&drv_data->pdev->dev,
- "bad message state in interrupt handler\n");
+ pxa2xx_spi_write(drv_data, SSCR0,
+pxa2xx_spi_read(drv_data, SSCR0)
+& ~SSCR0_SSE);
+ pxa2xx_spi_write(drv_data, SSCR1,
+pxa2xx_spi_read(drv_data, SSCR1)
+& ~drv_data->int_cr1);
+ if (!pxa25x_ssp_comp(drv_data))
+ pxa2xx_spi_write(drv_data, SSTO, 0);
+ write_SSSR_CS(drv_data, drv_data->clear_sr);
- /* Never fail */
- return IRQ_HANDLED;
- }
+ dev_err(&drv_data->pdev->dev,
+ "bad message state in interrupt handler\n");
- return drv_data->transfer_handler(drv_data);
+ /* Never fail */
+ return IRQ_HANDLED;
+ }
+
+ ret |= drv_data->transfer_handler(drv_data);
+
+ status = pxa2xx_spi_read(drv_data, SSSR);
+ sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
+ }
}
/*
--
2.1.4
[PATCH 0/2] spi: pca2xx: Prepare for and enable MSI support
This enhances the pca2xx driver's interrupt handler with support for edge-triggered interrupts and makes use of that for PCI-hosted variants, like the Intel Quark SoC. Jan Jan Kiszka (2): spi: pxa2xx: Prepare for edge-triggered interrupts spi: pca2xx-pci: Allow MSI drivers/spi/spi-pxa2xx-pci.c | 14 +++-- drivers/spi/spi-pxa2xx.c | 50 +--- 2 files changed, 40 insertions(+), 24 deletions(-) -- 2.1.4
Re: [PATCH v8 00/18] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
Hi Tomasz, On 13/01/2017 14:59, Tomasz Nowicki wrote: > Hello Eric, > > On 11.01.2017 10:41, Eric Auger wrote: >> Following LPC discussions, we now report reserved regions through >> the iommu-group sysfs reserved_regions attribute file. >> >> Reserved regions are populated through the IOMMU get_resv_region >> callback (former get_dm_regions), now implemented by amd-iommu, >> intel-iommu and arm-smmu: >> - the intel-iommu reports the [0xfee0 - 0xfeef] MSI window >> as a reserved region and RMRR regions as direct-mapped regions. >> - the amd-iommu reports device direct mapped regions, the MSI region >> and HT regions. >> - the arm-smmu reports the MSI window (arbitrarily located at >> 0x800 and 1MB large). >> >> Unsafe interrupt assignment is tested by enumerating all MSI irq >> domains and checking MSI remapping is supported in the above hierarchy. >> This check is done in case we detect the iommu translates MSI >> (an IOMMU_RESV_MSI window exists). Otherwise the IRQ remapping >> capability is checked at IOMMU level. Obviously this is a defensive >> IRQ safety assessment: Assuming there are several MSI controllers >> in the system and at least one does not implement IRQ remapping, >> the assignment will be considered as unsafe (even if this controller >> is not acessible from the assigned devices). >> >> The series first patch stems from Robin's branch: >> http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/misc >> >> >> Best Regards >> >> Eric >> >> Git: complete series available at >> https://github.com/eauger/linux/tree/v4.10-rc3-reserved-v8 > > I tested the series on ThunderX with internal 10G VNIC and Intel IXGBE > NIC. Please feel free to add my: > Tested-by: Tomasz Nowicki Many thanks! Eric > > Thanks, > Tomasz > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [tpmdd-devel] [PATCH RFC v2 3/5] tpm: infrastructure for TPM spaces
On Thu, Jan 12, 2017 at 05:17:23PM -0800, James Bottomley wrote:
> On Thu, 2017-01-12 at 19:46 +0200, Jarkko Sakkinen wrote:
> > @@ -189,6 +190,12 @@ struct tpm_chip *tpm_chip_alloc(struct device
> > *pdev,
> > chip->cdev.owner = THIS_MODULE;
> > chip->cdev.kobj.parent = &chip->dev.kobj;
> >
> > + chip->work_space.context_buf = kzalloc(PAGE_SIZE,
> > GFP_KERNEL);
> > + if (!chip->work_space.context_buf) {
> > + rc = -ENOMEM;
> > + goto out;
> > + }
> > +
>
> I think the work_buf handling can be greatly simplified by making it a
> pointer to the space: it's only usable between tpm2_prepare_space() and
> tpm2_commit_space() which are protected by the chip mutex, so there's
> no need for it to exist outside of these calls (i.e. it can be NULL).
>
> Doing it this way also saves the allocation and copying overhead of
> work_space.
>
> The patch below can be folded to effect this.
Hey, I have to take my words back. There's a separate buffer for space
for a reason. If the transaction fails for example when RM is doing its
job, we can revert to the previous set of transient objects.
Your change would completely thrawt this. I tried varius ways to heal
when RM decorations fail and this is the most fail safe to do it so lets
stick with it.
> James
/Jarkko
Re: [PATCH v2 0/2] phy: Replace the deprecated extcon API
Hi Kishon, On 2017년 01월 10일 17:16, Chanwoo Choi wrote: > Hi Kishon, > > Could you review these patches or pick up them if there is no any comment? If there are no comments, could you apply these patches? > > On 2016년 12월 30일 13:11, Chanwoo Choi wrote: >> This patches just replace the deprecated extcon API without any change >> of extcon operation and use the resource-managed function for >> extcon_register_notifier(). >> >> The new extcon API instead of deprecated API. >> - extcon_set_cable_state_() -> extcon_set_state_sync(); >> - extcon_get_cable_state_() -> extcon_get_state(); >> >> Changes from v1: >> - Rebase these patches based on v4.10-rc1. >> - Drop the usb/power-supply/chipidea patches. >> >> Chanwoo Choi (2): >> phy: rcar-gen3-usb2: Replace the deprecated extcon API >> phy: sun4i-usb: Replace the deprecated extcon API >> >> drivers/phy/phy-rcar-gen3-usb2.c | 8 >> drivers/phy/phy-sun4i-usb.c | 4 ++-- >> 2 files changed, 6 insertions(+), 6 deletions(-) >> > -- Best Regards, Chanwoo Choi S/W Center, Samsung Electronics
Re: [PATCH] s390: virtio: constify virtio_config_ops structures
On 01/13/2017 07:48 PM, Bhumika Goyal wrote:
> Declare virtio_config_ops structure as const as it is only stored in the
> config field of a virtio_device structure. This field is of type const, so
> virtio_config_ops structures having this property can be declared const.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct virtio_config_ops i@p={...};
>
> @ok1@
> identifier r1.i;
> position p;
> struct virtio_ccw_device x;
> @@
> x.vdev.config=&i@p
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct virtio_config_ops i;
>
> File size before and after applying the patch remains the same.
> text databss dec hex filename
> 9235 296 32928 42459 a5db drivers/s390/virtio/virtio_ccw.o
>
> Signed-off-by: Bhumika Goyal
thanks applied.
> ---
> drivers/s390/virtio/virtio_ccw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/s390/virtio/virtio_ccw.c
> b/drivers/s390/virtio/virtio_ccw.c
> index 639ed4e..6508bf4 100644
> --- a/drivers/s390/virtio/virtio_ccw.c
> +++ b/drivers/s390/virtio/virtio_ccw.c
> @@ -920,7 +920,7 @@ static void virtio_ccw_set_status(struct virtio_device
> *vdev, u8 status)
> kfree(ccw);
> }
>
> -static struct virtio_config_ops virtio_ccw_config_ops = {
> +static const struct virtio_config_ops virtio_ccw_config_ops = {
> .get_features = virtio_ccw_get_features,
> .finalize_features = virtio_ccw_finalize_features,
> .get = virtio_ccw_get_config,
>
Re: [PATCH 1/4] phy: sun4i-usb: add support for V3s USB PHY
On Friday 06 January 2017 07:26 PM, Maxime Ripard wrote: > On Tue, Jan 03, 2017 at 11:25:31PM +0800, Icenowy Zheng wrote: >> Allwinner V3s come with a USB PHY controller slightly different to other >> SoCs, with only one PHY. >> >> Add support for it. >> >> Signed-off-by: Icenowy Zheng > > Acked-by: Maxime Ripard merged, thanks! -Kishon > > Thanks, > Maxime >
Re: [Intel-gfx] [RESEND PATCH v14 2/2] drm/i915: Put "cooked" vlank counters in frame CRC lines
On 10 January 2017 at 17:31, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 05:54:57PM +0200, Ville Syrjälä wrote:
>> On Tue, Jan 10, 2017 at 02:43:05PM +0100, Tomeu Vizoso wrote:
>> > Use drm_accurate_vblank_count so we have the full 32 bit to represent
>> > the frame counter and userspace has a simpler way of knowing when the
>> > counter wraps around.
>> >
>> > Signed-off-by: Tomeu Vizoso
>> > Reviewed-by: Emil Velikov
>> > Reviewed-by: Robert Foss
>> > ---
>> >
>> > drivers/gpu/drm/i915/i915_irq.c | 6 +++---
>> > 1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> > b/drivers/gpu/drm/i915/i915_irq.c
>> > index b9beb5955dae..75fb1f66cc0c 100644
>> > --- a/drivers/gpu/drm/i915/i915_irq.c
>> > +++ b/drivers/gpu/drm/i915/i915_irq.c
>> > @@ -1557,7 +1557,6 @@ static void display_pipe_crc_irq_handler(struct
>> > drm_i915_private *dev_priv,
>> > struct drm_driver *driver = dev_priv->drm.driver;
>> > uint32_t crcs[5];
>> > int head, tail;
>> > - u32 frame;
>> >
>> > spin_lock(&pipe_crc->lock);
>> > if (pipe_crc->source) {
>> > @@ -1612,8 +1611,9 @@ static void display_pipe_crc_irq_handler(struct
>> > drm_i915_private *dev_priv,
>> > crcs[2] = crc2;
>> > crcs[3] = crc3;
>> > crcs[4] = crc4;
>> > - frame = driver->get_vblank_counter(&dev_priv->drm, pipe);
>> > - drm_crtc_add_crc_entry(&crtc->base, true, frame, crcs);
>> > + drm_crtc_add_crc_entry(&crtc->base, true,
>> > + drm_accurate_vblank_count(&crtc->base),
>>
>> My assumption would be that this gets called after the vblank irq
>> handler, so using the _accurate version seems a bit overkill.
>
> Since we're at like v15 of this I figured I'll pull this in, and we can
> polish this a bit more later. Tomeu, can you pls do that follow-up patch
> and get Ville to review+merge it.
At least on the SKL and SNB I have here, the -sequence subtests in
kms_pipe_crc_basic fail if I replace the call to
drm_accurate_vblank_count with drm_crtc_vblank_count.
Any ideas on why this could be?
Thanks,
Tomeu
Re: [PATCH] drivers: phy: constify phy_ops structures
On Sunday 08 January 2017 04:05 PM, Bhumika Goyal wrote:
> Declare phy_ops structures as const as they are only passed as an
> argument to the function devm_phy_create. This argument is of type const
> struct phy_ops *, so phy_ops structures having this property can be
> declared as const.
> Done using Coccinelle:
removed the rest of commit message and merged.
Thanks
Kishon
>
> @r1 disable optional_qualifier @
> identifier i;
> position p;
> @@
> static struct phy_ops i@p = {...};
>
> @ok1@
> identifier r1.i;
> position p;
> @@
> devm_phy_create(...,&i@p)
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct phy_ops i;
>
> File size details:
>
>text data bss dec hex filename
>1504 264 01768 6e8 phy/phy-bcm-cygnus-pcie.o
>1576 192 01768 6e8 phy/phy-bcm-cygnus-pcie.o
>
>1083 264 01347 543 phy/phy-hi6220-usb.o
>1155 192 01347 543 phy/phy-hi6220-usb.o
>
>2767 264 03031 bd7 phy/phy-mt65xx-usb3.o
>2829 192 03021 bcd phy/phy-mt65xx-usb3.o
>
>2710 304 03014 bc6 phy/phy-rcar-gen3-usb2.o
>2766 240 03006 bbe phy/phy-rcar-gen3-usb2.o
>
> Signed-off-by: Bhumika Goyal
> ---
> drivers/phy/phy-bcm-cygnus-pcie.c | 2 +-
> drivers/phy/phy-hi6220-usb.c | 2 +-
> drivers/phy/phy-mt65xx-usb3.c | 2 +-
> drivers/phy/phy-rcar-gen3-usb2.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/phy-bcm-cygnus-pcie.c
> b/drivers/phy/phy-bcm-cygnus-pcie.c
> index 082c03f..0f4ac5d 100644
> --- a/drivers/phy/phy-bcm-cygnus-pcie.c
> +++ b/drivers/phy/phy-bcm-cygnus-pcie.c
> @@ -114,7 +114,7 @@ static int cygnus_pcie_phy_power_off(struct phy *p)
> return cygnus_pcie_power_config(phy, false);
> }
>
> -static struct phy_ops cygnus_pcie_phy_ops = {
> +static const struct phy_ops cygnus_pcie_phy_ops = {
> .power_on = cygnus_pcie_phy_power_on,
> .power_off = cygnus_pcie_phy_power_off,
> .owner = THIS_MODULE,
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> index b2141cb..398c102 100644
> --- a/drivers/phy/phy-hi6220-usb.c
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -112,7 +112,7 @@ static int hi6220_phy_exit(struct phy *phy)
> return hi6220_phy_setup(priv, false);
> }
>
> -static struct phy_ops hi6220_phy_ops = {
> +static const struct phy_ops hi6220_phy_ops = {
> .init = hi6220_phy_start,
> .exit = hi6220_phy_exit,
> .owner = THIS_MODULE,
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> index 4d85e73..d972067 100644
> --- a/drivers/phy/phy-mt65xx-usb3.c
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -506,7 +506,7 @@ static struct phy *mt65xx_phy_xlate(struct device *dev,
> return instance->phy;
> }
>
> -static struct phy_ops mt65xx_u3phy_ops = {
> +static const struct phy_ops mt65xx_u3phy_ops = {
> .init = mt65xx_phy_init,
> .exit = mt65xx_phy_exit,
> .power_on = mt65xx_phy_power_on,
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c
> b/drivers/phy/phy-rcar-gen3-usb2.c
> index c63da1b..17be045 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -350,7 +350,7 @@ static int rcar_gen3_phy_usb2_power_off(struct phy *p)
> return ret;
> }
>
> -static struct phy_ops rcar_gen3_phy_usb2_ops = {
> +static const struct phy_ops rcar_gen3_phy_usb2_ops = {
> .init = rcar_gen3_phy_usb2_init,
> .exit = rcar_gen3_phy_usb2_exit,
> .power_on = rcar_gen3_phy_usb2_power_on,
>
Re: [PATCH v2 2/2] phy: sun4i-usb: Replace the deprecated extcon API
On Friday 30 December 2016 09:41 AM, Chanwoo Choi wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Cc: Kishon Vijay Abraham I
> Cc: Maxime Ripard
> Cc: Chen-Yu Tsai
> Signed-off-by: Chanwoo Choi
merged both the patches in this series.
Thanks
Kishon
> ---
> drivers/phy/phy-sun4i-usb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bf28a0fdd569..eae171e18043 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -534,7 +534,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
> work_struct *work)
> mutex_unlock(&phy0->mutex);
>
> if (id_notify) {
> - extcon_set_cable_state_(data->extcon, EXTCON_USB_HOST,
> + extcon_set_state_sync(data->extcon, EXTCON_USB_HOST,
> !id_det);
> /* When leaving host mode force end the session here */
> if (force_session_end && id_det == 1) {
> @@ -547,7 +547,7 @@ static void sun4i_usb_phy0_id_vbus_det_scan(struct
> work_struct *work)
> }
>
> if (vbus_notify)
> - extcon_set_cable_state_(data->extcon, EXTCON_USB, vbus_det);
> + extcon_set_state_sync(data->extcon, EXTCON_USB, vbus_det);
>
> if (sun4i_usb_phy0_poll(data))
> queue_delayed_work(system_wq, &data->detect, POLL_TIME);
>
[PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
From: Borislav Petkov
We wanna know who's doing such a thing. Like slab.c does that.
Signed-off-by: Borislav Petkov
---
mm/slub.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/slub.c b/mm/slub.c
index 067598a00849..1b0fa7625d6d 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t
flags, int node)
flags &= ~GFP_SLAB_BUG_MASK;
pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
(%pGg). Fix your code!\n",
invalid_mask, &invalid_mask, flags, &flags);
+ dump_stack();
}
return allocate_slab(s,
--
2.11.0
Re: [PATCH 0/6] USB support for Broadcom NSP SoC
On Tuesday 13 December 2016 07:50 AM, Florian Fainelli wrote: > On 11/09/2016 01:33 AM, Yendapally Reddy Dhananjaya Reddy wrote: >> This patch set contains the usb support for Broadcom NSP SoC. >> The usb phy is connected through mdio interface. The mdio interface >> can be used to access either internal phys or external phys using a >> multiplexer. >> >> The first patch provides the documentation details for mdio-mux and >> second patch provides the documentation details for usb3 phy. The third >> patch contains the mdio-mux support and fourth patch contains the >> changes to the mdio bus driver. >> >> The fifth patch provides the phy driver and sixth patch provides the >> enable method for usb. >> >> This patch series has been tested on NSP bcm958625HR board. >> This patch series is based on v4.9.0-rc1 and is available from github- >> repo: https://github.com/Broadcom/cygnus-linux.git >> branch:nsp-usb-v1 > > Can you resubmit this patch series with the feedback from Andrew, Rob > and Scott addressed? can the phy patches be re-submitted based on latest mainline and addressing those feedbacks? Thanks Kishon
Re: [patch net-next] stmmac: indent an if statement
On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote: > From: Dan Carpenter > Date: Thu, 12 Jan 2017 21:46:32 +0300 > > > The break statement should be indented one more tab. > > > > Signed-off-by: Dan Carpenter > > Applied, but like Julia I think we might have a missing of_node_put() > here. Of course, sorry for dropping the ball on this. I'll send a patch for that. regards, dan carpenter
Re: [PATCH] Revert "scsi: mpt3sas: Fix secure erase premature termination"
* James Bottomley wrote: > On Sun, 2017-01-15 at 10:19 +0100, Ingo Molnar wrote: > > So there's a new mpt3sas SCSI driver boot regression, introduced in > > this merge window, which made one of my servers unbootable. > > We're not reverting a fix that would cause regressions for others. You really need to reconsider that stance ... > However, The fix was manifestly wrong, so does this fix of the fix work for > you: > > http://marc.info/?l=linux-scsi&m=148329237807604 > > It's been languishing a bit because no-one seemed to care enough to > test or review it. IOf you can add a tested by, that will give the two > we need to push it. I have tested your other patch that you pointed to: http://marc.info/?l=linux-scsi&m=148449968522828 Which patch fixes the bug too (I removed my revert first) - so you can add my: Reported-by: Ingo Molnar Tested-by: Ingo Molnar BTW., is it wise to work around the out of spec firmware in the mpt3sas code and leave the overly optimistic assumptions in the SCSI code intact? The problem is that other SCSI hardware could be affected as well - and especially enterprise class server hardware has long testing and thus regression latencies (as my example proves). Wouldn't it be more robust to only submit one pass-through command at a time from the SCSI layer, and maybe opt-in hardware that is known to implement the SAT standard fully? (But I'm just kibitzing here really.) Thanks, Ingo
Re: [PATCH 2/3] Broadcom USB DRD Phy driver for Northstar2
Hi,
On Wednesday 30 November 2016 11:25 AM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.
>
> Signed-off-by: Raviteja Garimella
> ---
> drivers/phy/Kconfig | 13 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-bcm-ns2-usbdrd.c | 587
> +++
> 3 files changed, 601 insertions(+)
> create mode 100644 drivers/phy/phy-bcm-ns2-usbdrd.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index fe00f91..b3b6a73 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -479,6 +479,19 @@ config PHY_CYGNUS_PCIE
> Enable this to support the Broadcom Cygnus PCIe PHY.
> If unsure, say N.
>
> +config PHY_NS2_USB_DRD
> + tristate "Broadcom Northstar2 USB DRD PHY support"
> + depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
> + select GENERIC_PHY
> + select EXTCON
> + default ARCH_BCM_IPROC
> + help
> + Enable this to support the Broadcom Northstar2 USB DRD PHY.
> + This driver initializes the PHY in either HOST or DEVICE mode.
> + The host or device configuration is read from device tree.
> +
> + If unsure, say N.
> +
> source "drivers/phy/tegra/Kconfig"
>
> config PHY_NS2_PCIE
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a534cf5..b733ba2 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -58,5 +58,6 @@ obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
> obj-$(CONFIG_PHY_BRCM_SATA) += phy-brcm-sata.o
> obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o
> obj-$(CONFIG_PHY_CYGNUS_PCIE)+= phy-bcm-cygnus-pcie.o
> +obj-$(CONFIG_PHY_NS2_USB_DRD)+= phy-bcm-ns2-usbdrd.o
> obj-$(CONFIG_ARCH_TEGRA) += tegra/
> obj-$(CONFIG_PHY_NS2_PCIE) += phy-bcm-ns2-pcie.o
> diff --git a/drivers/phy/phy-bcm-ns2-usbdrd.c
> b/drivers/phy/phy-bcm-ns2-usbdrd.c
> new file mode 100644
> index 000..460040d
> --- /dev/null
> +++ b/drivers/phy/phy-bcm-ns2-usbdrd.c
> @@ -0,0 +1,587 @@
> +/*
> + * Copyright (C) 2016 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define ICFG_DRD_AFE 0x0
> +#define ICFG_MISC_STAT 0x18
> +#define ICFG_DRD_P0CTL 0x1C
> +#define ICFG_STRAP_CTRL 0x20
> +#define ICFG_FSM_CTRL0x24
> +
> +#define IDM_RST_BIT BIT(0)
> +#define AFE_CORERDY_VDDC BIT(18)
> +#define PHY_PLL_RESETB BIT(15)
> +#define PHY_RESETB BIT(14)
> +#define PHY_PLL_LOCK BIT(0)
> +
> +#define DRD_DEV_MODE BIT(20)
> +#define OHCI_OVRCUR_POL BIT(11)
> +#define ICFG_OFF_MODEBIT(6)
> +#define PLL_LOCK_RETRY 1000
> +
> +#define EVT_DEVICE 0
> +#define EVT_HOST 1
> +#define EVT_IDLE 2
> +
> +#define DRD_HOST_MODE(BIT(2) | BIT(3))
> +#define DRD_DEVICE_MODE (BIT(4) | BIT(5))
> +#define DRD_HOST_VAL 0x803
> +#define DRD_DEV_VAL 0x807
> +#define GPIO_DELAY 20
> +#define PHY_WQ_DELAY msecs_to_jiffies(600)
> +
> +struct ns2_phy_data;
> +struct ns2_phy_driver {
> + void __iomem *icfgdrd_regs;
> + void __iomem *idmdrd_rst_ctrl;
> + void __iomem *crmu_usb2_ctrl;
> + void __iomem *usb2h_strap_reg;
> + spinlock_t lock; /* spin lock for phy driver */
> + bool host_mode;
> + struct ns2_phy_data *data;
> + struct extcon_specific_cable_nb extcon_dev;
> + struct extcon_specific_cable_nb extcon_host;
> + struct notifier_block host_nb;
> + struct notifier_block dev_nb;
> + struct delayed_work conn_work;
> + struct extcon_dev *edev;
> + struct gpio_desc *vbus_gpiod;
> + struct gpio_desc *id_gpiod;
> + int id_irq;
> + int vbus_irq;
> + unsigned long debounce_jiffies;
> + struct delayed_work wq_extcon;
> +};
> +
> +struct ns2_phy_data {
> + struct ns2_phy_driver *driver;
> + struct phy *phy;
>
Re: [PATCH 1/2] spi: pxa2xx: Prepare for edge-triggered interrupts
On Mon, 2017-01-16 at 10:05 +0100, Jan Kiszka wrote:
> When using the a device with edge-triggered interrupts, such as MSIs,
> the interrupt handler has to ensure that there is a point in time
> during
> its execution where all interrupts sources are silent so that a new
> event can trigger a new interrupt again.
>
> This is achieved here by looping over SSSR evaluation. We need to take
> into account that SSCR1 may be changed by the transfer handler, thus
> we
> need to redo the mask calculation, at least regarding the volatile
> interrupt enable bit (TIE).
Could you split this to two patches, one just move the code under
question to a helper function (no functional change), the other does
what you state in commit message here?
>
> Signed-off-by: Jan Kiszka
> ---
> drivers/spi/spi-pxa2xx.c | 50 +++--
> ---
> 1 file changed, 28 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index dd7b5b4..24bf549 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -737,6 +737,7 @@ static irqreturn_t ssp_int(int irq, void *dev_id)
> struct driver_data *drv_data = dev_id;
> u32 sccr1_reg;
> u32 mask = drv_data->mask_sr;
> + irqreturn_t ret = IRQ_NONE;
> u32 status;
>
> /*
> @@ -760,37 +761,42 @@ static irqreturn_t ssp_int(int irq, void
> *dev_id)
>
> sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
>
> - /* Ignore possible writes if we don't need to write */
> - if (!(sccr1_reg & SSCR1_TIE))
> - mask &= ~SSSR_TFS;
> -
> /* Ignore RX timeout interrupt if it is disabled */
> if (!(sccr1_reg & SSCR1_TINTE))
> mask &= ~SSSR_TINT;
>
> - if (!(status & mask))
> - return IRQ_NONE;
> + while (1) {
> + /* Ignore possible writes if we don't need to write
> */
> + if (!(sccr1_reg & SSCR1_TIE))
> + mask &= ~SSSR_TFS;
>
> - if (!drv_data->master->cur_msg) {
> + if (!(status & mask))
> + return ret;
>
> - pxa2xx_spi_write(drv_data, SSCR0,
> - pxa2xx_spi_read(drv_data, SSCR0)
> - & ~SSCR0_SSE);
> - pxa2xx_spi_write(drv_data, SSCR1,
> - pxa2xx_spi_read(drv_data, SSCR1)
> - & ~drv_data->int_cr1);
> - if (!pxa25x_ssp_comp(drv_data))
> - pxa2xx_spi_write(drv_data, SSTO, 0);
> - write_SSSR_CS(drv_data, drv_data->clear_sr);
> + if (!drv_data->master->cur_msg) {
>
> - dev_err(&drv_data->pdev->dev,
> - "bad message state in interrupt handler\n");
> + pxa2xx_spi_write(drv_data, SSCR0,
> + pxa2xx_spi_read(drv_data,
> SSCR0)
> + & ~SSCR0_SSE);
> + pxa2xx_spi_write(drv_data, SSCR1,
> + pxa2xx_spi_read(drv_data,
> SSCR1)
> + & ~drv_data->int_cr1);
> + if (!pxa25x_ssp_comp(drv_data))
> + pxa2xx_spi_write(drv_data, SSTO, 0);
> + write_SSSR_CS(drv_data, drv_data->clear_sr);
>
> - /* Never fail */
> - return IRQ_HANDLED;
> - }
> + dev_err(&drv_data->pdev->dev,
> + "bad message state in interrupt
> handler\n");
>
> - return drv_data->transfer_handler(drv_data);
> + /* Never fail */
> + return IRQ_HANDLED;
> + }
> +
> + ret |= drv_data->transfer_handler(drv_data);
> +
> + status = pxa2xx_spi_read(drv_data, SSSR);
> + sccr1_reg = pxa2xx_spi_read(drv_data, SSCR1);
> + }
> }
>
> /*
--
Andy Shevchenko
Intel Finland Oy
[GIT PULL] AppArmor fixes for 4.11
Hi James, This is a set of bug fixes, a few additions to apparmorfs policy introspection, a lot of code refactoring, and cleanups taking care of most of the compiler and sparse warnings. It does not implement new mediation or change the behavior of current upstream apparmor mediation but provides a base to begin doing RFCs for updated apparmor mediation. Thanks, -John --- The following changes since commit b8aa8453918ebfd93d78de56c2afd4b735e02e27: security: Fix inode_getattr documentation (2017-01-10 17:39:23 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor for-security for you to fetch changes up to e6bfa25deb5096c05a08f01e4d6a436dd331fa88: apparmor: replace remaining BUG_ON() asserts with AA_BUG() (2017-01-16 01:18:56 -0800) John Johansen (56): apparmor: move lib definitions into separate lib include apparmor: split out shared policy_XXX fns to lib apparmor: split apparmor policy namespaces code into its own file apparmor: rename namespace to ns to improve code line lengths apparmor: rename sid to secid apparmor: rename PFLAG_INVALID to PFLAG_STALE apparmor: rename replacedby to proxy apparmor: add strn version of lookup_profile fn apparmor: add strn version of aa_find_ns apparmor: add lib fn to find the "split" for fqnames apparmor: add fn to lookup profiles by fqname apparmor: allow ns visibility question to consider subnses apparmor: add macro for bug asserts to check that a lock is held apparmor: add debug assert AA_BUG and Kconfig to control debug info apparmor: rename mediated_filesystem() to path_mediated_fs() apparmor: rename hname_tail to basename apparmor: constify policy name and hname apparmor: pass gfp param into aa_policy_init() apparmor: update policy_destroy to use new debug asserts apparmor: refactor prepare_ns() and make usable from different views apparmor: pass gfp_t parameter into profile allocation apparmor: name null-XXX profiles after the executable apparmor: remove paranoid load switch apparmor: add support for force complain flag to support learning mode apparmor: prepare to support newer versions of policy apparmor: add get_dfa() fn apparmor: allow policydb to be used as the file dfa apparmor: add a default null dfa apparmor: provide userspace flag indicating binfmt_elf_mmap change apparmor: add special .null file used to "close" fds at exec apparmor: track ns level so it can be used to help in view checks apparmor: Make aa_remove_profile() callable from a different view apparmor: allow introspecting the policy namespace name apparmor: allow specifying the profile doing the management apparmor: add ns being viewed as a param to policy_view_capable() apparmor: add ns being viewed as a param to policy_admin_capable() apparmor: add profile and ns params to aa_may_manage_policy() apparmor: add ns name to the audit data for policy loads apparmor: allow introspecting the loaded policy pre internal transform apparmor: audit policy ns specified in policy load apparmor: pass the subject profile into profile replace/remove apparmor: add per policy ns .load, .replace, .remove interface files apparmor: fail task profile update if current_cred isn't real_cred apparmor: rename context abreviation cxt to the more standard ctx apparmor: change op from int to const char * apparmor: change aad apparmor_audit_data macro to a fn macro apparmor: remove unused op parameter from simple_write_to_buffer() apparmor: fix change_hat debug output apparmor: convert change_profile to use fqname later to give better control apparmor: make computing policy hashes conditional on kernel parameter apparmor: update cap audit to check SECURITY_CAP_NOAUDIT apparmor: add per cpu work buffers to avoid allocating buffers at every hook apparmor: add check for apparmor enabled in module parameters missing it apparmor: fix restricted endian type warnings for dfa unpack apparmor: fix restricted endian type warnings for policy unpack apparmor: replace remaining BUG_ON() asserts with AA_BUG() Kees Cook (1): apparmor: use designated initializers Tetsuo Handa (1): AppArmor: Use GFP_KERNEL for __aa_kvmalloc(). Tyler Hicks (1): apparmor: sysctl to enable unprivileged user ns AppArmor policy loading William Hua (1): apparmor: support querying extended trusted helper extra data security/apparmor/Kconfig| 31 +- security/apparmor/Makefile | 2 +- security/apparmor/apparmorfs.c | 681 ++ security/apparmor/audit.c| 98 +--- security/app
Re: Build regressions/improvements in v4.10-rc4
On Mon, Jan 16, 2017 at 10:05 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.10-rc4[1] to v4.10-rc3[3], the summaries are:
> - build errors: +10/-1
> [1]
> http://kisskb.ellerman.id.au/kisskb/head/49def1853334396f948dcb4cedb9347abb318df5/
> (all 267 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/head/a121103c922847ba5010819a3f250f1f7fc84ab8/
> (all 267 configs)
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: 'REQ_OP_WRITE'
undeclared (first use in this function): => 363:25
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: dereferencing
pointer to incomplete type: => 361:6, 374:24, 360:6
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: expected ';'
before '{' token: => 457:39
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'bio_add_page'
[-Werror=implicit-function-declaration]: => 364:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'bio_alloc'
[-Werror=implicit-function-declaration]: => 355:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'bio_for_each_segment_all'
[-Werror=implicit-function-declaration]: => 457:2
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'bio_put'
[-Werror=implicit-function-declaration]: => 369:4
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'bio_set_op_attrs'
[-Werror=implicit-function-declaration]: => 363:3
+ /home/kisskb/slave/src/fs/crypto/crypto.c: error: implicit
declaration of function 'submit_bio_wait'
[-Werror=implicit-function-declaration]: => 373:3
x86_64-randconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> We wanna know who's doing such a thing. Like slab.c does that.
>
> Signed-off-by: Borislav Petkov
> ---
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 067598a00849..1b0fa7625d6d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s,
> gfp_t flags, int node)
> flags &= ~GFP_SLAB_BUG_MASK;
> pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
> (%pGg). Fix your code!\n",
> invalid_mask, &invalid_mask, flags, &flags);
> + dump_stack();
Will it make sense to change these two lines above to WARN(true, .)?
> }
>
> return allocate_slab(s,
> --
> 2.11.0
>
signature.asc
Description: PGP signature
Re: linux-next 0112 tree breaks fs DAX
On Fri, Jan 13, 2017 at 06:16:41PM +0800, Xiong Zhou wrote:
> Hi,
>
> These cases "hang" when testing with -o dax mount option:
> xfstests generic/030 generic/34{0,4,5,6} generic/198
> (maybe more)
>
> The test programme holetest or aiodio keep running for a
> long time. It's killable, but it seems never return.
>
> With both ext4 and xfs as fs.
>
> Without -o dax mount option, cases pass in seconds.
>
> 0111 tree passed the tests.
>
> sh-4.2# git log --oneline next-20170111..next-20170112 fs/dax.c
> 0c9a7909dd13 mm, dax: change pmd_fault() to take only vmf parameter
> f8dbc198d4ea mm, dax: make pmd_fault() and friends be the same as fault()
0112 tree with above 2 commits reverted pass the tests.
Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
Hi Kishon,
> Hi Łukasz,
>
> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
> > Hi Kishon,
> >
> >> Hi,
> >>
> >> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
> >>> Some devices (due to e.g. bad PCIe signal integrity) require to
> >>> run with forced GEN1 speed on PCIe bus.
> >>>
> >>> This patch changes the speed explicitly on dra7 based devices when
> >>> proper device tree attribute is defined for the PCIe controller.
> >>>
> >>> Signed-off-by: Lukasz Majewski
> >>
> >> Bjorn has already queued a patch to do the same thing
> >> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xx
> >
> > It seems like Bjorn only modifies CAP registers.
>
> The patch also modifies the LNKCTL2 register.
> >
> > He also needs to change register with 0x080C offset to actually
> > ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>
> This bit is used to initiate speed change (after the link is
> initialized in GEN1). Resetting the bit (like what you have done
> here) prevents speed change.
This is strange, but e2e advised me to do things as I did in the patch
to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
Link:
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/566421
Both patches modify 0x5180 007C register to set GEN1 capability
(PCI_EXP_LNKCAP_SLS_2_5GB)
The problem is with second register (in your patch):
>From SPRUHZ6G TRM:
PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
- TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
description in TRM
It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
default /reset value.
Could you clarify which way to _force_ PCIe GEN1 operation is correct?
Mine shows differences in lspci output (as posted in [1]).
>
> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking
> the IP register.
>From the original patch description:
"Add support to force Root Complex to work in GEN1 mode if so desired,
but don't force GEN1 mode on any board just yet."
Are there any (floating around) patches allowing forcing GEN1 operation
on any board (I would like to reuse/port them to my current solution)?
Thanks in advance,
Łukasz Majewski
>
> Thanks
> Kishon
>
> >
> > Best regards,
> > Łukasz
> >
> >>
> >> Thanks
> >> Kishon
> >>
> >>> ---
> >>>
> >>> Patch applies on newest origin/master
> >>> SHA1: f4d3935e4f4884ba80561db5549394afb8eef8f7
> >>>
> >>> Tested at AM5728
> >>>
> >>> ---
> >>> Documentation/devicetree/bindings/pci/ti-pci.txt | 1 +
> >>> drivers/pci/host/pci-dra7xx.c| 23
> >>> +++
> >>> drivers/pci/host/pcie-designware.h | 1 + 3 files
> >>> changed, 25 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt
> >>> b/Documentation/devicetree/bindings/pci/ti-pci.txt index
> >>> 60e2516..9f97409 100644 ---
> >>> a/Documentation/devicetree/bindings/pci/ti-pci.txt +++
> >>> b/Documentation/devicetree/bindings/pci/ti-pci.txt @@ -25,6 +25,7
> >>> @@ PCIe Designware Controller
> >>> Optional Property:
> >>> - gpios : Should be added if a gpio line is required to drive
> >>> PERST# line
> >>> + - to,pcie-is-gen1: Indicates that forced gen1 port operation is
> >>> needed.
> >>> Example:
> >>> axi {
> >>> diff --git a/drivers/pci/host/pci-dra7xx.c
> >>> b/drivers/pci/host/pci-dra7xx.c index 9595fad..eec5fae 100644
> >>> --- a/drivers/pci/host/pci-dra7xx.c
> >>> +++
> >>> b/drivers/pci/host/pci-https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xxdra7xx.c
> >>> @@ -63,6 +63,13 @@ #define
> >>> LINK_UP BIT(16)
> >>> #define
> >>> DRA7XX_CPU_TO_BUS_ADDR0x0FFF
> >>> +#define PCIECTRL_EP_DBICS_LNK_CAP
> >>> 0x007C +#define
> >>> MAX_LINK_SPEEDS_MASK GENMASK(3, 0)
> >>> +#define MAX_LINK_SPEEDS_GEN1
> >>> BIT(0) + +#define
> >>> PCIECTRL_PL_WIDTH_SPEED_CTL 0x080C
> >>> +#define CFG_DIRECTED_SPEED_CHANGE
> >>> BIT(17) + struct dra7xx_pcie { struct pcie_port pp;
> >>> void __iomem*base; /* DT
> >>> ti_conf */ @@ -270,6 +277,7 @@ static int __init
> >>> dra7xx_add_pcie_port(struct dra7xx_pcie *dra7xx, struct pcie_port
> >>> *pp = &dra7xx->pp; struct device *dev = pp->dev;
> >>> struct resource *res;
> >>> + u32 val;
> >>>
> >>> pp->irq = platform_get_irq(pdev, 1);
> >>> if (pp->irq < 0) {
> >>> @@ -296,6 +304,18 @@ static int __init dra7xx_add_pcie_port(struct
> >>> dra7xx_pcie *dra7xx, if (!pp->dbi_base)
> >>> return -ENOMEM;
> >>>
> >>> + if (pp->is_gen1) {
> >>> + dev_info(dev, "GEN1 forced\n");
> >>> +
> >>> + val = readl(pp->dbi_base +
> >>> PCIECTRL_EP_DBICS_LNK_CAP);
> >>> + set_mask_bits(&val, MAX_LINK_SPEEDS_MASK,
> >>> MAX_LINK_SPEEDS_GEN1);
> >>> + writel(val, pp->dbi_base +
> >>> PCIECTRL_EP_DBICS_LNK_CAP); +
> >>> + val = readl(pp->dbi_base +
> >>>
Re: fs, net: deadlock between bind/splice on af_unix
On Fri, Dec 9, 2016 at 7:41 AM, Al Viro wrote:
> On Thu, Dec 08, 2016 at 10:32:00PM -0800, Cong Wang wrote:
>
>> > Why do we do autobind there, anyway, and why is it conditional on
>> > SOCK_PASSCRED? Note that e.g. for SOCK_STREAM we can bloody well get
>> > to sending stuff without autobind ever done - just use socketpair()
>> > to create that sucker and we won't be going through the connect()
>> > at all.
>>
>> In the case Dmitry reported, unix_dgram_sendmsg() calls unix_autobind(),
>> not SOCK_STREAM.
>
> Yes, I've noticed. What I'm asking is what in there needs autobind triggered
> on sendmsg and why doesn't the same need affect the SOCK_STREAM case?
>
>> I guess some lock, perhaps the u->bindlock could be dropped before
>> acquiring the next one (sb_writer), but I need to double check.
>
> Bad idea, IMO - do you *want* autobind being able to come through while
> bind(2) is busy with mknod?
Ping. This is still happening on HEAD.
[ INFO: possible circular locking dependency detected ]
4.9.0 #1 Not tainted
---
syz-executor6/25491 is trying to acquire lock:
(&u->bindlock){+.+.+.}, at: []
unix_autobind.isra.28+0xc5/0x880 net/unix/af_unix.c:852
but task is already holding lock:
(&pipe->mutex/1){+.+.+.}, at: [] pipe_lock_nested
fs/pipe.c:66 [inline]
(&pipe->mutex/1){+.+.+.}, at: []
pipe_lock+0x56/0x70 fs/pipe.c:74
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
[ 836.500536] [] validate_chain
kernel/locking/lockdep.c:2265 [inline]
[ 836.500536] []
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
[ 836.508456] [] lock_acquire+0x2a1/0x630
kernel/locking/lockdep.c:3753
[ 836.516117] [] __mutex_lock_common
kernel/locking/mutex.c:521 [inline]
[ 836.516117] []
mutex_lock_nested+0x24e/0xff0 kernel/locking/mutex.c:621
[ 836.524139] [] pipe_lock_nested
fs/pipe.c:66 [inline]
[ 836.524139] [] pipe_lock+0x56/0x70 fs/pipe.c:74
[ 836.531287] []
iter_file_splice_write+0x262/0xf80 fs/splice.c:717
[ 836.539720] [] do_splice_from
fs/splice.c:869 [inline]
[ 836.539720] [] do_splice fs/splice.c:1160 [inline]
[ 836.539720] [] SYSC_splice fs/splice.c:1410 [inline]
[ 836.539720] [] SyS_splice+0x7c0/0x1690
fs/splice.c:1393
[ 836.547273] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 836.560730] [] validate_chain
kernel/locking/lockdep.c:2265 [inline]
[ 836.560730] []
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
[ 836.568655] [] lock_acquire+0x2a1/0x630
kernel/locking/lockdep.c:3753
[ 836.576230] []
percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:35
[inline]
[ 836.576230] [] percpu_down_read
include/linux/percpu-rwsem.h:58 [inline]
[ 836.576230] []
__sb_start_write+0x19a/0x2b0 fs/super.c:1252
[ 836.584168] [] sb_start_write
include/linux/fs.h:1554 [inline]
[ 836.584168] [] mnt_want_write+0x3f/0xb0
fs/namespace.c:389
[ 836.591744] [] filename_create+0x151/0x610
fs/namei.c:3598
[ 836.599574] [] kern_path_create+0x33/0x40
fs/namei.c:3644
[ 836.607328] [] unix_mknod
net/unix/af_unix.c:967 [inline]
[ 836.607328] [] unix_bind+0x4c3/0xe00
net/unix/af_unix.c:1035
[ 836.614634] [] SYSC_bind+0x20e/0x4a0
net/socket.c:1382
[ 836.621950] [] SyS_bind+0x24/0x30 net/socket.c:1368
[ 836.629015] [] entry_SYSCALL_64_fastpath+0x1f/0xc2
[ 836.642405] [] check_prev_add
kernel/locking/lockdep.c:1828 [inline]
[ 836.642405] []
check_prevs_add+0xa8d/0x1c00 kernel/locking/lockdep.c:1938
[ 836.650348] [] validate_chain
kernel/locking/lockdep.c:2265 [inline]
[ 836.650348] []
__lock_acquire+0x2149/0x3430 kernel/locking/lockdep.c:3338
[ 836.658315] [] lock_acquire+0x2a1/0x630
kernel/locking/lockdep.c:3753
[ 836.665928] [] __mutex_lock_common
kernel/locking/mutex.c:521 [inline]
[ 836.665928] []
mutex_lock_interruptible_nested+0x2e1/0x12a0
kernel/locking/mutex.c:650
[ 836.675287] []
unix_autobind.isra.28+0xc5/0x880 net/unix/af_unix.c:852
[ 836.683571] []
unix_dgram_sendmsg+0x104c/0x1720 net/unix/af_unix.c:1667
[ 836.691870] []
unix_seqpacket_sendmsg+0xf3/0x160 net/unix/af_unix.c:2071
[ 836.700261] [] sock_sendmsg_nosec
net/socket.c:621 [inline]
[ 836.700261] [] sock_sendmsg+0xca/0x110
net/socket.c:631
[ 836.707758] [] kernel_sendmsg+0x47/0x60
net/socket.c:639
[ 836.715327] []
sock_no_sendpage+0x216/0x300 net/core/sock.c:2321
[ 836.723278] [] kernel_sendpage+0x90/0xe0
net/socket.c:3289
[ 836.730944] [] sock_sendpage+0x8c/0xc0
net/socket.c:775
[ 836.738421] []
pipe_to_sendpage+0x29d/0x3e0 fs/splice.c:469
[ 836.746374] [] splice_from_pipe_feed
fs/splice.c:520 [inline]
[ 836.746374] []
__splice_from_pipe+0x328/0x760 fs/splice.c:644
[ 836.754487]
Re: [PATCH] tpm/tpm_i2c_infineon: ensure no ongoing commands on shutdown
On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote: > On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote: > > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote: > > > Resetting TPM while processing a command may lead to issues > > > on the next boot. Ensure that we don't have any ongoing > > > commands, and that no further commands can be sent to the chip > > > by unregistering the device in the shutdown handler. > > > tpm_chip_unregister() waits for the completion of an ongoing > > > command, if any, and then clears out chip->ops and unregisters > > > sysfs entities. > > > > Unregistering in a shutdown handler seems very strange, it also waits > > for userspace things, so I wonder if it could be problematic? > > > > Maybe just use > > > >down_write(&chip->ops_sem); > >chip->ops = NULL; > >up_write(&chip->ops_sem); > > > > In the shutdown handler? > > down_write(&chip->ops_sem) would still wait for completing the initiated > writes, since tpm_write() in tpm-dev.c calls tpm_try_get_ops(). > Also, tpm-sysfs.c calls chip->ops directly, so sysfs should be > unregistered first. Why don't you fix the tpm-sysfs issue but rather misusing tpm_chip_unregister? /Jarkko
Re: [PATCH] drm: etnaviv: constify etnaviv_iommu_ops structures
Am Montag, den 16.01.2017, 00:20 +0530 schrieb Bhumika Goyal:
> Declare etnaviv_iommu_ops structure as const as it is only used when
> the reference of one of its field is stored in the ops field of a
> iommu_domain structure. This ops field is of type const, so
> etnaviv_iommu_ops structures having similar properties can be declared
> const too.
> Done using Coccinelle:
>
> @r1 disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct etnaviv_iommu_ops i@p={...};
>
> @ok1@
> identifier r1.i;
> position p;
> struct etnaviv_iommu_domain x;
> @@
> x.domain.ops=&i...@p.ops;
>
> @bad@
> position p!={r1.p,ok1.p};
> identifier r1.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r1.i;
> @@
> +const
> struct etnaviv_iommu_ops i;
>
> Before and after size details of .o file remains the same after
> cross compiling for arm architecture.
>
> Signed-off-by: Bhumika Goyal
Thanks, I've applied this patch to my tree.
> ---
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> index 81f1583..7a7c97f 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
> @@ -184,7 +184,7 @@ static void etnaviv_iommuv1_dump(struct iommu_domain
> *domain, void *buf)
> memcpy(buf, etnaviv_domain->pgtable.pgtable, PT_SIZE);
> }
>
> -static struct etnaviv_iommu_ops etnaviv_iommu_ops = {
> +static const struct etnaviv_iommu_ops etnaviv_iommu_ops = {
> .ops = {
> .domain_free = etnaviv_domain_free,
> .map = etnaviv_iommuv1_map,
Re: [PATCH 2/2] spi: pca2xx-pci: Allow MSI
On Mon, 2017-01-16 at 10:06 +0100, Jan Kiszka wrote:
> Now that the core is ready for edge-triggered interrupts, we can
> safely
> allow the PCI versions that provide this to enable the feature and,
> thus, have less shared interrupts.
>
My comments below.
> - if (IS_ERR(ssp->clk))
> + if (IS_ERR(ssp->clk))
> return PTR_ERR(ssp->clk);
This doesn't belong to the patch.
> + pci_set_master(dev);
> +
> + ret = pci_alloc_irq_vectors(dev, 1, 1, PCI_IRQ_ALL_TYPES);
> + if (ret < 0) {
> + clk_unregister(ssp->clk);
> + return ret;
> + }
> + ssp->irq = pci_irq_vector(dev, 0);
> +
This looks good, though I would put it closer to the initial place of
ssp->irq assignment, i.e. before clock registering.
> + pci_free_irq_vectors(dev);
> + pci_free_irq_vectors(dev);
You know my answer, right? So, please be sure that we are using
pcim_alloc_irq_vectors().
Yes, I know there is (was?) no such API, needs to be created. Currently
this might make a mess on ->remove().
--
Andy Shevchenko
Intel Finland Oy
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 11:28:40AM +0200, Leon Romanovsky wrote:
> On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> > From: Borislav Petkov
> >
> > We wanna know who's doing such a thing. Like slab.c does that.
> >
> > Signed-off-by: Borislav Petkov
> > ---
> > mm/slub.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/slub.c b/mm/slub.c
> > index 067598a00849..1b0fa7625d6d 100644
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s,
> > gfp_t flags, int node)
> > flags &= ~GFP_SLAB_BUG_MASK;
> > pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
> > (%pGg). Fix your code!\n",
> > invalid_mask, &invalid_mask, flags, &flags);
> > + dump_stack();
>
> Will it make sense to change these two lines above to WARN(true, .)?
Should be equivalent.
I'd even go a step further and make this a small inline function,
something like warn_unexpected_gfp(flags) or so and call it from both
from slab.c and slub.c.
Depending on what mm folks prefer, that is.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [tpmdd-devel] [PATCH v8 2/2] tpm: add securityfs support for TPM 2.0 firmware event log
On Fri, Jan 13, 2017 at 01:09:29PM -0500, Stefan Berger wrote:
> On 01/11/2017 02:54 AM, Nayna Jain wrote:
> > Unlike the device driver support for TPM 1.2, the TPM 2.0 does
> > not support the securityfs pseudo files for displaying the
> > firmware event log.
> >
> > This patch enables support for providing the TPM 2.0 event log in
> > binary form. TPM 2.0 event log supports a crypto agile format that
> > records multiple digests, which is different from TPM 1.2. This
> > patch enables the tpm_bios_log_setup for TPM 2.0 and adds the
> > event log parser which understand the TPM 2.0 crypto agile format.
> >
> > Signed-off-by: Nayna Jain
> > ---
> > drivers/char/tpm/Makefile | 2 +-
> > .../char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} | 35 ++--
> > drivers/char/tpm/tpm2_eventlog.c | 203
> > +
> > drivers/char/tpm/tpm_acpi.c| 3 +
> > drivers/char/tpm/tpm_eventlog.h| 63 +++
> > 5 files changed, 291 insertions(+), 15 deletions(-)
> > rename drivers/char/tpm/{tpm_eventlog.c => tpm1_eventlog.c} (95%)
> > create mode 100644 drivers/char/tpm/tpm2_eventlog.c
> >
> >
> > diff --git a/drivers/char/tpm/tpm_acpi.c b/drivers/char/tpm/tpm_acpi.c
> > index b7718c9..169edf3 100644
> > --- a/drivers/char/tpm/tpm_acpi.c
> > +++ b/drivers/char/tpm/tpm_acpi.c
> > @@ -54,6 +54,9 @@ int tpm_read_log_acpi(struct tpm_chip *chip)
> > u64 len, start;
> > struct tpm_bios_log *log;
> >
> > + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > + return -ENODEV;
> > +
>
>
> Works with SeaBIOS when this check is disabled.
What about OF call paths?
>Stefan
/Jarkko
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
[Let's add Andrew]
On Mon 16-01-17 10:16:43, Borislav Petkov wrote:
> From: Borislav Petkov
>
> We wanna know who's doing such a thing. Like slab.c does that.
Yes this was an omission on my side in 72baeef0c271 ("slab: do not panic
on invalid gfp_mask").
>
> Signed-off-by: Borislav Petkov
Acked-by: Michal Hocko
Thanks!
> ---
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 067598a00849..1b0fa7625d6d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s,
> gfp_t flags, int node)
> flags &= ~GFP_SLAB_BUG_MASK;
> pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
> (%pGg). Fix your code!\n",
> invalid_mask, &invalid_mask, flags, &flags);
> + dump_stack();
> }
>
> return allocate_slab(s,
> --
> 2.11.0
--
Michal Hocko
SUSE Labs
Re: [patch net-next] stmmac: indent an if statement
On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote: > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote: > > From: Dan Carpenter > > Date: Thu, 12 Jan 2017 21:46:32 +0300 > > > > > The break statement should be indented one more tab. > > > > > > Signed-off-by: Dan Carpenter > > > > Applied, but like Julia I think we might have a missing of_node_put() > > here. > > Of course, sorry for dropping the ball on this. I'll send a patch for > that. > Actually, I've looked at it some more and I think this function is OK. We're supposed to do an of_node_put() later... I can't find where that happens, but presumably that's because I don't know stmmac well. This code here, though, is fine. regards, dan carpenter
Re: [PATCH] tpm_tis: use default timeout value if chip reports it as zero
On Fri, Jan 13, 2017 at 10:37:00PM +0100, Maciej S. Szmigiero wrote:
> Since commit 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM
> access") Atmel 3203 TPM on ThinkPad X61S (TPM firmware version 13.9) no
> longer works.
> The initialization proceeds fine until we get and start using chip-reported
> timeouts - and the chip reports C and D timeouts of zero.
>
> It turns out that until commit 8e54caf407b98e ("tpm: Provide a generic
> means to override the chip returned timeouts") we had actually let default
> timeout values remain in this case, so let's bring back this behavior to
> make chips like Atmel 3203 work again.
>
> Use a common code that was introduced by that commit so a warning is
> printed in this case and /sys/class/tpm/tpm*/timeouts correctly says the
> timeouts aren't chip-original.
>
> Signed-off-by: Maciej S. Szmigiero
>
> Fixes: 1107d065fdf1 ("tpm_tis: Introduce intermediate layer for TPM access")
> Cc: sta...@vger.kernel.org
Reviewed-by: Jarkko Sakkinen
/Jarkko
> ---
> This replaces "tpm_tis: override reported C and D timeouts for Atmel 3203"
> submission.
>
> drivers/char/tpm/tpm-interface.c | 53
>
> 1 file changed, 32 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index fecdd3fa8126..a3461cbdde5f 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -522,8 +522,7 @@ static int tpm_startup(struct tpm_chip *chip, __be16
> startup_type)
> int tpm_get_timeouts(struct tpm_chip *chip)
> {
> cap_t cap;
> - unsigned long new_timeout[4];
> - unsigned long old_timeout[4];
> + unsigned long timeout_old[4], timeout_chip[4], timeout_eff[4];
> ssize_t rc;
>
> if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
> @@ -564,11 +563,15 @@ int tpm_get_timeouts(struct tpm_chip *chip)
> return rc;
> }
>
> - old_timeout[0] = be32_to_cpu(cap.timeout.a);
> - old_timeout[1] = be32_to_cpu(cap.timeout.b);
> - old_timeout[2] = be32_to_cpu(cap.timeout.c);
> - old_timeout[3] = be32_to_cpu(cap.timeout.d);
> - memcpy(new_timeout, old_timeout, sizeof(new_timeout));
> + timeout_old[0] = jiffies_to_usecs(chip->timeout_a);
> + timeout_old[1] = jiffies_to_usecs(chip->timeout_b);
> + timeout_old[2] = jiffies_to_usecs(chip->timeout_c);
> + timeout_old[3] = jiffies_to_usecs(chip->timeout_d);
> + timeout_chip[0] = be32_to_cpu(cap.timeout.a);
> + timeout_chip[1] = be32_to_cpu(cap.timeout.b);
> + timeout_chip[2] = be32_to_cpu(cap.timeout.c);
> + timeout_chip[3] = be32_to_cpu(cap.timeout.d);
> + memcpy(timeout_eff, timeout_chip, sizeof(timeout_eff));
>
> /*
>* Provide ability for vendor overrides of timeout values in case
> @@ -576,16 +579,24 @@ int tpm_get_timeouts(struct tpm_chip *chip)
>*/
> if (chip->ops->update_timeouts != NULL)
> chip->timeout_adjusted =
> - chip->ops->update_timeouts(chip, new_timeout);
> + chip->ops->update_timeouts(chip, timeout_eff);
>
> if (!chip->timeout_adjusted) {
> - /* Don't overwrite default if value is 0 */
> - if (new_timeout[0] != 0 && new_timeout[0] < 1000) {
> - int i;
> + /* Restore default if chip reported 0 */
> + int i;
>
> + for (i = 0; i < ARRAY_SIZE(timeout_eff); i++) {
> + if (timeout_eff[i])
> + continue;
> +
> + timeout_eff[i] = timeout_old[i];
> + chip->timeout_adjusted = true;
> + }
> +
> + if (timeout_eff[0] != 0 && timeout_eff[0] < 1000) {
> /* timeouts in msec rather usec */
> - for (i = 0; i != ARRAY_SIZE(new_timeout); i++)
> - new_timeout[i] *= 1000;
> + for (i = 0; i != ARRAY_SIZE(timeout_eff); i++)
> + timeout_eff[i] *= 1000;
> chip->timeout_adjusted = true;
> }
> }
> @@ -594,16 +605,16 @@ int tpm_get_timeouts(struct tpm_chip *chip)
> if (chip->timeout_adjusted) {
> dev_info(&chip->dev,
>HW_ERR "Adjusting reported timeouts: A %lu->%luus B
> %lu->%luus C %lu->%luus D %lu->%luus\n",
> - old_timeout[0], new_timeout[0],
> - old_timeout[1], new_timeout[1],
> - old_timeout[2], new_timeout[2],
> - old_timeout[3], new_timeout[3]);
> + timeout_chip[0], timeout_eff[0],
> + timeout_chip[1], timeout_eff[1],
> + timeout_chip[2], timeout_eff[2],
> + timeout_chip[3], timeout_eff[3]);
> }
>
> - chip->timeout_a = usecs_to_jiffies(new_timeout[0]);
Re: [PATCH v2 0/2] phy: Replace the deprecated extcon API
On Monday 16 January 2017 02:40 PM, Chanwoo Choi wrote: > Hi Kishon, > > On 2017년 01월 10일 17:16, Chanwoo Choi wrote: >> Hi Kishon, >> >> Could you review these patches or pick up them if there is no any comment? > > If there are no comments, could you apply these patches? merged it already. You should see it phy -next before tomorrow. Thanks Kishon > >> >> On 2016년 12월 30일 13:11, Chanwoo Choi wrote: >>> This patches just replace the deprecated extcon API without any change >>> of extcon operation and use the resource-managed function for >>> extcon_register_notifier(). >>> >>> The new extcon API instead of deprecated API. >>> - extcon_set_cable_state_() -> extcon_set_state_sync(); >>> - extcon_get_cable_state_() -> extcon_get_state(); >>> >>> Changes from v1: >>> - Rebase these patches based on v4.10-rc1. >>> - Drop the usb/power-supply/chipidea patches. >>> >>> Chanwoo Choi (2): >>> phy: rcar-gen3-usb2: Replace the deprecated extcon API >>> phy: sun4i-usb: Replace the deprecated extcon API >>> >>> drivers/phy/phy-rcar-gen3-usb2.c | 8 >>> drivers/phy/phy-sun4i-usb.c | 4 ++-- >>> 2 files changed, 6 insertions(+), 6 deletions(-) >>> >> > >
[PATCH v2] virtio_console: fix a crash in config_work_handler
Using control_work instead of config_work as the 3rd argument to
container_of results in an invalid portdev pointer. Indeed, the work
structure is initialized as below:
INIT_WORK(&portdev->config_work, &config_work_handler);
It leads to a crash when portdev->vdev is dereferenced later. This bug
is triggered when the guest uses a virtio-console without multiport
feature and receives a config_changed virtio interrupt.
Signed-off-by: G. Campana
---
drivers/char/virtio_console.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8b00e79..17857be 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1862,7 +1862,7 @@ static void config_work_handler(struct work_struct *work)
{
struct ports_device *portdev;
- portdev = container_of(work, struct ports_device, control_work);
+ portdev = container_of(work, struct ports_device, config_work);
if (!use_multiport(portdev)) {
struct virtio_device *vdev;
struct port *port;
--
2.7.4
Re: [tpmdd-devel] [PATCH RFC v2 5/5] tpm2: expose resource manager via a device link /dev/tpms
On Fri, Jan 13, 2017 at 09:40:08AM -0800, James Bottomley wrote: > On Fri, 2017-01-13 at 10:25 -0700, Jason Gunthorpe wrote: > > On Thu, Jan 12, 2017 at 10:56:28PM +0200, Jarkko Sakkinen wrote: > > > > > > dev_t tpm_devt; > > > > > > But they should have different major device numbers. > > > > major/minors don't really matter these days since they are dynamic > > Right, although we have this weird piece of code: > > > if (chip->dev_num == 0) > chip->dev.devt = MKDEV(MISC_MAJOR, TPM_MINOR); > else > chip->dev.devt = MKDEV(MAJOR(tpm_devt), chip->dev_num); > > So the first TPM device gets the MISC_MAJOR with TPM_MINOR and the rest > get the dynamic major/minor. It means when you do an ls on a complex > system you get something like: > > crw--- 1 root root 10, 224 Jan 13 06:21 /dev/tpm0 > crw--- 1 root root 246, 1 Jan 13 09:38 /dev/tpm1 > crw-rw-rw- 1 root root 246, 65536 Jan 13 06:21 /dev/tpms0 > crw-rw-rw- 1 root root 246, 65537 Jan 13 09:38 /dev/tpms1 > > Perhaps it's time just to junk the reserved misc minor? +1 And Jason is correct about major numbers. I still am puzzled whether these should share the device class and devt with raw /dev/tpm0. /Jarkko
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 10:37:02AM +0100, Borislav Petkov wrote:
> On Mon, Jan 16, 2017 at 11:28:40AM +0200, Leon Romanovsky wrote:
> > On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> > > From: Borislav Petkov
> > >
> > > We wanna know who's doing such a thing. Like slab.c does that.
> > >
> > > Signed-off-by: Borislav Petkov
> > > ---
> > > mm/slub.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index 067598a00849..1b0fa7625d6d 100644
> > > --- a/mm/slub.c
> > > +++ b/mm/slub.c
> > > @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s,
> > > gfp_t flags, int node)
> > > flags &= ~GFP_SLAB_BUG_MASK;
> > > pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
> > > (%pGg). Fix your code!\n",
> > > invalid_mask, &invalid_mask, flags, &flags);
> > > + dump_stack();
> >
> > Will it make sense to change these two lines above to WARN(true, .)?
>
> Should be equivalent.
Almost, except one point - pr_warn and dump_stack have different log
levels. There is a chance that user won't see pr_warn message above, but
dump_stack will be always present.
For WARN_XXX, users will always see message and stack at the same time.
>
> I'd even go a step further and make this a small inline function,
> something like warn_unexpected_gfp(flags) or so and call it from both
> from slab.c and slub.c.
>
> Depending on what mm folks prefer, that is.
>
> --
> Regards/Gruss,
> Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.
signature.asc
Description: PGP signature
Re: [PATCH] staging: greybus: fix checkpatch unsigned warnings
On Fri, Jan 13, 2017 at 09:54:51PM +0100, Roman Sommer wrote:
> Fix checkpatch warnings for parameter type unsigned in greybus.
> Note that this patch does not fix all checkpatch warnings for the
> affected files.
Thanks for the update. In the future, make sure to include a patch
revision in the Subject (e.g. "[PATCH v3] staging: ...") and a changelog
below the cut-off line ("---").
Funny that checkpatch warns about mentioning checkpatch in the Subject
line. Good thing ignoring checkpatch selectively is perfectly fine.
> Signed-off-by: Christian Bewermeyer
> Signed-off-by: Roman Sommer
Reviewed-by: Johan Hovold
Thanks,
Johan
Re: [tpmdd-devel] [PATCH RFC v2 3/5] tpm: infrastructure for TPM spaces
On Sat, Jan 14, 2017 at 12:53:15PM -0500, Ken Goldman wrote:
> On 1/13/2017 11:28 AM, Jarkko Sakkinen wrote:
>
> > > > +
> > > > + if (!tpm2_find_cc_attrs(chip, cc, &attrs)) {
> > > > + /* should never happen */
> > > > + dev_err(&chip->dev, "TPM returned a different CC:
> > > > 0x%04x\n",
> > > > + cc);
> > > > + rc = -EFAULT;
> > > > + goto out_err;
> > > > + }
>
> Something is strange here. Is "CC" command code?
>
> The TPM does not return a command code. The mapping should use the
> command code from the command.
>
> It could be the code is correct - the command code mapped OK in the command
> but then failed in the response. But the error message is strange.
Thanks. I'll update that message.
/Jarkko
Re: [PATCH RFC 2/2] ARM: nommu: remap exception base address to RAM
Hi,
On 15/01/17 11:47, Afzal Mohammed wrote:
> Hi,
>
> On Sat, Jan 07, 2017 at 10:43:39PM +0530, Afzal Mohammed wrote:
>> On Tue, Dec 13, 2016 at 10:02:26AM +, Russell King - ARM Linux wrote:
>
>>> Also, if the region setup for the vectors was moved as well, it would
>>> then be possible to check the ID registers to determine whether this
>>> is supported, and make the decision where to locate the vectors base
>>> more dynamically.
>>
>> This would affect Cortex-R's, which is a bit concerning due to lack of
>> those platforms with me, let me try to get it right.
>
> QEMU too doesn't seem to provide a Cortex-R target
>
>> Seems translating __setup_mpu() altogether to C
>
> afaics, a kind of C translation is already present as
> mpu_setup_region() in arch/arm/mm/nommu.c that takes care of
> MPU_RAM_REGION only. And that seems to be a kind of redundant as it is
> also done in asm at __setup_mpu(). Git blames asm & C to consecutive
> commits, that makes me a little shaky about the conclusion on it being
> redundant.
>
It is not redundant. MPU setup is done it two steps. The first step done in
asm to enable caches, there only kernel image is covered; the second step takes
care on the whole RAM given via dt or "mem=" parameter.
I think other regions are kept there to avoid C side dancing in case of SMP.
>> & installing at a later, but suitable place might be better.
>
> But looks like enabling MPU can't be moved to C & that would
> necessitate keeping at least some portion of__setu_mpu() in asm.
>
> Instead, moving region setup only for vectors to C as Russell
> suggested at first would have to be done.
>
> A kind of diff at the end is in my mind, with additional changes to
> handle the similar during secondary cpu bringup too.
>
> Thinking of invoking mpu_setup() from secondary_start_kernel() in
> arch/arm/kernel/smp.c, with mpu_setup() being slightly modified to
> avoid storing region details again when invoked by secondary cpu's.
I have wip patches on reworking MPU setup code. The idea is to start using
mpu_rgn_info[] actively, so asm part for secondariness would just sync-up
content of that array. Additionally, it seems that we can reuse free MPU slots
to cover memory which is discarded due to MPU alignment restrictions...
>
> Vladimir, once changes are done after a revisit, i would need your
> help to test on Cortex-R.
I'm more than happy to help, but currently I have limited bandwidth, so if it
can wait till the next dev cycle I'd try to make MPU rework finished by that
time.
>
> As an aside, wasn't aware of the fact that Cortex-R supports SMP
> Linux, had thought that, of !MMU one's, only Blackfin & J2 had it.
>
>
>> Also !MMU Kernel could boot on 3 ARM v7-A platforms - AM335x Beagle
>> Bone (A8), AM437x IDK (A9) & Vybrid VF610 (on A5 core, note that it
>> has M4 core too)
>
> Talking about Cortex-M, AMx3's too have it, to be specific M3, but
> they are not Linux-able unlike the one in VF610.
>
Thanks!
Vladimir
> Regards
> afzal
>
> --->8---
>
> diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
> index e0565d73e49e..f8ac79b6136d 100644
> --- a/arch/arm/kernel/head-nommu.S
> +++ b/arch/arm/kernel/head-nommu.S
> @@ -249,20 +249,6 @@ ENTRY(__setup_mpu)
> setup_region r0, r5, r6, MPU_INSTR_SIDE @ 0x0, BG region, enabled
> 2: isb
>
> - /* Vectors region */
> - set_region_nr r0, #MPU_VECTORS_REGION
> - isb
> - /* Shared, inaccessible to PL0, rw PL1 */
> - mov r0, #CONFIG_VECTORS_BASE@ Cover from VECTORS_BASE
> - ldr r5,=(MPU_AP_PL1RW_PL0NA | MPU_RGN_NORMAL)
> - /* Writing N to bits 5:1 (RSR_SZ) --> region size 2^N+1 */
> - mov r6, #(((2 * PAGE_SHIFT - 1) << MPU_RSR_SZ) | 1 << MPU_RSR_EN)
> -
> - setup_region r0, r5, r6, MPU_DATA_SIDE @ VECTORS_BASE, PL0 NA, enabled
> - beq 3f @ Memory-map not unified
> - setup_region r0, r5, r6, MPU_INSTR_SIDE @ VECTORS_BASE, PL0 NA, enabled
> -3: isb
> -
> /* Enable the MPU */
> mrc p15, 0, r0, c1, c0, 0 @ Read SCTLR
> bic r0, r0, #CR_BR @ Disable the 'default mem-map'
> diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
> index e82056df0635..7fe8906322d5 100644
> --- a/arch/arm/mm/nommu.c
> +++ b/arch/arm/mm/nommu.c
> @@ -269,12 +269,19 @@ void __init mpu_setup(void)
> ilog2(memblock.memory.regions[0].size),
> MPU_AP_PL1RW_PL0RW | MPU_RGN_NORMAL);
> if (region_err) {
> - panic("MPU region initialization failure! %d", region_err);
> + panic("MPU RAM region initialization failure! %d", region_err);
> } else {
> - pr_info("Using ARMv7 PMSA Compliant MPU. "
> - "Region independence: %s, Max regions: %d\n",
> - mpu_iside_independent() ? "Yes" : "No",
> - mpu_max_regions());
> +
Re: [PATCH] fix race caused by hyperthreads when online an offline cpu
On 2017/1/16 17:05, Thomas Gleixner wrote: On Mon, 16 Jan 2017, Zhou Chengming wrote: Can you please stop sending the same patch over and over every other day? Granted, things get forgotten, but sending a polite reminder after a week is definitely enough. Maintainers are not machines responding within a split second on every mail they get. And that patch is not so substantial that it justifies that kind of spam. Very sorry for the noise. We are just not sure this is the right fix because it's hard to reproduce. Thanks. Thanks, tglx .
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 11:48:51AM +0200, Leon Romanovsky wrote: > Almost, except one point - pr_warn and dump_stack have different log Actually, Michal pointed out on IRC a more relevant difference: WARN() taints the kernel and we don't want that for GFP flags misuse. Also, from looking at __warn(), it checks panic_on_warn and we explode if set. So no, we probably don't want WARN() here. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH v1 1/3] dt: bindings: add documentation for zx2967 family reset controller
Hi,
On Sat, 2017-01-14 at 15:05 +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family
> reset controller.
>
> Signed-off-by: Baoyou Xie
> ---
> .../devicetree/bindings/reset/zte,zx2967-reset.txt | 20
>
> 1 file changed, 20 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
> b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
> new file mode 100644
> index 000..22d590e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
> @@ -0,0 +1,20 @@
> +ZTE zx2967 SoCs Reset Controller
> +===
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Required properties:
> +- compatible: should be one of the following.
> + * zte,zx296718-reset
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #reset-cells: must be 1.
> +
> +example:
> +
> + toprst: reset@1461060 {
That node should be named reset-controller.
> + compatible = "zte,zx296718-reset";
> + reg = <0x01461060 0x8>;
> + #reset-cells = <1>;
> + };
regards
Philipp
Re: [PATCH v1 3/3] reset: zx2967: add reset controller driver for ZTE's zx2967 family
On Sat, 2017-01-14 at 15:05 +0800, Baoyou Xie wrote:
> This patch adds reset controller driver for ZTE's zx2967 family.
>
> Signed-off-by: Baoyou Xie
> ---
> drivers/reset/Kconfig| 6 ++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-zx2967.c | 136
> +++
> 3 files changed, 143 insertions(+)
> create mode 100644 drivers/reset/reset-zx2967.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 172dc96..972d077 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -92,6 +92,12 @@ config RESET_ZYNQ
> help
> This enables the reset controller driver for Xilinx Zynq SoCs.
>
> +config RESET_ZX2967
> + bool "ZX2967 Reset Driver"
> + depends on ARCH_ZX || COMPILE_TEST
> + help
> + This enables the reset controller driver for ZTE zx2967 family.
> +
> source "drivers/reset/sti/Kconfig"
> source "drivers/reset/hisilicon/Kconfig"
> source "drivers/reset/tegra/Kconfig"
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 13b346e..807b77b 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -14,3 +14,4 @@ obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
> obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
> +obj-$(CONFIG_RESET_ZX2967) += reset-zx2967.o
> diff --git a/drivers/reset/reset-zx2967.c b/drivers/reset/reset-zx2967.c
> new file mode 100644
> index 000..63f9c41
> --- /dev/null
> +++ b/drivers/reset/reset-zx2967.c
> @@ -0,0 +1,136 @@
> +/*
> + * ZTE's zx2967 family thermal sensor driver
This description is incorrect.
> + *
> + * Copyright (C) 2017 ZTE Ltd.
> + *
> + * Author: Baoyou Xie
> + *
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +struct zx2967_reset {
> + void __iomem*reg_base;
> + spinlock_t lock;
> + struct reset_controller_dev rcdev;
> +};
> +
> +static int zx2967_reset_assert(struct reset_controller_dev *rcdev,
> +unsigned long id)
> +{
> + struct zx2967_reset *reset = NULL;
> + int bank = id / 32;
> + int offset = id % 32;
> + unsigned int reg;
> + unsigned long flags;
> +
> + reset = container_of(rcdev, struct zx2967_reset, rcdev);
> +
> + spin_lock_irqsave(&reset->lock, flags);
> +
> + reg = readl(reset->reg_base + (bank * 4));
> + writel(reg & ~BIT(offset), reset->reg_base + (bank * 4));
> + reg = readl(reset->reg_base + (bank * 4));
> +
> + spin_unlock_irqrestore(&reset->lock, flags);
> +
> + return 0;
> +}
> +
> +static int zx2967_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct zx2967_reset *reset = NULL;
> + int bank = id / 32;
> + int offset = id % 32;
> + unsigned int reg;
> + unsigned long flags;
> +
> + reset = container_of(rcdev, struct zx2967_reset, rcdev);
> +
> + spin_lock_irqsave(&reset->lock, flags);
> +
> + reg = readl(reset->reg_base + (bank * 4));
> + writel(reg | BIT(offset), reset->reg_base + (bank * 4));
> + reg = readl(reset->reg_base + (bank * 4));
> +
> + spin_unlock_irqrestore(&reset->lock, flags);
> +
> + return 0;
> +}
> +
> +static struct reset_control_ops zx2967_reset_ops = {
> + .assert = zx2967_reset_assert,
> + .deassert = zx2967_reset_deassert,
> +};
> +
> +static int zx2967_reset_probe(struct platform_device *pdev)
> +{
> + struct zx2967_reset *reset;
> + struct resource *res;
> +
> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
> + if (!reset)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reset->reg_base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(reset->reg_base))
> + return PTR_ERR(reset->reg_base);
> +
> + spin_lock_init(&reset->lock);
> +
> + reset->rcdev.owner = THIS_MODULE;
> + reset->rcdev.nr_resets = resource_size(res) * 8;
> + reset->rcdev.ops = &zx2967_reset_ops;
> + reset->rcdev.of_node = pdev->dev.of_node;
> +
> + dev_info(&pdev->dev, "reset controller cnt:%d",
> + reset->rcdev.nr_resets);
> +
> + return reset_controller_register(&reset->rcdev);
As Shawn suggested, use the devm_ variant here. It allows you to drop
the remove function below.
> +}
> +
> +static int zx2967_reset_remove(struct platform_device *pdev)
> +{
> + struct zx2967_reset *reset = platform_get_drvdata(pdev);
> +
> + reset_controller_unregister(&reset->rcdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id zx2967_reset_dt_ids[] = {
> + { .compatible = "zte,zx296718-reset", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, zx2967_reset_dt_ids);
> +
> +static struct platfo
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon 16-01-17 11:48:51, Leon Romanovsky wrote:
> On Mon, Jan 16, 2017 at 10:37:02AM +0100, Borislav Petkov wrote:
> > On Mon, Jan 16, 2017 at 11:28:40AM +0200, Leon Romanovsky wrote:
> > > On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> > > > From: Borislav Petkov
> > > >
> > > > We wanna know who's doing such a thing. Like slab.c does that.
> > > >
> > > > Signed-off-by: Borislav Petkov
> > > > ---
> > > > mm/slub.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/mm/slub.c b/mm/slub.c
> > > > index 067598a00849..1b0fa7625d6d 100644
> > > > --- a/mm/slub.c
> > > > +++ b/mm/slub.c
> > > > @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache
> > > > *s, gfp_t flags, int node)
> > > > flags &= ~GFP_SLAB_BUG_MASK;
> > > > pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp:
> > > > %#x (%pGg). Fix your code!\n",
> > > > invalid_mask, &invalid_mask, flags,
> > > > &flags);
> > > > + dump_stack();
> > >
> > > Will it make sense to change these two lines above to WARN(true, .)?
> >
> > Should be equivalent.
>
> Almost, except one point - pr_warn and dump_stack have different log
> levels. There is a chance that user won't see pr_warn message above, but
> dump_stack will be always present.
>
> For WARN_XXX, users will always see message and stack at the same time.
On the other hand WARN* will taint the kernel and this sounds a bit
overreacting for something like a wrong gfp mask which is perfectly
recoverable. Not to mention users who care configured to panic on
warning.
So while I do not have a strong opinion on this I would rather stay with
the dump_stack.
--
Michal Hocko
SUSE Labs
Re: [PATCH 09/10] ARM: dts: da850: add the SATA node
2017-01-13 20:36 GMT+01:00 David Lechner :
> On 01/13/2017 06:38 AM, Bartosz Golaszewski wrote:
>>
>> Add the SATA node to the da850 device tree.
>>
>> Signed-off-by: Bartosz Golaszewski
>> ---
>> arch/arm/boot/dts/da850.dtsi | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 1f6a47d..f5086b1 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -427,6 +427,12 @@
>> phy-names = "usb-phy";
>> status = "disabled";
>> };
>> + sata: ahci@0x218000 {
>
>
> 0x needs to be omitted.
>
> sata: ahci@218000 {
>
Will fix in v2.
Thanks,
Bartosz Golaszewski
Re: [PATCH] tpm: add session handles to the save and restore of the tpm2 space manager
On Fri, Jan 13, 2017 at 11:24:13AM -0800, James Bottomley wrote:
> Session handles are slightly more difficult to manage because any TPM
> only has a finite number of allowed handles, even if the session has
> been saved; so when you context save a session, you must not flush it
> because that would destroy the ability to context load it (you only
> flush sessions when you're done with them) and the tpm won't re-use
> the handle. Additionally, sessions can be flushed as part of the
> successful execution of a command if the continueSession attribute is
> clear, so we have to mark any session we find in the command (using
> TPM2_HT_TAG_FOR_FLUSH) so it can be cleared from the space if the
> command successfully executes.
>
> Finally, a session may also be cleared by flushing it, so we have to
> emulate the TPM2_FlushContext command to see if a session is being
> flushed and manually clear it from the space.
>
> We also fully flush all sessions on device close.
Some big overview comments without going deeply into details. I will
use more time for this once the
Please do not use handle allocation code for sessions. This commit
makes the implementation a mess. Just use the phandle directly and
have array of session phandles for each space.
I would also almost require to have at minimum two patches: one that
implements purely isolation and another that implements swapping.
It might be for example that I want to land TPM spaces with session
isolation to one release and swapping to n+1 because my hunch tells
me that it is better to bake the swapping part for a while.
One more thing. Maybe commit messages should speak uniformally about
TPM spaces? They are a tool to implement resource manager, not a
resource manager.
/Jarkko
>
> Signed-off-by: James Bottomley
>
> diff --git a/drivers/char/tpm/tpm-interface.c
> b/drivers/char/tpm/tpm-interface.c
> index f5c9355..d8e896e 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -400,6 +400,10 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
> tpm_space *space,
> if (chip->dev.parent)
> pm_runtime_get_sync(chip->dev.parent);
>
> + rc = tpm2_emulate(chip, space, ordinal, buf, bufsiz);
> + if (rc)
> + goto out;
> +
> rc = tpm2_prepare_space(chip, space, ordinal, buf, bufsiz);
> if (rc)
> goto out;
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index adf7810..b922652 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
> @@ -136,7 +136,8 @@ enum tpm2_capabilities {
> };
>
> enum tpm2_properties {
> - TPM_PT_TOTAL_COMMANDS = 0x0129,
> + TPM_PT_ACTIVE_SESSIONS_MAX = 0x0111,
> + TPM_PT_TOTAL_COMMANDS = 0x0129,
> };
>
> enum tpm2_startup_types {
> @@ -214,6 +215,8 @@ struct tpm_chip {
> struct tpm_space *work_space;
> u32 nr_commands;
> u32 *cc_attrs_tbl;
> + struct tpm_sessions *sessions;
> + int max_sessions;
> };
>
> #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
> @@ -583,4 +586,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct
> tpm_space *space,
> u32 cc, u8 *buf, size_t bufsiz);
> int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
> u32 cc, u8 *buf, size_t bufsiz);
> +void tpm2_flush_space(struct tpm_chip *chip, struct tpm_space *space);
> +int tpm2_emulate(struct tpm_chip *chip, struct tpm_space *space,
> + u32 cc, u8 *buf, size_t bufsiz);
> #endif
> diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> index 285361e..e8e9f32 100644
> --- a/drivers/char/tpm/tpm2-space.c
> +++ b/drivers/char/tpm/tpm2-space.c
> @@ -25,15 +25,29 @@ enum tpm2_handle_types {
> TPM2_HT_TRANSIENT = 0x8000,
> };
>
> -static void tpm2_flush_space(struct tpm_chip *chip)
> +#define TPM2_HT_TAG_FOR_FLUSH0xF000
> +
> +void tpm2_flush_space(struct tpm_chip *chip, struct tpm_space *space)
> {
> - struct tpm_space *space = chip->work_space;
> int i;
>
> - for (i = 0; i < ARRAY_SIZE(space->context_tbl); i++)
> - if (space->context_tbl[i] && ~space->context_tbl[i])
> - tpm2_flush_context_cmd(chip, space->context_tbl[i],
> -TPM_TRANSMIT_UNLOCKED);
> + for (i = 0; i < ARRAY_SIZE(space->context_tbl); i++) {
> + u32 handle = space->context_tbl[i];
> + u32 handle_type;
> +
> + if (handle == 0 || handle == ~0)
> + continue;
> +
> + if ((handle & TPM2_HT_TAG_FOR_FLUSH) ==
> + TPM2_HT_TAG_FOR_FLUSH)
> + handle &= ~TPM2_HT_TAG_FOR_FLUSH;
> +
> + handle_type = (handle & 0xFF00);
> +
> + tpm2_flush_context_cmd(chip, handle, TPM_TRANSMIT_UNLOCKED);
> +
> + space->context_tbl[i] = 0;
> + }
> }
>
>
Re: [PATCH] tpm: add session handles to the save and restore of the tpm2 space manager
On Mon, Jan 16, 2017 at 12:04:15PM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 11:24:13AM -0800, James Bottomley wrote:
> > Session handles are slightly more difficult to manage because any TPM
> > only has a finite number of allowed handles, even if the session has
> > been saved; so when you context save a session, you must not flush it
> > because that would destroy the ability to context load it (you only
> > flush sessions when you're done with them) and the tpm won't re-use
> > the handle. Additionally, sessions can be flushed as part of the
> > successful execution of a command if the continueSession attribute is
> > clear, so we have to mark any session we find in the command (using
> > TPM2_HT_TAG_FOR_FLUSH) so it can be cleared from the space if the
> > command successfully executes.
> >
> > Finally, a session may also be cleared by flushing it, so we have to
> > emulate the TPM2_FlushContext command to see if a session is being
> > flushed and manually clear it from the space.
> >
> > We also fully flush all sessions on device close.
>
> Some big overview comments without going deeply into details. I will
> use more time for this once the
... transient object swapping and /dev/tpms0 are in the shape :-)
/Jarkko
>
> Please do not use handle allocation code for sessions. This commit
> makes the implementation a mess. Just use the phandle directly and
> have array of session phandles for each space.
>
> I would also almost require to have at minimum two patches: one that
> implements purely isolation and another that implements swapping.
>
> It might be for example that I want to land TPM spaces with session
> isolation to one release and swapping to n+1 because my hunch tells
> me that it is better to bake the swapping part for a while.
>
> One more thing. Maybe commit messages should speak uniformally about
> TPM spaces? They are a tool to implement resource manager, not a
> resource manager.
>
> /Jarkko
>
> >
> > Signed-off-by: James Bottomley
> >
> > diff --git a/drivers/char/tpm/tpm-interface.c
> > b/drivers/char/tpm/tpm-interface.c
> > index f5c9355..d8e896e 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -400,6 +400,10 @@ ssize_t tpm_transmit(struct tpm_chip *chip, struct
> > tpm_space *space,
> > if (chip->dev.parent)
> > pm_runtime_get_sync(chip->dev.parent);
> >
> > + rc = tpm2_emulate(chip, space, ordinal, buf, bufsiz);
> > + if (rc)
> > + goto out;
> > +
> > rc = tpm2_prepare_space(chip, space, ordinal, buf, bufsiz);
> > if (rc)
> > goto out;
> > diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> > index adf7810..b922652 100644
> > --- a/drivers/char/tpm/tpm.h
> > +++ b/drivers/char/tpm/tpm.h
> > @@ -136,7 +136,8 @@ enum tpm2_capabilities {
> > };
> >
> > enum tpm2_properties {
> > - TPM_PT_TOTAL_COMMANDS = 0x0129,
> > + TPM_PT_ACTIVE_SESSIONS_MAX = 0x0111,
> > + TPM_PT_TOTAL_COMMANDS = 0x0129,
> > };
> >
> > enum tpm2_startup_types {
> > @@ -214,6 +215,8 @@ struct tpm_chip {
> > struct tpm_space *work_space;
> > u32 nr_commands;
> > u32 *cc_attrs_tbl;
> > + struct tpm_sessions *sessions;
> > + int max_sessions;
> > };
> >
> > #define to_tpm_chip(d) container_of(d, struct tpm_chip, dev)
> > @@ -583,4 +586,7 @@ int tpm2_prepare_space(struct tpm_chip *chip, struct
> > tpm_space *space,
> >u32 cc, u8 *buf, size_t bufsiz);
> > int tpm2_commit_space(struct tpm_chip *chip, struct tpm_space *space,
> > u32 cc, u8 *buf, size_t bufsiz);
> > +void tpm2_flush_space(struct tpm_chip *chip, struct tpm_space *space);
> > +int tpm2_emulate(struct tpm_chip *chip, struct tpm_space *space,
> > + u32 cc, u8 *buf, size_t bufsiz);
> > #endif
> > diff --git a/drivers/char/tpm/tpm2-space.c b/drivers/char/tpm/tpm2-space.c
> > index 285361e..e8e9f32 100644
> > --- a/drivers/char/tpm/tpm2-space.c
> > +++ b/drivers/char/tpm/tpm2-space.c
> > @@ -25,15 +25,29 @@ enum tpm2_handle_types {
> > TPM2_HT_TRANSIENT = 0x8000,
> > };
> >
> > -static void tpm2_flush_space(struct tpm_chip *chip)
> > +#define TPM2_HT_TAG_FOR_FLUSH 0xF000
> > +
> > +void tpm2_flush_space(struct tpm_chip *chip, struct tpm_space *space)
> > {
> > - struct tpm_space *space = chip->work_space;
> > int i;
> >
> > - for (i = 0; i < ARRAY_SIZE(space->context_tbl); i++)
> > - if (space->context_tbl[i] && ~space->context_tbl[i])
> > - tpm2_flush_context_cmd(chip, space->context_tbl[i],
> > - TPM_TRANSMIT_UNLOCKED);
> > + for (i = 0; i < ARRAY_SIZE(space->context_tbl); i++) {
> > + u32 handle = space->context_tbl[i];
> > + u32 handle_type;
> > +
> > + if (handle == 0 || handle == ~0)
> > + continue;
> > +
> > + if ((handle & TPM2_HT_TAG_FOR_FLUSH
Re: [Intel-gfx] [PATCH v4] lib/scatterlist: Avoid potential scatterlist entry overflow
On 13/01/2017 22:23, Andy Shevchenko wrote:
@@ -402,9 +403,16 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
/* compute number of contiguous chunks */
chunks = 1;
- for (i = 1; i < n_pages; ++i)
- if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) +
1)
+ seg_len = PAGE_SIZE;
+ for (i = 1; i < n_pages; ++i) {
+ if (seg_len >= max_segment ||
+ page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) +
1) {
++chunks;
+ seg_len = PAGE_SIZE;
+ } else {
+ seg_len += PAGE_SIZE;
+ }
+ }
Wouldn't be following looks more readable?
seg_len = 0;
// Are compilers so stupid doing calculation per iteration in
for-conditional?
// for (i = 0; i + 1 < n_pages; i++) ?
I didn't get what you meant here?
Why do we start from 1? I see here two micro (?) optimizations:
1) starting from 1 on believe that compiler dumb enough to every time
do a calculation in condition;
The existing code starts from 1 because the pfn condition looks up page
i - 1. I don't feel there is a need to change that as well.
2) ++i instead of i++, but this is just matter of style, it's not a c++.
Note that I haven't changed the existing code in this respect. I am
happy to change it though.
for (i = 1; i < n_pages; ++i) {
seg_len += PAGE_SIZE;
if (seg_len >= max_segment || page_to_pfn(pages[i]) !=
page_to_pfn(pages[i - 1]) + 1) {
++chunks;
seg_len = PAGE_SIZE;
}
}
Tried it in my unit tester but it doesn't work for all scenarios, guess
there is a subtle bug somewhere. I don't find it that unreadable so would
prefer to leave it since it works.
Last seems has to be
seg_len = 0;
Oh right, of course. Your suggestion generates a tiny bit smaller binary
so I am happy to change that as well. I'll resend the patch hopefully today.
Regards,
Tvrtko
[PATCH v2 0/11] Rockchip dw-mipi-dsi driver
Hi all This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. And these patches also fixes some driver bugs; add the power domain support. they have been tested on rk3399 and rk3288 evb board. Chris Zhong (7): dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi drm/rockchip/dsi: remove mode_valid function dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: add dw-mipi power domain support drm/rockchip/dsi: fix phy clk lane stop state timeout drm/rockchip/dsi: fix insufficient bandwidth of some panel Mark Yao (2): drm/rockchip/dsi: return probe defer if attach panel failed drm/rockchip/dsi: fix mipi display can't found at init time xubilv (2): drm/rockchip/dsi: fix the issue can not send commands drm/rockchip/dsi: decrease the value of Ths-prepare .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 254 + 2 files changed, 163 insertions(+), 98 deletions(-) -- 2.6.3
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On 01/16/2017 10:16 AM, Borislav Petkov wrote:
> From: Borislav Petkov
>
> We wanna know who's doing such a thing. Like slab.c does that.
>
> Signed-off-by: Borislav Petkov
Acked-by: Vlastimil Babka
> ---
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 067598a00849..1b0fa7625d6d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s,
> gfp_t flags, int node)
> flags &= ~GFP_SLAB_BUG_MASK;
> pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x
> (%pGg). Fix your code!\n",
> invalid_mask, &invalid_mask, flags, &flags);
> + dump_stack();
> }
>
> return allocate_slab(s,
>
[PATCH v2 01/11] dt-bindings: add rk3399 support for dw-mipi-rockchip
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1753f0c..0f82568 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -5,10 +5,12 @@ Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk), as described in [1]. + clock(ref) and APB clock(pclk). For RK3399, a phy config clock + (phy_cfg) is additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3
[PATCH v2 04/11] dt-bindings: add power domain node for dw-mipi-rockchip
Signed-off-by: Chris Zhong Acked-by: Rob Herring --- .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 0f82568..188f6f7 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -15,6 +15,9 @@ Required properties: - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. +Optional properties: +- power-domains: a phandle to mipi dsi power domain node. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt [2] Documentation/devicetree/bindings/media/video-interfaces.txt -- 2.6.3
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 10:55:22AM +0100, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 11:48:51AM +0200, Leon Romanovsky wrote: > > Almost, except one point - pr_warn and dump_stack have different log > > Actually, Michal pointed out on IRC a more relevant difference: > > WARN() taints the kernel and we don't want that for GFP flags misuse. And doesn't dump_stack do the same? It pollutes the log too. > Also, from looking at __warn(), it checks panic_on_warn and we explode > if set. Right, it is very valid point. > > So no, we probably don't want WARN() here. I understand, Thanks. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. signature.asc Description: PGP signature
[PATCH v2 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel
Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
for some panel, it will cause the screen display is not normal, so
increases the badnwidth to 1 / 0.8.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9dfa73d..5a973fe 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
if (mpclk) {
- /* take 1 / 0.9, since mbps must big than bandwidth of RGB */
- tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
+ /* take 1 / 0.8, since mbps must big than bandwidth of RGB */
+ tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;
if (tmp < max_mbps)
target_mbps = tmp;
else
--
2.6.3
[PATCH v2 10/11] drm/rockchip/dsi: fix phy clk lane stop state timeout
Before phy init, the detection of phy state should be controlled manually. After that, we can switch the detection to hardward, it is automatic. Hence move PHY_TXREQUESTCLKHS setting to the end of phy init. Signed-off-by: Chris Zhong --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index f50909e..9dfa73d 100644 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c @@ -475,6 +475,8 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi) dev_err(dsi->dev, "failed to wait for phy clk lane stop state\n"); + dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS); + phy_init_end: if (!IS_ERR(dsi->phy_cfg_clk)) clk_disable_unprepare(dsi->phy_cfg_clk); @@ -721,7 +723,6 @@ static void dw_mipi_dsi_init(struct dw_mipi_dsi *dsi) | PHY_RSTZ | PHY_SHUTDOWNZ); dsi_write(dsi, DSI_CLKMGR_CFG, TO_CLK_DIVIDSION(10) | TX_ESC_CLK_DIVIDSION(7)); - dsi_write(dsi, DSI_LPCLK_CTRL, PHY_TXREQUESTCLKHS); } static void dw_mipi_dsi_dpi_config(struct dw_mipi_dsi *dsi, -- 2.6.3
[PATCH v2 08/11] drm/rockchip/dsi: fix the issue can not send commands
From: xubilv
There is a bug in hdr_write function, the value from the caller will be
overwritten, it cause the mipi can not send the correct command. And the
MIPI_DSI_GENERIC_SHORT_WRITE_n_PARAM message type should be supported.
Signed-off-by: xubilv
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 4ec82f6..4a2691c 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -572,10 +572,12 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi *dsi, u32 val)
{
int ret;
+ u32 sts;
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_CMD_FULL), 1000,
+sts, !(sts & GEN_CMD_FULL), 1000,
CMD_PKT_STATUS_TIMEOUT_US);
+
if (ret < 0) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
@@ -584,8 +586,9 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi
*dsi, u32 val)
dsi_write(dsi, DSI_GEN_HDR, val);
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
-val, val & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
+sts, sts & (GEN_CMD_EMPTY | GEN_PLD_W_EMPTY),
1000, CMD_PKT_STATUS_TIMEOUT_US);
+
if (ret < 0) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
@@ -594,8 +597,8 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi
*dsi, u32 val)
return 0;
}
-static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_short_write(struct dw_mipi_dsi *dsi,
+ const struct mipi_dsi_msg *msg)
{
const u16 *tx_buf = msg->tx_buf;
u32 val = GEN_HDATA(*tx_buf) | GEN_HTYPE(msg->type);
@@ -609,13 +612,14 @@ static int dw_mipi_dsi_dcs_short_write(struct dw_mipi_dsi
*dsi,
return dw_mipi_dsi_gen_pkt_hdr_write(dsi, val);
}
-static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi *dsi,
- const struct mipi_dsi_msg *msg)
+static int dw_mipi_dsi_long_write(struct dw_mipi_dsi *dsi,
+ const struct mipi_dsi_msg *msg)
{
const u32 *tx_buf = msg->tx_buf;
int len = msg->tx_len, pld_data_bytes = sizeof(*tx_buf), ret;
u32 val = GEN_HDATA(msg->tx_len) | GEN_HTYPE(msg->type);
u32 remainder = 0;
+ u32 sts = 0;
if (msg->tx_len < 3) {
dev_err(dsi->dev, "wrong tx buf length %zu for long write\n",
@@ -635,7 +639,7 @@ static int dw_mipi_dsi_dcs_long_write(struct dw_mipi_dsi
*dsi,
}
ret = readx_poll_timeout(readl, dsi->base + DSI_CMD_PKT_STATUS,
-val, !(val & GEN_PLD_W_FULL), 1000,
+sts, !(sts & GEN_PLD_W_FULL), 1000,
CMD_PKT_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev,
@@ -656,11 +660,15 @@ static ssize_t dw_mipi_dsi_host_transfer(struct
mipi_dsi_host *host,
switch (msg->type) {
case MIPI_DSI_DCS_SHORT_WRITE:
case MIPI_DSI_DCS_SHORT_WRITE_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_0_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_1_PARAM:
+ case MIPI_DSI_GENERIC_SHORT_WRITE_2_PARAM:
case MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE:
- ret = dw_mipi_dsi_dcs_short_write(dsi, msg);
+ ret = dw_mipi_dsi_short_write(dsi, msg);
break;
case MIPI_DSI_DCS_LONG_WRITE:
- ret = dw_mipi_dsi_dcs_long_write(dsi, msg);
+ case MIPI_DSI_GENERIC_LONG_WRITE:
+ ret = dw_mipi_dsi_long_write(dsi, msg);
break;
default:
dev_err(dsi->dev, "unsupported message type\n");
--
2.6.3
[PATCH v2 09/11] drm/rockchip/dsi: decrease the value of Ths-prepare
From: xubilv Signed-off-by: xubilv Signed-off-by: Chris Zhong --- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c index 4a2691c..f50909e 100644 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c @@ -455,7 +455,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi) BANDGAP_SEL(BANDGAP_96_10)); dw_mipi_dsi_phy_write(dsi, 0x70, TLP_PROGRAM_EN | 0xf); - dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x55); + dw_mipi_dsi_phy_write(dsi, 0x71, THS_PRE_PROGRAM_EN | 0x2d); dw_mipi_dsi_phy_write(dsi, 0x72, THS_ZERO_PROGRAM_EN | 0xa); dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK | -- 2.6.3
[PATCH v2 06/11] drm/rockchip/dsi: return probe defer if attach panel failed
From: Mark Yao
Return -EINVAL would cause mipi dsi bad behavior, probe defer
to ensure mipi find the correct mode,
Signed-off-by: Mark Yao
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d2a3efb..5e3f031 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -549,10 +549,14 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->channel = device->channel;
dsi->format = device->format;
dsi->panel = of_drm_find_panel(device->dev.of_node);
- if (dsi->panel)
- return drm_panel_attach(dsi->panel, &dsi->connector);
+ if (!dsi->panel) {
+ DRM_ERROR("failed to find panel\n");
+ return -EPROBE_DEFER;
+ }
- return -EINVAL;
+ drm_panel_attach(dsi->panel, &dsi->connector);
+
+ return 0;
}
static int dw_mipi_dsi_host_detach(struct mipi_dsi_host *host,
@@ -560,7 +564,8 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
{
struct dw_mipi_dsi *dsi = host_to_dsi(host);
- drm_panel_detach(dsi->panel);
+ if (dsi->panel)
+ drm_panel_detach(dsi->panel);
return 0;
}
--
2.6.3
[PATCH] rtc: stm32: fix comparison warnings
This patches fixes comparison between signed and unsigned values as it
could produce an incorrect result when the signed value is converted to
unsigned:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_valid_alrm':
drivers/rtc/rtc-stm32.c:404:21: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if tm->tm_year > cur_year) &&
...
It also fixes comparison always true or false due to the fact that unsigned
value is compared against zero with >= or <:
drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_init':
drivers/rtc/rtc-stm32.c:514:35: warning: comparison of unsigned expression >= 0
is always true [-Wtype-limits]
for (pred_a = pred_a_max; pred_a >= 0; pred_a-- ) {
drivers/rtc/rtc-stm32.c:530:44: warning: comparison of unsigned expression < 0
is always false [-Wtype-limits]
(rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
Signed-off-by: Amelie Delaunay
---
drivers/rtc/rtc-stm32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-stm32.c b/drivers/rtc/rtc-stm32.c
index 03c97c1..bd57eb1 100644
--- a/drivers/rtc/rtc-stm32.c
+++ b/drivers/rtc/rtc-stm32.c
@@ -383,7 +383,7 @@ static int stm32_rtc_alarm_irq_enable(struct device *dev,
unsigned int enabled)
static int stm32_rtc_valid_alrm(struct stm32_rtc *rtc, struct rtc_time *tm)
{
- unsigned int cur_day, cur_mon, cur_year, cur_hour, cur_min, cur_sec;
+ int cur_day, cur_mon, cur_year, cur_hour, cur_min, cur_sec;
unsigned int dr = readl_relaxed(rtc->base + STM32_RTC_DR);
unsigned int tr = readl_relaxed(rtc->base + STM32_RTC_TR);
@@ -509,7 +509,7 @@ static int stm32_rtc_init(struct platform_device *pdev,
pred_a_max = STM32_RTC_PRER_PRED_A >> STM32_RTC_PRER_PRED_A_SHIFT;
pred_s_max = STM32_RTC_PRER_PRED_S >> STM32_RTC_PRER_PRED_S_SHIFT;
- for (pred_a = pred_a_max; pred_a >= 0; pred_a--) {
+ for (pred_a = pred_a_max; pred_a + 1 > 0; pred_a--) {
pred_s = (rate / (pred_a + 1)) - 1;
if (((pred_s + 1) * (pred_a + 1)) == rate)
@@ -525,7 +525,7 @@ static int stm32_rtc_init(struct platform_device *pdev,
pred_s = (rate / (pred_a + 1)) - 1;
dev_warn(&pdev->dev, "ck_rtc is %s\n",
-(rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
+(rate < ((pred_a + 1) * (pred_s + 1))) ?
"fast" : "slow");
}
--
1.9.1
[PATCH v2 05/11] drm/rockchip/dsi: add dw-mipi power domain support
Reference the power domain incase dw-mipi power down when
in use.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 8f8d48a..d2a3efb 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -291,6 +292,7 @@ struct dw_mipi_dsi {
struct clk *pclk;
struct clk *phy_cfg_clk;
+ int dpms_mode;
unsigned int lane_mbps; /* per lane */
u32 channel;
u32 lanes;
@@ -842,6 +844,9 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder
*encoder,
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
int ret;
+ if (dsi->dpms_mode == DRM_MODE_DPMS_ON)
+ return;
+
dsi->mode = adjusted_mode;
ret = dw_mipi_dsi_get_lane_bps(dsi);
@@ -853,6 +858,8 @@ static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder
*encoder,
return;
}
+ pm_runtime_get_sync(dsi->dev);
+
dw_mipi_dsi_init(dsi);
dw_mipi_dsi_dpi_config(dsi, mode);
dw_mipi_dsi_packet_handler_config(dsi);
@@ -874,6 +881,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
{
struct dw_mipi_dsi *dsi = encoder_to_dsi(encoder);
+ if (dsi->dpms_mode != DRM_MODE_DPMS_ON)
+ return;
+
drm_panel_disable(dsi->panel);
if (clk_prepare_enable(dsi->pclk)) {
@@ -893,7 +903,9 @@ static void dw_mipi_dsi_encoder_disable(struct drm_encoder
*encoder)
dw_mipi_dsi_set_mode(dsi, DW_MIPI_DSI_CMD_MODE);
dw_mipi_dsi_disable(dsi);
+ pm_runtime_put(dsi->dev);
clk_disable_unprepare(dsi->pclk);
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
}
static void dw_mipi_dsi_encoder_commit(struct drm_encoder *encoder)
@@ -927,6 +939,7 @@ static void dw_mipi_dsi_encoder_commit(struct drm_encoder
*encoder)
regmap_write(dsi->grf_regmap, pdata->grf_switch_reg, val);
dev_dbg(dsi->dev, "vop %s output to dsi0\n", (mux) ? "LIT" : "BIG");
+ dsi->dpms_mode = DRM_MODE_DPMS_ON;
}
static int
@@ -1094,6 +1107,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dsi->dev = dev;
dsi->pdata = pdata;
+ dsi->dpms_mode = DRM_MODE_DPMS_OFF;
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
@@ -1139,6 +1153,8 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
dev_set_drvdata(dev, dsi);
+ pm_runtime_enable(dev);
+
dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
dsi->dsi_host.dev = dev;
return mipi_dsi_host_register(&dsi->dsi_host);
@@ -1154,6 +1170,7 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct
device *master,
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
mipi_dsi_host_unregister(&dsi->dsi_host);
+ pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
--
2.6.3
Re: [PATCH 1/5] [media] ir-rx51: port to rc-core
Hi Ivo, On Fri, Dec 30, 2016 at 03:50:42PM +0200, Ivaylo Dimitrov wrote: > On 30.12.2016 15:30, Sean Young wrote: > > > >On Fri, Dec 30, 2016 at 01:07:52PM +, Sean Young wrote: > >>Hi Ivo,, > >> > >>On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote: > >>>On 20.12.2016 19:50, Sean Young wrote: > This driver was written using lirc since rc-core did not support > transmitter-only hardware at that time. Now that it does, port > this driver. > > Compile tested only. > > >>> > >>>I guess after that change, there will be no more /dev/lircN device, right? > >>>Neither will LIRC_XXX IOCTL codes be supported? > >> > >>Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be > >>supported through ir-lirc-codec.c. > >> > >>By using rc-core, the driver will be more succinct, and some latent bugs > >>will be fixed. For example, at the moment it is possible to write hours > >>of IR data and keep the n900 from suspending. > >> > >>I'm working on lirc scancode sending and receiving using the IR encoders, > >>and when that is in place, any rc-core driver will get it for free. > >> > >>>That looks to me as a completely new driver, not a port to new API. > >>> > >>>Right now there are applications using the current behaviour (pierogi for > >>>example), which will be broken by the change. > >> > >>Nothing should break. > > > >Speaking of which, if you would please test this, that would be great. My > >N900 died many years ago. > > > > Will do, but next year :) . Have you had a chance to test the ir-rx51 changes? Thanks Sean
[PATCH v2 02/11] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 101 -
1 file changed, 74 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index d9aa382..04fd595 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -28,9 +28,17 @@
#define DRIVER_NAME"dw-mipi-dsi"
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_GRF_DSI_MODE0x
#define DSI_VERSION0x00
#define DSI_PWR_UP 0x04
@@ -147,7 +155,6 @@
#define LPRX_TO_CNT(p) ((p) & 0x)
#define DSI_BTA_TO_CNT 0x8c
-
#define DSI_LPCLK_CTRL 0x94
#define AUTO_CLKLANE_CTRL BIT(1)
#define PHY_TXREQUESTCLKHS BIT(0)
@@ -213,11 +220,11 @@
#define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
#define LOW_PROGRAM_EN 0
#define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val) ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
#define PLL_LOOP_DIV_ENBIT(5)
#define PLL_INPUT_DIV_EN BIT(4)
@@ -263,6 +270,11 @@ enum {
};
struct dw_mipi_dsi_plat_data {
+ u32 dsi0_en_bit;
+ u32 dsi1_en_bit;
+ u32 grf_switch_reg;
+ u32 grf_dsi0_mode;
+ u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
@@ -279,6 +291,7 @@ struct dw_mipi_dsi {
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk *phy_cfg_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -353,6 +366,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct
drm_encoder *encoder)
{
return container_of(encoder, struct dw_mipi_dsi, encoder);
}
+
static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
{
writel(val, dsi->base + reg);
@@ -364,7 +378,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
}
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
{
/*
* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -400,6 +414,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PWR_UP, POWERUP);
+ if (!IS_ERR(dsi->phy_cfg_clk)) {
+ ret = clk_prepare_enable(dsi->phy_cfg_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+ return ret;
+ }
+ }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
VCO_RANGE_CON_SEL(vco) |
VCO_IN_CAP_CON_LOW |
@@ -439,22 +461,23 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
-
ret = readx_poll_timeout(readl, dsi->base + DSI_PHY_STATUS,
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
- return ret;
+ goto phy_init_end;
}
ret = readx_poll_timeout(readl, dsi->base + DSI_PHY_STATUS,
val, val & STOP_STATE_CLK_LANE, 1000,
PHY_STATUS_TIMEOUT_US);
- if (ret < 0) {
+ if (ret < 0)
dev_err(dsi->dev,
"failed to wait for phy clk lane stop state\n");
- return ret;
-
[PATCH v2 07/11] drm/rockchip/dsi: fix mipi display can't found at init time
From: Mark Yao
The problem is that:
mipi panel probe request mipi_dsi_host_register.
mipi host attach is call from panel device, so the defer function
always can't works.
So at the first bind time, always can't found mipi panel.
Signed-off-by: Mark Yao
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 57 +++---
1 file changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 5e3f031..4ec82f6 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -551,11 +551,9 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host
*host,
dsi->panel = of_drm_find_panel(device->dev.of_node);
if (!dsi->panel) {
DRM_ERROR("failed to find panel\n");
- return -EPROBE_DEFER;
+ return -ENODEV;
}
- drm_panel_attach(dsi->panel, &dsi->connector);
-
return 0;
}
@@ -567,6 +565,7 @@ static int dw_mipi_dsi_host_detach(struct mipi_dsi_host
*host,
if (dsi->panel)
drm_panel_detach(dsi->panel);
+ dsi->panel = NULL;
return 0;
}
@@ -1048,6 +1047,8 @@ static int dw_mipi_dsi_register(struct drm_device *drm,
&dw_mipi_dsi_atomic_connector_funcs,
DRM_MODE_CONNECTOR_DSI);
+ drm_panel_attach(dsi->panel, &dsi->connector);
+
drm_mode_connector_attach_encoder(connector, encoder);
return 0;
@@ -1097,23 +1098,17 @@ MODULE_DEVICE_TABLE(of, dw_mipi_dsi_dt_ids);
static int dw_mipi_dsi_bind(struct device *dev, struct device *master,
void *data)
{
- const struct of_device_id *of_id =
- of_match_device(dw_mipi_dsi_dt_ids, dev);
- const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
struct platform_device *pdev = to_platform_device(dev);
struct drm_device *drm = data;
- struct dw_mipi_dsi *dsi;
+ struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
struct resource *res;
int ret;
- dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
- if (!dsi)
- return -ENOMEM;
-
- dsi->dev = dev;
- dsi->pdata = pdata;
dsi->dpms_mode = DRM_MODE_DPMS_OFF;
+ if (!dsi->panel)
+ return -EPROBE_DEFER;
+
ret = rockchip_mipi_parse_dt(dsi);
if (ret)
return ret;
@@ -1160,9 +1155,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct
device *master,
pm_runtime_enable(dev);
- dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
- dsi->dsi_host.dev = dev;
- return mipi_dsi_host_register(&dsi->dsi_host);
+ return 0;
err_pllref:
clk_disable_unprepare(dsi->pllref_clk);
@@ -1174,7 +1167,6 @@ static void dw_mipi_dsi_unbind(struct device *dev, struct
device *master,
{
struct dw_mipi_dsi *dsi = dev_get_drvdata(dev);
- mipi_dsi_host_unregister(&dsi->dsi_host);
pm_runtime_disable(dev);
clk_disable_unprepare(dsi->pllref_clk);
}
@@ -1186,11 +1178,40 @@ static const struct component_ops dw_mipi_dsi_ops = {
static int dw_mipi_dsi_probe(struct platform_device *pdev)
{
- return component_add(&pdev->dev, &dw_mipi_dsi_ops);
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *of_id =
+ of_match_device(dw_mipi_dsi_dt_ids, dev);
+ const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
+ struct dw_mipi_dsi *dsi;
+ int ret;
+
+ dsi = devm_kzalloc(&pdev->dev, sizeof(*dsi), GFP_KERNEL);
+ if (!dsi)
+ return -ENOMEM;
+
+ dsi->dev = dev;
+ dsi->pdata = pdata;
+ dsi->dsi_host.ops = &dw_mipi_dsi_host_ops;
+ dsi->dsi_host.dev = &pdev->dev;
+
+ ret = mipi_dsi_host_register(&dsi->dsi_host);
+ if (ret)
+ return ret;
+
+ platform_set_drvdata(pdev, dsi);
+ ret = component_add(&pdev->dev, &dw_mipi_dsi_ops);
+ if (ret)
+ mipi_dsi_host_unregister(&dsi->dsi_host);
+
+ return ret;
}
static int dw_mipi_dsi_remove(struct platform_device *pdev)
{
+ struct dw_mipi_dsi *dsi = dev_get_drvdata(&pdev->dev);
+
+ if (dsi)
+ mipi_dsi_host_unregister(&dsi->dsi_host);
component_del(&pdev->dev, &dw_mipi_dsi_ops);
return 0;
}
--
2.6.3
[PATCH v2 03/11] drm/rockchip/dsi: remove mode_valid function
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 04fd595..8f8d48a 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -276,8 +276,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -978,23 +976,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1065,33 +1048,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
Re: [Intel-gfx] [PATCH v4] lib/scatterlist: Avoid potential scatterlist entry overflow
On Mon, Jan 16, 2017 at 12:05 PM, Tvrtko Ursulin
wrote:
> - for (i = 1; i < n_pages; ++i)
> + for (i = 1; i < n_pages; ++i) {
// Are compilers so stupid doing calculation per iteration in
for-conditional?
// for (i = 0; i + 1 < n_pages; i++) ?
>>> I didn't get what you meant here?
>> Why do we start from 1? I see here two micro (?) optimizations:
>> 1) starting from 1 on believe that compiler dumb enough to every time
>> do a calculation in condition;
> The existing code starts from 1 because the pfn condition looks up page i -
> 1. I don't feel there is a need to change that as well.
>> 2) ++i instead of i++, but this is just matter of style, it's not a c++.
> Note that I haven't changed the existing code in this respect. I am happy to
> change it though.
Yes, this is another story. Just a side note to existing code, indeed.
--
With Best Regards,
Andy Shevchenko
[PATCH] thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL
Currently when CPU_THERMAL is not defined the thermal sensors are not even exposed consequently no cooling is possible. CPU_THERMAL eventually depends on CPUFREQ. CPPUFREQ is not the only cooling for CPU. The thermal shutdown for critical temperatures is another cooling solution which will currently not get enabled if CPU_THERMAL is not defined. Remove this dependency so as to have the last level of thermal protection working even without CPUFREQ defined. Signed-off-by: Keerthy --- drivers/thermal/ti-soc-thermal/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/thermal/ti-soc-thermal/Kconfig b/drivers/thermal/ti-soc-thermal/Kconfig index ea8283f..fe0e877 100644 --- a/drivers/thermal/ti-soc-thermal/Kconfig +++ b/drivers/thermal/ti-soc-thermal/Kconfig @@ -11,7 +11,6 @@ config TI_SOC_THERMAL config TI_THERMAL bool "Texas Instruments SoCs thermal framework support" depends on TI_SOC_THERMAL - depends on CPU_THERMAL help If you say yes here you want to get support for generic thermal framework for the Texas Instruments on die bandgap temperature sensor. -- 1.9.1
Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
On Mon, Jan 16, 2017 at 12:09:30PM +0200, Leon Romanovsky wrote: > And doesn't dump_stack do the same? It pollutes the log too. It is not about polluting the log - it is about tainting. __warn()->add_taint(taint, LOCKDEP_STILL_OK); -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 03/10] devicetree: bindings: add bindings for ahci-da850
2017-01-13 20:25 GMT+01:00 David Lechner : > On 01/13/2017 06:37 AM, Bartosz Golaszewski wrote: >> >> Add DT bindings for the TI DA850 AHCI SATA controller. >> >> Signed-off-by: Bartosz Golaszewski >> --- >> .../devicetree/bindings/ata/ahci-da850.txt | 21 >> + >> 1 file changed, 21 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/ata/ahci-da850.txt >> >> diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt >> b/Documentation/devicetree/bindings/ata/ahci-da850.txt >> new file mode 100644 >> index 000..d07c241 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt >> @@ -0,0 +1,21 @@ >> +Device tree binding for the TI DA850 AHCI SATA Controller >> +- >> + >> +Required properties: >> + - compatible: must be "ti,da850-ahci" >> + - reg: physical base addresses and sizes of the controller's register >> areas >> + - interrupts: interrupt specifier (refer to the interrupt binding) >> + >> +Optional properties: >> + - clocks: clock specifier (refer to the common clock binding) >> + - da850,clk_multiplier: the multiplier for the reference clock needed >> + for 1.5GHz PLL output > > > A clock multiplier property seems redundant if you are specifying a clock. > It should be possible to get the rate from the clock to determine which > multiplier is needed. > I probably should have named it differently. This is not a multiplier of a clock derived from PLL0 or PLL1. Instead it's a value set by writing to the Port PHY Control Register (MPY bits) of the SATA controller that configures the multiplier for the external low-jitter clock. On the lcdk the signals (REFCLKP, REFCLKN) are provided by CDCM61001 (SATA OSCILLATOR component on the schematics). I'll find a better name and comment the property accordingly. FYI: the da850 platform does not use the common clock framework, so I don't specify the clock property on the sata node in the device tree. Instead I add the clock lookup entry in patch [01/10]. This is transparent for AHCI which can get the clock as usual by calling clk_get() in ahci_platform_get_resources(). Thanks, Bartosz Golaszewski
Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
+ Joao, Jingoo Hi, On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote: > Hi Kishon, > >> Hi Łukasz, >> >> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote: >>> Hi Kishon, >>> Hi, On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote: > Some devices (due to e.g. bad PCIe signal integrity) require to > run with forced GEN1 speed on PCIe bus. > > This patch changes the speed explicitly on dra7 based devices when > proper device tree attribute is defined for the PCIe controller. > > Signed-off-by: Lukasz Majewski Bjorn has already queued a patch to do the same thing https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-dra7xx >>> >>> It seems like Bjorn only modifies CAP registers. >> >> The patch also modifies the LNKCTL2 register. >>> >>> He also needs to change register with 0x080C offset to actually >>> ( PCIECTRL_PL_WIDTH_SPEED_CTL ) >> >> This bit is used to initiate speed change (after the link is >> initialized in GEN1). Resetting the bit (like what you have done >> here) prevents speed change. > > This is strange, but e2e advised me to do things as I did in the patch > to _force_ GEN1 operation on PCIe2 port [1] (AM5728) > > Link: > [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/566421 > > Both patches modify 0x5180 007C register to set GEN1 capability > (PCI_EXP_LNKCAP_SLS_2_5GB) > > The problem is with second register (in your patch): > > From SPRUHZ6G TRM: > > PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0) > - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more > description in TRM > > It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as > default /reset value. The default value is 0x2 (or else none of the cards would have enumerated in GEN2) > > > Could you clarify which way to _force_ PCIe GEN1 operation is correct? > Mine shows differences in lspci output (as posted in [1]). You'll see the difference even with the patch in Bjorn's tree ;-) I think these are 2 different approaches to keep the link at GEN1. Joao or Jingoo, do you have any suggestion here? > >> >> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking >> the IP register. > > From the original patch description: > > "Add support to force Root Complex to work in GEN1 mode if so desired, > but don't force GEN1 mode on any board just yet." > > Are there any (floating around) patches allowing forcing GEN1 operation > on any board (I would like to reuse/port them to my current solution)? For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt with the patch in Bjorn's tree. Thanks Kishon
Re: [PATCH 06/10] sata: ahci_da850: implement a softreset quirk
2017-01-16 0:12 GMT+01:00 Tejun Heo :
> On Fri, Jan 13, 2017 at 01:38:00PM +0100, Bartosz Golaszewski wrote:
>> +static int ahci_da850_softreset(struct ata_link *link,
>> + unsigned int *class, unsigned long deadline)
>> +{
>> + int pmp, ret;
>> +
>> + pmp = sata_srst_pmp(link);
>> +
>> + ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
>> + if (pmp && ret == -EBUSY)
>> + return ahci_do_softreset(link, class, 0,
>> + deadline, ahci_check_ready);
>> +
>> + return ret;
>> +}
>
> Please add some comments explaining what's going on.
Sure, I'll add some explanation in v2.
Thanks,
Bartosz Golaszewski
