Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management
Hi Hans, On 12/05/2016 01:25 PM, Hans Verkuil wrote: > On 12/01/2016 10:03 AM, Stanimir Varbanov wrote: >> this add functions for: >> - remove buffers from src/dst queue by index >> - remove exact buffer from src/dst queue >> >> also extends m2m API to iterate over a list of src/dst buffers >> in safely and non-safely manner. >> >> Signed-off-by: Stanimir Varbanov >> --- >> drivers/media/v4l2-core/v4l2-mem2mem.c | 37 +++ >> include/media/v4l2-mem2mem.h | 83 >> ++ >> 2 files changed, 120 insertions(+) >> >> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c >> b/drivers/media/v4l2-core/v4l2-mem2mem.c >> index 6bc27e7b2a33..d689e7bb964f 100644 >> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c >> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c >> @@ -126,6 +126,43 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx >> *q_ctx) >> } >> EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove); >> >> +void v4l2_m2m_buf_remove_exact(struct v4l2_m2m_queue_ctx *q_ctx, >> + struct vb2_v4l2_buffer *vbuf) > > I'd call this v4l2_m2m_buf_remove_by_buf to be consistent with _by_idx. Thanks, I will rename it. -- regards, Stan
Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
On Mon, Dec 05, 2016 at 01:12:25PM +0100, Benjamin Gaignard wrote: > 2016-12-05 12:23 GMT+01:00 Thierry Reding : > > On Mon, Dec 05, 2016 at 12:08:32PM +0100, Benjamin Gaignard wrote: > >> 2016-12-05 7:53 GMT+01:00 Thierry Reding : > >> > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote: > >> >> Define bindings for pwm-stm32 > >> >> > >> >> version 2: > >> >> - use parameters instead of compatible of handle the hardware > >> >> configuration > >> >> > >> >> Signed-off-by: Benjamin Gaignard > >> >> --- > >> >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 > >> >> ++ > >> >> 1 file changed, 38 insertions(+) > >> >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> >> > >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> >> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> >> new file mode 100644 > >> >> index 000..575b9fb > >> >> --- /dev/null > >> >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> >> @@ -0,0 +1,38 @@ > >> >> +STMicroelectronics PWM driver bindings for STM32 > >> > > >> > Technically this bindings describe devices, so "driver binding" is a > >> > somewhat odd wording. Perhaps: > >> > > >> > STMicroelectronics STM32 General Purpose Timer PWM bindings > >> > > >> > ? > >> done > >> > >> > > >> >> + > >> >> +Must be a sub-node of STM32 general purpose timer driver > >> >> +Parent node properties are describe in > >> >> ../mfd/stm32-general-purpose-timer.txt > >> > > >> > Again, "driver parent node" is odd. Perhaps: > >> > > >> > Must be a sub-node of an STM32 General Purpose Timer device tree > >> > node. See ../mfd/stm32-general-purpose-timer.txt for details > >> > about > >> > the parent node. > >> > > >> > ? > >> > >> done > >> > >> > > >> >> +Required parameters: > >> >> +- compatible:Must be "st,stm32-pwm" > >> >> +- pinctrl-names: Set to "default". > >> >> +- pinctrl-0: List of phandles pointing to pin > >> >> configuration nodes > >> >> + for PWM module. > >> >> + For Pinctrl properties, please refer to [1]. > >> > > >> > Your indentation and capitalization are inconsistent. Also, please refer > >> > to the pinctrl bindings by relative path and inline, rather than as a > >> > footnote reference. > >> > >> OK > >> > >> > > >> >> + > >> >> +Optional parameters: > >> >> +- st,breakinput: Set if the hardware have break input capabilities > >> >> +- st,breakinput-polarity: Set break input polarity. Default is 0 > >> >> + The value define the active polarity: > >> >> + - 0 (active LOW) > >> >> + - 1 (active HIGH) > >> > > >> > Could we fold these into a single property? If st,breakinput-polarity is > >> > not present it could simply mean that there is no break input, and if it > >> > is present you don't have to rely on a default. > >> > >> I need to know if I have to activate breakinput feature and on which level > >> I will rewrite it like that: > >> Optional parameters: > >> - st,breakinput-polarity-high: Set if break input polarity is active > >> on high level. > >> - st,breakinput-polarity-high: Set if break input polarity is active > >> on low level. > > > > How is that different from a single property: > > > > Optional properties: > > - st,breakinput-polarity: If present, a break input is available > > for the channel. In that case the property value denotes the > > polarity of the break input: > > - 0: active low > > - 1: active high > > > > ? > > For break input feature I need two information: do I have to active it > and if activated > on which level. > I have two solutions: > - one parameter with a value (0 or 1) -> st,breakinput-polarity > - two parameters without value -> st,breakinput-active-high and > st,breakinput-active-low > > By default break input feature is disabled Right, what I was suggesting is that you use the first solution because it's the typical way to use for tristate options. It's also much easier to test for in practice because for the second solution you have to parse two properties before you know whether it is active or not. The second is typically the solution for required properties where only one of the properties is used to override the default. Thierry signature.asc Description: PGP signature
Re: [tpmdd-devel] [PATCH v2 1/3] tpm_crb: map locality registers
On Mon, Dec 05, 2016 at 12:07:51PM +, Winkler, Tomas wrote:
> > > ---
> > > drivers/char/tpm/tpm_crb.c | 96
> > > ++
> > > 1 file changed, 64 insertions(+), 32 deletions(-)
> > >
> > > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > > index 717b6b4..8d81b66 100644
> > > --- a/drivers/char/tpm/tpm_crb.c
> > > +++ b/drivers/char/tpm/tpm_crb.c
> > > @@ -52,18 +52,28 @@ enum crb_cancel {
> > > CRB_CANCEL_INVOKE = BIT(0),
> > > };
> > >
> > > -struct crb_control_area {
> > > - u32 req;
> > > - u32 sts;
> > > - u32 cancel;
> > > - u32 start;
> > > - u32 int_enable;
> > > - u32 int_sts;
> > > - u32 cmd_size;
> > > - u32 cmd_pa_low;
> > > - u32 cmd_pa_high;
> > > - u32 rsp_size;
> > > - u64 rsp_pa;
> > > +struct crb_regs_head {
> > > + u32 loc_state;
> > > + u32 reserved1;
> > > + u32 loc_ctrl;
> > > + u32 loc_sts;
> > > + u8 reserved2[32];
> > > + u64 intf_id;
> > > + u64 ctrl_ext;
> > > +} __packed;
> > > +
> > > +struct crb_regs_tail {
> > > + u32 ctrl_req;
> > > + u32 ctrl_sts;
> > > + u32 ctrl_cancel;
> > > + u32 ctrl_start;
> > > + u32 ctrl_int_enable;
> > > + u32 ctrl_int_sts;
> > > + u32 ctrl_cmd_size;
> > > + u32 ctrl_cmd_pa_low;
> > > + u32 ctrl_cmd_pa_high;
> > > + u32 ctrl_rsp_size;
> > > + u64 ctrl_rsp_pa;
> > > } __packed;
>
>
> Now I wonder if using traditional offsets wouldn't be cleaner solution.
I'm not sure what you are trying to say.
> > > enum crb_status {
> > > @@ -78,7 +88,8 @@ enum crb_flags {
> > > struct crb_priv {
> > > unsigned int flags;
> > > void __iomem *iobase;
> > > - struct crb_control_area __iomem *cca;
> > > + struct crb_regs_head __iomem *regs_h;
> > > + struct crb_regs_tail __iomem *regs_t;
> Why just not leaving it cca, it's descriptive enough.
> > > u8 __iomem *cmd;
> > > u8 __iomem *rsp;
> > > u32 cmd_size;
> > > @@ -104,7 +115,7 @@ static int __maybe_unused crb_go_idle(struct device
> > *dev, struct crb_priv *priv)
> > > if (priv->flags & CRB_FL_ACPI_START)
> > > return 0;
> > >
> > > - iowrite32(CRB_CTRL_REQ_GO_IDLE, &priv->cca->req);
> > > + iowrite32(CRB_CTRL_REQ_GO_IDLE, &priv->regs_t->ctrl_req);
> > > /* we don't really care when this settles */
> > >
> > > return 0;
> > > @@ -128,21 +139,23 @@ static int __maybe_unused crb_cmd_ready(struct
> > device *dev,
> > > struct crb_priv *priv)
> > > {
> > > ktime_t stop, start;
> > > + u32 req;
> > >
> > > if (priv->flags & CRB_FL_ACPI_START)
> > > return 0;
> > >
> > > - iowrite32(CRB_CTRL_REQ_CMD_READY, &priv->cca->req);
> > > + iowrite32(CRB_CTRL_REQ_CMD_READY, &priv->regs_t->ctrl_req);
> > >
> > > start = ktime_get();
> > > stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
> > > do {
> > > - if (!(ioread32(&priv->cca->req) &
> > CRB_CTRL_REQ_CMD_READY))
> > > + req = ioread32(&priv->regs_t->ctrl_req);
> > > + if (!(req & CRB_CTRL_REQ_CMD_READY))
> > > return 0;
> > > usleep_range(50, 100);
> > > } while (ktime_before(ktime_get(), stop));
> > >
> > > - if (ioread32(&priv->cca->req) & CRB_CTRL_REQ_CMD_READY) {
> > > + if (ioread32(&priv->regs_t->ctrl_req) & CRB_CTRL_REQ_CMD_READY)
> > {
> > > dev_warn(dev, "cmdReady timed out\n");
> > > return -ETIME;
> > > }
> > > @@ -155,7 +168,7 @@ static u8 crb_status(struct tpm_chip *chip)
> > > struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > > u8 sts = 0;
> > >
> > > - if ((ioread32(&priv->cca->start) & CRB_START_INVOKE) !=
> > > + if ((ioread32(&priv->regs_t->ctrl_start) & CRB_START_INVOKE) !=
> > > CRB_START_INVOKE)
> > > sts |= CRB_DRV_STS_COMPLETE;
> > >
> > > @@ -171,7 +184,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> > size_t count)
> > > if (count < 6)
> > > return -EIO;
> > >
> > > - if (ioread32(&priv->cca->sts) & CRB_CTRL_STS_ERROR)
> > > + if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > > return -EIO;
> > >
> > > memcpy_fromio(buf, priv->rsp, 6);
> > > @@ -210,7 +223,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf,
> > size_t len)
> > > /* Zero the cancel register so that the next command will not get
> > >* canceled.
> > >*/
> > > - iowrite32(0, &priv->cca->cancel);
> > > + iowrite32(0, &priv->regs_t->ctrl_cancel);
> > >
> > > if (len > priv->cmd_size) {
> > > dev_err(&chip->dev, "invalid command count value %zd %d\n",
> > @@
> > > -224,7 +237,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf,
> > > size_t
> > len)
> > > wmb();
> > >
> > > if (priv->flags & CRB_FL_CRB_START)
> > > - iowrite32(CRB_START_INVOKE, &priv->cca->start);
> > > + iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> > >
> > > if (priv->flags & CRB_FL_ACPI_START)
> > > rc = crb_do_acpi_start(chip);
> > > @@ -236,7 +249,7 @@ static void crb_cancel(struct tpm_chip *chip) {
> > > struct crb_priv
Re: [PATCH v4 8/9] media: venus: hfi: add Venus HFI files
Hi Hans,
On 12/05/2016 02:05 PM, Hans Verkuil wrote:
> On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
>> Here is the implementation of Venus video accelerator low-level
>> functionality. It contanins code which setup the registers and
>> startup uthe processor, allocate and manipulates with the shared
>> memory used for sending commands and receiving messages.
>>
>> Signed-off-by: Stanimir Varbanov
>> ---
>> drivers/media/platform/qcom/venus/hfi_venus.c| 1508
>> ++
>> drivers/media/platform/qcom/venus/hfi_venus.h| 23 +
>> drivers/media/platform/qcom/venus/hfi_venus_io.h | 98 ++
>> 3 files changed, 1629 insertions(+)
>> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
>> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
>> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h
>>
>> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
>> b/drivers/media/platform/qcom/venus/hfi_venus.c
>> new file mode 100644
>> index ..f004a9a80d85
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
>> @@ -0,0 +1,1508 @@
>> +static int venus_tzbsp_set_video_state(enum tzbsp_video_state state)
>> +{
>> +return qcom_scm_video_set_state(state, 0);
>
> This functions doesn't seem to exist. Is there a prerequisite patch series
> that
> introduces this function?
yes, the patchset [1] is under review.
--
regards,
Stan
[1] https://lkml.org/lkml/2016/11/7/533
Re: [PATCH 2/2] driver core: Silence device links sphinx warning
Em Sun, 4 Dec 2016 13:10:04 +0100
Lukas Wunner escreveu:
> Silence this warning emitted by sphinx:
> include/linux/device.h:938: warning: No description found for parameter
> 'links'
>
> While at it, fix typos in comments of device links code.
>
> Cc: Rafael J. Wysocki
> Cc: Greg Kroah-Hartman
> Cc: Jonathan Corbet
> Cc: Silvio Fricke
> Signed-off-by: Lukas Wunner
> ---
> drivers/base/core.c| 4 ++--
> include/linux/device.h | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index d0c9df5..8c25e68 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -172,7 +172,7 @@ static int device_reorder_to_tail(struct device *dev,
> void *not_used)
> *
> * The supplier device is required to be registered when this function is
> called
> * and NULL will be returned if that is not the case. The consumer device
> need
> - * not be registerd, however.
> + * not be registered, however.
> */
> struct device_link *device_link_add(struct device *consumer,
> struct device *supplier, u32 flags)
> @@ -225,7 +225,7 @@ struct device_link *device_link_add(struct device
> *consumer,
> INIT_LIST_HEAD(&link->c_node);
> link->flags = flags;
>
> - /* Deterine the initial link state. */
> + /* Determine the initial link state. */
> if (flags & DL_FLAG_STATELESS) {
> link->status = DL_STATE_NONE;
> } else {
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 3896af4..87edfdf 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -813,6 +813,7 @@ struct dev_links_info {
> * on. This shrinks the "Board Support Packages" (BSPs) and
> * minimizes board-specific #ifdefs in drivers.
> * @driver_data: Private pointer for driver specific info.
> + * @links: Links to suppliers and consumers of this device.
> * @power: For device power management.
> * See Documentation/power/admin-guide/devices.rst for details.
> * @pm_domain: Provide callbacks that are executed during system
> suspend,
Hmm... I'm not seeing "links" at driver-core-next:
https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git/tree/include/linux/device.h?h=driver-core-next
On what tree did you base this patch?
--
Thanks,
Mauro
Re: usb/gadget: GPF in usb_gadget_unregister_driver
On Sat, Dec 3, 2016 at 6:31 PM, Felix Hädicke wrote: > Hi, >> Hi! >> >> I've got the following error report while running the syzkaller fuzzer. >> >> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). >> >> general protection fault: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> task: 88006cd0db40 task.stack: 88006a05 >> RIP: 0010:[] [] >> __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP: 0018:88006a056ea8 EFLAGS: 00010246 >> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8 >> RDX: RSI: 88006cd0e340 RDI: 860cead0 >> RBP: 88006a056f38 R08: R09: >> R10: 0006 R11: R12: >> R13: R14: 860cea00 R15: 88006a056f10 >> FS: () GS:88003ec0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0 >> Stack: >> 859785e0 41b58ab3 8593717a 8201a9d0 >> 11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338 >> 0a06 11000d40ade4 88006cd0e340 >> Call Trace: >> [] list_del+0xd/0x70 lib/list_debug.c:77 >> [] usb_gadget_unregister_driver+0x120/0x240 >> drivers/usb/gadget/udc/core.c:1365 >> [] dev_release+0x80/0x160 >> drivers/usb/gadget/legacy/inode.c:1187 >> [] __fput+0x332/0x7f0 fs/file_table.c:208 >> [] fput+0x15/0x20 fs/file_table.c:244 >> [] task_work_run+0x19b/0x270 kernel/task_work.c:116 >> [< inline >] exit_task_work include/linux/task_work.h:21 >> [] do_exit+0x16aa/0x2530 kernel/exit.c:828 >> [] do_group_exit+0x149/0x420 kernel/exit.c:932 >> [] get_signal+0x76d/0x17b0 kernel/signal.c:2307 >> [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807 >> [] exit_to_usermode_loop+0x170/0x200 >> arch/x86/entry/common.c:156 >> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 >> [] syscall_return_slowpath+0x3d3/0x420 >> arch/x86/entry/common.c:259 >> [] entry_SYSCALL_64_fastpath+0xc0/0xc2 >> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f >> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> >> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00 >> RIP [] __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP >> ---[ end trace 883f708e6720200f ]--- >> Kernel panic - not syncing: Fatal exception >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Kernel Offset: disabled >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Looks similar to the oops which I had reported a few days ago. See mail > "PROBLEM: Oops when unbinding an inactive gadget configfs configuration > from UDC". Maybe you want to test my bugfix proposal "usb: gadget: udc: > core: fix return code of usb_gadget_probe_driver()". Hi Felix, Looks quite similar, but your patch doesn't help in my case. Thanks! > > Regards, > Felix >
Re: usb/gadget: GPF in usb_gadget_unregister_driver
On Sat, Dec 3, 2016 at 6:13 PM, Greg Kroah-Hartman wrote: > On Sat, Dec 03, 2016 at 05:36:35PM +0100, Andrey Konovalov wrote: >> Hi! >> >> I've got the following error report while running the syzkaller fuzzer. >> >> On commit 3c49de52d5647cda8b42c4255cf8a29d1e22eff5 (Dec 2). >> >> general protection fault: [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 10564 Comm: syz-executor0 Not tainted 4.9.0-rc7+ #4 >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 >> task: 88006cd0db40 task.stack: 88006a05 >> RIP: 0010:[] [] >> __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP: 0018:88006a056ea8 EFLAGS: 00010246 >> RAX: dc00 RBX: 11000d40add6 RCX: 860ceac8 >> RDX: RSI: 88006cd0e340 RDI: 860cead0 >> RBP: 88006a056f38 R08: R09: >> R10: 0006 R11: R12: >> R13: R14: 860cea00 R15: 88006a056f10 >> FS: () GS:88003ec0() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 2000d000 CR3: 05c1d000 CR4: 06f0 >> Stack: >> 859785e0 41b58ab3 8593717a 8201a9d0 >> 11000d40ade0 88006cd0db40 817e5a3c 88006cd0e338 >> 0a06 11000d40ade4 88006cd0e340 >> Call Trace: >> [] list_del+0xd/0x70 lib/list_debug.c:77 >> [] usb_gadget_unregister_driver+0x120/0x240 >> drivers/usb/gadget/udc/core.c:1365 >> [] dev_release+0x80/0x160 >> drivers/usb/gadget/legacy/inode.c:1187 >> [] __fput+0x332/0x7f0 fs/file_table.c:208 >> [] fput+0x15/0x20 fs/file_table.c:244 >> [] task_work_run+0x19b/0x270 kernel/task_work.c:116 >> [< inline >] exit_task_work include/linux/task_work.h:21 >> [] do_exit+0x16aa/0x2530 kernel/exit.c:828 >> [] do_group_exit+0x149/0x420 kernel/exit.c:932 >> [] get_signal+0x76d/0x17b0 kernel/signal.c:2307 >> [] do_signal+0xd2/0x2120 arch/x86/kernel/signal.c:807 >> [] exit_to_usermode_loop+0x170/0x200 >> arch/x86/entry/common.c:156 >> [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 >> [] syscall_return_slowpath+0x3d3/0x420 >> arch/x86/entry/common.c:259 >> [] entry_SYSCALL_64_fastpath+0xc0/0xc2 >> Code: c5 0f 84 e2 00 00 00 48 b8 00 02 00 00 00 00 ad de 49 39 c4 0f >> 84 ec 00 00 00 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> >> 3c 02 00 0f 85 35 01 00 00 4d 8b 04 24 49 39 c8 0f 85 e1 00 >> RIP [] __list_del_entry+0xce/0x280 lib/list_debug.c:57 >> RSP >> ---[ end trace 883f708e6720200f ]--- >> Kernel panic - not syncing: Fatal exception >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Kernel Offset: disabled > > Any hints as to what you were doing when this happend? Hi Greg, I was running a fuzzer that mounts gadgetfs and concurrently writes garbage to /dev/gadget/dummy_udc. I'll see if I can reproduce it. Thanks! > > thanks, > > greg k-h
[PATCH] mfd: axp20x: correct a typo in axp20x_device_remove documentation
The documentation of axp20x_device_remove() have a typo and use axp20x_device_probe() as name. This patch fix this typo. Signed-off-by: Corentin Labbe --- include/linux/mfd/axp20x.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h index 476eb64..73ab982 100644 --- a/include/linux/mfd/axp20x.h +++ b/include/linux/mfd/axp20x.h @@ -605,7 +605,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x); int axp20x_device_probe(struct axp20x_dev *axp20x); /** - * axp20x_device_probe(): Remove a axp20x device + * axp20x_device_remove(): Remove a axp20x device * * @axp20x: axp20x device to remove * -- 2.7.3
[PATCH 5/5] docs: 00-INDEX: document directories/files with no docs
There are a number of files/directories that don't contain any documentation. They're related to ReST file conversion. As a matter of completeness, since Makefile is also documented there, add an entry for those files too. Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 19 +++ 1 file changed, 19 insertions(+) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 272f5c4481f1..6d488509285d 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -14,6 +14,8 @@ Following translations are available on the WWW: - this file. ABI/ - info on kernel <-> userspace ABI and relative interface stability. +CodingStyle + - nothing here, just a pointer to process/coding-style.rst. DMA-API.txt - DMA API, pci_ API & extensions for non-consistent memory machines. DMA-API-HOWTO.txt @@ -39,6 +41,9 @@ Intel-IOMMU.txt Makefile - This file does nothing. Removing it breaks make htmldocs and make distclean. +Makefile.sphinx + - This file does nothing. Removing it breaks make htmldocs and + make distclean. PCI/ - info related to PCI drivers. RCU/ @@ -47,6 +52,8 @@ SAK.txt - info on Secure Attention Keys. SM501.txt - Silicon Motion SM501 multimedia companion chip +SubmittingPatches + - nothing here, just a pointer to process/coding-style.rst. accounting/ - documentation on accounting and taskstats. acpi/ @@ -93,6 +100,8 @@ clk.txt - info on the common clock framework cma/ - Continuous Memory Area (CMA) debugfs interface. +conf.py + - nothing here. Just a configuration file for Sphinx. connector/ - docs on the netlink based userspace<->kernel space communication mod. console/ @@ -135,6 +144,8 @@ digsig.txt -info on the Digital Signature Verification API dma-buf-sharing.txt - the DMA Buffer Sharing API Guide +docutils.conf + - nothing here. Just a configuration file for docutils. dontdiff - file containing a list of files that should never be diff'ed. driver-api/ @@ -201,6 +212,8 @@ ide/ - Information regarding the Enhanced IDE drive. iio/ - info on industrial IIO configfs support. +index.rst + - main index for the documentation at ReST format. infiniband/ - directory with documents concerning Linux InfiniBand support. input/ @@ -307,6 +320,8 @@ nvdimm/ - info on non-volatile devices. nvmem/ - info on non volatile memory framework. +output/ + - default directory where html/LaTeX/pdf files will be written. padata.txt - An introduction to the "padata" parallel execution API parisc/ @@ -387,6 +402,10 @@ sound/ - directory with info on sound card support. spi/ - overview of Linux kernel Serial Peripheral Interface (SPI) support. +sphinx/ + - no doumentation here, just files required by Sphinx toolchain. +sphinx-static/ + - no doumentation here, just files required by Sphinx toolchain. static-keys.txt - info on how static keys allow debug code in hotpaths via patching svga.txt -- 2.9.3
Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
2016-12-05 12:23 GMT+01:00 Thierry Reding : > On Mon, Dec 05, 2016 at 12:08:32PM +0100, Benjamin Gaignard wrote: >> 2016-12-05 7:53 GMT+01:00 Thierry Reding : >> > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote: >> >> Define bindings for pwm-stm32 >> >> >> >> version 2: >> >> - use parameters instead of compatible of handle the hardware >> >> configuration >> >> >> >> Signed-off-by: Benjamin Gaignard >> >> --- >> >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 >> >> ++ >> >> 1 file changed, 38 insertions(+) >> >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> >> >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> >> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> >> new file mode 100644 >> >> index 000..575b9fb >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> >> @@ -0,0 +1,38 @@ >> >> +STMicroelectronics PWM driver bindings for STM32 >> > >> > Technically this bindings describe devices, so "driver binding" is a >> > somewhat odd wording. Perhaps: >> > >> > STMicroelectronics STM32 General Purpose Timer PWM bindings >> > >> > ? >> done >> >> > >> >> + >> >> +Must be a sub-node of STM32 general purpose timer driver >> >> +Parent node properties are describe in >> >> ../mfd/stm32-general-purpose-timer.txt >> > >> > Again, "driver parent node" is odd. Perhaps: >> > >> > Must be a sub-node of an STM32 General Purpose Timer device tree >> > node. See ../mfd/stm32-general-purpose-timer.txt for details about >> > the parent node. >> > >> > ? >> >> done >> >> > >> >> +Required parameters: >> >> +- compatible:Must be "st,stm32-pwm" >> >> +- pinctrl-names: Set to "default". >> >> +- pinctrl-0: List of phandles pointing to pin >> >> configuration nodes >> >> + for PWM module. >> >> + For Pinctrl properties, please refer to [1]. >> > >> > Your indentation and capitalization are inconsistent. Also, please refer >> > to the pinctrl bindings by relative path and inline, rather than as a >> > footnote reference. >> >> OK >> >> > >> >> + >> >> +Optional parameters: >> >> +- st,breakinput: Set if the hardware have break input capabilities >> >> +- st,breakinput-polarity: Set break input polarity. Default is 0 >> >> + The value define the active polarity: >> >> + - 0 (active LOW) >> >> + - 1 (active HIGH) >> > >> > Could we fold these into a single property? If st,breakinput-polarity is >> > not present it could simply mean that there is no break input, and if it >> > is present you don't have to rely on a default. >> >> I need to know if I have to activate breakinput feature and on which level >> I will rewrite it like that: >> Optional parameters: >> - st,breakinput-polarity-high: Set if break input polarity is active >> on high level. >> - st,breakinput-polarity-high: Set if break input polarity is active >> on low level. > > How is that different from a single property: > > Optional properties: > - st,breakinput-polarity: If present, a break input is available > for the channel. In that case the property value denotes the > polarity of the break input: > - 0: active low > - 1: active high > > ? For break input feature I need two information: do I have to active it and if activated on which level. I have two solutions: - one parameter with a value (0 or 1) -> st,breakinput-polarity - two parameters without value -> st,breakinput-active-high and st,breakinput-active-low By default break input feature is disabled > >> > The pwm- prefix is rather redundant since the node is already named pwm. >> > Why not simply st,channels? Or simply channels, since it's not really >> > anything specific to this hardware. >> > >> > Come to think of it, might be worth having a discussion with our DT >> > gurus about what their stance is on using the # as prefix for numbers >> > (such as in #address-cells or #size-cells). This could be #channels to >> > mark it more explicitly as representing a count. >> > >> >> +- st,32bits-counter: Set if the hardware have a 32 bits counter >> >> +- st,complementary: Set if the hardware have complementary output >> >> channels >> > >> > "hardware has" and also maybe mention explicitly that this is a boolean >> > property. Otherwise people might be left wondering what it should be set >> > to. Or maybe word this differently to imply that it's boolean: >> > >> > - st,32bits-counter: if present, the hardware has a 32 bit counter >> > - st,complementary: if present, the hardware has a complementary >> > output channel >> >> I found a way to detect, at probe time, the number of channels, counter size, >> break input capability and complementary channels so I will remove >
[PATCH 2/5] docs: 00-INDEX: consolidate process/ and admin-guide/ description
Instead of having descriptions for individual files inside the process/ and admin-guide/ documentation, consolidate them into one entry per directory, just like other descriptions inside 00-INDEX. Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 61 -- 1 file changed, 4 insertions(+), 57 deletions(-) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index c08de5574d48..02583a1f409c 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -14,13 +14,6 @@ Following translations are available on the WWW: - this file. ABI/ - info on kernel <-> userspace ABI and relative interface stability. - -admin-guide/bug-hunting.rst - - brute force method of doing binary search of patches to find bug. -process/changes.rst - - list of changes that break older software packages. -process/coding-style.rst - - how the maintainers expect the C code in the kernel to look. DMA-API.txt - DMA API, pci_ API & extensions for non-consistent memory machines. DMA-API-HOWTO.txt @@ -33,8 +26,6 @@ DocBook/ - directory with DocBook templates etc. for kernel documentation. EDID/ - directory with info on customizing EDID for broken gfx/displays. -process/howto.rst - - the process and procedures of how to do Linux kernel development. IPMI.txt - info on Linux Intelligent Platform Management Interface (IPMI) Driver. IRQ-affinity.txt @@ -48,32 +39,22 @@ Intel-IOMMU.txt Makefile - This file does nothing. Removing it breaks make htmldocs and make distclean. -process/management-style.rst - - how to (attempt to) manage kernel hackers. RCU/ - directory with info on RCU (read-copy update). SAK.txt - info on Secure Attention Keys. SM501.txt - Silicon Motion SM501 multimedia companion chip -admin-guide/security-bugs.rst - - procedure for reporting security bugs found in the kernel. -process/submit-checklist.rst - - Linux kernel patch submission checklist. -process/submitting-drivers.rst - - procedure to get a new driver source included into the kernel tree. -process/submitting-patches.rst - - procedure to get a source patch included into the kernel tree. VGA-softcursor.txt - how to change your VGA cursor from a blinking underscore. accounting/ - documentation on accounting and taskstats. acpi/ - info on ACPI-specific hooks in the kernel. +admin-guide/ + - info related to Linux users and system admins. aoe/ - description of AoE (ATA over Ethernet) along with config examples. -process/applying-patches.rst - - description of various trees and how to apply their patches. arm/ - directory with info about Linux on the ARM architecture. arm64/ @@ -86,8 +67,6 @@ auxdisplay/ - misc. LCD driver documentation (cfag12864b, ks0108). backlight/ - directory with info on controlling backlights in flat panel displays -admin-guide/bad-memory.rst - - how to use kernel parameters to exclude bad RAM regions. basic_profiling.txt - basic instructions for those who wants to profile Linux kernel. bcache.txt @@ -152,12 +131,8 @@ debugging-via-ohci1394.txt - how to use firewire like a hardware debugger memory reader. dell_rbu.txt - document demonstrating the use of the Dell Remote BIOS Update driver. -process/ - - how to work with the mainline kernel development process. device-mapper/ - directory with info on Device Mapper. -admin-guide/devices.rst - - plain ASCII listing of all the nodes in /dev/ with major minor #'s. devicetree/ - directory with info on device tree files used by OF/PowerPC/ARM digsig.txt @@ -178,8 +153,6 @@ efi-stub.txt - How to use the EFI boot stub to bypass GRUB or elilo on EFI systems. eisa.txt - info on EISA bus support. -process/email-clients.rst - - info on how to use e-mail to send un-mangled (git) patches. extcon/ - directory with porting guide for Android kernel switch driver. fault-injection/ @@ -226,10 +199,6 @@ ia64/ - directory with info about Linux on Intel 64 bit architecture. infiniband/ - directory with documents concerning Linux InfiniBand support. -admin-guide/init.rst - - what to do when the kernel can't find the 1st process to run. -admin-guide/initrd.rst - - how to use the RAM disk as an initial/temporary root filesystem. input/ - info on Linux input device support. intel_txt.txt @@ -248,20 +217,14 @@ isapnp.txt - info on Linux ISA Plug & Play support. isdn/ - directory with info on the Linux ISDN support, and supported cards. -admin-guide/java.rst - - info on the in-kernel binary support for Java(tm). ja_JP/ - directory with Japanese translations of various documents kbuild/ - directory with info about the kernel build process. kdump/ - dir
[PATCH 3/5] docs: 00-INDEX: add missing entries for documentation files/dirs
Several directories and individual files don't have entries at 00-INDEX. Add them, using, as reference, the initial text inside the documentation file(s). Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 64 ++ 1 file changed, 60 insertions(+), 4 deletions(-) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 02583a1f409c..bd532a7e03e6 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -39,6 +39,8 @@ Intel-IOMMU.txt Makefile - This file does nothing. Removing it breaks make htmldocs and make distclean. +PCI/ + - info related to PCI drivers. RCU/ - directory with info on RCU (read-copy update). SAK.txt @@ -93,12 +95,16 @@ cachetlb.txt - describes the cache/TLB flushing interfaces Linux uses. cdrom/ - directory with information on the CD-ROM drivers that Linux has. -cgroups/ - - cgroups features, including cpusets and memory controller. +cgroup-v1/ + - cgroups v1 features, including cpusets and memory controller. +cgroup-v2.txt + - cgroups v2 features, including cpusets and memory controller. circular-buffers.txt - how to make use of the existing circular buffer infrastructure clk.txt - info on the common clock framework +cma/ + - Continuous Memory Area (CMA) debugfs interface. coccinelle.txt - info on how to get and use the Coccinelle code checking tool. connector/ @@ -131,8 +137,12 @@ debugging-via-ohci1394.txt - how to use firewire like a hardware debugger memory reader. dell_rbu.txt - document demonstrating the use of the Dell Remote BIOS Update driver. +dev-tools/ + - directory with info on development tools for the kernel. device-mapper/ - directory with info on Device Mapper. +dmaengine/ + - the DMA engine and controller API guides. devicetree/ - directory with info on device tree files used by OF/PowerPC/ARM digsig.txt @@ -141,6 +151,8 @@ dma-buf-sharing.txt - the DMA Buffer Sharing API Guide dontdiff - file containing a list of files that should never be diff'ed. +driver-api/ + - the Linux driver implementer's API guide. driver-model/ - directory with info about Linux driver model. dynamic-debug-howto.txt @@ -155,10 +167,14 @@ eisa.txt - info on EISA bus support. extcon/ - directory with porting guide for Android kernel switch driver. +isa.txt + - info on EISA bus support. fault-injection/ - dir with docs about the fault injection capabilities infrastructure. fb/ - directory with info on the frame buffer graphics abstraction layer. +features/ + - status of feature implementation on different architectures. filesystems/ - info on the vfs and the various filesystems that Linux supports. firmware_class/ @@ -167,14 +183,20 @@ flexible-arrays.txt - how to make use of flexible sized arrays in linux fmc/ - information about the FMC bus abstraction +fpga/ + - FPGA Manager Core. frv/ - Fujitsu FR-V Linux documentation. futex-requeue-pi.txt - info on requeueing of tasks from a non-PI futex to a PI futex +gcc-plugins.txt + - GCC plugin infrastructure. gcov.txt - use of GCC's coverage testing tool "gcov" with the Linux kernel gpio/ - gpio related documentation +gpu/ + - directory with information on GPU driver developer's guide. hid/ - directory with information on human interface devices highuid.txt @@ -197,6 +219,10 @@ x86/i386/ - directory with info about Linux on Intel 32 bit architecture. ia64/ - directory with info about Linux on Intel 64 bit architecture. +ide/ + - Information regarding the Enhanced IDE drive. +iio/ + - info on industrial IIO configfs support. infiniband/ - directory with documents concerning Linux InfiniBand support. input/ @@ -221,6 +247,8 @@ ja_JP/ - directory with Japanese translations of various documents kbuild/ - directory with info about the kernel build process. +kernel-doc-nano-HOWTO.txt + - outdated info about kernel-doc documentation. kdump/ - directory with mini HowTo on getting the crash dump code to work. doc-guide/ @@ -247,6 +275,8 @@ ldm.txt - a brief description of LDM (Windows Dynamic Disks). leds/ - directory with info about LED handling under Linux. +livepatch/ + - info on kernel live patching. local_ops.txt - semantics and behavior of local atomic operations. locking/ @@ -265,16 +295,22 @@ magic-number.txt - list of magic numbers used to mark/protect kernel data structures. mailbox.txt - How to write drivers for the common mailbox framework (IPC). -media-framework.txt - - info on media framework, its data structures, functions and usage. +md-cluster.txt + - info on shared-device RAID MD cluster. +media/ + - info
[PATCH 1/5] scripts: add a script to check if Documentation/00-INDEX is sane
It is easy to forget adding/removing entries at the Documentation/00-INDEX file. In a matter of fact, even before ReST conversion, people use to forget adding things here, as there are lots of missing stuff out there. Now that we're doing a hard work converting entries to ReST, and while this hole file is not outdated, it is good to have some tool that would help to verify that this file is kept updated. Signed-off-by: Mauro Carvalho Chehab --- scripts/check_00index.sh | 66 1 file changed, 66 insertions(+) create mode 100755 scripts/check_00index.sh diff --git a/scripts/check_00index.sh b/scripts/check_00index.sh new file mode 100755 index ..6ac9527aeddb --- /dev/null +++ b/scripts/check_00index.sh @@ -0,0 +1,66 @@ +#!/bin/bash + +cd Documentation/ + +# Check entries that should be removed + +obsolete="" +for i in $(tail -n +12 00-INDEX |grep -E '^[a-zA-Z0-9]+'); do + if [ ! -e $i ]; then + obsolete="$obsolete $i" + fi +done + +# Check directory entries that should be added +search="" +dir="" +for i in $(find . -maxdepth 1 -type d); do + if [ "$i" != "." ]; then + new=$(echo $i|perl -ne 's,./(.*),$1/,; print $_') + search="$search $new" + fi +done + +for i in $search; do + if [ "$(grep -P "^$i" 00-INDEX)" == "" ]; then + dir="$dir $i" + fi +done + +# Check file entries that should be added +search="" +file="" +for i in $(find . -maxdepth 1 -type f); do + if [ "$i" != "./.gitignore" ]; then + new=$(echo $i|perl -ne 's,./(.*),$1,; print $_') + search="$search $new" + fi +done + +for i in $search; do + if [ "$(grep -P "^$i\$" 00-INDEX)" == "" ]; then + file="$file $i" + fi +done + +# Output its findings + +echo -e "Documentation/00-INDEX check results:\n" + +if [ "$obsolete" != "" ]; then + echo -e "- Should remove those entries:\n\t$obsolete\n" +else + echo -e "- No obsolete entries\n" +fi + +if [ "$dir" != "" ]; then + echo -e "- Should document those directories:\n\t$dir\n" +else + echo -e "- No new directories to add\n" +fi + +if [ "$file" != "" ]; then + echo -e "- Should document those files:\n\t$file" +else + echo "- No new files to add" +fi -- 2.9.3
[PATCH 0/5] Update Documentation/00-INDEX
Keeping a manually filled index over time is not perfect, as people often forget to keep the index file updated. As Brian noticed, the recent conversion to ReST caused some new issues. It turns, however, that the problem with this file predates the ReST conversion, as several entries were missing, including really old ones like PCI/ and isa.txt. Well, after converting everything to ReST file, the 00-INDEX one will become obsoleted by index.rst, but, as there are still a lot stuff to do, it will take some time. So, in order to check it, I wrote a small script that compares the files and directories at Documentation/ with the ones at 00-INDEX. Then, I synchronized the entries, making the script happy. We might think on integrating the script with checkpatch.pl, but, as we should get rid of 00-INDEX, it probably not worth the efforts. Mauro Carvalho Chehab (5): scripts: add a script to check if Documentation/00-INDEX is sane docs: 00-INDEX: consolidate process/ and admin-guide/ description docs: 00-INDEX: add missing entries for documentation files/dirs docs: 00-INDEX: remove non-existing entries docs: 00-INDEX: document directories/files with no docs Documentation/00-INDEX | 196 --- scripts/check_00index.sh | 66 2 files changed, 149 insertions(+), 113 deletions(-) create mode 100755 scripts/check_00index.sh -- 2.9.3
[PATCH 4/5] docs: 00-INDEX: remove non-existing entries
Several entries were moved to a directory; others got simply removed. Get rid of those entries. Signed-off-by: Mauro Carvalho Chehab --- Documentation/00-INDEX | 52 -- 1 file changed, 52 deletions(-) diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index bd532a7e03e6..272f5c4481f1 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -47,8 +47,6 @@ SAK.txt - info on Secure Attention Keys. SM501.txt - Silicon Motion SM501 multimedia companion chip -VGA-softcursor.txt - - how to change your VGA cursor from a blinking underscore. accounting/ - documentation on accounting and taskstats. acpi/ @@ -61,28 +59,18 @@ arm/ - directory with info about Linux on the ARM architecture. arm64/ - directory with info about Linux on the 64 bit ARM architecture. -assoc_array.txt - - generic associative array intro. -atomic_ops.txt - - semantics and behavior of atomic and bitmask operations. auxdisplay/ - misc. LCD driver documentation (cfag12864b, ks0108). backlight/ - directory with info on controlling backlights in flat panel displays -basic_profiling.txt - - basic instructions for those who wants to profile Linux kernel. bcache.txt - Block-layer cache on fast SSDs to improve slow (raid) I/O performance. -binfmt_misc.txt - - info on the kernel support for extra binary formats. blackfin/ - directory with documentation for the Blackfin arch. block/ - info on the Block I/O (BIO) layer. blockdev/ - info on block devices & drivers -braille-console.txt - - info on how to use serial devices for Braille support. bt8xxgpio.txt - info on how to modify a bt8xx video card for GPIO usage. btmrvl.txt @@ -105,8 +93,6 @@ clk.txt - info on the common clock framework cma/ - Continuous Memory Area (CMA) debugfs interface. -coccinelle.txt - - info on how to get and use the Coccinelle code checking tool. connector/ - docs on the netlink based userspace<->kernel space communication mod. console/ @@ -155,8 +141,6 @@ driver-api/ - the Linux driver implementer's API guide. driver-model/ - directory with info about Linux driver model. -dynamic-debug-howto.txt - - how to use the dynamic debug (dyndbg) feature. early-userspace/ - info about initramfs, klibc, and userspace early during boot. edac.txt @@ -191,8 +175,6 @@ futex-requeue-pi.txt - info on requeueing of tasks from a non-PI futex to a PI futex gcc-plugins.txt - GCC plugin infrastructure. -gcov.txt - - use of GCC's coverage testing tool "gcov" with the Linux kernel gpio/ - gpio related documentation gpu/ @@ -201,8 +183,6 @@ hid/ - directory with information on human interface devices highuid.txt - notes on the change from 16 bit to 32 bit user/group IDs. -hsi.txt - - HSI subsystem overview. hwspinlock.txt - hardware spinlock provides hardware assistance for synchronization timers/ @@ -213,8 +193,6 @@ hwmon/ - directory with docs on various hardware monitoring drivers. i2c/ - directory with info about the I2C bus/protocol (2 wire, kHz speed). -i2o/ - - directory with info about the Linux I2O subsystem. x86/i386/ - directory with info about Linux on Intel 32 bit architecture. ia64/ @@ -243,8 +221,6 @@ isapnp.txt - info on Linux ISA Plug & Play support. isdn/ - directory with info on the Linux ISDN support, and supported cards. -ja_JP/ - - directory with Japanese translations of various documents kbuild/ - directory with info about the kernel build process. kernel-doc-nano-HOWTO.txt @@ -255,12 +231,6 @@ doc-guide/ - how to write and format reStructuredText kernel documentation kernel-per-CPU-kthreads.txt - List of all per-CPU kthreads and how they introduce jitter. -kmemcheck.txt - - info on dynamic checker that detects uses of uninitialized memory. -kmemleak.txt - - info on how to make use of the kernel memory leak detection system -ko_KR/ - - directory with Korean translations of various documents kobject.txt - info of the kobject infrastructure of the Linux kernel. kprobes.txt @@ -277,8 +247,6 @@ leds/ - directory with info about LED handling under Linux. livepatch/ - info on kernel live patching. -local_ops.txt - - semantics and behavior of local atomic operations. locking/ - directory with info about kernel locking primitives lockup-watchdogs.txt @@ -291,8 +259,6 @@ lzo.txt - kernel LZO decompressor input formats m68k/ - directory with info about Linux on Motorola 68k architecture. -magic-number.txt - - list of magic numbers used to mark/protect kernel data structures. mailbox.txt - How to write drivers for the common mailbox framework (IPC). md-cluster.txt @@ -319,8 +2
Applied "regulator: core: add newline in debug message" to the regulator tree
The patch
regulator: core: add newline in debug message
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b2661e983f5b55d4895673bd5eafa14b1e7c8881 Mon Sep 17 00:00:00 2001
From: David Lechner
Date: Sun, 4 Dec 2016 19:48:11 -0600
Subject: [PATCH] regulator: core: add newline in debug message
This adds a trailing newline to a debug message.
Signed-off-by: David Lechner
Signed-off-by: Mark Brown
---
drivers/regulator/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index b6b3aa8ef5db..cf23b1e2ac4c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -204,7 +204,7 @@ static struct device_node *of_get_regulator(struct device
*dev, const char *supp
regnode = of_parse_phandle(dev->of_node, prop_name, 0);
if (!regnode) {
- dev_dbg(dev, "Looking up %s property in node %s failed",
+ dev_dbg(dev, "Looking up %s property in node %s failed\n",
prop_name, dev->of_node->full_name);
return NULL;
}
--
2.10.2
Applied "ASoC: cq93vc: remove MFD_DAVINCI_VOICECODEC dependency for CQ0093VC" to the asoc tree
The patch ASoC: cq93vc: remove MFD_DAVINCI_VOICECODEC dependency for CQ0093VC has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 4de429888c5b534f43a3d693e3627021b17e900c Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Fri, 2 Dec 2016 04:01:22 + Subject: [PATCH] ASoC: cq93vc: remove MFD_DAVINCI_VOICECODEC dependency for CQ0093VC CQ0093VC is no longer dependent on MFD_DAVINCI_VOICECODEC, let's remove it. Otherwise, we can't compile it by COMPILE_TEST on non-DAVINCE platform Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown --- sound/soc/codecs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index c67667bb970f..cb195b07e7d2 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -45,7 +45,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_ALC5623 if I2C select SND_SOC_ALC5632 if I2C select SND_SOC_BT_SCO - select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC + select SND_SOC_CQ0093VC select SND_SOC_CS35L32 if I2C select SND_SOC_CS35L33 if I2C select SND_SOC_CS42L51_I2C if I2C -- 2.10.2
Applied "regulator: Fix regulator_get_error_flags() signature mismatch" to the regulator tree
The patch
regulator: Fix regulator_get_error_flags() signature mismatch
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 30103b5b6432a51c3822a26dc340e35d91237f39 Mon Sep 17 00:00:00 2001
From: David Lechner
Date: Sun, 4 Dec 2016 16:52:31 -0600
Subject: [PATCH] regulator: Fix regulator_get_error_flags() signature mismatch
The function signature of does not match regulator_get_error_flags()
when CONFIG_REGULATOR is not defined vs. when it is not defined.
This makes both declarations match to prevent compiler errors.
Signed-off-by: David Lechner
Signed-off-by: Mark Brown
---
include/linux/regulator/consumer.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index 528eb1f5273e..ea0fffa5faeb 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -498,7 +498,8 @@ static inline unsigned int regulator_get_mode(struct
regulator *regulator)
return REGULATOR_MODE_NORMAL;
}
-static inline int regulator_get_error_flags(struct regulator *regulator)
+static inline int regulator_get_error_flags(struct regulator *regulator,
+ unsigned int *flags)
{
return -EINVAL;
}
--
2.10.2
Re: [PATCH v4 8/9] media: venus: hfi: add Venus HFI files
On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
> Here is the implementation of Venus video accelerator low-level
> functionality. It contanins code which setup the registers and
> startup uthe processor, allocate and manipulates with the shared
> memory used for sending commands and receiving messages.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/hfi_venus.c| 1508
> ++
> drivers/media/platform/qcom/venus/hfi_venus.h| 23 +
> drivers/media/platform/qcom/venus/hfi_venus_io.h | 98 ++
> 3 files changed, 1629 insertions(+)
> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
> create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h
>
> diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
> b/drivers/media/platform/qcom/venus/hfi_venus.c
> new file mode 100644
> index ..f004a9a80d85
> --- /dev/null
> +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
> @@ -0,0 +1,1508 @@
> +static int venus_tzbsp_set_video_state(enum tzbsp_video_state state)
> +{
> + return qcom_scm_video_set_state(state, 0);
This functions doesn't seem to exist. Is there a prerequisite patch series that
introduces this function?
> +}
Regards,
Hans
[PATCH] MAINTAINERS: clarify that "B:" is the URI where to file bugs
Different subsystems and drivers have different preferences for where to
file bugs and what information to include. 686564434e88 ("MAINTAINERS:
Add bug tracking system location entry type") added "B:" entry for this.
Clarify that "B:" specifies the URI for the bug tracker directly, a web
page for detailed info on filing bugs, or a mailto: URI.
Fixes: 686564434e88 ("MAINTAINERS: Add bug tracking system location entry type")
Cc: Rafael J. Wysocki
Cc: Andrew Morton
Signed-off-by: Jani Nikula
---
Rafael, I just noticed the "B:" entry popped up in MAINTAINERS from
686564434e88 ("MAINTAINERS: Add bug tracking system location entry
type").
I've been pushing this for some time now, and I'd sent the last patch
adding this before the kernel summit discussion you refer to [1], and
Andrew picked it up, along with the rest in the series. This is where
the whole idea came from!
Specifying "B:" as URI lets subsystems decide whether it contains a bug
tracker or something else.
[1]
http://lkml.kernel.org/r/1476966135-26943-1-git-send-email-jani.nik...@intel.com
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index f7fd00ef1323..8f55d44b5b26 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -77,7 +77,8 @@ Descriptions of section entries:
Q: Patchwork web based patch tracking system site
T: SCM tree type and location.
Type is one of: git, hg, quilt, stgit, topgit
- B: Bug tracking system location.
+ B: URI for where to file bugs. A web-page with detailed bug
+ filing info, a direct bug tracker link, or a mailto: URI.
S: Status, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
--
2.1.4
[PATCH v3] iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped
We met the DMAR fault both on hpsa P420i and P421 SmartArray controllers
under kdump, it can be steadily reproduced on several different machines,
the dmesg log is like:
HP HPSA Driver (v 3.4.16-0)
hpsa :02:00.0: using doorbell to reset controller
hpsa :02:00.0: board ready after hard reset.
hpsa :02:00.0: Waiting for controller to respond to no-op
DMAR: Setting identity map for device :02:00.0 [0xe8000 - 0xe8fff]
DMAR: Setting identity map for device :02:00.0 [0xf4000 - 0xf4fff]
DMAR: Setting identity map for device :02:00.0 [0xbdf6e000 - 0xbdf6efff]
DMAR: Setting identity map for device :02:00.0 [0xbdf6f000 - 0xbdf7efff]
DMAR: Setting identity map for device :02:00.0 [0xbdf7f000 - 0xbdf82fff]
DMAR: Setting identity map for device :02:00.0 [0xbdf83000 - 0xbdf84fff]
DMAR: DRHD: handling fault status reg 2
DMAR: [DMA Read] Request device [02:00.0] fault addr f000 [fault reason 06]
PTE Read access is not set
hpsa :02:00.0: controller message 03:00 timed out
hpsa :02:00.0: no-op failed; re-trying
After some debugging, we found that the fault addr is from DMA initiated at
the driver probe stage after reset(not in-flight DMA), and the corresponding
pte entry value is correct, the fault is likely due to the old iommu caches
of the in-flight DMA before it.
Thus we need to flush the old cache after context mapping is setup for the
device, where the device is supposed to finish reset at its driver probe
stage and no in-flight DMA exists hereafter.
I'm not sure if the hardware is responsible for invalidating all the related
caches allocated in the iommu hardware before, but seems not the case for hpsa,
actually many device drivers have problems in properly resetting the hardware.
Anyway flushing (again) by software in kdump kernel when the device gets context
mapped which is a quite infrequent operation does little harm.
With this patch, the problematic machine can survive the kdump tests.
CC: Myron Stowe
CC: Joseph Szczypek
CC: Don Brace
CC: Baoquan He
CC: Dave Young
Fixes: 091d42e43d21 ("iommu/vt-d: Copy translation tables from old kernel")
Fixes: dbcd861f252d ("iommu/vt-d: Do not re-use domain-ids from the old kernel")
Fixes: cf484d0e6939 ("iommu/vt-d: Mark copied context entries")
Signed-off-by: Xunlei Pang
---
v2->v3:
Flush context cache only and add Fixes-tag, according to Joerg's comments.
drivers/iommu/intel-iommu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 3965e73..624eac9 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2024,6 +2024,25 @@ static int domain_context_mapping_one(struct dmar_domain
*domain,
if (context_present(context))
goto out_unlock;
+ /*
+* For kdump cases, old valid entries may be cached due to the
+* in-flight DMA and copied pgtable, but there is no unmapping
+* behaviour for them, thus we need an explicit cache flush for
+* the newly-mapped device. For kdump, at this point, the device
+* is supposed to finish reset at its driver probe stage, so no
+* in-flight DMA will exist, and we don't need to worry anymore
+* hereafter.
+*/
+ if (context_copied(context)) {
+ u16 did_old = context_domain_id(context);
+
+ if (did_old >= 0 && did_old < cap_ndoms(iommu->cap))
+ iommu->flush.flush_context(iommu, did_old,
+ (((u16)bus) << 8) | devfn,
+ DMA_CCMD_MASK_NOBIT,
+ DMA_CCMD_DEVICE_INVL);
+ }
+
pgd = domain->pgd;
context_clear_entry(context);
--
1.8.3.1
RE: [tpmdd-devel] [PATCH v2 1/3] tpm_crb: map locality registers
> > ---
> > drivers/char/tpm/tpm_crb.c | 96
> > ++
> > 1 file changed, 64 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index 717b6b4..8d81b66 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -52,18 +52,28 @@ enum crb_cancel {
> > CRB_CANCEL_INVOKE = BIT(0),
> > };
> >
> > -struct crb_control_area {
> > - u32 req;
> > - u32 sts;
> > - u32 cancel;
> > - u32 start;
> > - u32 int_enable;
> > - u32 int_sts;
> > - u32 cmd_size;
> > - u32 cmd_pa_low;
> > - u32 cmd_pa_high;
> > - u32 rsp_size;
> > - u64 rsp_pa;
> > +struct crb_regs_head {
> > + u32 loc_state;
> > + u32 reserved1;
> > + u32 loc_ctrl;
> > + u32 loc_sts;
> > + u8 reserved2[32];
> > + u64 intf_id;
> > + u64 ctrl_ext;
> > +} __packed;
> > +
> > +struct crb_regs_tail {
> > + u32 ctrl_req;
> > + u32 ctrl_sts;
> > + u32 ctrl_cancel;
> > + u32 ctrl_start;
> > + u32 ctrl_int_enable;
> > + u32 ctrl_int_sts;
> > + u32 ctrl_cmd_size;
> > + u32 ctrl_cmd_pa_low;
> > + u32 ctrl_cmd_pa_high;
> > + u32 ctrl_rsp_size;
> > + u64 ctrl_rsp_pa;
> > } __packed;
Now I wonder if using traditional offsets wouldn't be cleaner solution.
> > enum crb_status {
> > @@ -78,7 +88,8 @@ enum crb_flags {
> > struct crb_priv {
> > unsigned int flags;
> > void __iomem *iobase;
> > - struct crb_control_area __iomem *cca;
> > + struct crb_regs_head __iomem *regs_h;
> > + struct crb_regs_tail __iomem *regs_t;
Why just not leaving it cca, it's descriptive enough.
> > u8 __iomem *cmd;
> > u8 __iomem *rsp;
> > u32 cmd_size;
> > @@ -104,7 +115,7 @@ static int __maybe_unused crb_go_idle(struct device
> *dev, struct crb_priv *priv)
> > if (priv->flags & CRB_FL_ACPI_START)
> > return 0;
> >
> > - iowrite32(CRB_CTRL_REQ_GO_IDLE, &priv->cca->req);
> > + iowrite32(CRB_CTRL_REQ_GO_IDLE, &priv->regs_t->ctrl_req);
> > /* we don't really care when this settles */
> >
> > return 0;
> > @@ -128,21 +139,23 @@ static int __maybe_unused crb_cmd_ready(struct
> device *dev,
> > struct crb_priv *priv)
> > {
> > ktime_t stop, start;
> > + u32 req;
> >
> > if (priv->flags & CRB_FL_ACPI_START)
> > return 0;
> >
> > - iowrite32(CRB_CTRL_REQ_CMD_READY, &priv->cca->req);
> > + iowrite32(CRB_CTRL_REQ_CMD_READY, &priv->regs_t->ctrl_req);
> >
> > start = ktime_get();
> > stop = ktime_add(start, ms_to_ktime(TPM2_TIMEOUT_C));
> > do {
> > - if (!(ioread32(&priv->cca->req) &
> CRB_CTRL_REQ_CMD_READY))
> > + req = ioread32(&priv->regs_t->ctrl_req);
> > + if (!(req & CRB_CTRL_REQ_CMD_READY))
> > return 0;
> > usleep_range(50, 100);
> > } while (ktime_before(ktime_get(), stop));
> >
> > - if (ioread32(&priv->cca->req) & CRB_CTRL_REQ_CMD_READY) {
> > + if (ioread32(&priv->regs_t->ctrl_req) & CRB_CTRL_REQ_CMD_READY)
> {
> > dev_warn(dev, "cmdReady timed out\n");
> > return -ETIME;
> > }
> > @@ -155,7 +168,7 @@ static u8 crb_status(struct tpm_chip *chip)
> > struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > u8 sts = 0;
> >
> > - if ((ioread32(&priv->cca->start) & CRB_START_INVOKE) !=
> > + if ((ioread32(&priv->regs_t->ctrl_start) & CRB_START_INVOKE) !=
> > CRB_START_INVOKE)
> > sts |= CRB_DRV_STS_COMPLETE;
> >
> > @@ -171,7 +184,7 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf,
> size_t count)
> > if (count < 6)
> > return -EIO;
> >
> > - if (ioread32(&priv->cca->sts) & CRB_CTRL_STS_ERROR)
> > + if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > return -EIO;
> >
> > memcpy_fromio(buf, priv->rsp, 6);
> > @@ -210,7 +223,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf,
> size_t len)
> > /* Zero the cancel register so that the next command will not get
> > * canceled.
> > */
> > - iowrite32(0, &priv->cca->cancel);
> > + iowrite32(0, &priv->regs_t->ctrl_cancel);
> >
> > if (len > priv->cmd_size) {
> > dev_err(&chip->dev, "invalid command count value %zd %d\n",
> @@
> > -224,7 +237,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t
> len)
> > wmb();
> >
> > if (priv->flags & CRB_FL_CRB_START)
> > - iowrite32(CRB_START_INVOKE, &priv->cca->start);
> > + iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> >
> > if (priv->flags & CRB_FL_ACPI_START)
> > rc = crb_do_acpi_start(chip);
> > @@ -236,7 +249,7 @@ static void crb_cancel(struct tpm_chip *chip) {
> > struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> >
> > - iowrite32(CRB_CANCEL_INVOKE, &priv->cca->cancel);
> > + iowrite32(CRB_CANCEL_INVOKE, &priv->regs_t->ctrl_cancel);
> >
> > if ((priv->flags & CRB_FL_ACPI_START) && crb
Re: [PATCH] [media] usbtv: add a new usbid
On Sun, 2016-12-04 at 22:59 +0800, Icenowy Zheng wrote: > > 04.12.2016, 22:00, "Icenowy Zheng" : > > A new usbid of UTV007 is found in a newly bought device. > > > > The usbid is 1f71:3301. > > > > The ID on the chip is: > > UTV007 > > A89029.1 > > 1520L18K1 > > > > Seems that my device come with more capabilities. > > I tested it under Windows, and I got wireless Analog TV > and FM radio functions. (An antenna is shipped with my device) > > Maybe a new radio function is be added, combined with the > new USB ID. > > But at least Composite AV function works well with current usbtv > driver and XawTV. Well, someone with the hardware would need to capture the traffic from the Windows driver (and ideally also extend the driver). Would you mind giving it a try? Do you have a link to some further details about the device you got? Perhaps if it's available cheaply from dealextreme or somewhere I could take a look too. Lubo
Re: [PATCH 1/2] Documentation/core-api/device_link: Add initial documentation
Em Sun, 4 Dec 2016 13:10:04 +0100
Lukas Wunner escreveu:
> Document device links as introduced in v4.10 with commits:
> 4bdb35506b89 ("driver core: Add a wrapper around
>__device_release_driver()")
> 9ed9895370ae ("driver core: Functional dependencies tracking
>support")
> 8c73b4288496 ("PM / sleep: Make async suspend/resume of devices use
>device links")
> 21d5c57b3726 ("PM / runtime: Use device links")
> baa8809f6097 ("PM / runtime: Optimize the use of device links")
>
> Cc: Rafael J. Wysocki
> Cc: Greg Kroah-Hartman
> Cc: Luis R. Rodriguez
> Cc: Jonathan Corbet
> Cc: Silvio Fricke
> Cc: Marek Szyprowski
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Andrzej Hajda
> Cc: Mauro Carvalho Chehab
> Cc: Inki Dae
> Cc: Joerg Roedel
> Cc: Kukjin Kim
> Cc: Krzysztof Kozlowski
> Cc: Mark Brown
> Cc: Tomeu Vizoso
> Cc: Kevin Hilman
> Cc: Ulf Hansson
> Cc: Geert Uytterhoeven
> Cc: Tobias Jakobi
> Cc: Tomasz Figa
> Cc: Grant Likely
> Cc: Laurent Pinchart
> Cc: Lars-Peter Clausen
> Cc: Dmitry Torokhov
> Cc: Christoph Hellwig
> Cc: Arnd Bergmann
> Cc: Alan Stern
> Cc: Hanjun Guo
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: io...@lists.linux-foundation.org
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Lukas Wunner
> ---
> Documentation/core-api/device_link.rst | 279
> +
> Documentation/core-api/index.rst | 8 +
> 2 files changed, 287 insertions(+)
> create mode 100644 Documentation/core-api/device_link.rst
>
> diff --git a/Documentation/core-api/device_link.rst
> b/Documentation/core-api/device_link.rst
> new file mode 100644
> index 000..5f57134
> --- /dev/null
> +++ b/Documentation/core-api/device_link.rst
> @@ -0,0 +1,279 @@
> +
> +Device links
> +
> +
> +By default, the driver core only enforces dependencies between devices
> +that are borne out of a parent/child relationship within the device
> +hierarchy: When suspending, resuming or shutting down the system, devices
> +are ordered based on this relationship, i.e. children are always suspended
> +before their parent, and the parent is always resumed before its children.
> +
> +Sometimes there is a need to represent device dependencies beyond the
> +mere parent/child relationship, e.g. between siblings, and have the
> +driver core automatically take care of them.
> +
> +Secondly, the driver core by default does not enforce any driver presence
> +dependencies, i.e. that one device must be bound to a driver before
> +another one can probe or function correctly.
> +
> +Often these two dependency types come together, so a device depends on
> +another one both with regards to driver presence *and* with regards to
> +suspend/resume and shutdown ordering.
> +
> +Device links allow representation of such dependencies in the driver core.
> +
> +In its standard form, a device link combines *both* dependency types:
> +It guarantees correct suspend/resume and shutdown ordering between a
> +"supplier" device and its "consumer" devices, and it guarantees driver
> +presence on the supplier. The consumer devices are not probed before the
> +supplier is bound to a driver, and they're unbound before the supplier
> +is unbound.
> +
> +When driver presence on the supplier is irrelevant and only correct
> +suspend/resume and shutdown ordering is needed, the device link may
> +simply be set up with the ``DL_FLAG_STATELESS`` flag. In other words,
> +enforcing driver presence on the supplier is optional.
> +
> +Another optional feature is runtime PM integration: By setting the
> +``DL_FLAG_PM_RUNTIME`` flag on addition of the device link, the PM core
> +is instructed to runtime resume the supplier and keep it active
> +whenever and for as long as the consumer is runtime resumed.
> +
> +Usage
> +=
You should be using, instead:
Usage
-
(and the same '-' symbol for all sections of this chapter)
The way you did, in thesis, ReST should be putting all tags at the
same level as the first one, as they're all using '='.
The other ReST markups look OK on my eyes.
Regards,
Mauro
> +
> +The earliest point in time when device links can be added is after
> +:c:func:`device_add()` has been called for the supplier and
> +:c:func:`device_initialize()` has been called for the consumer.
> +
> +It is legal to add them later, but care must be taken that the system
> +remains in a consistent state: E.g. a device link cannot be added in
> +the midst of a suspend/resume transition, so either commencement of
> +such a transition needs to be prevented with :c:func:`lock_system_sleep()`,
> +or the device link needs to be added from a function which is guaranteed
> +not to run in parallel to a suspend/resume transition, such as from a
> +device ``->probe`` callback or a boot-time PCI quirk.
> +
> +Another example for an inconsistent state would be a device link that
> +represents a dri
Re: [PATCH 0/2] Device links documentation
Hi Lukas, Em Sun, 4 Dec 2016 13:10:04 +0100 Lukas Wunner escreveu: > Here's my suggestion for initial documentation on the device links > feature that's queued for 4.10 on Greg KH's driver-core-next branch. > Please let me know if you have any additions or corrections. > > To read this in rendered form: > http://wunner.de/kernel-doc/core-api/device_link.html > > Patch [2/2] could go in via driver-core-next, but patch [1/2] would > need to go in via docs-next (because the core-api directory doesn't > exist yet in driver-core-next). > > @Jonathan Corbet: Is core-api the right place to put this? An > alternative would be Documentation/driver-api, but unlike core-api > it contains less prose text but mostly just bare API docs gleaned > from kernel-doc. Just my 2 cents here, but, IMHO, this belongs to driver-api. Yeah, it contains less prose, with is, IMHO, something that should be improved ;) Regards, Mauro
[PATCH v8 2/6] powerpc: pSeries/Kconfig: Add qspinlock build config
pSeries/powerNV will use qspinlock from now on. Signed-off-by: Pan Xinhui --- arch/powerpc/platforms/pseries/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index bec90fb..8a87d06 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -23,6 +23,14 @@ config PPC_PSERIES select PPC_DOORBELL default y +config ARCH_USE_QUEUED_SPINLOCKS + default y + bool "Enable qspinlock" + help + Enabling this option will let kernel use qspinlock which is a kind of + fairlock. It has shown a good performance improvement on x86 and also ppc + especially in high contention cases. + config PPC_SPLPAR depends on PPC_PSERIES bool "Support for shared-processor logical partitions" -- 2.4.11
Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
Hi! > >>We had experimented this tuning on STB IP where just datagrams > >>had to send externally. To be honest, although we had seen > >>better results w/o any timer, we kept this approach enabled > >>because the timer was fast enough to cover our tests on SH4 boxes. > > > >Please reply to David, and explain how it is supposed to > >work... because right now it does not. 40 msec delays are not > >acceptable in default configuration. > > I mean, that on UP and SMP system this schema helped > to improve the performance saving CPU on my side and this has been > tested since a long time (~4 years). > I tested something similar to yours where unidirectional traffic > with limited throughput was needed and I can confirm you that > tuning/removing coalesce parameters this helped. The tuning I decided > to keep in the driver was suitable in several user cases and if now > you have problems or you want to review it I can just confirm that > there are no problems on my side. If you want to simply the logic > around the tx process and remove timer on official driver I can accept > that. I will just ask you uto double check if the throughput and > CPU usage when request max throughput (better if on GiGa setup) has > no regressions. > Otherwise we could start thinking about adaptive schema if feasible. Ok, so you see the issue. Good. See the other email to description how it could be fixed... the logic is broken. How it was not discovered for 4 years is mystery to me. > >Agreed that no irqlock protection is needed if we rely on napi and timers. > > ok Actually I was wrong there. Another reason to disable tx coalescing until it is fixed. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
Hi!
> the idea behind the TX mitigation is to mix the interrupt and
> timer and this approach gave us real benefit in terms
> of performances and CPU usage (especially on SH4-200/SH4-300 platforms
> based).
> In the ring, some descriptors can raise the irq (according to a
> threshold) and set the IC bit. In this path, the NAPI poll will be
> scheduled.
> But there is a timer that can run (and we experimented that no high
> resolution is needed) to clear the tx resources.
I'm sorry, but it is just broken. It could have never worked. If it
appered it did, you did not test it right.
First, low-res timers have resolution down to one per second (see
David's email). It is not acceptable to delay transmits for 40msec,
and certainly not acceptable to delay them for 1000msec.
Second, the logic is wrong:
if (likely(priv->tx_coal_frames > priv->tx_count_frames))
mod_timer(&priv->txtimer,
STMMAC_COAL_TIMER(priv->tx_coal_timer));
else {
priv->tx_count_frames = 0;
priv->hw->desc->set_tx_ic(desc);
priv->xstats.tx_set_ic_bit++;
}
doing tx_clean() after set number of packets, or set time after the
first packet is transmitted would make sense. But that's not what the
code does. As long as packets are being transmitted, you move the
timer into the future.. so that finally you run out of the place, then
wait for timer (!) and only then you do the cleaning.
Third, times are wrong by order of magnitude. AFAICT cleaning should
be at around 5msec at 100mbit speeds, and at around .5msec at
gigabit. You have 40msec there. (Perhaps that is not too important if
the logic is fixed, as described above).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [v3 PATCH] netlink: Do not schedule work from sk_destruct
On Mon, Dec 5, 2016 at 8:28 AM, Herbert Xu wrote:
> On Mon, Dec 05, 2016 at 03:26:00PM +0800, Herbert Xu wrote:
>> On Mon, Dec 05, 2016 at 03:19:46PM +0800, Herbert Xu wrote:
>> >
>> > Thanks for the patch. It'll obviously work but I wanted avoid that
>> > because it penalises the common path for the rare case.
>> >
>> > Andrey, please try this patch and let me know if it's any better.
>> >
>> > ---8<---
>> > Subject: netlink: Do not schedule work from sk_destruct
>>
>> Crap, I screwed it up again. Here is a v2 which moves the atomic
>> call into the RCU callback as otherwise the socket can be freed from
>> another path while we await the RCU callback.
>
> With the move it no longer makes sense to rename deferred_put_nlk_sk
> so here is v3 which restores the original name.
>
> ---8<---
> It is wrong to schedule a work from sk_destruct using the socket
> as the memory reserve because the socket will be freed immediately
> after the return from sk_destruct.
>
> Instead we should do the deferral prior to sk_free.
>
> This patch does just that.
>
> Fixes: 707693c8a498 ("netlink: Call cb->done from a worker thread")
> Signed-off-by: Herbert Xu
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 602e5eb..246f29d 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -322,11 +322,13 @@ static void netlink_skb_set_owner_r(struct sk_buff
> *skb, struct sock *sk)
> sk_mem_charge(sk, skb->truesize);
> }
>
> -static void __netlink_sock_destruct(struct sock *sk)
> +static void netlink_sock_destruct(struct sock *sk)
> {
> struct netlink_sock *nlk = nlk_sk(sk);
>
> if (nlk->cb_running) {
> + if (nlk->cb.done)
> + nlk->cb.done(&nlk->cb);
> module_put(nlk->cb.module);
> kfree_skb(nlk->cb.skb);
> }
> @@ -348,21 +350,7 @@ static void netlink_sock_destruct_work(struct
> work_struct *work)
> struct netlink_sock *nlk = container_of(work, struct netlink_sock,
> work);
>
> - nlk->cb.done(&nlk->cb);
> - __netlink_sock_destruct(&nlk->sk);
> -}
> -
> -static void netlink_sock_destruct(struct sock *sk)
> -{
> - struct netlink_sock *nlk = nlk_sk(sk);
> -
> - if (nlk->cb_running && nlk->cb.done) {
> - INIT_WORK(&nlk->work, netlink_sock_destruct_work);
> - schedule_work(&nlk->work);
> - return;
> - }
> -
> - __netlink_sock_destruct(sk);
> + sk_free(&nlk->sk);
> }
>
> /* This lock without WQ_FLAG_EXCLUSIVE is good on UP and it is _very_ bad on
> @@ -667,8 +655,18 @@ static int netlink_create(struct net *net, struct socket
> *sock, int protocol,
> static void deferred_put_nlk_sk(struct rcu_head *head)
> {
> struct netlink_sock *nlk = container_of(head, struct netlink_sock,
> rcu);
> + struct sock *sk = &nlk->sk;
> +
> + if (!atomic_dec_and_test(&sk->sk_refcnt))
> + return;
> +
> + if (nlk->cb_running && nlk->cb.done) {
> + INIT_WORK(&nlk->work, netlink_sock_destruct_work);
> + schedule_work(&nlk->work);
> + return;
> + }
>
> - sock_put(&nlk->sk);
> + sk_free(sk);
> }
>
> static int netlink_release(struct socket *sock)
> --
> Email: Herbert Xu
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Herbert,
Tested the last version of your patch, the reports go away.
Thanks for the fix!
Tested-by: Andrey Konovalov
Re: [PATCH] [media] usbtv: add a new usbid
On Sun, 2016-12-04 at 21:59 +0800, Icenowy Zheng wrote:
> A new usbid of UTV007 is found in a newly bought device.
>
> The usbid is 1f71:3301.
>
> The ID on the chip is:
> UTV007
> A89029.1
> 1520L18K1
>
> Both video and audio is tested with the modified usbtv driver.
Thank you.
Acked-by: Lubomir Rintel
Also, it may make sense to add
Tested-by: Icenowy Zheng
>
> Signed-off-by: Icenowy Zheng
> ---
> drivers/media/usb/usbtv/usbtv-core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/usb/usbtv/usbtv-core.c
> b/drivers/media/usb/usbtv/usbtv-core.c
> index dc76fd4..0324633 100644
> --- a/drivers/media/usb/usbtv/usbtv-core.c
> +++ b/drivers/media/usb/usbtv/usbtv-core.c
> @@ -141,6 +141,7 @@ static void usbtv_disconnect(struct usb_interface
> *intf)
>
> static struct usb_device_id usbtv_id_table[] = {
> { USB_DEVICE(0x1b71, 0x3002) },
> + { USB_DEVICE(0x1f71, 0x3301) },
> {}
> };
> MODULE_DEVICE_TABLE(usb, usbtv_id_table);
[PATCH] gpio/gpiolib.c:Fixing style issues in gpiolib.c
Fixing the following checkpatch.pl error:
ERROR: else should follow close brace '}'
+ }
+ else if (test_bit(FLAG_OPEN_SOURCE, &desc->flags)) {
ERROR: space prohibited after that open parenthesis '('
+ if ( !desc->gdev->chip ) { \
ERROR: space prohibited before that close parenthesis ')'
+ if ( !desc->gdev->chip ) { \
and following warnings :
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: else is not generally useful after a break or return
+ break;
+ else
Change-Id: I9164832686efb8db1f6d365f89f278e998104f81
Signed-off-by: Mukesh Kaushik
---
drivers/gpio/gpiolib.c | 34 --
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 93ed0e0..1b3361a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -85,7 +85,7 @@ static inline void desc_set_label(struct gpio_desc *d, const
char *label)
/**
* Convert a GPIO number to its descriptor
*/
-struct gpio_desc *gpio_to_desc(unsigned gpio)
+struct gpio_desc *gpio_to_desc(unsigned int gpio)
{
struct gpio_device *gdev;
unsigned long flags;
@@ -157,9 +157,8 @@ static int gpiochip_find_base(int ngpio)
/* found a free space? */
if (gdev->base + gdev->ngpio <= base)
break;
- else
- /* nope, check the space right before the chip */
- base = gdev->base - ngpio;
+ /* nope, check the space right before the chip */
+ base = gdev->base - ngpio;
}
if (gpio_is_valid(base)) {
@@ -182,7 +181,7 @@ static int gpiochip_find_base(int ngpio)
int gpiod_get_direction(struct gpio_desc *desc)
{
struct gpio_chip*chip;
- unsignedoffset;
+ unsigned intoffset;
int status = -EINVAL;
chip = gpiod_to_chip(desc);
@@ -1104,7 +1103,7 @@ int gpiochip_add_data(struct gpio_chip *chip, void *data)
{
unsigned long flags;
int status = 0;
- unsignedi;
+ unsigned inti;
int base = chip->base;
struct gpio_device *gdev;
@@ -1311,7 +1310,7 @@ void gpiochip_remove(struct gpio_chip *chip)
struct gpio_device *gdev = chip->gpiodev;
struct gpio_desc *desc;
unsigned long flags;
- unsignedi;
+ unsigned inti;
boolrequested = false;
/* FIXME: should the legacy sysfs handling be moved to gpio_device? */
@@ -1640,7 +1639,7 @@ static void gpiochip_irq_relres(struct irq_data *d)
module_put(chip->gpiodev->owner);
}
-static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset)
+static int gpiochip_to_irq(struct gpio_chip *chip, unsigned int offset)
{
return irq_find_mapping(chip->irqdomain, offset);
}
@@ -1717,7 +1716,7 @@ int _gpiochip_irqchip_add(struct gpio_chip *gpiochip,
struct device_node *of_node;
bool irq_base_set = false;
unsigned int offset;
- unsigned irq_base = 0;
+ unsigned int irq_base = 0;
if (!gpiochip || !irqchip)
return -EINVAL;
@@ -1815,7 +1814,7 @@ static inline void
gpiochip_irqchip_free_valid_mask(struct gpio_chip *gpiochip)
* @chip: the gpiochip owning the GPIO
* @offset: the offset of the GPIO to request for GPIO function
*/
-int gpiochip_generic_request(struct gpio_chip *chip, unsigned offset)
+int gpiochip_generic_request(struct gpio_chip *chip, unsigned int offset)
{
return pinctrl_request_gpio(chip->gpiodev->base + offset);
}
@@ -1826,7 +1825,7 @@ int gpiochip_generic_request(struct gpio_chip *chip,
unsigned offset)
* @chip: the gpiochip to request the gpio function for
* @offset: the offset of the GPIO to free from GPIO function
*/
-void gpiochip_generic_free(struct gpio_chip *chip, unsigned offset)
+void gpiochip_generic_free(struct gpio_chip *chip, unsigned int offset)
{
pinctrl_free_gpio(chip->gpiodev->base + offset);
}
@@ -2015,7 +2014,7 @@ static int __gpiod_request(struct gpio_desc *desc, const
char *label)
pr_warn("%s: invalid GPIO (no device)\n", __func__); \
return -EINVAL; \
} \
- if ( !desc->gdev->chip ) { \
+ if (!desc->gdev->chip) { \
dev_warn(&desc->gdev->dev, \
"%s: backing chip is gone\n", __func__); \
return 0; \
@@ -2117,7 +2116,7 @@ void gpiod_free(struct gpio_desc *desc)
* help with diagnostics, and knowing that the signal is used as a GPIO
* can help avoid accidentally multiplexing it to another controller.
*/
-const char *gpiochip_is_requested(struct gpio_chip *chip, unsigned offset)
+const char *gpiochip_is_requested(struct gpio_chip *chip, unsigned int offset)
{
struct gpio_desc *desc;
@@ -2244,8 +224
Re: [v5,1/5] soc: qcom: smem_state: Fix include for ERR_PTR()
Hi Dave, Andy Gross writes: > On 1 December 2016 at 04:17, Valo, Kalle wrote: >> Kalle Valo writes: >> >>> It found the same problem. Interestingly I'm also building x86 with 32 >>> bit, maybe it's related? >>> >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git >>> pending >>> head: 1ea16a1c457939b4564643f7637d5cc639a8d3b7 >>> commit: 5eb09c672b01460804fd49b1c9cc7d1072a102f0 [96/99] wcn36xx: >>> Transition driver to SMD client >>> config: i386-allmodconfig (attached as .config) >>> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 >>> reproduce: >>> git checkout 5eb09c672b01460804fd49b1c9cc7d1072a102f0 >>> # save the attached .config to linux build tree >>> make ARCH=i386 >>> >>> All errors (new ones prefixed by >>): >>> > ERROR: "qcom_wcnss_open_channel" > [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined! >> >> Bjorn mentioned me on IRC that this is because of a missing commit in my >> tree: >> >> daa6e41ce2b5 soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API >> >> When I pull the tag below (which contains the above commit) wcn36xx >> builds fine for me: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git >> tags/qcom-drivers-for-4.10 >> >> Andy, is it ok if I pull your tag also to my ath.git tree to solve the >> wcn36xx build problem? My trees go to Linus via net-next and I don't >> know when exactly Dave would send a pull request to Linus, before or >> after the arm trees, but as the tag seems to contain only few patches I >> hope it doesn't matter. > > The qcom-drivers-for-4.10 tag was already merged into arm-soc. But > having you pull it as well won't cause issues so long as you are using > the tag (which you are). I don't see any issues with this approach. Andy, thanks for the confirmation. Dave, how do you suggest to handle depency issues like this? I have pending important wcn36xx patches (converting the driver to use the recently introduced proper SMD subsystem) which have a build dependency on a commit which is in Andy's tag qcom-drivers-for-4.10. The commit in question is currently in arm-soc tree going to 4.10, but not in your net-next tree. I assume Linus will pull that during the next merge window. What I'm planning to do is to pull tag qcom-drivers-for-4.10 to my tree and then send the patches to you. This will mean that from my pull request you would get four new qcom-drivers commits which are not in your tree, yet. Or do you prefer that I wait the qcom-drivers commits trickle down from Linux until I send you wcn36xx patches? Or something else? $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.10 >From git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux * tag qcom-drivers-for-4.10 -> FETCH_HEAD Auto-merging MAINTAINERS Merge made by the 'recursive' strategy. MAINTAINERS |1 + drivers/firmware/qcom_scm.c |4 +++- include/dt-bindings/pinctrl/qcom,pmic-gpio.h |4 include/dt-bindings/pinctrl/qcom,pmic-mpp.h |6 ++ include/linux/soc/qcom/wcnss_ctrl.h | 13 + 5 files changed, 27 insertions(+), 1 deletion(-) $ git log --oneline ORIG_HEAD.. 6d0491261ecc Merge tag 'qcom-drivers-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux into test bd4760ca0315 firmware: qcom: scm: Use devm_reset_controller_register() 4fb1a4207804 MAINTAINERS: add drivers/pinctrl/qcom to ARM/QUALCOMM SUPPORT 636959fc1232 pinctrl: pm8994: add pad voltage regulator defines daa6e41ce2b5 soc: qcom: wcnss_ctrl: Stub wcnss_ctrl API $ -- Kalle Valo
Re: stmmac: turn coalescing / NAPI off in stmmac
Hi!
> >>>So patch currently looks like this (hand edited, can't be
> >>>applied, got it working few hours ago). Does it look acceptable?
> >>>
> >>>I'd prefer this to go after the patch that pulls common code to single
> >>>place, so that single place needs to be patched. Plus I guess I should
> >>>add ifdefs, so that more advanced NAPI / tx coalescing code can be
> >>>reactivated when it is fixed. Trivial fixes can go on top. Does that
> >>>sound like a plan?
> >>
> >>Hmm, what I find strange is that, just this code is running since a
> >>long time on several platforms and Chip versions. No raise condition
> >>have been found or lock protection problems (also proving look
> >>mechanisms).
> >
> >Well, it works better for me when I disable CONFIG_SMP. It is normal
> >that locking problems are hard to reproduce :-(.
>
> can you share me the test, maybe I can try to reproduce on ARM box.
> Are you using 3.x or 4.x GMAC?
I'm using board similar to altera socfpga. 3.70a, as far as I can
tell.
gmac0: ethernet@ff70 {
compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a",
"snps,dwmac\
";
> >>Pavel, I ask you sorry if I missed some problems so, if you can
> >>(as D. Miller asked) to send us a cover letter + all patches
> >>I will try to reply soon. I can do also some tests if you ask
> >>me that! I could run on 3.x and 4.x but I cannot promise you
> >>benchmarks.
> >
> >Actually... I have questions here. David normally pulls from you (can
> >I have a address of your git tree?).
>
> No I send the patches to the mailing list.
Aha, ok.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues
On 12/05, Oleg Nesterov wrote:
>
> Yes, but on a second thought task_rcu_dereference() won't really help,
I forgot to explain why, see below.
> #define xxx_wait_event(xxx, event) {
> // comment to explain why
> WARN_ON(current->exit_state);
Otherwise this process/thread can be already (auto)reaped and wakeup
can't rely on rcu.
And task_rcu_dereference() can't help because it can return NULL in
this case.
Oleg.
Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
Hi, > > Actually, I was wrong. irqlock protection is needed, since > stmmac_tx_clean() is called from timer, and that's interrupt context, > as you can confirm using BUG_ON(in_interrupt()); > in_interrupt() can mean both softirq and hardirq context. In this case it means softirq. So I guess you were right before, and no irq locking is needed. Regards, Lino
[PATCH 1/1 v2] input: usbhid: fix improper return value
Function hid_post_reset() should return negative error codes on
failures. However, in its implementation, it incorrectly returns 1.
This patch fixes the bug, returning proper error codes on failures.
Signed-off-by: Pan Bian
---
drivers/hid/usbhid/hid-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index ae83af6..333108e 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -1459,7 +1459,7 @@ static int hid_post_reset(struct usb_interface *intf)
rdesc = kmalloc(hid->dev_rsize, GFP_KERNEL);
if (!rdesc) {
dbg_hid("couldn't allocate rdesc memory (post_reset)\n");
- return 1;
+ return -ENOMEM;
}
status = hid_get_class_descriptor(dev,
interface->desc.bInterfaceNumber,
@@ -1467,13 +1467,13 @@ static int hid_post_reset(struct usb_interface *intf)
if (status < 0) {
dbg_hid("reading report descriptor failed (post_reset)\n");
kfree(rdesc);
- return 1;
+ return status;
}
status = memcmp(rdesc, hid->dev_rdesc, hid->dev_rsize);
kfree(rdesc);
if (status != 0) {
dbg_hid("report descriptor changed\n");
- return 1;
+ return -EPERM;
}
/* No need to do another reset or clear a halted endpoint */
--
1.9.1
Re: [PATCH] ASoC: cq93vc: enable compiling on COMPILE_TEST
On Fri, Dec 02, 2016 at 03:59:36AM +, Kuninori Morimoto wrote: > > Hi Mark > > I posted cq93vc dependency fixup (= no depend to MFD_DAVINCI_VOICECODEC) > patch which were 2 patches. Please don't send cover letters for single patches, if there is anything that needs saying put it in the changelog of the patch or after the --- if it's administrative stuff. This reduces mail volume and ensures that any important information is recorded in the changelog rather than being lost. signature.asc Description: PGP signature
Re: [PATCH 1/3] ARM: dts: imx6: Add Savageboard common file
On Sun, Dec 4, 2016 at 11:07 PM, Milo Kim wrote:
> + regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + reg_3p3v: regulator@0 {
> + compatible = "regulator-fixed";
> + reg = <0>;
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-always-on;
> + };
Please remove the regulators container and put the regulator node
directly as follows:
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
regulator-always-on;
}
> + };
> +};
> +
> +&clks {
> + assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
> + <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
> + assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
> +<&clks IMX6QDL_CLK_PLL3_USB_OTG>;
> +};
> +
> +&fec {
> + phy-mode = "rgmii";
> + phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_HIGH>;
I think you meant
phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> +&iomuxc {
> + savageboard {
> + pinctrl_emmc: emmcgrp {
> + fsl,pins = <
> + MX6QDL_PAD_SD4_CMD__SD4_CMD
> 0x17059
> + MX6QDL_PAD_SD4_CLK__SD4_CLK
> 0x10059
> + MX6QDL_PAD_SD4_DAT0__SD4_DATA0
> 0x17059
> + MX6QDL_PAD_SD4_DAT1__SD4_DATA1
> 0x17059
> + MX6QDL_PAD_SD4_DAT2__SD4_DATA2
> 0x17059
> + MX6QDL_PAD_SD4_DAT3__SD4_DATA3
> 0x17059
> + MX6QDL_PAD_SD4_DAT4__SD4_DATA4
> 0x17059
> + MX6QDL_PAD_SD4_DAT5__SD4_DATA5
> 0x17059
> + MX6QDL_PAD_SD4_DAT6__SD4_DATA6
> 0x17059
> + MX6QDL_PAD_SD4_DAT7__SD4_DATA7
> 0x17059
> + >;
> + };
You can remove the savegeboard level. Please check
arch/arm/boot/dts/imx6q-tbs2910.dts.
iomux usually go as the last node of the dts file.
Re: [PATCH v3 4/7] PWM: add pwm driver for stm32 plaftorm
On Mon, Dec 05, 2016 at 12:02:45PM +0100, Benjamin Gaignard wrote:
> 2016-12-05 8:23 GMT+01:00 Thierry Reding :
> > On Fri, Dec 02, 2016 at 11:17:19AM +0100, Benjamin Gaignard wrote:
> >> This driver add support for pwm driver on stm32 platform.
> >
> > "adds". Also please use PWM in prose because it's an abbreviation.
> >
> >> The SoC have multiple instances of the hardware IP and each
> >> of them could have small differences: number of channels,
> >> complementary output, counter register size...
> >> Use DT parameters to handle those differentes configuration
> >
> > "different configurations"
>
> ok
>
> >
> >>
> >> version 2:
> >> - only keep one comptatible
> >> - use DT paramaters to discover hardware block configuration
> >
> > "parameters"
>
> ok
>
> >
> >>
> >> Signed-off-by: Benjamin Gaignard
> >> ---
> >> drivers/pwm/Kconfig | 8 ++
> >> drivers/pwm/Makefile| 1 +
> >> drivers/pwm/pwm-stm32.c | 285
> >>
> >> 3 files changed, 294 insertions(+)
> >> create mode 100644 drivers/pwm/pwm-stm32.c
> >>
> >> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> >> index bf01288..a89fdba 100644
> >> --- a/drivers/pwm/Kconfig
> >> +++ b/drivers/pwm/Kconfig
> >> @@ -388,6 +388,14 @@ config PWM_STI
> >> To compile this driver as a module, choose M here: the module
> >> will be called pwm-sti.
> >>
> >> +config PWM_STM32
> >> + bool "STMicroelectronics STM32 PWM"
> >> + depends on ARCH_STM32
> >> + depends on OF
> >> + select MFD_STM32_GP_TIMER
> >
> > Should that be a "depends on"?
>
> I think select is fine because the wanted feature is PWM not the mfd part
I think in that case you may want to hide the MFD Kconfig option. See
Documentation/kbuild/kconfig-language.txt (notes about select) for the
details.
[...]
> >> +};
> >> +
> >> +#define to_stm32_pwm_dev(x) container_of(chip, struct stm32_pwm_dev, chip)
> >
> > Please turn this into a static inline.
>
> with putting struct pwm_chip as first filed I will just cast the structure
Don't do that, please. container_of() is still preferred because it is
correct and won't break even if you (or somebody else) changes the order
in the future. The fact that it might be optimized away is a detail, or
a micro-optimization. Force-casting is a bad idea because it won't catch
errors if for some reason the field doesn't remain in the first position
forever.
> >> +static void stm32_pwm_disable(struct pwm_chip *chip, struct pwm_device
> >> *pwm)
> >> +{
> >> + u32 mask;
> >> + struct stm32_pwm_dev *dev = to_stm32_pwm_dev(chip);
> >> +
> >> + /* Disable channel */
> >> + mask = TIM_CCER_CC1E << (pwm->hwpwm * 4);
> >> + if (dev->caps & CAP_COMPLEMENTARY)
> >> + mask |= TIM_CCER_CC1NE << (pwm->hwpwm * 4);
> >> +
> >> + regmap_update_bits(dev->regmap, TIM_CCER, mask, 0);
> >> +
> >> + /* When all channels are disabled, we can disable the controller */
> >> + if (!__active_channels(dev))
> >> + regmap_update_bits(dev->regmap, TIM_CR1, TIM_CR1_CEN, 0);
> >> +
> >> + clk_disable(dev->clk);
> >> +}
> >
> > All of the above can be folded into the ->apply() hook for atomic PWM
> > support.
> >
> > Also, in the above you use clk_enable() in the ->enable() callback and
> > clk_disable() in ->disable(). If you need the clock to access registers
> > you'll have to enabled it in the others as well because there are no
> > guarantees that configuration will only happen between ->enable() and
> > ->disable(). Atomic PWM simplifies this a bit, but you still need to be
> > careful about when to enable the clock in your ->apply() hook.
>
> I have used regmap functions enable/disable clk for me when accessing to
> the registers.
> I only have to take care of clk enable/disable when PWM state change.
Okay, that's fine then.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH v4 5/9] media: venus: vdec: add video decoder files
I have two comments (and the same two comments apply to the video encoder patch
as well):
On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
> This consists of video decoder implementation plus decoder
> controls.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/platform/qcom/venus/vdec.c | 976
> +
> drivers/media/platform/qcom/venus/vdec.h | 32 +
> drivers/media/platform/qcom/venus/vdec_ctrls.c | 149
> 3 files changed, 1157 insertions(+)
> create mode 100644 drivers/media/platform/qcom/venus/vdec.c
> create mode 100644 drivers/media/platform/qcom/venus/vdec.h
> create mode 100644 drivers/media/platform/qcom/venus/vdec_ctrls.c
>
> diff --git a/drivers/media/platform/qcom/venus/vdec.c
> b/drivers/media/platform/qcom/venus/vdec.c
> new file mode 100644
> index ..9f585a1e0ff1
> --- /dev/null
> +++ b/drivers/media/platform/qcom/venus/vdec.c
> @@ -0,0 +1,976 @@
> +static int
> +vdec_s_selection(struct file *file, void *fh, struct v4l2_selection *s)
> +{
> + struct venus_inst *inst = to_inst(file);
> +
> + if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
> + s->target != V4L2_SEL_TGT_COMPOSE)
> + return -EINVAL;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_COMPOSE:
> + s->r.width = inst->out_width;
> + s->r.height = inst->out_height;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + s->r.top = 0;
> + s->r.left = 0;
> +
> + return 0;
> +}
This doesn't actually set anything, so what's the point of this function?
I've fixed the corresponding test in v4l2-compliance so you can now drop this
op and v4l2-compliance won't complain anymore.
> +static int vdec_start_streaming(struct vb2_queue *q, unsigned int count)
> +{
> + struct venus_inst *inst = vb2_get_drv_priv(q);
> + struct venus_core *core = inst->core;
> + struct device *dev = core->dev;
> + u32 ptype;
> + int ret;
> +
> + mutex_lock(&inst->lock);
> +
> + if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> + inst->streamon_out = 1;
> + else
> + inst->streamon_cap = 1;
> +
> + if (!(inst->streamon_out & inst->streamon_cap)) {
> + mutex_unlock(&inst->lock);
> + return 0;
> + }
> +
> + inst->reconfig = false;
> + inst->sequence = 0;
> + inst->codec_cfg = false;
> +
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0)
> + return ret;
This should be a goto so that 'helper_buffers_done(inst, VB2_BUF_STATE_QUEUED);'
is called on error.
It's wrong anyway since you don't unlock the mutex in this return path either.
> +
> + ret = vdec_init_session(inst);
> + if (ret)
> + goto put_sync;
> +
> + ret = vdec_set_properties(inst);
> + if (ret)
> + goto deinit_sess;
> +
> + if (core->res->hfi_version == HFI_VERSION_3XX) {
> + struct hfi_buffer_size_actual buf_sz;
> +
> + ptype = HFI_PROPERTY_PARAM_BUFFER_SIZE_ACTUAL;
> + buf_sz.type = HFI_BUFFER_OUTPUT;
> + buf_sz.size = inst->output_buf_size;
> +
> + ret = hfi_session_set_property(inst, ptype, &buf_sz);
> + if (ret)
> + goto deinit_sess;
> + }
> +
> + ret = vdec_verify_conf(inst);
> + if (ret)
> + goto deinit_sess;
> +
> + ret = helper_set_num_bufs(inst, inst->num_input_bufs,
> + inst->num_output_bufs);
> + if (ret)
> + goto deinit_sess;
> +
> + ret = helper_vb2_start_streaming(inst);
> + if (ret)
> + goto deinit_sess;
> +
> + mutex_unlock(&inst->lock);
> +
> + return 0;
> +
> +deinit_sess:
> + hfi_session_deinit(inst);
> +put_sync:
> + pm_runtime_put_sync(dev);
> + helper_buffers_done(inst, VB2_BUF_STATE_QUEUED);
> + if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> + inst->streamon_out = 0;
> + else
> + inst->streamon_cap = 0;
> + mutex_unlock(&inst->lock);
> + return ret;
> +}
Regards,
Hans
Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller
On Mon, Nov 28, 2016 at 03:06:23PM +0300, Mika Westerberg wrote: > This is 6th iteration of the series. You can find the previous versions > archived on: > > v5: https://lwn.net/Articles/706363/ > v4: https://lwn.net/Articles/703773/ > v3: https://lwn.net/Articles/697231/ > v2: http://lists.infradead.org/pipermail/linux-mtd/2016-June/068277.html > v1: https://lkml.org/lkml/2016/6/14/269 > > This patch series adds support for the Intel SPI serial flash controller > found on many recent Intel CPUs including Baytrail and Braswell. This > driver makes it possible to access the BIOS and other platform data which > is stored on the SPI serial flash. It is also possible to upgrade the BIOS > using this driver if it has not been protected by special hardware bits. > > The patch [1/3] includes documentation how to upgrade BIOS on MinnowBoard > MAX. > > Since poking the SPI serial flash can brick the machine, this driver can > only be enabled when CONFIG_EXPERT=y and even then it will remain read-only > unless instructed othwerwise by module parameter. Hi Lee, I think we have enough acks from the MTD maintainers. I wonder if you could merge this series via your MFD tree?
Re: [PATCH v4 1/9] media: v4l2-mem2mem: extend m2m APIs for more accurate buffer management
On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
> this add functions for:
> - remove buffers from src/dst queue by index
> - remove exact buffer from src/dst queue
>
> also extends m2m API to iterate over a list of src/dst buffers
> in safely and non-safely manner.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/media/v4l2-core/v4l2-mem2mem.c | 37 +++
> include/media/v4l2-mem2mem.h | 83
> ++
> 2 files changed, 120 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> b/drivers/media/v4l2-core/v4l2-mem2mem.c
> index 6bc27e7b2a33..d689e7bb964f 100644
> --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> @@ -126,6 +126,43 @@ void *v4l2_m2m_buf_remove(struct v4l2_m2m_queue_ctx
> *q_ctx)
> }
> EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove);
>
> +void v4l2_m2m_buf_remove_exact(struct v4l2_m2m_queue_ctx *q_ctx,
> +struct vb2_v4l2_buffer *vbuf)
I'd call this v4l2_m2m_buf_remove_by_buf to be consistent with _by_idx.
Other than that, this looks OK.
Regards,
Hans
> +{
> + struct v4l2_m2m_buffer *b;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&q_ctx->rdy_spinlock, flags);
> + b = container_of(vbuf, struct v4l2_m2m_buffer, vb);
> + list_del(&b->list);
> + q_ctx->num_rdy--;
> + spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_exact);
> +
> +struct vb2_v4l2_buffer *
> +v4l2_m2m_buf_remove_by_idx(struct v4l2_m2m_queue_ctx *q_ctx, unsigned int
> idx)
> +
> +{
> + struct v4l2_m2m_buffer *b, *tmp;
> + struct vb2_v4l2_buffer *ret = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&q_ctx->rdy_spinlock, flags);
> + list_for_each_entry_safe(b, tmp, &q_ctx->rdy_queue, list) {
> + if (b->vb.vb2_buf.index == idx) {
> + list_del(&b->list);
> + q_ctx->num_rdy--;
> + ret = &b->vb;
> + break;
> + }
> + }
> + spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_m2m_buf_remove_by_idx);
> +
> /*
> * Scheduling handlers
> */
> diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
> index 3ccd01bd245e..c8632c52d5e2 100644
> --- a/include/media/v4l2-mem2mem.h
> +++ b/include/media/v4l2-mem2mem.h
> @@ -437,6 +437,41 @@ static inline void *v4l2_m2m_next_dst_buf(struct
> v4l2_m2m_ctx *m2m_ctx)
> }
>
> /**
> + * v4l2_m2m_for_each_dst_buf() - iterate over a list of destination ready
> + * buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + */
> +#define v4l2_m2m_for_each_dst_buf(m2m_ctx, b)\
> + list_for_each_entry(b, &m2m_ctx->cap_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_src_buf() - iterate over a list of source ready buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + */
> +#define v4l2_m2m_for_each_src_buf(m2m_ctx, b)\
> + list_for_each_entry(b, &m2m_ctx->out_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_dst_buf_safe() - iterate over a list of destination
> ready
> + * buffers safely
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + */
> +#define v4l2_m2m_for_each_dst_buf_safe(m2m_ctx, b, n)\
> + list_for_each_entry_safe(b, n, &m2m_ctx->cap_q_ctx.rdy_queue, list)
> +
> +/**
> + * v4l2_m2m_for_each_src_buf_safe() - iterate over a list of source ready
> + * buffers safely
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + */
> +#define v4l2_m2m_for_each_src_buf_safe(m2m_ctx, b, n)\
> + list_for_each_entry_safe(b, n, &m2m_ctx->out_q_ctx.rdy_queue, list)
> +
> +/**
> * v4l2_m2m_get_src_vq() - return vb2_queue for source buffers
> *
> * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> @@ -488,6 +523,54 @@ static inline void *v4l2_m2m_dst_buf_remove(struct
> v4l2_m2m_ctx *m2m_ctx)
> return v4l2_m2m_buf_remove(&m2m_ctx->cap_q_ctx);
> }
>
> +/**
> + * v4l2_m2m_buf_remove_exact() - take off exact buffer from the list of ready
> + * buffers
> + *
> + * @q_ctx: pointer to struct @v4l2_m2m_queue_ctx
> + */
> +void v4l2_m2m_buf_remove_exact(struct v4l2_m2m_queue_ctx *q_ctx,
> +struct vb2_v4l2_buffer *vbuf);
> +
> +/**
> + * v4l2_m2m_src_buf_remove_exact() - take off exact source buffer from the
> list
> + * of ready buffers
> + *
> + * @m2m_ctx: m2m context assigned to the instance given by struct
> &v4l2_m2m_ctx
> + */
> +static inline void v4l2_m2m_src_buf_remove_exact(struct v4l2_m2m_ctx
> *m2m_ctx,
> + struct vb2_v4l2_buffer *vbuf)
> +{
> + v4l2_m2m_buf_remove_exact(&m2m_ctx->out_q_ctx,
Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues
Davidlohr, Peter, I'll try to read this patch later, just one note.
On 12/05, Peter Zijlstra wrote:
>
> On Fri, Dec 02, 2016 at 06:18:39PM -0800, Davidlohr Bueso wrote:
> > @@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem)
> > */
> > __this_cpu_dec(*sem->read_count);
> >
> > + rcu_read_lock();
> > + writer = rcu_dereference(sem->writer);
>
> Don't think this is correct, I think Oleg suggested using
> task_rcu_dereference(), which is a giant pile of magic.
Yes, but on a second thought task_rcu_dereference() won't really help,
but we can just use rcu_dereference().
> The problem is that task_struct isn't RCU protected as such.
Yes. But percpu_down_write() should not be used after exit_notify(), so we
can rely on rcu_read_lock(), release_task()->call_rcu(delayed_put_task_struct)
can't be called until an exiting task passes exit_notify().
But then we probably need WARN_ON(current->exit_state) in percpu_down_write().
And personally I think this change should add the new helpers, they can have
more users. Something like
struct xxx {
struct task_struct *task;
};
xxx_wake_up(struct xxx *xxx)
{
rcu_read_lock();
task = rcu_dereference(xxx->task);
if (task)
wake_up_process(task);
rcu_read_unlock();
}
#define xxx_wait_event(xxx, event) {
// comment to explain why
WARN_ON(current->exit_state);
xxx->task = current;
...
}
Oleg.
Re: [PATCH] regulator: Fix regulator_get_error_flags() signature mismatch
On Sun, Dec 4, 2016 at 11:52 PM, David Lechner wrote:
> The function signature of does not match regulator_get_error_flags()
> when CONFIG_REGULATOR is not defined vs. when it is not defined.
> This makes both declarations match to prevent compiler errors.
>
> Signed-off-by: David Lechner
> ---
> include/linux/regulator/consumer.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/regulator/consumer.h
> b/include/linux/regulator/consumer.h
> index 528eb1f..ea0fffa 100644
> --- a/include/linux/regulator/consumer.h
> +++ b/include/linux/regulator/consumer.h
> @@ -498,7 +498,8 @@ static inline unsigned int regulator_get_mode(struct
> regulator *regulator)
> return REGULATOR_MODE_NORMAL;
> }
>
> -static inline int regulator_get_error_flags(struct regulator *regulator)
> +static inline int regulator_get_error_flags(struct regulator *regulator,
> + unsigned int *flags)
> {
> return -EINVAL;
ouch, i missed this change when i modified the patch,
sorry, and thanks for fixing it David,
Regards,
-Axel.
> }
> --
> 2.7.4
>
Re: [PATCH 1/1] arm64: Correcting format specifier for printing 64 bit addresses
On Mon, Dec 05, 2016 at 01:39:53PM +0530, Maninder Singh wrote: > This patch corrects format specifier for printing 64 bit addresses. > > Signed-off-by: Maninder Singh > Signed-off-by: Vaneet Narang > --- > arch/arm64/kernel/signal.c | 2 +- > arch/arm64/kvm/sys_regs.c | 8 ++-- > arch/arm64/mm/fault.c | 15 ++- > arch/arm64/mm/mmu.c| 4 ++-- > 4 files changed, 19 insertions(+), 10 deletions(-) Any reason not to fix kvm/trace.h too? Anyway, rest of this looks fine: Acked-by: Will Deacon Will
Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
On Mon, Dec 05, 2016 at 12:08:32PM +0100, Benjamin Gaignard wrote: > 2016-12-05 7:53 GMT+01:00 Thierry Reding : > > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote: > >> Define bindings for pwm-stm32 > >> > >> version 2: > >> - use parameters instead of compatible of handle the hardware configuration > >> > >> Signed-off-by: Benjamin Gaignard > >> --- > >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 > >> ++ > >> 1 file changed, 38 insertions(+) > >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> > >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> new file mode 100644 > >> index 000..575b9fb > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > >> @@ -0,0 +1,38 @@ > >> +STMicroelectronics PWM driver bindings for STM32 > > > > Technically this bindings describe devices, so "driver binding" is a > > somewhat odd wording. Perhaps: > > > > STMicroelectronics STM32 General Purpose Timer PWM bindings > > > > ? > done > > > > >> + > >> +Must be a sub-node of STM32 general purpose timer driver > >> +Parent node properties are describe in > >> ../mfd/stm32-general-purpose-timer.txt > > > > Again, "driver parent node" is odd. Perhaps: > > > > Must be a sub-node of an STM32 General Purpose Timer device tree > > node. See ../mfd/stm32-general-purpose-timer.txt for details about > > the parent node. > > > > ? > > done > > > > >> +Required parameters: > >> +- compatible:Must be "st,stm32-pwm" > >> +- pinctrl-names: Set to "default". > >> +- pinctrl-0: List of phandles pointing to pin > >> configuration nodes > >> + for PWM module. > >> + For Pinctrl properties, please refer to [1]. > > > > Your indentation and capitalization are inconsistent. Also, please refer > > to the pinctrl bindings by relative path and inline, rather than as a > > footnote reference. > > OK > > > > >> + > >> +Optional parameters: > >> +- st,breakinput: Set if the hardware have break input capabilities > >> +- st,breakinput-polarity: Set break input polarity. Default is 0 > >> + The value define the active polarity: > >> + - 0 (active LOW) > >> + - 1 (active HIGH) > > > > Could we fold these into a single property? If st,breakinput-polarity is > > not present it could simply mean that there is no break input, and if it > > is present you don't have to rely on a default. > > I need to know if I have to activate breakinput feature and on which level > I will rewrite it like that: > Optional parameters: > - st,breakinput-polarity-high: Set if break input polarity is active > on high level. > - st,breakinput-polarity-high: Set if break input polarity is active > on low level. How is that different from a single property: Optional properties: - st,breakinput-polarity: If present, a break input is available for the channel. In that case the property value denotes the polarity of the break input: - 0: active low - 1: active high ? > > The pwm- prefix is rather redundant since the node is already named pwm. > > Why not simply st,channels? Or simply channels, since it's not really > > anything specific to this hardware. > > > > Come to think of it, might be worth having a discussion with our DT > > gurus about what their stance is on using the # as prefix for numbers > > (such as in #address-cells or #size-cells). This could be #channels to > > mark it more explicitly as representing a count. > > > >> +- st,32bits-counter: Set if the hardware have a 32 bits counter > >> +- st,complementary: Set if the hardware have complementary output > >> channels > > > > "hardware has" and also maybe mention explicitly that this is a boolean > > property. Otherwise people might be left wondering what it should be set > > to. Or maybe word this differently to imply that it's boolean: > > > > - st,32bits-counter: if present, the hardware has a 32 bit counter > > - st,complementary: if present, the hardware has a complementary > > output channel > > I found a way to detect, at probe time, the number of channels, counter size, > break input capability and complementary channels so I will remove > "st,breakinput", "st,32bits-counter", "st,complementary" and "st,pwm-num-chan" > parameters Oh hey, that's very neat. I suppose in that case my comment above about the break input polarity is somewhat obsoleted. Still I think you won't need two properties. Instead you can follow what other similar properties have done: choose a default (often low-active) and have a single optional property to override the default (often high-active). In your case: - st,breakinput-active-high: Som
RE: [PATCH] perf/x86: fix event counter update issue
On Monday, December 5, 2016 11:25 AM, Peter Zijlstra wrote: > I'll certainly, try. I've queued it as per the below. Great, thank you! Lukas
Re: [PATCH 1/3] dev_pm_qos: Improve sysfs pm_qos_latency_tolerance validation
On Tue 2016-11-29 17:11:50, Andy Lutomirski wrote:
> Negative values are special. Don't let users write them directly.
>
> Signed-off-by: Andy Lutomirski
Acked-by: Pavel Machek
> --- a/drivers/base/power/sysfs.c
> +++ b/drivers/base/power/sysfs.c
> @@ -263,7 +263,11 @@ static ssize_t pm_qos_latency_tolerance_store(struct
> device *dev,
> s32 value;
> int ret;
>
> - if (kstrtos32(buf, 0, &value)) {
> + if (kstrtos32(buf, 0, &value) == 0) {
> + /* Users can't write negative values directly */
> + if (value < 0)
> + return -EINVAL;
> + } else {
> if (!strcmp(buf, "auto") || !strcmp(buf, "auto\n"))
> value = PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT;
> else if (!strcmp(buf, "any") || !strcmp(buf, "any\n"))
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: adm80211: add checks for dma mapping errors
Alexey Khoroshilov wrote: > The driver does not check if mapping dma memory succeed. > The patch adds the checks and failure handling. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov Patch applied to wireless-drivers-next.git, thanks. d15697de60db adm80211: add checks for dma mapping errors -- https://patchwork.kernel.org/patch/9459295/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: bio linked list corruption.
On 5 December 2016 at 00:04, Vegard Nossum wrote: > FWIW I hit this as well: > > BUG: unable to handle kernel paging request at 81ff08b7 > IP: [] __lock_acquire.isra.32+0xda/0x1a30 > CPU: 0 PID: 21744 Comm: trinity-c56 Tainted: GB 4.9.0-rc7+ #217 [...] > I think you can rule out btrfs in any case, probably block layer as > well, since it looks like this comes from shmem. I should rather say that the VM runs on a 9p root filesystem and it doesn't use/mount any block devices or disk-based filesystems. I have all the trinity logs for the crash if that's useful. I tried a couple of runs with just the (at the time) in-progress syscalls but it didn't turn up anything interesting. Otherwise it seems like a lot of data to go through by hand. The crashing child seems to have just started, though, if that's relevant: [child56:21744] [0] open(filename="/sys/block/loop2/power/runtime_active_time", flags=0x777b01, mode=666) = -1 (Not a directory) [child56:21744] [1] [32BIT] sched_getattr(pid=1, param=0x7f37ec26c000, size=3415) = -1 (Invalid argument) [child56:21744] [2] [32BIT] access(filename="/proc/2/task/2/net/stat/arp_cache", mode=2000) = -1 (Invalid argument) [child56:21744] [3] getegid() = 0xfffe [child56:21744] [4] swapoff(path="/proc/721/task/721/net/dev_snmp6/tunl0") = -1 (Operation not permitted) [child56:21744] [5] timerfd_create(clockid=0x0, flags=0x0) = 439 [child56:21744] [6] pkey_mprotect(start=0x7f37ee656000, len=0, prot=0x108, key=0x600) = 0 [child56:21744] [7] msync(start=0x7f37ee657000, len=0, flags=0x6) = 0 [child56:21744] [8] flock(fd=168, cmd=0xffc191f30b0c) = -1 (Invalid argument) [child56:21744] [9] add_key(_type=0x437a15, _description=0x7f37ec06c000, _payload=0x7f37ec06c000, plen=0, ringid=0xfff8) The other logfiles end thusly: ==> trinity-child0.log <== [child0:21593] [311] faccessat(dfd=246, filename="/proc/983/task/983/net/protocols", mode=2000) = -1 (Invalid argument) [child0:21593] [312] renameat(olddfd=246, oldname="/proc/13/task/13/attr/sockcreate", newdfd=377, newname="/proc/16/task/16/net/stat/rt_cache") = -1 (Permission denied) [child0:21593] [313] [32BIT] readv(fd=289, vec=0x2e1a3d0, vlen=215) = 0 ==> trinity-child100.log <== [child100:21536] [439] setgid(gid=0x2a000200) = -1 (Operation not permitted) [child100:21536] [440] waitid(which=175, upid=21587, infop=0x4, options=3542, ru=0x7f37ec76c000) = -1 (Invalid argument) [child100:21536] [441] getxattr(pathname="/proc/980/task/980/net/ptype", name=0x7f37ee466000, value=0x7f37ec26c000, size=49) = -1 (Operation not supported) ==> trinity-child101.log <== [child101:21537] [55] getcwd(buf=0x7f37ee466000, size=4096) = 39 [child101:21537] [56] [32BIT] munlock(addr=0x7f37ee658000, len=0) = 0 [child101:21537] [57] semctl(semid=0xbd851e2b40e7df, semnum=0x1b1b1b1b1b, cmd=0x20, arg=0xcacacacaca) = -1 (Invalid argument) ==> trinity-child102.log <== [child102:21542] [11] readahead(fd=353, offset=2, count=249) = -1 (Invalid argument) [child102:21542] [12] add_key(_type=0x43793f, _description=0x7f37ec46c000, _payload=0x7f37ee658000, plen=32, ringid=0xfffa) = -1 (Invalid argument) [child102:21542] [13] time(tloc=0x7f37ee466000) = 0x584474e0 ==> trinity-child103.log <== [child103:21543] [45] dup(fildes=183) = 512 [child103:21543] [46] rt_sigpending(set=0x7f37ec86c000, sigsetsize=32) = -1 (Invalid argument) [child103:21543] [47] newstat(filename="/proc/587/task/587/gid_map", statbuf=0x7f37ee466000) = 0 ==> trinity-child104.log <== [child104:21546] [49] getdents(fd=162, dirent=0x0, count=127) = -1 (Not a directory) [child104:21546] [50] [32BIT] clock_adjtime(which_clock=0, utx=0x4) = -1 (Bad address) [child104:21546] [51] setsid() = 0x542a ==> trinity-child105.log <== [child105:21547] [523] epoll_wait(epfd=244, events=0x8, maxevents=246, timeout=-1) = -1 (Invalid argument) [child105:21547] [524] dup2(oldfd=244, newfd=244) = 244 [child105:21547] [525] acct(name=0x7f37ec26c000) = -1 (Operation not permitted) ==> trinity-child106.log <== [child106:19910] [136] getegid() = 0xfffe [child106:19910] [137] munmap(addr=0x7f37ee65a000, len=4096) = 0 [child106:19910] [138] clock_nanosleep(which_clock=0x1, flags=0x1, rqtp=0x7f37ec06c000, rmtp=0x7f37ee466000) ==> trinity-child107.log <== [child107:21224] [994] copy_file_range(fd_in=373, off_in=0x2400e210, fd_out=373, off_out=8, len=8, flags=0x0) = -1 (Bad file descriptor) [child107:21224] [995] kcmp(pid1=1, pid2=21453, type=0x5, idx1=0x787878787878, idx2=0xff6060606060) = -1 (Operation not permitted) [child107:21224] [996] [32BIT] readv(fd=365, vec=0x2e27e10, vlen=36) = 0 ==> trinity-child108.log <== [child108:21226] [759] recvfrom(fd=219, ubuf=0x7f37ec26c000, size=8, flags=0x0, addr=0x2e1ed80, addr_len=110) = -1 (Bad file descriptor) [child108:21226] [760] shmat(shmid=-4097, shmaddr=0x7f37ee465000, shmflg=-195) = -1 (Invalid argument) [child108:21226] [761] [32BIT] seccomp(op=0x0, flags=0x0, uargs=0x0) ==> trinity-child109
Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
2016-12-05 7:53 GMT+01:00 Thierry Reding : > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote: >> Define bindings for pwm-stm32 >> >> version 2: >> - use parameters instead of compatible of handle the hardware configuration >> >> Signed-off-by: Benjamin Gaignard >> --- >> .../devicetree/bindings/pwm/pwm-stm32.txt | 38 >> ++ >> 1 file changed, 38 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> >> diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> new file mode 100644 >> index 000..575b9fb >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt >> @@ -0,0 +1,38 @@ >> +STMicroelectronics PWM driver bindings for STM32 > > Technically this bindings describe devices, so "driver binding" is a > somewhat odd wording. Perhaps: > > STMicroelectronics STM32 General Purpose Timer PWM bindings > > ? done > >> + >> +Must be a sub-node of STM32 general purpose timer driver >> +Parent node properties are describe in >> ../mfd/stm32-general-purpose-timer.txt > > Again, "driver parent node" is odd. Perhaps: > > Must be a sub-node of an STM32 General Purpose Timer device tree > node. See ../mfd/stm32-general-purpose-timer.txt for details about > the parent node. > > ? done > >> +Required parameters: >> +- compatible:Must be "st,stm32-pwm" >> +- pinctrl-names: Set to "default". >> +- pinctrl-0: List of phandles pointing to pin configuration >> nodes >> + for PWM module. >> + For Pinctrl properties, please refer to [1]. > > Your indentation and capitalization are inconsistent. Also, please refer > to the pinctrl bindings by relative path and inline, rather than as a > footnote reference. OK > >> + >> +Optional parameters: >> +- st,breakinput: Set if the hardware have break input capabilities >> +- st,breakinput-polarity: Set break input polarity. Default is 0 >> + The value define the active polarity: >> + - 0 (active LOW) >> + - 1 (active HIGH) > > Could we fold these into a single property? If st,breakinput-polarity is > not present it could simply mean that there is no break input, and if it > is present you don't have to rely on a default. I need to know if I have to activate breakinput feature and on which level I will rewrite it like that: Optional parameters: - st,breakinput-polarity-high: Set if break input polarity is active on high level. - st,breakinput-polarity-high: Set if break input polarity is active on low level. >> +- st,pwm-num-chan: Number of available PWM channels. Default is 0. > > The pwm- prefix is rather redundant since the node is already named pwm. > Why not simply st,channels? Or simply channels, since it's not really > anything specific to this hardware. > > Come to think of it, might be worth having a discussion with our DT > gurus about what their stance is on using the # as prefix for numbers > (such as in #address-cells or #size-cells). This could be #channels to > mark it more explicitly as representing a count. > >> +- st,32bits-counter: Set if the hardware have a 32 bits counter >> +- st,complementary: Set if the hardware have complementary output channels > > "hardware has" and also maybe mention explicitly that this is a boolean > property. Otherwise people might be left wondering what it should be set > to. Or maybe word this differently to imply that it's boolean: > > - st,32bits-counter: if present, the hardware has a 32 bit counter > - st,complementary: if present, the hardware has a complementary > output channel I found a way to detect, at probe time, the number of channels, counter size, break input capability and complementary channels so I will remove "st,breakinput", "st,32bits-counter", "st,complementary" and "st,pwm-num-chan" parameters > > Thierry
Re: Cherryview wake up events
On Sun, Dec 04, 2016 at 07:52:19PM +0100, Johannes Stezenbach wrote: > Hi, > > On Wed, Oct 05, 2016 at 04:05:11PM +0300, Mika Westerberg wrote: > > On Wed, Oct 05, 2016 at 02:46:48PM +0200, Johannes Stezenbach wrote: > > > On Fri, Sep 23, 2016 at 11:19:04AM +0300, Mika Westerberg wrote: > > > > David (CC'd) is working on getting the Dollar Cove PMIC driver > > > > upstreamed to the mainline kernel. > > > > > > May I ask when to expect a patch? I'm ready if you > > > have something to test, even if it's not in > > > shape for mainline yet. > > > > It typically takes quite some time to get all the legal stuff done > > before the code can be published. And if people are busy with other > > things it takes even more time. > > > > So please be patient, it will happen sooner or later ;-) > > I don't want to nag, but just so it doesn't drop off > the TODO list due to "lack of interest": What's the > status? Will Santa bring the the TI Dollar Cove PMIC driver? David, do you have any estimate? > While I'm at it, I also have questions about S0ix support > in Linux which I didn't find answers to by web search. > Does S0ix depend on the PMIC driver? And will it be > used during run time or only in "sleep" state > (which would mean "echo freeze >/sys/power/state" > since ACPI S3 isn't supported)? AFAIK it is dependent only on components on the SoC. If all goes well freeze mode will enter S0ix (or it can be entered runtime as well if all drivers support runtime PM and have moved devices into D3). > Now all I know is it doesn't seem to be used so far (running 4.9.0-rc7+): > > /sys/kernel/debug/pmc_atom/sleep_state:S0IR Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I1 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I2 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I3 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0 Residency: 160934496us Yeah, seems that the system has not entered S0ix.
Re: [PATCH v3 4/7] PWM: add pwm driver for stm32 plaftorm
2016-12-05 8:23 GMT+01:00 Thierry Reding :
> On Fri, Dec 02, 2016 at 11:17:19AM +0100, Benjamin Gaignard wrote:
>> This driver add support for pwm driver on stm32 platform.
>
> "adds". Also please use PWM in prose because it's an abbreviation.
>
>> The SoC have multiple instances of the hardware IP and each
>> of them could have small differences: number of channels,
>> complementary output, counter register size...
>> Use DT parameters to handle those differentes configuration
>
> "different configurations"
ok
>
>>
>> version 2:
>> - only keep one comptatible
>> - use DT paramaters to discover hardware block configuration
>
> "parameters"
ok
>
>>
>> Signed-off-by: Benjamin Gaignard
>> ---
>> drivers/pwm/Kconfig | 8 ++
>> drivers/pwm/Makefile| 1 +
>> drivers/pwm/pwm-stm32.c | 285
>>
>> 3 files changed, 294 insertions(+)
>> create mode 100644 drivers/pwm/pwm-stm32.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index bf01288..a89fdba 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -388,6 +388,14 @@ config PWM_STI
>> To compile this driver as a module, choose M here: the module
>> will be called pwm-sti.
>>
>> +config PWM_STM32
>> + bool "STMicroelectronics STM32 PWM"
>> + depends on ARCH_STM32
>> + depends on OF
>> + select MFD_STM32_GP_TIMER
>
> Should that be a "depends on"?
I think select is fine because the wanted feature is PWM not the mfd part
>
>> + help
>> + Generic PWM framework driver for STM32 SoCs.
>> +
>> config PWM_STMPE
>> bool "STMPE expander PWM export"
>> depends on MFD_STMPE
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index 1194c54..5aa9308 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -37,6 +37,7 @@ obj-$(CONFIG_PWM_ROCKCHIP) += pwm-rockchip.o
>> obj-$(CONFIG_PWM_SAMSUNG)+= pwm-samsung.o
>> obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
>> obj-$(CONFIG_PWM_STI)+= pwm-sti.o
>> +obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
>> obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
>> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
>> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
>> diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
>> new file mode 100644
>> index 000..a362f63
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-stm32.c
>> @@ -0,0 +1,285 @@
>> +/*
>> + * Copyright (C) STMicroelectronics 2016
>> + * Author: Gerald Baeza
>
> Could use a blank line between the above. Also, please use a single
> space after : for consistency.
ok
>
>> + * License terms: GNU General Public License (GPL), version 2
>
> Here too.
OK
>
>> + *
>> + * Inspired by timer-stm32.c from Maxime Coquelin
>> + * pwm-atmel.c from Bo Shen
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>
> Please sort these alphabetically.
ok
>> +
>> +#include
>> +
>> +#define DRIVER_NAME "stm32-pwm"
>> +
>> +#define CAP_COMPLEMENTARYBIT(0)
>> +#define CAP_32BITS_COUNTER BIT(1)
>> +#define CAP_BREAKINPUT BIT(2)
>> +#define CAP_BREAKINPUT_POLARITY BIT(3)
>
> Just make these boolean. Makes the conditionals a lot simpler to read.
I will do that for v4
>> +
>> +struct stm32_pwm_dev {
>
> No need for the _dev suffix.
>
>> + struct device *dev;
>> + struct clk *clk;
>> + struct regmap *regmap;
>> + struct pwm_chip chip;
>
> It's slightly more efficient to put this as first field because then
> to_stm32_pwm() becomes a no-op.
Ok I will remove it
>
>> + int caps;
>> + int npwm;
>
> unsigned int, please.
>
>> + u32 polarity;
>
> Maybe use a prefix here to stress that it is the polarity of the
> complementary output. Otherwise one might take it for the PWM signal's
> polarity that's already part of the PWM state.
I will rename it
>
>> +};
>> +
>> +#define to_stm32_pwm_dev(x) container_of(chip, struct stm32_pwm_dev, chip)
>
> Please turn this into a static inline.
with putting struct pwm_chip as first filed I will just cast the structure
>> +
>> +static u32 __active_channels(struct stm32_pwm_dev *pwm_dev)
>
> No need for a __ prefix.
I wlll remove it
>
>> +{
>> + u32 ccer;
>> +
>> + regmap_read(pwm_dev->regmap, TIM_CCER, &ccer);
>> +
>> + return ccer & TIM_CCER_CCXE;
>> +}
>> +
>> +static int write_ccrx(struct stm32_pwm_dev *dev, struct pwm_device *pwm,
>> + u32 ccr)
>
> u32 value, perhaps? I first mistook this to be a register offset.
OK
>
>> +{
>> + switch (pwm->hwpwm) {
>> + case 0:
>> + return regmap_write(dev->regmap, TIM_CCR1, ccr);
>> + case 1:
>> + return regmap_write(dev->regmap, TIM_CCR2, ccr);
>> + case 2:
>> + return regmap_write(dev->regmap, TIM_CCR3, ccr);
>> + case 3:
>> + return regmap_write(dev->regmap, TIM_CCR4, ccr);
>> + }
>> + return -EINVAL;
>> +}
>>
Re: Unkillable processes due to PTRACE_TRACEME again
On 12/05, Oleg Nesterov wrote:
>
> On 12/02, Dmitry Vyukov wrote:
> >
> > I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> > the same unwaitable zombie processes.
>
> This is another thing, and notabug. This is how ptrace works,
>
> > void *thr(void *arg)
> > {
> > ptrace(PTRACE_TRACEME, 0, 0, 0);
> > }
> >
> > int main()
> > {
> > int pid = fork();
> > if (pid == 0) {
> > pthread_t th;
> > pthread_create(&th, 0, thr, 0);
> > usleep(10);
> > exit(0);
> > }
> > usleep(20);
> > kill(pid, SIGKILL);
> > int status = 0;
> > waitpid(pid, &status, __WALL);
>
> waitpid(pid) hangs because you need to reap the sub-thread first.
I'm afraid I wasn't clear...
So the child process has 2 threads, the leader thread L and the sub-thread T.
waitpid(pid == L->pid) will block until all the threads go away, but since T is
traced it won't autoreap, the tracer should do waitpid(T->pid) first to reap
this zombie. waitpid(-1) should work too.
Oleg.
[PATCH v8 4/6] powerpc/pv-qspinlock: powerpc support pv-qspinlock
The default pv-qspinlock uses qspinlock(native version of pv-qspinlock).
pv_lock initialization should be done in bootstage with irq disabled.
And if we run as a guest with powerKVM/pHyp shared_processor mode,
restore pv_lock_ops callbacks to pv-qspinlock(pv version) which makes
full use of virtualization.
There is a hash table, we store cpu number into it and the key is lock.
So everytime pv_wait can know who is the lock holder by searching the
lock. Also store the lock in a per_cpu struct, and remove it when we own
the lock. Then pv_wait can know which lock we are spinning on. But the
cpu in the hash table might not be the correct lock holder, as for
performace issue, we does not take care of hash conflict.
Also introduce spin_lock_holder, which tells who owns the lock now.
currently the only user is spin_unlock_wait.
Signed-off-by: Pan Xinhui
---
arch/powerpc/include/asm/qspinlock.h | 29 +++-
arch/powerpc/include/asm/qspinlock_paravirt.h | 36 +
.../powerpc/include/asm/qspinlock_paravirt_types.h | 13 ++
arch/powerpc/kernel/paravirt.c | 153 +
arch/powerpc/lib/locks.c | 8 +-
arch/powerpc/platforms/pseries/setup.c | 5 +
6 files changed, 241 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/include/asm/qspinlock_paravirt.h
create mode 100644 arch/powerpc/include/asm/qspinlock_paravirt_types.h
create mode 100644 arch/powerpc/kernel/paravirt.c
diff --git a/arch/powerpc/include/asm/qspinlock.h
b/arch/powerpc/include/asm/qspinlock.h
index 4c89256..8fd6349 100644
--- a/arch/powerpc/include/asm/qspinlock.h
+++ b/arch/powerpc/include/asm/qspinlock.h
@@ -15,7 +15,7 @@ static inline u8 *__qspinlock_lock_byte(struct qspinlock
*lock)
return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
}
-static inline void queued_spin_unlock(struct qspinlock *lock)
+static inline void native_queued_spin_unlock(struct qspinlock *lock)
{
/* release semantics is required */
smp_store_release(__qspinlock_lock_byte(lock), 0);
@@ -27,6 +27,33 @@ static inline int queued_spin_is_locked(struct qspinlock
*lock)
return atomic_read(&lock->val);
}
+#ifdef CONFIG_PARAVIRT_SPINLOCKS
+#include
+/*
+ * try to know who is the lock holder, however it is not always true
+ * Return:
+ * -1, we did not know the lock holder.
+ * other value, likely is the lock holder.
+ */
+extern int spin_lock_holder(void *lock);
+
+static inline void queued_spin_lock_slowpath(struct qspinlock *lock, u32 val)
+{
+ pv_queued_spin_lock(lock, val);
+}
+
+static inline void queued_spin_unlock(struct qspinlock *lock)
+{
+ pv_queued_spin_unlock(lock);
+}
+#else
+#define spin_lock_holder(l) (-1)
+static inline void queued_spin_unlock(struct qspinlock *lock)
+{
+ native_queued_spin_unlock(lock);
+}
+#endif
+
#include
/* we need override it as ppc has io_sync stuff */
diff --git a/arch/powerpc/include/asm/qspinlock_paravirt.h
b/arch/powerpc/include/asm/qspinlock_paravirt.h
new file mode 100644
index 000..d87cda0
--- /dev/null
+++ b/arch/powerpc/include/asm/qspinlock_paravirt.h
@@ -0,0 +1,36 @@
+#ifndef CONFIG_PARAVIRT_SPINLOCKS
+#error "do not include this file"
+#endif
+
+#ifndef _ASM_QSPINLOCK_PARAVIRT_H
+#define _ASM_QSPINLOCK_PARAVIRT_H
+
+#include
+
+extern void pv_lock_init(void);
+extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __pv_init_lock_hash(void);
+extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
+extern void __pv_queued_spin_unlock(struct qspinlock *lock);
+
+static inline void pv_queued_spin_lock(struct qspinlock *lock, u32 val)
+{
+ pv_lock_op.lock(lock, val);
+}
+
+static inline void pv_queued_spin_unlock(struct qspinlock *lock)
+{
+ pv_lock_op.unlock(lock);
+}
+
+static inline void pv_wait(u8 *ptr, u8 val)
+{
+ pv_lock_op.wait(ptr, val);
+}
+
+static inline void pv_kick(int cpu)
+{
+ pv_lock_op.kick(cpu);
+}
+
+#endif
diff --git a/arch/powerpc/include/asm/qspinlock_paravirt_types.h
b/arch/powerpc/include/asm/qspinlock_paravirt_types.h
new file mode 100644
index 000..83611ed
--- /dev/null
+++ b/arch/powerpc/include/asm/qspinlock_paravirt_types.h
@@ -0,0 +1,13 @@
+#ifndef _ASM_QSPINLOCK_PARAVIRT_TYPES_H
+#define _ASM_QSPINLOCK_PARAVIRT_TYPES_H
+
+struct pv_lock_ops {
+ void (*lock)(struct qspinlock *lock, u32 val);
+ void (*unlock)(struct qspinlock *lock);
+ void (*wait)(u8 *ptr, u8 val);
+ void (*kick)(int cpu);
+};
+
+extern struct pv_lock_ops pv_lock_op;
+
+#endif
diff --git a/arch/powerpc/kernel/paravirt.c b/arch/powerpc/kernel/paravirt.c
new file mode 100644
index 000..e697b17
--- /dev/null
+++ b/arch/powerpc/kernel/paravirt.c
@@ -0,0 +1,153 @@
+/*
+ * 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 Foundatio
Re: [PATCH v9 07/16] drivers: acpi: implement acpi_dma_configure
On Mon, Dec 05, 2016 at 03:22:02PM +0530, Sricharan wrote:
> Hi Lorenzo,
>
> >
> >On Sat, Dec 3, 2016 at 11:39 AM, Lorenzo Pieralisi
> > wrote:
> >> On Sat, Dec 03, 2016 at 03:11:09AM +0100, Rafael J. Wysocki wrote:
> >>> On Fri, Dec 2, 2016 at 4:38 PM, Lorenzo Pieralisi
> >>> wrote:
> >>> > Rafael, Mark, Suravee,
> >>> >
> >>> > On Mon, Nov 21, 2016 at 10:01:39AM +, Lorenzo Pieralisi wrote:
> >>> >> On DT based systems, the of_dma_configure() API implements DMA
> >>> >> configuration for a given device. On ACPI systems an API equivalent to
> >>> >> of_dma_configure() is missing which implies that it is currently not
> >>> >> possible to set-up DMA operations for devices through the ACPI generic
> >>> >> kernel layer.
> >>> >>
> >>> >> This patch fills the gap by introducing
> >>> >> acpi_dma_configure/deconfigure()
> >>> >> calls that for now are just wrappers around arch_setup_dma_ops() and
> >>> >> arch_teardown_dma_ops() and also updates ACPI and PCI core code to use
> >>> >> the newly introduced acpi_dma_configure/acpi_dma_deconfigure functions.
> >>> >>
> >>> >> Since acpi_dma_configure() is used to configure DMA operations, the
> >>> >> function initializes the dma/coherent_dma masks to sane default values
> >>> >> if the current masks are uninitialized (also to keep the default values
> >>> >> consistent with DT systems) to make sure the device has a complete
> >>> >> default DMA set-up.
> >>> >
> >>> > I spotted a niggle that unfortunately was hard to spot (and should not
> >>> > be a problem per se but better safe than sorry) and I am not comfortable
> >>> > with it.
> >>> >
> >>> > Following commit d0562674838c ("ACPI / scan: Parse _CCA and setup
> >>> > device coherency") in acpi_bind_one() we check if the acpi_device
> >>> > associated with a device just added supports DMA, first it was
> >>> > done with acpi_check_dma() and then commit 1831eff876bd ("device
> >>> > property: ACPI: Make use of the new DMA Attribute APIs") changed
> >>> > it to acpi_get_dma_attr().
> >>> >
> >>> > The subsequent check (attr != DEV_DMA_NOT_SUPPORTED) is always true
> >>> > on _any_ acpi device we pass to acpi_bind_one() on x86, which was
> >>> > fine because we used it to call arch_setup_dma_ops(), which is a nop
> >>> > on x86. On ARM64 a _CCA method is required to define if a device
> >>> > supports DMA so (attr != DEV_DMA_NOT_SUPPORTED) may well be false.
> >>> >
> >>> > Now, acpi_bind_one() is used to bind an acpi_device to its physical
> >>> > node also for pseudo-devices like cpus and memory nodes. For those
> >>> > objects, on x86, attr will always be != DEV_DMA_NOT_SUPPORTED.
> >>> >
> >>> > So far so good, because on x86 arch_setup_dma_ops() is empty code.
> >>> >
> >>> > With this patch, I use the (attr != DEV_DMA_NOT_SUPPORTED) check
> >>> > to call acpi_dma_configure() which is basically a nop on x86 except
> >>> > that it sets up the dma_mask/coherent_dma_mask to a sane default value
> >>> > (after all we are setting up DMA for the device so it makes sense to
> >>> > initialize the masks there if they were unset since we are configuring
> >>> > DMA for the device in question) for the given device.
> >>> >
> >>> > Problem is, as per the explanation above, we are also setting the
> >>> > default dma masks for pseudo-devices (eg CPUs) that were previously
> >>> > untouched, it should not be a problem per-se but I am not comfortable
> >>> > with that, honestly it does not make much sense.
> >>> >
> >>> > An easy "fix" would be to move the default dma masks initialization out
> >>> > of acpi_dma_configure() (as it was in previous patch versions of this
> >>> > series - I moved it to acpi_dma_configure() just a consolidation point
> >>> > for initializing the masks instead of scattering them in every
> >>> > acpi_dma_configure caller) I can send this as a fix-up patch to Joerg if
> >>> > we think that's the right thing to do (or I can send it to Rafael later
> >>> > when the code is in the merged depending on the timing) just let me
> >>> > know please.
> >>>
> >>> Why can't arch_setup_dma_ops() set those masks too?
> >>
> >> Because the dma masks set-up is done by the caller (see
> >> of_dma_configure()) according to firmware configuration or
> >> platform data knowledge. I wanted to replicate the of_dma_configure()
> >> interface on ACPI for obvious reasons (on ARM systems), I stopped
> >> short of adding ACPI code to mirror of_dma_get_range() equivalent
> >> (through the _DMA object) but I am really really nervous about changing
> >> the code path on x86 because in theory all is fine, in practice even
> >> just setting the masks to sane values can have unexpected consequences,
> >> I just can't know (that's why I wasn't doing it in the first iterations
> >> of this series).
> >>
> >> Side note: DT with of_dma_configure() and ACPI with
> >> acpi_create_platform_device() set the default dma mask for all
> >> platform devices already _regardless_ of what they really are, though
> >> arguably acpi_b
RE: [patch net v2] net: fec: fix compile with CONFIG_M5272
From: Nikita Yushchenko Sent: Monday,
December 05, 2016 4:16 PM
>To: David S. Miller ; Andy Duan
>; Troy Kisky ;
>Andrew Lunn ; Eric Nelson ; Philippe
>Reynes ; Johannes Berg ;
>net...@vger.kernel.org
>Cc: Chris Healy ; Fabio Estevam
>; linux-kernel@vger.kernel.org; Nikita
>Yushchenko
>Subject: [patch net v2] net: fec: fix compile with CONFIG_M5272
>
>Commit 4dfb80d18d05 ("net: fec: cache statistics while device is down")
>introduced unconditional statistics-related actions.
>
>However, when driver is compiled with CONFIG_M5272, staticsics-related
>definitions do not exist, which results into build errors.
>
>Fix that by adding explicit handling of !defined(CONFIG_M5272) case.
>
>Fixes: 4dfb80d18d05 ("net: fec: cache statistics while device is down")
>Signed-off-by: Nikita Yushchenko
>---
>Changes since v1:
>- instead of #ifdef'ing calls to fec_enet_update_ethtool_stats(), add
> definition of empty fec_enet_update_ethtool_stats() for CONFIG_M5272
> case,
>- add FEC_STATS_SIZE macro to avoid #ifdef in the middle of
> alloc_etherdev_mqs() args.
>
> drivers/net/ethernet/freescale/fec_main.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
Acked-by: Fugang Duan
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index 5f77caa59534..741cf4a57bfc 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -2313,6 +2313,8 @@ static const struct fec_stat {
> { "IEEE_rx_octets_ok", IEEE_R_OCTETS_OK }, };
>
>+#define FEC_STATS_SIZE (ARRAY_SIZE(fec_stats) * sizeof(u64))
>+
> static void fec_enet_update_ethtool_stats(struct net_device *dev) {
> struct fec_enet_private *fep = netdev_priv(dev); @@ -2330,7
>+2332,7 @@ static void fec_enet_get_ethtool_stats(struct net_device *dev,
> if (netif_running(dev))
> fec_enet_update_ethtool_stats(dev);
>
>- memcpy(data, fep->ethtool_stats, ARRAY_SIZE(fec_stats) *
>sizeof(u64));
>+ memcpy(data, fep->ethtool_stats, FEC_STATS_SIZE);
> }
>
> static void fec_enet_get_strings(struct net_device *netdev, @@ -2355,6
>+2357,12 @@ static int fec_enet_get_sset_count(struct net_device *dev, int
>sset)
> return -EOPNOTSUPP;
> }
> }
>+
>+#else/* !defined(CONFIG_M5272) */
>+#define FEC_STATS_SIZE 0
>+static inline void fec_enet_update_ethtool_stats(struct net_device
>+*dev) { }
> #endif /* !defined(CONFIG_M5272) */
>
> static int fec_enet_nway_reset(struct net_device *dev) @@ -3293,8
>+3301,7 @@ fec_probe(struct platform_device *pdev)
>
> /* Init network device */
> ndev = alloc_etherdev_mqs(sizeof(struct fec_enet_private) +
>- ARRAY_SIZE(fec_stats) * sizeof(u64),
>- num_tx_qs, num_rx_qs);
>+ FEC_STAT_SIZE, num_tx_qs, num_rx_qs);
> if (!ndev)
> return -ENOMEM;
>
>--
>2.1.4
Re: net/can: warning in raw_setsockopt/__alloc_pages_slowpath
On 12/02/2016 06:05 PM, Oliver Hartkopp wrote:
>
>
> On 12/02/2016 04:42 PM, Marc Kleine-Budde wrote:
>> On 12/02/2016 04:11 PM, Oliver Hartkopp wrote:
>>>
>>>
>>> On 12/02/2016 02:24 PM, Marc Kleine-Budde wrote:
On 12/02/2016 01:43 PM, Andrey Konovalov wrote:
>>>
>>>
> [] raw_setsockopt+0x1be/0x9f0 net/can/raw.c:506
We should add a check for a sensible optlen
> static int raw_setsockopt(struct socket *sock, int level, int optname,
> char __user *optval, unsigned int optlen)
> {
> struct sock *sk = sock->sk;
> struct raw_sock *ro = raw_sk(sk);
> struct can_filter *filter = NULL; /* dyn. alloc'ed filters */
> struct can_filter sfilter; /* single filter */
> struct net_device *dev = NULL;
> can_err_mask_t err_mask = 0;
> int count = 0;
> int err = 0;
>
> if (level != SOL_CAN_RAW)
> return -EINVAL;
>
> switch (optname) {
>
> case CAN_RAW_FILTER:
> if (optlen % sizeof(struct can_filter) != 0)
> return -EINVAL;
here...
if (optlen > 64 * sizeof(struct can_filter))
return -EINVAL;
>>>
>>> Agreed.
>>>
>>> But what is sensible here?
>>> 64 filters is way to small IMO.
>>>
>>> When thinking about picking a bunch of single CAN IDs I would tend to
>>> something like 512 filters.
>>
>> Ok - 64 was just an arbitrary chosen value for demonstration purposes :)
>>
>
> :-)
>
> Would you like to send a patch?
Yes, how many Filters? 512? Can you test, as I don't have the setup ready?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[PATCH] objtool: fix bytes check of lea's rex_prefix
For the "lea %(rsp), %rbp" case, we check if there is a rex_prefix. But we check "bytes" which is insn_byte_t[4] in rex_prefix (insn_field structure). Therefore, the check is always true. Instead, check nbytes which is the right one. Signed-off-by: Jiri Slaby Cc: Josh Poimboeuf --- tools/objtool/arch/x86/decode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/objtool/arch/x86/decode.c b/tools/objtool/arch/x86/decode.c index b63a31be1218..5e0dea2cdc01 100644 --- a/tools/objtool/arch/x86/decode.c +++ b/tools/objtool/arch/x86/decode.c @@ -99,7 +99,7 @@ int arch_decode_instruction(struct elf *elf, struct section *sec, break; case 0x8d: - if (insn.rex_prefix.bytes && + if (insn.rex_prefix.nbytes && insn.rex_prefix.bytes[0] == 0x48 && insn.modrm.nbytes && insn.modrm.bytes[0] == 0x2c && insn.sib.nbytes && insn.sib.bytes[0] == 0x24) -- 2.11.0
Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend
Hi David,
Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
> During suspend there may still be some i2c access happening.
> And if we don't keep i2c irq ON, there may be i2c access timeout if
> i2c is in irq mode of operation.
can you describe the issue you're trying to fix a bit more please?
I.e. I'd think the i2c-core does suspend i2c-client devices first, so that
these should be able to finish up their ongoing transfers and not start any
new ones instead?
Your irq can still happen slightly after the system started going to actually
sleep, so to me it looks like you just widened the window where irqs can be
handled. Especially as your irq could also just simply stem from the start
state, so you cannot even be sure if your transaction actually is finished.
So to me it looks like the i2c-connected device driver should be fixed instead?
In the past I solved this for example in the zforce_ts driver [0] to
prevent i2c transfers from happening during suspend.
Heiko
[0]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/input/touchscreen/zforce_ts.c
>
> Signed-off-by: David Wu
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index df22066..67af32a 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1261,7 +1261,7 @@ static int rk3x_i2c_probe(struct platform_device
> *pdev) }
>
> ret = devm_request_irq(&pdev->dev, irq, rk3x_i2c_irq,
> -0, dev_name(&pdev->dev), i2c);
> +IRQF_NO_SUSPEND, dev_name(&pdev->dev), i2c);
> if (ret < 0) {
> dev_err(&pdev->dev, "cannot request IRQ\n");
> return ret;
Re: [PATCH v3 3/7] PWM: add pwm-stm32 DT bindings
On Mon, Dec 05, 2016 at 08:35:35AM +, Lee Jones wrote: > On Mon, 05 Dec 2016, Thierry Reding wrote: > > > On Fri, Dec 02, 2016 at 11:17:18AM +0100, Benjamin Gaignard wrote: > > > Define bindings for pwm-stm32 > > > > > > version 2: > > > - use parameters instead of compatible of handle the hardware > > > configuration > > > > > > Signed-off-by: Benjamin Gaignard > > > --- > > > .../devicetree/bindings/pwm/pwm-stm32.txt | 38 > > > ++ > > > 1 file changed, 38 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt > > > > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > > > b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > > > new file mode 100644 > > > index 000..575b9fb > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt > > > @@ -0,0 +1,38 @@ > > > +STMicroelectronics PWM driver bindings for STM32 > > > > Technically this bindings describe devices, so "driver binding" is a > > somewhat odd wording. Perhaps: > > > > STMicroelectronics STM32 General Purpose Timer PWM bindings > > > > ? > > > > > + > > > +Must be a sub-node of STM32 general purpose timer driver > > > +Parent node properties are describe in > > > ../mfd/stm32-general-purpose-timer.txt > > > > Again, "driver parent node" is odd. Perhaps: > > > > Must be a sub-node of an STM32 General Purpose Timer device tree > > node. See ../mfd/stm32-general-purpose-timer.txt for details about > > the parent node. > > > > ? > > > > > +Required parameters: > > > +- compatible:Must be "st,stm32-pwm" > > > +- pinctrl-names: Set to "default". > > > +- pinctrl-0: List of phandles pointing to pin configuration > > > nodes > > > + for PWM module. > > > + For Pinctrl properties, please refer to [1]. > > > > Your indentation and capitalization are inconsistent. Also, please refer > > to the pinctrl bindings by relative path and inline, rather than as a > > footnote reference. > > > > > + > > > +Optional parameters: > > > +- st,breakinput: Set if the hardware have break input capabilities > > > +- st,breakinput-polarity: Set break input polarity. Default is 0 > > > + The value define the active polarity: > > > + - 0 (active LOW) > > > + - 1 (active HIGH) > > > > Could we fold these into a single property? If st,breakinput-polarity is > > not present it could simply mean that there is no break input, and if it > > is present you don't have to rely on a default. > > > > > +- st,pwm-num-chan: Number of available PWM channels. Default is 0. > > > > The pwm- prefix is rather redundant since the node is already named pwm. > > Why not simply st,channels? Or simply channels, since it's not really > > anything specific to this hardware. > > > > Come to think of it, might be worth having a discussion with our DT > > gurus about what their stance is on using the # as prefix for numbers > > (such as in #address-cells or #size-cells). This could be #channels to > > mark it more explicitly as representing a count. > > Unfortunately that ship has sailed. > > st,pwm-num-chan already exists (with your blessing). It's usually I think I did at the time object, though very mildly. The property here is somewhat different, though. For one this is a PWM specific node, so the pwm- prefix is completely redundant. Also for pwm-sti where you had introduced st,pwm-num-chan, the property denoted how many PWM channels vs. capture channels (st,capture-num-chan) the device was supposed to use. Here there are only one type of channels. > suggested to reuse exiting properties when writing new bindings. Given the above I think this case is different. Further my understanding is that the desire to reuse existing properties is primarily for generic properties. Vendor specific properties are always going to have to be defined in the specific bindings, so it doesn't matter very much whether they are reused or not. Lastly, I think st,pwm-num-chan is not optimal, and while it isn't very bad either, I do believe that when we see ways of improving things then we should do so, regardless of whether existing ways to describe things already exist. Especially if it comes at no additional cost. All of that said, this is my opinion and if everybody thinks that the st,pwm-num-chan is the better choice I'll merge it. Anyway, we'll need the Acked-by from one of the device tree bindings maintainers and I'd like to see at least an attempt at a discussion. Thierry signature.asc Description: PGP signature
[PATCH v2] crypto: sun4i-ss: support the Security System PRNG
From: LABBE Corentin
The Security System have a PRNG.
This patch add support for it as an hwrng.
Signed-off-by: Corentin Labbe
---
Changes since v1:
- Replaced all spin_lock_bh by simple spin_lock
- Removed handling of size not modulo 4 which will never happen
- Added add_random_ready_callback()
drivers/crypto/Kconfig | 8 +++
drivers/crypto/sunxi-ss/Makefile | 1 +
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 14 +
drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c | 99
drivers/crypto/sunxi-ss/sun4i-ss.h | 9 +++
5 files changed, 131 insertions(+)
create mode 100644 drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 4d2b81f..38f7aca 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -538,6 +538,14 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_SUN4I_SS_PRNG
+ bool "Support for Allwinner Security System PRNG"
+ depends on CRYPTO_DEV_SUN4I_SS
+ select HW_RANDOM
+ help
+ This driver provides kernel-side support for the Pseudo-Random
+ Number Generator found in the Security System.
+
config CRYPTO_DEV_ROCKCHIP
tristate "Rockchip's Cryptographic Engine driver"
depends on OF && ARCH_ROCKCHIP
diff --git a/drivers/crypto/sunxi-ss/Makefile b/drivers/crypto/sunxi-ss/Makefile
index 8f4c7a2..ca049ee 100644
--- a/drivers/crypto/sunxi-ss/Makefile
+++ b/drivers/crypto/sunxi-ss/Makefile
@@ -1,2 +1,3 @@
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sun4i-ss.o
sun4i-ss-y += sun4i-ss-core.o sun4i-ss-hash.o sun4i-ss-cipher.o
+sun4i-ss-$(CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG) += sun4i-ss-hwrng.o
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 3ac6c6c..fa739de 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -359,6 +359,16 @@ static int sun4i_ss_probe(struct platform_device *pdev)
}
}
platform_set_drvdata(pdev, ss);
+
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ /* Voluntarily made the PRNG optional */
+ err = sun4i_ss_hwrng_register(&ss->hwrng);
+ if (!err)
+ dev_info(ss->dev, "sun4i-ss PRNG loaded");
+ else
+ dev_err(ss->dev, "sun4i-ss PRNG failed");
+#endif
+
return 0;
error_alg:
i--;
@@ -386,6 +396,10 @@ static int sun4i_ss_remove(struct platform_device *pdev)
int i;
struct sun4i_ss_ctx *ss = platform_get_drvdata(pdev);
+#ifdef CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG
+ sun4i_ss_hwrng_remove(&ss->hwrng);
+#endif
+
for (i = 0; i < ARRAY_SIZE(ss_algs); i++) {
switch (ss_algs[i].type) {
case CRYPTO_ALG_TYPE_ABLKCIPHER:
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
new file mode 100644
index 000..8319cae
--- /dev/null
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c
@@ -0,0 +1,99 @@
+#include "sun4i-ss.h"
+
+static void sun4i_ss_seed(struct random_ready_callback *rdy)
+{
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(rdy, struct sun4i_ss_ctx, random_ready);
+ get_random_bytes(ss->seed, SS_SEED_LEN);
+ ss->random_ready.func = NULL;
+}
+
+static int sun4i_ss_hwrng_init(struct hwrng *hwrng)
+{
+ struct sun4i_ss_ctx *ss;
+ int ret;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+
+ ss->random_ready.owner = THIS_MODULE;
+ ss->random_ready.func = sun4i_ss_seed;
+
+ ret = add_random_ready_callback(&ss->random_ready);
+ switch (ret) {
+ case 0:
+ break;
+ case -EALREADY:
+ get_random_bytes(ss->seed, SS_SEED_LEN);
+ ss->random_ready.func = NULL;
+ ret = 0;
+ break;
+ default:
+ ss->random_ready.func = NULL;
+ }
+
+ return ret;
+}
+
+static int sun4i_ss_hwrng_read(struct hwrng *hwrng, void *buf,
+ size_t max, bool wait)
+{
+ int i;
+ u32 v;
+ u32 *data = buf;
+ const u32 mode = SS_OP_PRNG | SS_PRNG_CONTINUE | SS_ENABLED;
+ size_t len;
+ struct sun4i_ss_ctx *ss;
+
+ ss = container_of(hwrng, struct sun4i_ss_ctx, hwrng);
+ len = min_t(size_t, SS_DATA_LEN, max);
+
+ /* If the PRNG is not seeded */
+ if (ss->random_ready.func)
+ return -EAGAIN;
+
+ spin_lock(&ss->slock);
+
+ writel(mode, ss->base + SS_CTL);
+
+ /* write the seed */
+ for (i = 0; i < SS_SEED_LEN / 4; i++)
+ writel(ss->seed[i], ss->base + SS_KEY0 + i * 4);
+ writel(mode | SS_PRNG_START, ss->base + SS_CTL);
+
+ /* Read the random data */
+ readsl(ss->base + SS_TXFIFO, data, len / 4);
+
+ /* Update the seed */
+ for (i
Re: Build regressions/improvements in v4.9-rc8
On Mon, Dec 5, 2016 at 10:09 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.9-rc8[1] to v4.9-rc7[3], the summaries are:
> - build errors: +5/-10
+ /home/kisskb/slave/src/drivers/net/ethernet/freescale/fec_main.c:
error: 'fec_stats' undeclared (first use in this function): => 3296:7
+ /home/kisskb/slave/src/drivers/net/ethernet/freescale/fec_main.c:
error: implicit declaration of function
'fec_enet_update_ethtool_stats'
[-Werror=implicit-function-declaration]: => 2887:2
+ /home/kisskb/slave/src/drivers/net/ethernet/freescale/fec_main.c:
error: negative width in bit-field '': => 3296:7
+ /home/kisskb/slave/tmp/ccJlHrOq.s: Error: pcrel too far
BFD_RELOC_BFIN_10: => 912
m68k/m5272c3_defconfig (patch available)
> [1]
> http://kisskb.ellerman.id.au/kisskb/head/3e5de27e940d00d8d504dfb96625fb654f641509/
> (all 267 configs)
> [3]
> http://kisskb.ellerman.id.au/kisskb/head/e5517c2a5a49ed5e99047008629f1cd60246ea0e/
> (all 267 configs)
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: Unkillable processes due to PTRACE_TRACEME again
On 12/02, Dmitry Vyukov wrote:
>
> I am not on 2caceb3294a78c389b462e7e236a4e744a53a474 (Dec 1). And see
> the same unwaitable zombie processes.
This is another thing, and notabug. This is how ptrace works,
> void *thr(void *arg)
> {
> ptrace(PTRACE_TRACEME, 0, 0, 0);
> }
>
> int main()
> {
> int pid = fork();
> if (pid == 0) {
> pthread_t th;
> pthread_create(&th, 0, thr, 0);
> usleep(10);
> exit(0);
> }
> usleep(20);
> kill(pid, SIGKILL);
> int status = 0;
> waitpid(pid, &status, __WALL);
waitpid(pid) hangs because you need to reap the sub-thread first.
Oleg.
[RFC PATCH] kernel/sysctl: detect overflows when converting to uint
Commit 230633d109e3 ("kernel/sysctl.c: detect overflows when converting
to int") prevented writing to sysctl entries when integer overflow occurs.
However, this does not apply to unsigned integers.
To fix this, commit e7d316a02f68 ("sysctl: handle error writing UINT_MAX
to u32 fields") introduce a new proc handler proc_douintvec, however do
not handle the overflowing of unsigned int.
E.g. on a system where int has 32 bits and long has 64 bits
echo 0x11234 > /proc/sys/net/core/xfrm_aevent_etime
has the same effect as
echo 0x1234 > /proc/sys/net/core/xfrm_aevent_etime
The patch adds the missing check in do_proc_douintvec_conv.
With the patch an overflow of unsigned int will result in an error
EINVAL when writing to the the sysctl file system.
Signed-off-by: Yisheng Xie
---
kernel/sysctl.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 706309f..762ecf3 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2146,6 +2146,10 @@ static int do_proc_douintvec_conv(bool *negp, unsigned
long *lvalp,
if (write) {
if (*negp)
return -EINVAL;
+
+ if (*lvalp > (unsigned long) UINT_MAX)
+ return -EINVAL;
+
*valp = *lvalp;
} else {
unsigned int val = *valp;
--
1.7.12.4
Re: e1000e on Thinkpad x60: gigabit not available due to "SmartSpeed"
On Fri 2016-09-02 12:57:35, Lennart Sorensen wrote: > On Thu, Sep 01, 2016 at 02:58:13PM -0700, Greg wrote: > > On Thu, 2016-09-01 at 22:14 +0200, Pavel Machek wrote: > > > Hi! > > > > > > I have trouble getting 1000mbit out of my ethernet card. > > > > > > I tried direct connection between two PCs with different cables, and > > > no luck. > > > > > > Today I tried connection to 1000mbit switch, and no luck, either. (Two > > > cables, one was cat6, both short). > > > > > > My computer sees 1000mbit being advertised by the other side, but does > > > not advertise 1000mbit, "Link Speed was downgraded by SmartSpeed". > > > > Check your cables? > > > > https://vmxp.wordpress.com/2015/01/06/1gbe-intel-nic-throttled-to-100mbit-by-smartspeed/ > > Of course if it isn't the cable, then it could even be a broken pin in > the port. As far as I can tell, anything that causes one of the 3rd > or 4th pairs of wires to not work will degrade to 100Mbit on just the > first 2 pairs of wires and give that message. Some badly implemented > switches can also cause it of course. Ok, so it seems like broken pin in the port. I realized I had docking station available for the machine, and when connecting using that connector (not internal notebook one), I get gigabit speed. Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3 3/3] ARM: da850: fix da850_set_pll0rate()
On Monday 05 December 2016 03:39 PM, Bartosz Golaszewski wrote:
> This function is confusing - its second argument is an index to the
> freq table, not the requested clock rate in Hz, but it's used as the
> set_rate callback for the pll0 clock. It leads to an oops when the
> caller doesn't know the internals and passes the rate in Hz as
> argument instead of the cpufreq index since this argument isn't bounds
> checked either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Also: update the davinci cpufreq driver. It's the only user of this
> clock and currently it passes the cpufreq table index to
> clk_set_rate(), which is confusing. Make it pass the requested clock
> rate in Hz.
>
> Signed-off-by: Bartosz Golaszewski
> Acked-by: Viresh Kumar
> ---
> arch/arm/mach-davinci/da850.c | 20
> drivers/cpufreq/davinci-cpufreq.c | 2 +-
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 006ec56..9837541 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1179,14 +1179,26 @@ static int da850_set_armrate(struct clk *clk,
> unsigned long index)
> return clk_set_rate(pllclk, index);
> }
>
> -static int da850_set_pll0rate(struct clk *clk, unsigned long index)
> +static int da850_set_pll0rate(struct clk *clk, unsigned long rate)
> {
> - unsigned int prediv, mult, postdiv;
> - struct da850_opp *opp;
> struct pll_data *pll = clk->pll_data;
> + struct cpufreq_frequency_table *freq;
> + unsigned int prediv, mult, postdiv;
> + struct da850_opp *opp = NULL;
> int ret;
>
> - opp = (struct da850_opp *) cpufreq_info.freq_table[index].driver_data;
> + for (freq = da850_freq_table;
> + freq->frequency != CPUFREQ_TABLE_END; freq++) {
> + /* rate is in Hz, freq->frequency is in KHz */
> + if (freq->frequency == rate / 1000) {
Or
rate = rate / 1000;
before the loop begins? The idea behind my comment was mostly to reduce
the amount of calculation in the loop.
Thanks,
Sekhar
Re: [PATCH v3 1/3] ARM: da850: fix infinite loop in clk_set_rate()
On Monday 05 December 2016 04:02 PM, Bartosz Golaszewski wrote:
> 2016-12-05 11:15 GMT+01:00 Sekhar Nori :
>> On Monday 05 December 2016 03:39 PM, Bartosz Golaszewski wrote:
>>> The aemif clock is added twice to the lookup table in da850.c. This
>>> breaks the children list of pll0_sysclk3 as we're using the same list
>>> links in struct clk. When calling clk_set_rate(), we get stuck in
>>> propagate_rate().
>>>
>>> Create a separate clock for nand, inheriting the rate of the aemif
>>> clock and retrieve it in the davinci_nand module.
>>>
>>> Signed-off-by: Bartosz Golaszewski
>>> ---
>>> arch/arm/mach-davinci/da850.c | 7 ++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>>> index e770c97..c008e5e 100644
>>> --- a/arch/arm/mach-davinci/da850.c
>>> +++ b/arch/arm/mach-davinci/da850.c
>>> @@ -367,6 +367,11 @@ static struct clk aemif_clk = {
>>> .flags = ALWAYS_ENABLED,
>>> };
>>>
>>> +static struct clk aemif_nand_clk = {
>>> + .name = "nand",
>>> + .parent = &aemif_clk,
>>> +};
>>> +
>>> static struct clk usb11_clk = {
>>> .name = "usb11",
>>> .parent = &pll0_sysclk4,
>>> @@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
>>> CLK("da830-mmc.0", NULL, &mmcsd0_clk),
>>> CLK("da830-mmc.1", NULL, &mmcsd1_clk),
>>> CLK("ti-aemif", NULL, &aemif_clk),
>>> - CLK(NULL, "aemif",&aemif_clk),
>>> + CLK(NULL, "aemif",&aemif_nand_clk),
>>
>> Why use a NULL device name here? Same question was asked on v2
>
> Eek, sorry, I missed that.
For next version, can you also add a comment on top of 'struct clk
aemif_nand_clk' explaining why its needed?
Thanks,
Sekhar
Re: [RFC PATCH] PCI: designware: add host_init() error handling
Às 11:51 AM de 12/2/2016, Srinivas Kandagatla escreveu: > > > On 02/12/16 10:32, Joao Pinto wrote: >> >> Hi Srinivas, >> >> Às 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu: >>> drivers/pci/host/pci-dra7xx.c | 4 +++- >>> drivers/pci/host/pci-exynos.c | 4 +++- >>> drivers/pci/host/pci-imx6.c | 4 +++- >>> drivers/pci/host/pci-keystone.c | 4 +++- >>> drivers/pci/host/pci-layerscape.c | 12 >>> drivers/pci/host/pcie-armada8k.c| 4 +++- >>> drivers/pci/host/pcie-designware-plat.c | 4 +++- >>> drivers/pci/host/pcie-designware.c | 4 +++- >>> drivers/pci/host/pcie-designware.h | 2 +- >>> drivers/pci/host/pcie-qcom.c| 6 -- >>> drivers/pci/host/pcie-spear13xx.c | 4 +++- >>> 11 files changed, 37 insertions(+), 15 deletions(-) >>> >> >> Thanks for the patch! >> >> In my opinion your idea is good but only qcom driver is able to detect >> failure >> in the specific host init routine, all others have a 'return 0' even if >> something not well init. I would recomend that we take this issue a bit >> further >> and add the error checking to all specific pci drivers in order to make them >> as >> robust as qcom'. > I totally agree with you, I can give this a go in next version. Sure, but I think it would be better to finish now since we are on top of the task. I can help you if you need. Thanks Joao > > Thanks, > srini > >> >> Thanks, >> Joao >>
Re: stmmac ethernet in kernel 4.9-rc6: coalescing related pauses.
Hi! > >>In the ring, some descriptors can raise the irq (according to a > >>threshold) and set the IC bit. In this path, the NAPI poll will be > >>scheduled. > > > >Not NAPI poll but stmmac_tx_timer(), right? > > in the xmit according the the threshold the timer is started or the > interrupt is set inside the descriptor. > Then stmmac_tx_clean will be always called and, if you see the flow, > no irqlock protection is needed! Actually, I was wrong. irqlock protection is needed, since stmmac_tx_clean() is called from timer, and that's interrupt context, as you can confirm using BUG_ON(in_interrupt()); Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3 1/3] ARM: da850: fix infinite loop in clk_set_rate()
2016-12-05 11:15 GMT+01:00 Sekhar Nori :
> On Monday 05 December 2016 03:39 PM, Bartosz Golaszewski wrote:
>> The aemif clock is added twice to the lookup table in da850.c. This
>> breaks the children list of pll0_sysclk3 as we're using the same list
>> links in struct clk. When calling clk_set_rate(), we get stuck in
>> propagate_rate().
>>
>> Create a separate clock for nand, inheriting the rate of the aemif
>> clock and retrieve it in the davinci_nand module.
>>
>> Signed-off-by: Bartosz Golaszewski
>> ---
>> arch/arm/mach-davinci/da850.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
>> index e770c97..c008e5e 100644
>> --- a/arch/arm/mach-davinci/da850.c
>> +++ b/arch/arm/mach-davinci/da850.c
>> @@ -367,6 +367,11 @@ static struct clk aemif_clk = {
>> .flags = ALWAYS_ENABLED,
>> };
>>
>> +static struct clk aemif_nand_clk = {
>> + .name = "nand",
>> + .parent = &aemif_clk,
>> +};
>> +
>> static struct clk usb11_clk = {
>> .name = "usb11",
>> .parent = &pll0_sysclk4,
>> @@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
>> CLK("da830-mmc.0", NULL, &mmcsd0_clk),
>> CLK("da830-mmc.1", NULL, &mmcsd1_clk),
>> CLK("ti-aemif", NULL, &aemif_clk),
>> - CLK(NULL, "aemif",&aemif_clk),
>> + CLK(NULL, "aemif",&aemif_nand_clk),
>
> Why use a NULL device name here? Same question was asked on v2
Eek, sorry, I missed that.
> submission. Also, can you please make sure you are testing this in both
> DT mode (da850-lcdk) and non-DT boot (da850-evm).
Will do.
Thanks,
Bartosz
Re: [PATCH 3/3 v3] ALSA: usb-audio: fix race in snd_usb_endpoint_stop
On Mon, 05 Dec 2016 11:10:59 +0100, Jiada Wang wrote: > > Hi, Takashi > > On 11/30/2016 01:00 AM, Takashi Iwai wrote: > > On Wed, 30 Nov 2016 08:59:23 +0100, > > Jiada Wang wrote: > >> From: Mark Craske > >> > >> Kernel crash seen once: > >> > >> Unable to handle kernel NULL pointer dereference at virtual address > >> 0008 > >> pgd = a1d7c000 > >> [0008] *pgd=31c93831, *pte=, *ppte= > >> Internal error: Oops: 17 [#1] PREEMPT SMP ARM > >> CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1 > >> task: a3ae61c0 ti: a08c8000 task.ti: a08c8000 > >> PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio] > >> LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio] > >> pc : [<7f0eb22c>]lr : [<7f0e57fc>]psr: 200e0193 > >> sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4 > >> r10: 000a r9 : 0102 r8 : 94cb3000 > >> r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000 > >> r3 : 7f0eb21c r2 : r1 : 94cb3000 r0 : > >> Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user > >> Control: 10c5387d Table: 31d7c04a DAC: 0015 > >> Process dbus-daemon (pid: 250, stack limit = 0xa08c8238) > >> Stack: (0xa08c9c98 to 0xa08ca000) > >> ... > >> Backtrace: > >> [<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>] > >> (snd_complete_urb+0x140/0x1f0 [snd_usb_audio]) > >> [<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>] > >> (__usb_hcd_giveback_urb+0x78/0xf4) > >> [<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>] > >> (usb_giveback_urb_bh+0x8c/0xc0) > >> [<80371488>] (usb_giveback_urb_bh) from [<80028e3c>] > >> (tasklet_hi_action+0xc4/0x148) > >> [<80028d78>] (tasklet_hi_action) from [<80028358>] > >> (__do_softirq+0x190/0x380) > >> [<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc) > >> [<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8) > >> [<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8) > >> [<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78) > >> [<80508820>] (_raw_spin_unlock_irq) from [<8004b880>] > >> (finish_task_switch+0x5c/0x100) > >> [<8004b824>] (finish_task_switch) from [<805052f0>] > >> (__schedule+0x48c/0x6d8) > >> [<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c) > >> [<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0) > >> [<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20) > >> Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008) > >> Kernel panic - not syncing: Fatal exception in interrupt > >> > >> There is a race between retire_capture_urb()& stop_endpoints() which is > >> setting ep->data_subs to NULL. The underlying cause is in > >> snd_usb_endpoint_stop(), which sets > >>ep->data_subs = NULL; > >>ep->sync_slave = NULL; > >>ep->retire_data_urb = NULL; > >>ep->prepare_data_urb = NULL; > >> > >> An improvement, suggested by Andreas Pape (ADIT) is to read parameters > >> into local variables. This should solve race between stop and retire > >> where it is legal to store the pointers to local variable as they are > >> not freed in stop path but just set to NULL. > > Well, it's tricky. A saner way would be to clear the stuff really > > after all users are gone. > > > > An untested patch is below. Let me know if it really works. > Thanks for your proposal, I am afraid, we only found the race issue > once during > our automation test, so I can't test for your patch, > but from what I can see, your patch makes sense to me. > > The only difference when apply with your patch is, now in case > stop_endpoints() is called > from TRIGGER_STOP, these stuff won't get cleared, but I think this > isn't an issue, is it? Right. After the trigger-stop, the PCM state goes to SETUP, so it can't be played from that point immediately, thus the race won't happen. FWIW, below is the patch I'm going to queue. thanks, Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] ALSA: usb-audio: Fix race at stopping the stream We've got a kernel crash report showing like: Unable to handle kernel NULL pointer dereference at virtual address 0008 pgd = a1d7c000 [0008] *pgd=31c93831, *pte=, *ppte= Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1 task: a3ae61c0 ti: a08c8000 task.ti: a08c8000 PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio] LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio] pc : [<7f0eb22c>]lr : [<7f0e57fc>]psr: 200e0193 sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4 r10: 000a r9 : 0102 r8 : 94cb3000 r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000 r3 : 7f0eb21c r2 : r1 : 94cb3000 r0 : Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 31d7c04a DAC: 0015 Process dbus-daemon (pid: 250, stack limit = 0xa08c8238) Stack: (
Re: [RFC][PATCH] x86: Verify access_ok() context
On Tue, Nov 22, 2016 at 11:42:19AM -0800, Linus Torvalds wrote:
> On Tue, Nov 22, 2016 at 11:37 AM, Peter Zijlstra wrote:
> >
> > CONFIG_DEBUG_VM seems somehow inappropriate.
>
> The usual might_fault() logic? That uses
>
> defined(CONFIG_PROVE_LOCKING) || defined(CONFIG_DEBUG_ATOMIC_SLEEP)
>
> (and "might_sleep()" uses just CONFIG_DEBUG_ATOMIC_SLEEP, maybe that's fine).
>
Fair enough; something like so then?
---
Subject: x86: Verify access_ok() context
From: Peter Zijlstra
Date: Tue, 22 Nov 2016 10:57:15 +0100
I recently encountered wreckage because access_ok() was used where it
should not be, add an explicit WARN when access_ok() is used wrongly.
Cc: Andy Lutomirski
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/uaccess.h | 13 +++--
include/linux/preempt.h| 21 +
2 files changed, 24 insertions(+), 10 deletions(-)
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -68,6 +68,12 @@ static inline bool __chk_range_not_ok(un
__chk_range_not_ok((unsigned long __force)(addr), size, limit); \
})
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+#define ACCESS_OK_WARN() WARN_ON_ONCE(!in_task())
+#else
+#define ACCESS_OK_WARN()
+#endif
+
/**
* access_ok: - Checks if a user space pointer is valid
* @type: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that
@@ -88,8 +94,11 @@ static inline bool __chk_range_not_ok(un
* checks that the pointer is in the user space range - after calling
* this function, memory access functions may still return -EFAULT.
*/
-#define access_ok(type, addr, size) \
- likely(!__range_not_ok(addr, size, user_addr_max()))
+#define access_ok(type, addr, size)\
+({ \
+ ACCESS_OK_WARN(); \
+ likely(!__range_not_ok(addr, size, user_addr_max())); \
+})
/*
* These are the main single-value transfer routines. They automatically
--- a/include/linux/preempt.h
+++ b/include/linux/preempt.h
@@ -65,19 +65,24 @@
/*
* Are we doing bottom half or hardware interrupt processing?
- * Are we in a softirq context? Interrupt context?
- * in_softirq - Are we currently processing softirq or have bh disabled?
- * in_serving_softirq - Are we currently processing softirq?
+ *
+ * in_irq() - We're in (hard) IRQ context
+ * in_softirq() - We have BH disabled, or are processing softirqs
+ * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled
+ * in_serving_softirq() - We're in softirq context
+ * in_nmi() - We're in NMI context
+ * in_task() - We're in task context
+ *
+ * Note: due to the BH disabled confusion: in_softirq(),in_interrupt() really
+ * should not be used in new code.
*/
#define in_irq() (hardirq_count())
#define in_softirq() (softirq_count())
#define in_interrupt() (irq_count())
#define in_serving_softirq() (softirq_count() & SOFTIRQ_OFFSET)
-
-/*
- * Are we in NMI context?
- */
-#define in_nmi() (preempt_count() & NMI_MASK)
+#define in_nmi() (preempt_count() & NMI_MASK)
+#define in_task() (!(preempt_count() & \
+ (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET)))
/*
* The preempt_count offset after preempt_disable();
[PATCH v8 6/6] powerpc/pv-qspinlock: Optimise native unlock path
Avoid a function call under native version of qspinlock. On powerNV,
bafore applying this patch, every unlock is expensive. This small
optimizes enhance the performance.
We use static_key with jump_label which removes unnecessary loads of
lppaca and its stuff.
Signed-off-by: Pan Xinhui
---
arch/powerpc/include/asm/qspinlock_paravirt.h | 18 +-
arch/powerpc/kernel/paravirt.c| 4
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/qspinlock_paravirt.h
b/arch/powerpc/include/asm/qspinlock_paravirt.h
index d87cda0..8d39446 100644
--- a/arch/powerpc/include/asm/qspinlock_paravirt.h
+++ b/arch/powerpc/include/asm/qspinlock_paravirt.h
@@ -6,12 +6,14 @@
#define _ASM_QSPINLOCK_PARAVIRT_H
#include
+#include
extern void pv_lock_init(void);
extern void native_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
extern void __pv_init_lock_hash(void);
extern void __pv_queued_spin_lock_slowpath(struct qspinlock *lock, u32 val);
extern void __pv_queued_spin_unlock(struct qspinlock *lock);
+extern struct static_key_true sharedprocessor_key;
static inline void pv_queued_spin_lock(struct qspinlock *lock, u32 val)
{
@@ -20,7 +22,21 @@ static inline void pv_queued_spin_lock(struct qspinlock
*lock, u32 val)
static inline void pv_queued_spin_unlock(struct qspinlock *lock)
{
- pv_lock_op.unlock(lock);
+ /*
+* on powerNV and pSeries with jump_label, code will be
+* PowerNV:pSeries:
+* nop;b 2f;
+* native unlock 2:
+* pv unlock;
+* In this way, we can do unlock quick in native case.
+*
+* IF jump_label is not enabled, we fall back into
+* if condition, IOW, ld && cmp && bne.
+*/
+ if (static_branch_likely(&sharedprocessor_key))
+ native_queued_spin_unlock(lock);
+ else
+ pv_lock_op.unlock(lock);
}
static inline void pv_wait(u8 *ptr, u8 val)
diff --git a/arch/powerpc/kernel/paravirt.c b/arch/powerpc/kernel/paravirt.c
index e697b17..a0a000e 100644
--- a/arch/powerpc/kernel/paravirt.c
+++ b/arch/powerpc/kernel/paravirt.c
@@ -140,6 +140,9 @@ struct pv_lock_ops pv_lock_op = {
};
EXPORT_SYMBOL(pv_lock_op);
+struct static_key_true sharedprocessor_key = STATIC_KEY_TRUE_INIT;
+EXPORT_SYMBOL(sharedprocessor_key);
+
void __init pv_lock_init(void)
{
if (SHARED_PROCESSOR) {
@@ -149,5 +152,6 @@ void __init pv_lock_init(void)
pv_lock_op.unlock = __pv_queued_spin_unlock;
pv_lock_op.wait = __pv_wait;
pv_lock_op.kick = __pv_kick;
+ static_branch_disable(&sharedprocessor_key);
}
}
--
2.4.11
[PATCH v8 0/6] Implement qspinlock/pv-qspinlock on ppc
Hi All, this is the fairlock patchset. You can apply them and build successfully. patches are based on linux-next qspinlock can avoid waiter starved issue. It has about the same speed in single-thread and it can be much faster in high contention situations especially when the spinlock is embedded within the data structure to be protected. v7 -> v8: add one patch to drop a function call under native qspinlock unlock. Enabling qspinlock or not is a complier option now. rebase onto linux-next(4.9-rc7) v6 -> v7: rebase onto 4.8-rc4 v1 -> v6: too many details. snip. some benchmark result below perf bench these numbers are ops per sec, So the higher the better. *** on pSeries with 32 vcpus, 32Gb memory, pHyp. test case | pv-qspinlock | qspinlock| current-spinlock futex hash | 618572| 552332| 553788 futex lock-pi | 364 | 364 | 364 sched pipe | 78984 | 76060 | 81454 unix bench: these numbers are scores, So the higher the better. on PowerNV with 16 cores(cpus) (smt off), 32Gb memory: - pv-qspinlock and qspinlock have very similar results because pv-qspinlock use native version which is only having one callback overhead test case | pv-qspinlock and qspinlock | current-spinlock Execl Throughput 761.1 761.4 File Copy 1024 bufsize 2000 maxblocks 1259.81286.6 File Copy 256 bufsize 500 maxblocks782.2 790.3 File Copy 4096 bufsize 8000 maxblocks 2741.52817.4 Pipe Throughput 1063.21036.7 Pipe-based Context Switching 284.7 281.1 Process Creation 679.6 649.1 Shell Scripts (1 concurrent) 1933.21922.9 Shell Scripts (8 concurrent) 5003.34899.8 System Call Overhead 900.6 896.8 == System Benchmarks Index Score 1139.3 1133.0 --- - *** on pSeries with 32 vcpus, 32Gb memory, pHyp. test case | pv-qspinlock | qspinlock | current-spinlock Execl Throughput 877.1 891.2 872.8 File Copy 1024 bufsize 2000 maxblocks 1390.41399.21395.0 File Copy 256 bufsize 500 maxblocks 882.4 889.5 881.8 File Copy 4096 bufsize 8000 maxblocks 3112.33113.43121.7 Pipe Throughput 1095.81162.61158.5 Pipe-based Context Switching 194.9 192.7 200.7 Process Creation 518.4 526.4 509.1 Shell Scripts (1 concurrent)1401.91413.91402.2 Shell Scripts (8 concurrent)3215.63246.63229.1 System Call Overhead 833.2 892.4 888.1 System Benchmarks Index Score 1033.71052.51047.8 ** on pSeries with 32 vcpus, 16Gb memory, KVM. test case | pv-qspinlock | qspinlock | current-spinlock Execl Throughput 497.4518.7 497.8 File Copy 1024 bufsize 2000 maxblocks 1368.8 1390.11343.3 File Copy 256 bufsize 500 maxblocks 857.7859.8 831.4 File Copy 4096 bufsize 8000 maxblocks 2851.7 2838.12785.5 Pipe Throughput 1221.9 1265.31250.4 Pipe-based Context S
[PATCH v8 5/6] powerpc: pSeries: Add pv-qspinlock build config/make
pSeries run as a guest and might need pv-qspinlock. Signed-off-by: Pan Xinhui --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/platforms/pseries/Kconfig | 8 2 files changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 1925341..4780415 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_PPC_970_NAP) += idle_power4.o obj-$(CONFIG_PPC_P7_NAP) += idle_book3s.o procfs-y := proc_powerpc.o obj-$(CONFIG_PROC_FS) += $(procfs-y) +obj-$(CONFIG_PARAVIRT_SPINLOCKS) += paravirt.o rtaspci-$(CONFIG_PPC64)-$(CONFIG_PCI) := rtas_pci.o obj-$(CONFIG_PPC_RTAS) += rtas.o rtas-rtc.o $(rtaspci-y-y) obj-$(CONFIG_PPC_RTAS_DAEMON) += rtasd.o diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 8a87d06..0288c78 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -31,6 +31,14 @@ config ARCH_USE_QUEUED_SPINLOCKS fairlock. It has shown a good performance improvement on x86 and also ppc especially in high contention cases. +config PARAVIRT_SPINLOCKS + bool "Paravirtialization support for qspinlock" + depends on PPC_SPLPAR && QUEUED_SPINLOCKS + default y + help + If kernel need run as a guest then enable this option. + Generally it can let kernel have a better performace. + config PPC_SPLPAR depends on PPC_PSERIES bool "Support for shared-processor logical partitions" -- 2.4.11
[PATCH v8 3/6] powerpc: lib/locks.c: Add cpu yield/wake helper function
Add two corresponding helper functions to support pv-qspinlock.
For normal use, __spin_yield_cpu will confer current vcpu slices to the
target vcpu(say, a lock holder). If target vcpu is not specified or it
is in running state, such conferging to lpar happens or not depends.
Because hcall itself will introduce latency and a little overhead. And we
do NOT want to suffer any latency on some cases, e.g. in interrupt handler.
The second parameter *confer* can indicate such case.
__spin_wake_cpu is simpiler, it will wake up one vcpu regardless of its
current vcpu state.
Signed-off-by: Pan Xinhui
---
arch/powerpc/include/asm/spinlock.h | 4 +++
arch/powerpc/lib/locks.c| 59 +
2 files changed, 63 insertions(+)
diff --git a/arch/powerpc/include/asm/spinlock.h
b/arch/powerpc/include/asm/spinlock.h
index 954099e..6426bd5 100644
--- a/arch/powerpc/include/asm/spinlock.h
+++ b/arch/powerpc/include/asm/spinlock.h
@@ -64,9 +64,13 @@ static inline bool vcpu_is_preempted(int cpu)
/* We only yield to the hypervisor if we are in shared processor mode */
#define SHARED_PROCESSOR (lppaca_shared_proc(local_paca->lppaca_ptr))
extern void __spin_yield(arch_spinlock_t *lock);
+extern void __spin_yield_cpu(int cpu, int confer);
+extern void __spin_wake_cpu(int cpu);
extern void __rw_yield(arch_rwlock_t *lock);
#else /* SPLPAR */
#define __spin_yield(x)barrier()
+#define __spin_yield_cpu(x, y) barrier()
+#define __spin_wake_cpu(x) barrier()
#define __rw_yield(x) barrier()
#define SHARED_PROCESSOR 0
#endif
diff --git a/arch/powerpc/lib/locks.c b/arch/powerpc/lib/locks.c
index 6574626..bd872c9 100644
--- a/arch/powerpc/lib/locks.c
+++ b/arch/powerpc/lib/locks.c
@@ -23,6 +23,65 @@
#include
#include
+/*
+ * confer our slices to a specified cpu and return. If it is in running state
+ * or cpu is -1, then we will check confer. If confer is NULL, we will return
+ * otherwise we confer our slices to lpar.
+ */
+void __spin_yield_cpu(int cpu, int confer)
+{
+ unsigned int holder_cpu = cpu, yield_count;
+
+ if (cpu == -1)
+ goto yield_to_lpar;
+
+ BUG_ON(holder_cpu >= nr_cpu_ids);
+ yield_count = be32_to_cpu(lppaca_of(holder_cpu).yield_count);
+
+ /* if cpu is running, confer slices to lpar conditionally*/
+ if ((yield_count & 1) == 0)
+ goto yield_to_lpar;
+
+ plpar_hcall_norets(H_CONFER,
+ get_hard_smp_processor_id(holder_cpu), yield_count);
+ return;
+
+yield_to_lpar:
+ if (confer)
+ plpar_hcall_norets(H_CONFER, -1, 0);
+}
+EXPORT_SYMBOL_GPL(__spin_yield_cpu);
+
+void __spin_wake_cpu(int cpu)
+{
+ unsigned int holder_cpu = cpu;
+
+ BUG_ON(holder_cpu >= nr_cpu_ids);
+ /*
+* NOTE: we should always do this hcall regardless of
+* the yield_count of the holder_cpu.
+* as thers might be a case like below;
+* CPU 1 CPU 2
+* yielded = true
+* if (yielded)
+* __spin_wake_cpu()
+* __spin_yield_cpu()
+*
+* So we might lose a wake if we check the yield_count and
+* return directly if the holder_cpu is running.
+* IOW. do NOT code like below.
+* yield_count = be32_to_cpu(lppaca_of(holder_cpu).yield_count);
+* if ((yield_count & 1) == 0)
+* return;
+*
+* a PROD hcall marks the target_cpu proded, which cause the next cede
+* or confer called on the target_cpu invalid.
+*/
+ plpar_hcall_norets(H_PROD,
+ get_hard_smp_processor_id(holder_cpu));
+}
+EXPORT_SYMBOL_GPL(__spin_wake_cpu);
+
#ifndef CONFIG_QUEUED_SPINLOCKS
void __spin_yield(arch_spinlock_t *lock)
{
--
2.4.11
Re: ILP32 for ARM64: testing with glibc testsuite
On 2016/12/5 18:07, Andreas Schwab wrote: On Dez 05 2016, "Zhangjian (Bamvor)" wrote: Is there some progresses on it? We could collabrate to fix those issues. All the elf/nptl/rt fails should be fixed by the recent binutils fixes. Cool. How about the conform and other failures? Regards Bamvor Andreas.
Re: [PATCH] perf/x86: fix event counter update issue
On Fri, Dec 02, 2016 at 12:58:17PM +, Odzioba, Lukasz wrote:
> On Tuesday, November 29, 2016 9:33 PM, Liang, Kan wrote:
> > Yes, the patch as below fixes the issue on my SLM.
>
> It works for me as well.
> Can we still have it in 4.9?
I'll certainly, try. I've queued it as per the below.
---
Subject: perf,x86: Fix full width counter, counter overflow
Date: Tue, 29 Nov 2016 20:33:28 +
Lukasz reported that perf stat counters overflow is broken on KNL/SLM.
Both these parts have full_width_write set, and that does indeed have
a problem. In order to deal with counter wrap, we must sample the
counter at at least half the counter period (see also the sampling
theorem) such that we can unambiguously reconstruct the count.
However commit:
069e0c3c4058 ("perf/x86/intel: Support full width counting")
sets the sampling interval to the full period, not half.
Fixing that exposes another issue, in that we must not sign extend the
delta value when we shift it right; the counter cannot have
decremented after all.
With both these issues fixed, counter overflow functions correctly
again.
Cc: "mi...@redhat.com"
Cc: "a...@linux.intel.com"
Cc: Stephane Eranian
Cc: Alexander Shishkin
Cc: sta...@vger.kernel.org
Reported-by: Lukasz Odzioba
Tested-by: "Liang, Kan"
Tested-by: "Odzioba, Lukasz"
Fixes: 069e0c3c4058 ("perf/x86/intel: Support full width counting")
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/events/core.c |2 +-
arch/x86/events/intel/core.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -69,7 +69,7 @@ u64 x86_perf_event_update(struct perf_ev
int shift = 64 - x86_pmu.cntval_bits;
u64 prev_raw_count, new_raw_count;
int idx = hwc->idx;
- s64 delta;
+ u64 delta;
if (idx == INTEL_PMC_IDX_FIXED_BTS)
return 0;
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -4034,7 +4034,7 @@ __init int intel_pmu_init(void)
/* Support full width counters using alternative MSR range */
if (x86_pmu.intel_cap.full_width_write) {
- x86_pmu.max_period = x86_pmu.cntval_mask;
+ x86_pmu.max_period = x86_pmu.cntval_mask >> 1;
x86_pmu.perfctr = MSR_IA32_PMC0;
pr_cont("full-width counters, ");
}
Re: [RFC PATCH 2/2] Documentation: devictree: Add macb mdio bindings
Le 05/12/2016 à 03:55, Harini Katakam a écrit : > Hi Rob, > > > Thanks for the review. > On Sun, Dec 4, 2016 at 3:05 AM, Rob Herring wrote: >> On Mon, Nov 28, 2016 at 03:19:27PM +0530, Harini Katakam wrote: > >>> +Required properties: >>> +- compatible: Should be "cdns,macb-mdio" >> >> Only one version ever? This needs more specific compatible strings. >> > > This is part of the Cadence MAC in a way. > I can use revision number from the Cadence spec I was working with. > But it is not necessarily specific that version. Yes it is: you must specify the first precise SoC needing/implementing it: "cdns,zynqmp-gem-mdio" or "xlnx,zynq-gem-mdio" or anything looking like this. So, if an Atmel implementation is slightly different, we can still use our own "atmel,sama5d2-gem-mdio" or "cdns,sama5d2-gem-mdio" compatibility string. On the other hand, if it's strictly the same, we can use the "xlnx,zynq-gem-mdio" compatibility without any problem... > I'll take care of the other comments in the next version. > > Regards, > Harini > -- Nicolas Ferre
Re: 4.3 kernel panics when MMC/SDHC card is inserted on thinkpad
Hi David, On Sun, Dec 04, 2016 at 06:57:57PM -0600, David F wrote: > Aug 19 13:32:20 taz [ 156.425627] [ cut here ] > Aug 19 13:32:20 taz [ 156.428136] kernel BUG at > drivers/iommu/intel-iommu.c:3682! This BUG_ON triggered because the IOMMU driver can't find a domain for the device passed to intel_unmap. This looks like an IOMMU bug, but I am not 100% sure yet, because if there is no domain for a device the intel_map_page path returns 0 and the intel_unmap function should not be called. I need a couple of things to track this down. Can you please build a kernel with CONFIG_DMA_API_DEBUG=y and boot the kernel with IOMMU disabled? Insert and remove an SD-Card with this kernel and send me a full dmesg. Please also send me the output of 'lspci -v' and a full dmesg with IOMMU enabled and the BUG triggered. Thanks, Joerg
Re: [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation
On 05/12/16 08:01, Ryder Lee wrote:
Add DT bindings documentation for the crypto driver
Signed-off-by: Ryder Lee
---
.../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
new file mode 100644
index 000..8b1db08
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
@@ -0,0 +1,32 @@
+MediaTek cryptographic accelerators
+
+Required properties:
+- compatible: Should be "mediatek,mt7623-crypto"
Do you know how big the difference is between the crypto engine for
mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
Do this SoCs have a crypot engine? If so and they are quite similar, we
might think of adding a mtk-crypto binding and add soc specific bindings.
Regards,
Matthias
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the five crypto engines interrupts in numeric
+ order. These are global system and four descriptor rings.
+- clocks: the clock used by the core
+- clock-names: the names of the clock listed in the clocks property. These are
+ "ethif", "cryp"
+- power-domains: Must contain a reference to the PM domain.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+
+
+Example:
+ crypto: crypto@1b24 {
+ compatible = "mediatek,mt7623-crypto";
+ reg = <0 0x1b24 0 0x2>;
+ interrupts = ,
+,
+,
+,
+;
+ clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
+<ðsys CLK_ETHSYS_CRYPTO>;
+ clock-names = "ethif","cryp";
+ power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
+ };
can you establish this charity work
I am Amy Riddering, 41 years old, wife of late Mr. Michael James Riddering, USA citizen who was killed On 15 January 2016 in the Al Qaeda terrorist attack in Burkina Faso, I am a cancer victim, respond to me now because I want you to do a charity work for me. I want to hand over to you a fund worth $42.350.000.00 Dollars which I and my late husband deposited in a bank here, Contact me with the below email 4 more details my direct email (riddering0^^ @ ^^hotmail^^.^^com) You can visit the link below to know more information concerning me and my husband. http://www.telegraph.co.uk/news/worldnews/africaandindianocean/burkinafaso/12103065/Burkina-Faso-attacks-Al-Qaeda-Islamic-Maghreb-Hotel-Splendid-Ouagadougou-live.html Best Regards, Mrs. Amy Riddering
Re: ILP32 for ARM64 - testing with lmbench
Hi, Catalin, Guys Do you have suggestion of next move of upstreaming ILP32? There are already the test results of lmbench and specint. Do you they are ok or need more data to prove no regression? I have also noticed that there are ILP32 failures in glibc testsuite. Is it the only blocker for merge ILP32(in technology part)? We appreciate any feedback/suggestion and hope could collaborate to improve the upstream progress. (cc libc-alpha to get more input). Thanks Bamvor On 2016/11/17 15:48, Zhangjian (Bamvor) wrote: Hi, Maxim On 2016/11/17 13:02, Maxim Kuvyrkov wrote: Hi Bamvor, I'm surprised that you see this much difference from ILP32 patches on SPEC CPU2006int at all. The SPEC CPU2006 benchmarks spend almost no time in the kernel syscalls. I can imagine memory, TLB, and cache handling in the kernel could affect CPU2006 benchmarks. Do ILP32 patches touch code in those areas? Other than that, it would be interesting to check what the variance is between the 3 iterations of benchmark runs. Could you check what relative standard deviation is between the 3 iterations -- (STDEV(RUN1, RUN2, RUN3) / RUNselected)? For reference, in my [non-ILP32] benchmarking I see 1.1% for 401.bzip2, 0.8% for 429.mcf, 0.2% for 456.hmmer, and 0.1% for 462.libquantum. Here is my result: ILP32_mergedILP32_unmerged 401.bzip20.31%0.26% 429.mcf 1.61%1.36% 456.hmmer1.37%1.57% 462.libquantum 0.29%0.28% Regards Bamvor -- Maxim Kuvyrkov www.linaro.org On Nov 17, 2016, at 7:28 AM, Zhangjian (Bamvor) wrote: Hi, all I test specint of aarch64 LP64 when aarch32 el0 disable/enabled respectively and compare with ILP32 unmerged kernel(4.8-rc6) in our arm64 board. I found that difference(ILP32 disabled/ILP32 unmerged) is bigger when aarch32 el0 is enabled, compare with aarch32 el0 disabled kernel. And bzip2, mcg, hmmer, libquantum are the top four differences[1]. Note that bigger is better in specint test. In order to make sure the above results, I retest these four testcases in reportable way(reference the command in the end). The result[2] show that libquantum decrease -2.09% after ILP32 enabled and aarch32 on. I think it is in significant. The result of lmbench is not stable in my board. I plan to dig it later. [1] The following test result is tested through --size=ref --iterations=3. 1.1 Test when aarch32_el0 is enabled. ILP32 disabledbase line 400.perlbench100.00% 100% 401.bzip2 99.35% 100% 403.gcc 100.26% 100% 429.mcf 102.75% 100% 445.gobmk100.00% 100% 456.hmmer 95.66% 100% 458.sjeng100.00% 100% 462.libquantum 100.00% 100% 471.omnetpp 100.59% 100% 473.astar 99.66% 100% 483.xalancbmk 99.10% 100% 1.2 Test when aarch32_el0 is disabled ILP32 disabled base line 400.perlbench100.22% 100% 401.bzip2100.95% 100% 403.gcc 100.20% 100% 429.mcf 100.76% 100% 445.gobmk100.36% 100% 456.hmmer 97.94% 100% 458.sjeng 99.73% 100% 462.libquantum98.72% 100% 471.omnetpp 100.86% 100% 473.astar 99.15% 100% 483.xalancbmk100.08% 100% [2] The following test result is tested through: runspec --config=my.cfg --size=test,train,ref --noreportable --tune=base,peak --iterations=3 bzip2 mcf hmmer libquantum 2.1 Test when aarch32_el0 is enabled. ILP32_enabled base line 401.bzip2100.82% 100% 429.mcf 100.18% 100% 456.hmmer 99.64% 100% 462.libquantum97.91% 100% Regards Bamvor On 2016/10/28 20:46, Yury Norov wrote: [Add Steve Ellcey, thanks for testing on ThunderX] Lmbench-3.0-a9 testing is performed on ThunderX machine to check that ILP32 series does not add performance regressions for LP64. Test summary is in the table below. Our measurements doesn't show significant performance regression of LP64 if ILP32 code is merged, both enabled or disabled. ILP32 enabled ILP32 disabled Standard Kernel null syscall 0.1066 0.11210.1121 95.09% 100.00% stat 1.3947 1.38141.3864
Re: [PATCH 2/8] dt-bindings: document the STM32 RTC bindings
Hi Alexandre, Thanks for reviewing On 12/05/2016 11:06 AM, Alexandre Belloni wrote: Hi, On 02/12/2016 at 15:09:55 +0100, Amelie Delaunay wrote : This patch adds documentation of device tree bindings for the STM32 RTC. Signed-off-by: Amelie Delaunay --- .../devicetree/bindings/rtc/st,stm32-rtc.txt | 31 ++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt new file mode 100644 index 000..4578838 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt @@ -0,0 +1,31 @@ +STM32 Real Time Clock + +Required properties: +- compatible: "st,stm32-rtc". +- reg: address range of rtc register set. +- clocks: reference to the clock entry ck_rtc. +- clock-names: name of the clock used. Should be "ck_rtc". Is this name really useful? You're right, not useful. +- interrupt-parent: phandle for the interrupt controller. +- interrupts: rtc alarm interrupt. +- interrupt-names: rtc alarm interrupt name, should be "alarm". Same comment, is this name really useful? Ditto. Best regards, Amelie
Re: linux-next: unable to fetch the watchdog tree
Hi Stephen, Yes, I am setting up a new server. Kind regards, Wim. > Hi Wim, > > On Tue, 22 Nov 2016 09:49:19 +1100 Stephen Rothwell > wrote: > > > > On Mon, 14 Nov 2016 16:26:16 +0100 Wim Van Sebroeck wrote: > > > > > > This has been fixed. Thanks for notifying me about it. > > > > > > > For the past few days (nearly a week, sorry) fetching the watchdog tree > > > > (git://www.linux-watchdog.org/linux-watchdog-next.git#master) has > > > > resulted in a hung connection. > > > > It's happening again :-( > > And again. Have you considered moving your tree somewhere more > reliable like kernel.org? > > -- > Cheers, > Stephen Rothwell
Re: [PATCH v3 1/3] ARM: da850: fix infinite loop in clk_set_rate()
On Monday 05 December 2016 03:39 PM, Bartosz Golaszewski wrote:
> The aemif clock is added twice to the lookup table in da850.c. This
> breaks the children list of pll0_sysclk3 as we're using the same list
> links in struct clk. When calling clk_set_rate(), we get stuck in
> propagate_rate().
>
> Create a separate clock for nand, inheriting the rate of the aemif
> clock and retrieve it in the davinci_nand module.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/mach-davinci/da850.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index e770c97..c008e5e 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -367,6 +367,11 @@ static struct clk aemif_clk = {
> .flags = ALWAYS_ENABLED,
> };
>
> +static struct clk aemif_nand_clk = {
> + .name = "nand",
> + .parent = &aemif_clk,
> +};
> +
> static struct clk usb11_clk = {
> .name = "usb11",
> .parent = &pll0_sysclk4,
> @@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
> CLK("da830-mmc.0", NULL, &mmcsd0_clk),
> CLK("da830-mmc.1", NULL, &mmcsd1_clk),
> CLK("ti-aemif", NULL, &aemif_clk),
> - CLK(NULL, "aemif",&aemif_clk),
> + CLK(NULL, "aemif",&aemif_nand_clk),
Why use a NULL device name here? Same question was asked on v2
submission. Also, can you please make sure you are testing this in both
DT mode (da850-lcdk) and non-DT boot (da850-evm).
Thanks,
Sekhar
Re: [PATCH v2 3/3] ARM: da850: fix da850_set_pll0rate()
On Friday 02 December 2016 09:08 PM, Bartosz Golaszewski wrote:
> This function is broken - its second argument is an index to the freq
> table, not the requested clock rate in Hz. It leads to an oops when
> called from clk_set_rate() since this argument isn't bounds checked
> either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Also: update the davinci cpufreq driver. It's the only user of this
> clock and currently it passes the cpufreq table index to
> clk_set_rate(), which is confusing. Make it pass the requested clock
> rate in Hz.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/mach-davinci/da850.c | 22 ++
> drivers/cpufreq/davinci-cpufreq.c | 2 +-
> 2 files changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index a55101c..92e3303 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1179,14 +1179,28 @@ static int da850_set_armrate(struct clk *clk,
> unsigned long index)
> return clk_set_rate(pllclk, index);
> }
>
> -static int da850_set_pll0rate(struct clk *clk, unsigned long index)
> +static int da850_set_pll0rate(struct clk *clk, unsigned long rate)
> {
> - unsigned int prediv, mult, postdiv;
> - struct da850_opp *opp;
> struct pll_data *pll = clk->pll_data;
> + struct cpufreq_frequency_table *freq;
> + unsigned int prediv, mult, postdiv;
> + struct da850_opp *opp = NULL;
> int ret;
>
> - opp = (struct da850_opp *) cpufreq_info.freq_table[index].driver_data;
> + for (freq = da850_freq_table;
> + freq->frequency != CPUFREQ_TABLE_END; freq++) {
> + /* requested_rate is in Hz, freq->frequency is in KHz */
> + unsigned long freq_rate = freq->frequency * 1000;
A small optimization here. Instead of multiplying potentially every
frequency in the table by 1000, you could divide the incoming rate down
to KHz. This will also avoid the need for 'freq_rate'. Should have
noticed this earlier. Sorry about that.
Thanks,
Sekhar
[PATCH v2] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay
In asds configured with V4L2_ASYNC_MATCH_OF, the v4l2 subdev can be
part of a devicetree overlay, for example:
&media_bridge {
...
my_port: port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
ep: endpoint@0 {
remote-endpoint = <&camera0>;
};
};
};
/ {
fragment@0 {
target = <&i2c0>;
__overlay__ {
my_cam {
compatible = "foo,bar";
port {
camera0: endpoint {
remote-endpoint = <&my_port>;
...
};
};
};
};
};
};
Each time the overlay is applied, its of_node pointer will be
different. We are not interested in matching the pointer, what we
want to match is that the path is the one we are expecting. Change to
use of_node_cmp() so that we continue matching after the overlay has
been removed and reapplied.
Cc: Mauro Carvalho Chehab
Cc: Javier Martinez Canillas
Cc: Sakari Ailus
Signed-off-by: Javi Merino
---
drivers/media/v4l2-core/v4l2-async.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 5bada20..d33a17c 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -42,7 +42,8 @@ static bool match_devname(struct v4l2_subdev *sd,
static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return sd->of_node == asd->match.of.node;
+ return !of_node_cmp(of_node_full_name(sd->of_node),
+ of_node_full_name(asd->match.of.node));
}
static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
--
2.1.4
Re: [PATCH 3/3 v3] ALSA: usb-audio: fix race in snd_usb_endpoint_stop
Hi, Takashi
On 11/30/2016 01:00 AM, Takashi Iwai wrote:
On Wed, 30 Nov 2016 08:59:23 +0100,
Jiada Wang wrote:
From: Mark Craske
Kernel crash seen once:
Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = a1d7c000
[0008] *pgd=31c93831, *pte=, *ppte=
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
CPU: 0 PID: 250 Comm: dbus-daemon Not tainted 3.14.51-03479-gf50bdf4 #1
task: a3ae61c0 ti: a08c8000 task.ti: a08c8000
PC is at retire_capture_urb+0x10/0x1f4 [snd_usb_audio]
LR is at snd_complete_urb+0x140/0x1f0 [snd_usb_audio]
pc : [<7f0eb22c>]lr : [<7f0e57fc>]psr: 200e0193
sp : a08c9c98 ip : a08c9ce8 fp : a08c9ce4
r10: 000a r9 : 0102 r8 : 94cb3000
r7 : 94cb3000 r6 : 94d0f000 r5 : 94d0e8e8 r4 : 94d0e000
r3 : 7f0eb21c r2 : r1 : 94cb3000 r0 :
Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 31d7c04a DAC: 0015
Process dbus-daemon (pid: 250, stack limit = 0xa08c8238)
Stack: (0xa08c9c98 to 0xa08ca000)
...
Backtrace:
[<7f0eb21c>] (retire_capture_urb [snd_usb_audio]) from [<7f0e57fc>]
(snd_complete_urb+0x140/0x1f0 [snd_usb_audio])
[<7f0e56bc>] (snd_complete_urb [snd_usb_audio]) from [<80371118>]
(__usb_hcd_giveback_urb+0x78/0xf4)
[<803710a0>] (__usb_hcd_giveback_urb) from [<80371514>]
(usb_giveback_urb_bh+0x8c/0xc0)
[<80371488>] (usb_giveback_urb_bh) from [<80028e3c>]
(tasklet_hi_action+0xc4/0x148)
[<80028d78>] (tasklet_hi_action) from [<80028358>] (__do_softirq+0x190/0x380)
[<800281c8>] (__do_softirq) from [<80028858>] (irq_exit+0x8c/0xfc)
[<800287cc>] (irq_exit) from [<8000ea88>] (handle_IRQ+0x8c/0xc8)
[<8000e9fc>] (handle_IRQ) from [<800085e8>] (gic_handle_irq+0xbc/0xf8)
[<8000852c>] (gic_handle_irq) from [<80509044>] (__irq_svc+0x44/0x78)
[<80508820>] (_raw_spin_unlock_irq) from [<8004b880>]
(finish_task_switch+0x5c/0x100)
[<8004b824>] (finish_task_switch) from [<805052f0>] (__schedule+0x48c/0x6d8)
[<80504e64>] (__schedule) from [<805055d4>] (schedule+0x98/0x9c)
[<8050553c>] (schedule) from [<800116c8>] (do_work_pending+0x30/0xd0)
[<80011698>] (do_work_pending) from [<8000e160>] (work_pending+0xc/0x20)
Code: e1a0c00d e92ddff0 e24cb004 e24dd024 (e5902008)
Kernel panic - not syncing: Fatal exception in interrupt
There is a race between retire_capture_urb()& stop_endpoints() which is
setting ep->data_subs to NULL. The underlying cause is in
snd_usb_endpoint_stop(), which sets
ep->data_subs = NULL;
ep->sync_slave = NULL;
ep->retire_data_urb = NULL;
ep->prepare_data_urb = NULL;
An improvement, suggested by Andreas Pape (ADIT) is to read parameters
into local variables. This should solve race between stop and retire
where it is legal to store the pointers to local variable as they are
not freed in stop path but just set to NULL.
Well, it's tricky. A saner way would be to clear the stuff really
after all users are gone.
An untested patch is below. Let me know if it really works.
Thanks for your proposal, I am afraid, we only found the race issue once
during
our automation test, so I can't test for your patch,
but from what I can see, your patch makes sense to me.
The only difference when apply with your patch is, now in case
stop_endpoints() is called
from TRIGGER_STOP, these stuff won't get cleared, but I think this isn't
an issue, is it?
Thanks,
Jiada
However, additional races may still happen in close+hw_free against
retire, as there pointers may be freed in addition. For example, while
in retire_capture_urb() runtime->dma_area might be freed/nulled.
This shouldn't be a problem, as stop_endpoints() waits until all
active URBS get killed.
thanks,
Takashi
---
diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c
index c470251cea4b..f3fce9abece9 100644
--- a/sound/usb/endpoint.c
+++ b/sound/usb/endpoint.c
@@ -384,6 +384,9 @@ static void snd_complete_urb(struct urb *urb)
if (unlikely(atomic_read(&ep->chip->shutdown)))
goto exit_clear;
+ if (unlikely(!test_bit(EP_FLAG_RUNNING,&ep->flags)))
+ goto exit_clear;
+
if (usb_pipeout(ep->pipe)) {
retire_outbound_urb(ep, ctx);
/* can be stopped during retire callback */
@@ -534,6 +537,11 @@ static int wait_clear_urbs(struct snd_usb_endpoint *ep)
alive, ep->ep_num);
clear_bit(EP_FLAG_STOPPING,&ep->flags);
+ ep->data_subs = NULL;
+ ep->sync_slave = NULL;
+ ep->retire_data_urb = NULL;
+ ep->prepare_data_urb = NULL;
+
return 0;
}
@@ -1006,10 +1014,6 @@ void snd_usb_endpoint_stop(struct snd_usb_endpoint *ep)
if (--ep->use_count == 0) {
deactivate_urbs(ep, false);
- ep->data_subs = NULL;
- ep->sync_slave = NULL;
- ep->retire_data_urb = NULL;
- ep->prepare_data_urb = NULL;
set_bit(EP_FLAG_STOPPING,&ep->flags);
}
}
[PATCH v3 3/3] ARM: da850: fix da850_set_pll0rate()
This function is confusing - its second argument is an index to the
freq table, not the requested clock rate in Hz, but it's used as the
set_rate callback for the pll0 clock. It leads to an oops when the
caller doesn't know the internals and passes the rate in Hz as
argument instead of the cpufreq index since this argument isn't bounds
checked either.
Fix it by iterating over the array of supported frequencies and
selecting a one that matches or returning -EINVAL for unsupported
rates.
Also: update the davinci cpufreq driver. It's the only user of this
clock and currently it passes the cpufreq table index to
clk_set_rate(), which is confusing. Make it pass the requested clock
rate in Hz.
Signed-off-by: Bartosz Golaszewski
Acked-by: Viresh Kumar
---
arch/arm/mach-davinci/da850.c | 20
drivers/cpufreq/davinci-cpufreq.c | 2 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 006ec56..9837541 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1179,14 +1179,26 @@ static int da850_set_armrate(struct clk *clk, unsigned
long index)
return clk_set_rate(pllclk, index);
}
-static int da850_set_pll0rate(struct clk *clk, unsigned long index)
+static int da850_set_pll0rate(struct clk *clk, unsigned long rate)
{
- unsigned int prediv, mult, postdiv;
- struct da850_opp *opp;
struct pll_data *pll = clk->pll_data;
+ struct cpufreq_frequency_table *freq;
+ unsigned int prediv, mult, postdiv;
+ struct da850_opp *opp = NULL;
int ret;
- opp = (struct da850_opp *) cpufreq_info.freq_table[index].driver_data;
+ for (freq = da850_freq_table;
+freq->frequency != CPUFREQ_TABLE_END; freq++) {
+ /* rate is in Hz, freq->frequency is in KHz */
+ if (freq->frequency == rate / 1000) {
+ opp = (struct da850_opp *)freq->driver_data;
+ break;
+ }
+ }
+
+ if (opp == NULL)
+ return -EINVAL;
+
prediv = opp->prediv;
mult = opp->mult;
postdiv = opp->postdiv;
diff --git a/drivers/cpufreq/davinci-cpufreq.c
b/drivers/cpufreq/davinci-cpufreq.c
index b95a872..d54a27c 100644
--- a/drivers/cpufreq/davinci-cpufreq.c
+++ b/drivers/cpufreq/davinci-cpufreq.c
@@ -55,7 +55,7 @@ static int davinci_target(struct cpufreq_policy *policy,
unsigned int idx)
return ret;
}
- ret = clk_set_rate(armclk, idx);
+ ret = clk_set_rate(armclk, new_freq * 1000);
if (ret)
return ret;
--
2.9.3
[PATCH v3 1/3] ARM: da850: fix infinite loop in clk_set_rate()
The aemif clock is added twice to the lookup table in da850.c. This
breaks the children list of pll0_sysclk3 as we're using the same list
links in struct clk. When calling clk_set_rate(), we get stuck in
propagate_rate().
Create a separate clock for nand, inheriting the rate of the aemif
clock and retrieve it in the davinci_nand module.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/da850.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index e770c97..c008e5e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -367,6 +367,11 @@ static struct clk aemif_clk = {
.flags = ALWAYS_ENABLED,
};
+static struct clk aemif_nand_clk = {
+ .name = "nand",
+ .parent = &aemif_clk,
+};
+
static struct clk usb11_clk = {
.name = "usb11",
.parent = &pll0_sysclk4,
@@ -537,7 +542,7 @@ static struct clk_lookup da850_clks[] = {
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
CLK("da830-mmc.1", NULL, &mmcsd1_clk),
CLK("ti-aemif", NULL, &aemif_clk),
- CLK(NULL, "aemif",&aemif_clk),
+ CLK(NULL, "aemif",&aemif_nand_clk),
CLK("ohci-da8xx", "usb11",&usb11_clk),
CLK("musb-da8xx", "usb20",&usb20_clk),
CLK("spi_davinci.0",NULL, &spi0_clk),
--
2.9.3
Re: ILP32 for ARM64: testing with glibc testsuite
Hi, Steve On 2016/11/18 5:45, Steve Ellcey wrote: On Wed, 2016-11-16 at 15:22 +0400, Maxim Kuvyrkov wrote: On Nov 9, 2016, at 1:56 PM, Yury Norov wrote: Below is the results of glibc testsuite run for aarch64/lp64 I have been running the glibc testsuite as well. I have only run it on an ILP32 enabled kernel. Using that kernel, top-of-tree glibc, and the ILP32 glibc patches I have no LP64 regressions. There are 5 failures in LP64 mode but I get them with vanilla top-of-tree glibc sources too. They are: nptl/eintr1 (I actually don't run this because it kills the 'make check') debug/tst-backtrace5 debug/tst-backtrace6 nptl/tst-stack4 nptl/tst-thread_local1 In ILP32 mode I get 33 failures, they include the above failures (minus nptl/tst-thread_local1) plus: c++-types-check conform/ISO11/inttypes.h/conform conform/ISO11/stdint.h/conform conform/ISO99/inttypes.h/conform conform/ISO99/stdint.h/conform conform/POSIX2008/inttypes.h/conform conform/POSIX2008/stdint.h/conform conform/XOPEN2K/inttypes.h/conform conform/XOPEN2K/stdint.h/conform conform/XOPEN2K8/inttypes.h/conform conform/XOPEN2K8/stdint.h/conform elf/tst-tls1 elf/tst-tls1-static elf/tst-tls2 elf/tst-tls2-static elf/tst-tls3 math/check-abi-libm math/test-double math/test-double-finite math/test-float math/test-float-finite misc/tst-sync_file_range nptl/tst-cancel26 nptl/tst-cancel27 nptl/tst-sem3 rt/tst-mqueue1 rt/tst-mqueue2 rt/tst-mqueue4 rt/tst-mqueue7 stdlib/tst-makecontext3 I am currently looking at these ILP32 regressions (starting with the tls failures) to see if I can figure out what is happening with them. Is there some progresses on it? We could collabrate to fix those issues. Regards Bamvor Steve Ellcey sell...@caviumnetworks.com
[PATCH v3 2/3] ARM: da850: coding style fix
Fix alignment of the clock lookup table entries.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/da850.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index c008e5e..006ec56 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -548,7 +548,7 @@ static struct clk_lookup da850_clks[] = {
CLK("spi_davinci.0",NULL, &spi0_clk),
CLK("spi_davinci.1",NULL, &spi1_clk),
CLK("vpif", NULL, &vpif_clk),
- CLK("ahci_da850", NULL, &sata_clk),
+ CLK("ahci_da850", NULL, &sata_clk),
CLK("davinci-rproc.0", NULL, &dsp_clk),
CLK(NULL, NULL, &ehrpwm_clk),
CLK("ehrpwm.0", "fck", &ehrpwm0_clk),
--
2.9.3
[PATCH v3 0/3] ARM: da850: fix pll0 rate setting
While trying to set the pll0 rate from the kernel I noticed there are two issues with da850 clocks. The first patch fixes an infinite loop in propagate_rate(). The third fixes an oops in da850_set_pll0rate(). The second patch is just a coding style fix, while we're at it. v1 -> v2: - change the approach in 1/3: create a new clock for nand inheriting the rate from the aemif clock (verified that nand still works on da850-lcdk) - patch 3/3: also update the davinci_cpufreq driver - the only (indirect) user of da850_set_pll0rate() - s/requested_rate/rate in 3/3 v2 -> v3: - 1/3: keep the "aemif" connector id for the nand clock - 3/3: instead of multiplying freq->frequency, divide rate by 1000 - retested both davinci_nand and clk_set_rate() for pll0 Bartosz Golaszewski (3): ARM: da850: fix infinite loop in clk_set_rate() ARM: da850: coding style fix ARM: da850: fix da850_set_pll0rate() arch/arm/mach-davinci/da850.c | 29 +++-- drivers/cpufreq/davinci-cpufreq.c | 2 +- 2 files changed, 24 insertions(+), 7 deletions(-) -- 2.9.3
Re: ILP32 for ARM64: testing with glibc testsuite
On Dez 05 2016, "Zhangjian (Bamvor)" wrote: > Is there some progresses on it? We could collabrate to fix those issues. All the elf/nptl/rt fails should be fixed by the recent binutils fixes. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] i2c: rk3x: keep i2c irq ON in suspend
During suspend there may still be some i2c access happening.
And if we don't keep i2c irq ON, there may be i2c access timeout if
i2c is in irq mode of operation.
Signed-off-by: David Wu
---
drivers/i2c/busses/i2c-rk3x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index df22066..67af32a 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -1261,7 +1261,7 @@ static int rk3x_i2c_probe(struct platform_device *pdev)
}
ret = devm_request_irq(&pdev->dev, irq, rk3x_i2c_irq,
- 0, dev_name(&pdev->dev), i2c);
+ IRQF_NO_SUSPEND, dev_name(&pdev->dev), i2c);
if (ret < 0) {
dev_err(&pdev->dev, "cannot request IRQ\n");
return ret;
--
1.9.1
Re: [PATCH 2/8] dt-bindings: document the STM32 RTC bindings
Hi, On 02/12/2016 at 15:09:55 +0100, Amelie Delaunay wrote : > This patch adds documentation of device tree bindings for the STM32 RTC. > > Signed-off-by: Amelie Delaunay > --- > .../devicetree/bindings/rtc/st,stm32-rtc.txt | 31 > ++ > 1 file changed, 31 insertions(+) > create mode 100644 Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt > > diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt > b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt > new file mode 100644 > index 000..4578838 > --- /dev/null > +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.txt > @@ -0,0 +1,31 @@ > +STM32 Real Time Clock > + > +Required properties: > +- compatible: "st,stm32-rtc". > +- reg: address range of rtc register set. > +- clocks: reference to the clock entry ck_rtc. > +- clock-names: name of the clock used. Should be "ck_rtc". Is this name really useful? > +- interrupt-parent: phandle for the interrupt controller. > +- interrupts: rtc alarm interrupt. > +- interrupt-names: rtc alarm interrupt name, should be "alarm". Same comment, is this name really useful? -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[PATCH v2 1/6] net: stmmac: return error if no DMA configuration is found
From: Niklas Cassel
All drivers except pci glue layer calls stmmac_probe_config_dt.
stmmac_probe_config_dt does a kzalloc dma_cfg.
pci glue layer does kzalloc dma_cfg explicitly, so all current
drivers does a kzalloc dma_cfg.
Return an error if no DMA configuration is found, that way
we can assume that the DMA configuration always exists.
Signed-off-by: Niklas Cassel
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 982c95213da4..14366800e5e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1578,16 +1578,12 @@ static void stmmac_check_ether_addr(struct stmmac_priv
*priv)
*/
static int stmmac_init_dma_engine(struct stmmac_priv *priv)
{
- int pbl = DEFAULT_DMA_PBL, fixed_burst = 0, aal = 0;
- int mixed_burst = 0;
int atds = 0;
int ret = 0;
- if (priv->plat->dma_cfg) {
- pbl = priv->plat->dma_cfg->pbl;
- fixed_burst = priv->plat->dma_cfg->fixed_burst;
- mixed_burst = priv->plat->dma_cfg->mixed_burst;
- aal = priv->plat->dma_cfg->aal;
+ if (!priv->plat->dma_cfg) {
+ dev_err(priv->device, "DMA configuration not found\n");
+ return -EINVAL;
}
if (priv->extend_desc && (priv->mode == STMMAC_RING_MODE))
@@ -1599,8 +1595,12 @@ static int stmmac_init_dma_engine(struct stmmac_priv
*priv)
return ret;
}
- priv->hw->dma->init(priv->ioaddr, pbl, fixed_burst, mixed_burst,
- aal, priv->dma_tx_phy, priv->dma_rx_phy, atds);
+ priv->hw->dma->init(priv->ioaddr,
+ priv->plat->dma_cfg->pbl,
+ priv->plat->dma_cfg->fixed_burst,
+ priv->plat->dma_cfg->mixed_burst,
+ priv->plat->dma_cfg->aal,
+ priv->dma_tx_phy, priv->dma_rx_phy, atds);
if (priv->synopsys_id >= DWMAC_CORE_4_00) {
priv->rx_tail_addr = priv->dma_rx_phy +
--
2.1.4
[PATCH v2 2/6] net: stmmac: simplify the common DMA init API
From: Niklas Cassel
Use struct stmmac_dma_cfg *dma_cfg as an argument rather
than using all the struct members as individual arguments.
Signed-off-by: Niklas Cassel
---
drivers/net/ethernet/stmicro/stmmac/common.h| 4 ++--
drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c | 13 +++--
drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c | 7 ---
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c| 14 --
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +-
5 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 3ced2e1703c1..b13a144f72ad 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -412,8 +412,8 @@ extern const struct stmmac_desc_ops ndesc_ops;
struct stmmac_dma_ops {
/* DMA core initialization */
int (*reset)(void __iomem *ioaddr);
- void (*init)(void __iomem *ioaddr, int pbl, int fb, int mb,
-int aal, u32 dma_tx, u32 dma_rx, int atds);
+ void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg,
+u32 dma_tx, u32 dma_rx, int atds);
/* Configure the AXI Bus Mode Register */
void (*axi)(void __iomem *ioaddr, struct stmmac_axi *axi);
/* Dump DMA registers */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 990746955216..01d0d0f315e5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -82,8 +82,9 @@ static void dwmac1000_dma_axi(void __iomem *ioaddr, struct
stmmac_axi *axi)
writel(value, ioaddr + DMA_AXI_BUS_MODE);
}
-static void dwmac1000_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
- int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac1000_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
{
u32 value = readl(ioaddr + DMA_BUS_MODE);
@@ -99,20 +100,20 @@ static void dwmac1000_dma_init(void __iomem *ioaddr, int
pbl, int fb, int mb,
*/
value |= DMA_BUS_MODE_MAXPBL;
value &= ~DMA_BUS_MODE_PBL_MASK;
- value |= (pbl << DMA_BUS_MODE_PBL_SHIFT);
+ value |= (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT);
/* Set the Fixed burst mode */
- if (fb)
+ if (dma_cfg->fixed_burst)
value |= DMA_BUS_MODE_FB;
/* Mixed Burst has no effect when fb is set */
- if (mb)
+ if (dma_cfg->mixed_burst)
value |= DMA_BUS_MODE_MB;
if (atds)
value |= DMA_BUS_MODE_ATDS;
- if (aal)
+ if (dma_cfg->aal)
value |= DMA_BUS_MODE_AAL;
writel(value, ioaddr + DMA_BUS_MODE);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
index 61f54c99a7de..e5664da382f3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c
@@ -32,11 +32,12 @@
#include "dwmac100.h"
#include "dwmac_dma.h"
-static void dwmac100_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
- int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac100_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
{
/* Enable Application Access by writing to DMA CSR0 */
- writel(DMA_BUS_MODE_DEFAULT | (pbl << DMA_BUS_MODE_PBL_SHIFT),
+ writel(DMA_BUS_MODE_DEFAULT | (dma_cfg->pbl << DMA_BUS_MODE_PBL_SHIFT),
ioaddr + DMA_BUS_MODE);
/* Mask interrupts by writing to CSR7 */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 577316de6ba8..0946546d6dcd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -97,27 +97,29 @@ static void dwmac4_dma_init_channel(void __iomem *ioaddr,
int pbl,
writel(dma_rx_phy, ioaddr + DMA_CHAN_RX_BASE_ADDR(channel));
}
-static void dwmac4_dma_init(void __iomem *ioaddr, int pbl, int fb, int mb,
- int aal, u32 dma_tx, u32 dma_rx, int atds)
+static void dwmac4_dma_init(void __iomem *ioaddr,
+ struct stmmac_dma_cfg *dma_cfg,
+ u32 dma_tx, u32 dma_rx, int atds)
{
u32 value = readl(ioaddr + DMA_SYS_BUS_MODE);
int i;
/* Set the Fixed burst mode */
- if (fb)
+ if (dma_cfg->fixed_burst)
value |= DMA_SYS_BUS_FB;
/* Mixed Burst has no effect when fb is set */
- if (mb)
