[PATCH] input: keyboard: use of_property_read_bool()
Use more compact of_property_read_bool() calls instead of the
of_find_property() calls.
Signed-off-by: Shawn Lin
---
drivers/input/keyboard/tegra-kbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/tegra-kbc.c
b/drivers/input/keyboard/tegra-kbc.c
index f97c73b..a08825d 100644
--- a/drivers/input/keyboard/tegra-kbc.c
+++ b/drivers/input/keyboard/tegra-kbc.c
@@ -514,10 +514,10 @@ static int tegra_kbc_parse_dt(struct tegra_kbc *kbc)
if (!of_property_read_u32(np, "nvidia,repeat-delay-ms", &prop))
kbc->repeat_cnt = prop;
- if (of_find_property(np, "nvidia,needs-ghost-filter", NULL))
+ if (of_property_read_bool(np, "nvidia,needs-ghost-filter"))
kbc->use_ghost_filter = true;
- if (of_find_property(np, "nvidia,wakeup-source", NULL))
+ if (of_property_read_bool(np, "nvidia,wakeup-source"))
kbc->wakeup = true;
if (!of_get_property(np, "nvidia,kbc-row-pins", &proplen)) {
--
2.3.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: touchscreen: use of_property_read_bool()
Use more compact of_property_read_bool() calls instead of the of_find_property() calls. Signed-off-by: Shawn Lin --- drivers/input/touchscreen/mms114.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/mms114.c b/drivers/input/touchscreen/mms114.c index 7cce876..66df77b 100644 --- a/drivers/input/touchscreen/mms114.c +++ b/drivers/input/touchscreen/mms114.c @@ -406,9 +406,9 @@ static struct mms114_platform_data *mms114_parse_dt(struct device *dev) of_property_read_u32(np, "moving-threshold", &pdata->moving_threshold); - if (of_find_property(np, "x-invert", NULL)) + if (of_property_read_bool(np, "x-invert")) pdata->x_invert = true; - if (of_find_property(np, "y-invert", NULL)) + if (of_property_read_bool(np, "y-invert")) pdata->y_invert = true; return pdata; -- 2.3.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ahci: added a new driver for supporting Freescale AHCI sata
Hi,
On 06-09-15 07:39, Yuantian Tang wrote:
Hi,
-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Wednesday, September 02, 2015 4:32 PM
To: Tang Yuantian-B29983
Cc: t...@kernel.org; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ahci: added a new driver for supporting Freescale AHCI
sata
Hi,
On 02-09-15 04:25, yuantian.t...@freescale.com wrote:
From: Tang Yuantian
Currently Freescale QorIQ series SATA is supported by ahci_platform
driver. Some SoC specific settings have been put in uboot. So whether
SATA works or not heavily depends on uboot.
This patch will add a new driver to support QorIQ sata which removes
the dependency on any other boot loader.
Freescale QorIQ series sata, like ls1021a ls2085a ls1043a, is
compatible with serial ATA 3.0 and AHCI 1.3 specification.
Signed-off-by: Yuantian Tang
Thanks for the patch looks good overall.
You need to add a Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
(or a similar named file) documenting the compatible strings and what the
devicetree nodes should contain wrt reg, interrupts, etc.
properties. See Documentation/devicetree/bindings/ata/ahci-platform.txt
as an example.
Further comments inline.
I was about to use ahci_platform driver, so I added the bindings stuff to
Documentation/devicetree/bindings/ata/ahci-platform.txt
So I need to revert the old bingings first and then add a new one.
---
drivers/ata/Kconfig | 9 ++
drivers/ata/Makefile| 1 +
drivers/ata/ahci_platform.c | 1 -
drivers/ata/ahci_qoriq.c| 308
4 files changed, 318 insertions(+), 1 deletion(-)
create mode 100644 drivers/ata/ahci_qoriq.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index
15e40ee..6aaa3f8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -175,6 +175,15 @@ config AHCI_XGENE
help
This option enables support for APM X-Gene SoC SATA host
controller.
+config AHCI_QORIQ
+ tristate "Freescale QorIQ AHCI SATA support"
+ depends on OF
+ help
+ This option enables support for the Freescale QorIQ AHCI SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index
af70919..af45eff 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o
libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_ST)+= ahci_st.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_TEGRA) += ahci_tegra.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o libahci.o
libahci_platform.o
+obj-$(CONFIG_AHCI_QORIQ) += ahci_qoriq.o libahci.o
libahci_platform.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 1befb11..04975b8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,7 +76,6 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
- { .compatible = "fsl,qoriq-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
This will break booting new kernels with old dtb files, something which in
general is considered a big non-no, I suggest adding a comment that this has
been superseded by the new ahci_qoriq.c code, and maybe add a date to
retire the compatible in say a year from now.
There is no old dtb because LS* platforms are not been upstreamed yet.
So I think we can safely replace it without breaking anything.
Ok / ACK.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
Hey Krzysztof, On Mon, 2015-09-07 at 09:02 +0900, Krzysztof Kozlowski wrote: > On 07.09.2015 05:16, Sjoerd Simons wrote: > > The DesignWare HS OTG USB 2.0 is used in various SoC families among > > wich > > the various rockchip SoCs, enable the driver and the PHY glue for > > rockchip > +Cc Marek and Kukjin, > > This would conflict with Marek's: > [PATCH v2] ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB > ethernet gadget > http://www.spinics.net/lists/linux-samsung-soc/msg46743.html > > Probably your series and Marek's change should go together to the > same > tree. How about rebasing your work on top of it? Thanks for the pointer! I'm entirely happy to rebase on Mareks patch or this one dropped for now until Mareks patch lands. These patches were based on current linux-next, so i guess Mareks pathc didn't land just yet? Tbh, i don't really know what tries multi_v7 tends to go through (especially for non-platform specific changes) > Best regards, > Krzysztof > > > CONFIG_AB8500_USB=y > > CONFIG_KEYSTONE_USB_PHY=y > > CONFIG_OMAP_USB3=y > > @@ -658,6 +659,7 @@ CONFIG_PHY_HIX5HD2_SATA=y > > CONFIG_PWM_STI=m > > CONFIG_OMAP_USB2=y > > CONFIG_TI_PIPE3=y > > +CONFIG_PHY_ROCKCHIP_USB=y > > CONFIG_PHY_MIPHY28LP=y > > CONFIG_PHY_MIPHY365X=y > > CONFIG_PHY_RCAR_GEN2=m > > > -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1] audit: try harder to send to auditd upon netlink failure
On 15/09/04, Paul Moore wrote:
> On Friday, September 04, 2015 05:14:54 AM Richard Guy Briggs wrote:
> > There are several reports of the kernel losing contact with auditd ...
>
> Even if this doesn't completely solve the problem, I like the extra reporting
> and robustness of this change. Some comments inline ...
>
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 1c13e42..4ee114a 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -404,19 +404,54 @@ static void audit_printk_skb(struct sk_buff *skb)
> > audit_hold_skb(skb);
> > }
> >
> > +static char *audit_strerror(int err)
> > +{
> > + switch (err) {
> > + case -ECONNREFUSED:
> > + return "ECONNREFUSED";
> > + case -EPERM:
> > + return "EPERM";
> > + case -ENOMEM:
> > + return "ENOMEM";
> > + case -EAGAIN:
> > + return "EAGAIN";
> > + case -ERESTARTSYS:
> > + return "ERESTARTSYS";
> > + case -EINTR:
> > + return "EINTR";
> > + default:
> > + return "(other)";
> > + }
> > +}
>
> See comments below.
>
> > static void kauditd_send_skb(struct sk_buff *skb)
> > {
> > int err;
> > + int attempts = 0;
> > +#define AUDITD_RETRIES 5
> > +
> > +restart:
> > /* take a reference in case we can't send it and we want to hold it */
> > skb_get(skb);
>
> Should the restart label go after the skb_get() call? It seems like if we
> ever jump to restart we could end up needlessly bumping the skb's refcnt.
I checked specifically for this and all the paths through
netlink_unicast() that return an error consume the skb. In fact, all
paths through netlink_unicast() consume the skb.
> > err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
> > if (err < 0) {
> > BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
> > + pr_err("netlink_unicast sending to audit_pid=%d returned error:
> > %d,
> %s\n"
> > + , audit_pid, err, audit_strerror(err));
>
> This is a style nit, but please put the comma on the preceding line. I know
> why you did it, but it bothers me.
I blame Hugh Redelmeier with whom I worked on the FreeS/WAN project, who
has been heavily involved with the ANSI C standards committee. ;-)I
should be sticking with the prevailing standard of the existing code.
> I'm also debating if audit_strerror() is worth it. I agree with you that it
> is a good idea to indicate the specific error code, I'm just not sure we need
> to bother translating that into a proper errno name. Can you think of some
> reason why we would need the errno name as opposed to the integer?
Other than convenience, not really. The only reason other than that
would be if an unexpected error code is returned it will be mover
obvious to me when reviewing a user report. Other than that, it is
complete without the text.
> > if (audit_pid) {
> > - pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
> > - audit_log_lost("auditd disappeared");
> > - audit_pid = 0;
> > - audit_sock = NULL;
> > + if (err == -ECONNREFUSED || err == -EPERM
> > + || ++attempts >= AUDITD_RETRIES) {
> > + audit_log_lost("audit_pid=%d reset");
> > + audit_pid = 0;
> > + audit_sock = NULL;
> > + } else {
> > + pr_warn("re-scheduling(#%d) write to
> > audit_pid=%d\n"
> > + , attempts, audit_pid);
>
> Same thing with the comma.
>
> > + set_current_state(TASK_INTERRUPTIBLE);
> > + schedule();
> > + __set_current_state(TASK_RUNNING);
> > + goto restart;
>
> See my comment above about the skb's reference count.
>
> > + }
> > }
> > /* we might get lucky and get this in the next auditd */
> > audit_hold_skb(skb);
>
> --
> paul moore
> www.paul-moore.com
>
- RGB
--
Richard Guy Briggs
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RT Scheduler - BUG_ON (idx >= MAX_RT_PRIO)
On Mon, 2015-09-07 at 12:28 +0530, Chinmay V S wrote: > To catch the "culprit" in the middle of busting the scheduler's > internal data structures, what would be the recommended debug > mechanisms (or config options) that i can try? I'd configure kdump, let it explode, and examine runqueues in the crash dump first. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] uio: fix false positive __might_sleep warning splat
From: Michal Hocko
Andy has reported a __might_sleep warning
[ 5174.883617] WARNING: CPU: 0 PID: 1532 at
/home/agrover/git/kernel/kernel/sched/core.c:7389 __might_sleep+0x7d/0x90()
[ 5174.884407] do not call blocking ops when !TASK_RUNNING; state=1 set at
[] uio_read+0x91/0x170 [uio]
[ 5174.885198] Modules linked in: tcm_loop target_core_user uio
target_core_pscsi target_core_file target_core_iblock iscsi_target_mod
target_core_mod uinput fuse nfsv3 nfs_acl nfs lockd grace fscache sunrpc
microcode i2c_piix4 virtio_balloon i2c_core xfs libcrc32c crc32c_intel
virtio_net virtio_blk
[ 5174.887351] CPU: 0 PID: 1532 Comm: tcmu-runner Not tainted 4.2.0-rc7+
[ 5174.887853] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[ 5174.888633] 81a3b870 880045393ca8 817afaae
[ 5174.889224] 880045393cf8 880045393ce8 8109a846
880045393cd8
[ 5174.889793] a02a7150 02dc
880045008000
[ 5174.890375] Call Trace:
[ 5174.890562] [] dump_stack+0x4c/0x65
[ 5174.890938] [] warn_slowpath_common+0x86/0xc0
[ 5174.891388] [] warn_slowpath_fmt+0x46/0x50
[ 5174.891808] [] ? uio_read+0x91/0x170 [uio]
[ 5174.892237] [] ? uio_read+0x91/0x170 [uio]
[ 5174.892653] [] __might_sleep+0x7d/0x90
[ 5174.893055] [] __might_fault+0x43/0xa0
[ 5174.893448] [] ? schedule+0x3e/0x90
[ 5174.893820] [] uio_read+0x132/0x170 [uio]
[ 5174.894240] [] ? wake_up_q+0x70/0x70
[ 5174.894620] [] __vfs_read+0x28/0xe0
[ 5174.894993] [] ? security_file_permission+0xa3/0xc0
[ 5174.895541] [] ? rw_verify_area+0x4f/0xf0
[ 5174.896006] [] vfs_read+0x8a/0x140
[ 5174.896391] [] ? __schedule+0x425/0xcc0
[ 5174.896788] [] SyS_read+0x49/0xb0
The warning is a false positive because uio_read doesn't depent on
TASK_INTERRUPTIBLE after copy_to_user so it is safe to silence the
warning by an explicit setting the state to TASK_RUNNING in the path
which might call into TASK_RUNNING.
Reported-by: Andy Grover
Signed-off-by: Michal Hocko
---
drivers/uio/uio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 3257d4220d01..7d8959e3833b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -524,6 +524,7 @@ static ssize_t uio_read(struct file *filep, char __user
*buf,
event_count = atomic_read(&idev->event);
if (event_count != listener->event_count) {
+ __set_current_state(TASK_RUNNING);
if (copy_to_user(buf, &event_count, count))
retval = -EFAULT;
else {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mmap.c: Only call vma_unlock_anon_vm() when failure occurs in expand_upwards() and expand_downwards()
On Sat 05-09-15 18:11:40, Chen Gang wrote: > Hello All: > > I have send 2 new patches about mm, and 1 patch for arch metag via my > 21cn mail. Could any members help to tell me, whether he/she have > received the patches or not? Yes they seem to be in the archive. http://lkml.kernel.org/r/COL130-W64A6555222F8CEDA513171B9560%40phx.gbl http://lkml.kernel.org/r/COL130-W16C972B0457D5C7C9CB06B9560%40phx.gbl You can check that easily by http://lkml.kernel.org/r/$MESSAGE_ID -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
On 07.09.2015 16:10, Sjoerd Simons wrote: > Hey Krzysztof, > > On Mon, 2015-09-07 at 09:02 +0900, Krzysztof Kozlowski wrote: >> On 07.09.2015 05:16, Sjoerd Simons wrote: >>> The DesignWare HS OTG USB 2.0 is used in various SoC families among >>> wich >>> the various rockchip SoCs, enable the driver and the PHY glue for >>> rockchip >> +Cc Marek and Kukjin, >> >> This would conflict with Marek's: >> [PATCH v2] ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB >> ethernet gadget >> http://www.spinics.net/lists/linux-samsung-soc/msg46743.html >> >> Probably your series and Marek's change should go together to the >> same >> tree. How about rebasing your work on top of it? > > Thanks for the pointer! I'm entirely happy to rebase on Mareks patch or > this one dropped for now until Mareks patch lands. > > These patches were based on current linux-next, so i guess Mareks pathc > didn't land just yet? Tbh, i don't really know what tries multi_v7 > tends to go through (especially for non-platform specific changes) It was too late for Marek's patch to go for v4.3 merge window, so I applied it but not pushed to my for-next branch. AFAIU, Stephen does not want v4.4 material during merge window because of mangling with statistics. If you want to rebase (or cherry-pick), you can find Marek's patch here: branch: defconfig-for-next repo: git://github.com/krzk/linux.git However this *branch will be rebased on v4.3-rc1* (because this is material for v4.4). After v4.3-rc1 I can prepare a tag for other interested parties. As for multi_v7_defconfig policy, I got impression from the Arnd/Olof/Kevin comments on LKML, that platform specific changes should go through platform tree. However this is multi-platform change so maybe we can push both patches through arm-soc. Arnd, Olof, Kevin (BTW, you missed to CC him), How do you wish to handle this case (USB_DWC2 and two patches: Marek's and Sjoerd's)? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "scsi: convert host_busy to atomic_t" series causes regressions for some hardware configurations
Hi Christoph (and those reading!),
I wonder if there might be any update or, most important, anything else for me
to test in order to provide info to address this issue...
I really would like to find out whether it is a bug in my hardware (which would
be OK, as I know already how to work around it) or something that may happen on
any hardware as soon as an unfortunate combination of storage equipment is adopted.
Thanks for the help so far,
Best regards,
Sergio
On 30/08/2015 12:54, Sergio Callegari wrote:
Hi Christoph,
just checked.
Unfortunately, the patch below, applied on top of Linus' v3.17 (which I am
using as a test kernel) *does not fix the issue*.
Best regards,
Sergio
On 25/08/2015 13:00, Christoph Hellwig wrote:
Hi Sergio,
can you give the patch below a try?
libata currently completes the SCSI command before freeing the internal
command structure, which could lead to various races that mess with
the ATA command state, which might cause issues like the one you see.
diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 641a61a..92cc156 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1772,6 +1772,15 @@ nothing_to_do:
return 1;
}
+static void ata_qc_done(struct ata_queued_cmd *qc)
+{
+struct scsi_cmnd *cmd = qc->scsicmd;
+void (*done)(struct scsi_cmnd *) = qc->scsidone;
+
+ata_qc_free(qc);
+done(cmd);
+}
+
static void ata_scsi_qc_complete(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
@@ -1810,9 +1819,7 @@ static void ata_scsi_qc_complete(struct ata_queued_cmd
*qc)
if (need_sense && !ap->ops->error_handler)
ata_dump_status(ap->print_id, &qc->result_tf);
-qc->scsidone(cmd);
-
-ata_qc_free(qc);
+ata_qc_done(qc);
}
/**
@@ -2611,8 +2618,7 @@ static void atapi_sense_complete(struct ata_queued_cmd
*qc)
ata_gen_passthru_sense(qc);
}
-qc->scsidone(qc->scsicmd);
-ata_qc_free(qc);
+ata_qc_done(qc);
}
/* is it pointless to prefer PIO for "safety reasons"? */
@@ -2707,8 +2713,7 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
qc->dev->sdev->locked = 0;
qc->scsicmd->result = SAM_STAT_CHECK_CONDITION;
-qc->scsidone(cmd);
-ata_qc_free(qc);
+ata_qc_done(qc);
return;
}
@@ -2752,8 +2757,7 @@ static void atapi_qc_complete(struct ata_queued_cmd *qc)
cmd->result = SAM_STAT_GOOD;
}
-qc->scsidone(cmd);
-ata_qc_free(qc);
+ata_qc_done(qc);
}
/**
*atapi_xlat - Initialize PACKET taskfile
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] x86/headers: Remove
* Mikko Rapeli wrote: > > > +++ b/arch/x86/include/uapi/asm/sigcontext32.h > > > @@ -3,6 +3,6 @@ > > > > > > /* This is a legacy file - all the type definitions are in sigcontext.h: > > > */ > > > > > > -#include > > > +#include > > > > There's no asm/sigcontext.h file anymore if you apply my patches - but we > > could > > reintroduce it to make the copy of UAPI headers to user-space work as-is. > > Actually there is, in user space :) I mean in the kernel arch/x86/include/asm/sigcontext.h is gone (at least in that series), we use the UAPI header directly. > Then a nice solution would be for the kernel side wrapper to do like you > said (on top of your changes on master): > > --- /dev/null > +++ b/arch/x86/include/asm/sigcontext.h > @@ -0,0 +1,6 @@ > +#ifndef _ASM_X86_SIGCONTEXT_H > +#define _ASM_X86_SIGCONTEXT_H > + > +#include > + > +#endif /* _ASM_X86_SIGCONTEXT_H */ > > And I guess logically this belongs to commit "x86/headers: Remove > ". Yeah, will do this, plus some comments explaining that this is really just so that we can keep the UAPI side compatible with a 'straight user-space copying of the header files'. This won't affect the kernel as we won't include asm/sigcontext.h directly. (And even if we do, there's no harm done.) Agreed? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support
On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote: > On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote: > > >> Think of it from the end user perspective. Would you like your > > >> laptop (or > > >> whatever) to refuse to suspend because of this condition? The user > > >> may well expect that closing the lid on their laptop will reliably > > >> lead to it suspending to ram. Returning a failure here could result > > >> in a loss of data if the condition is not detected and the machine > subsequently runs out of power. > > >> > > > > > > Yes, the user may well expect that closing the lid on their laptop will > > > reliably > lead to it suspending to ram. > > > So the client(the user of the DMA) must to PAUSE or terminate the DMA > transmission. > > > > > > We need to rely on client doing the right thing here. > > > The DMA should not make a decision instead of client. > > > If the DMA is not idle in DMA suspend, it should be the client's issue. > > > We don't know what the client really want to do, so just return the non- > success value. > > > > The problem here is that neither the client nor the DMA controller > > driver should easily decide to stop the suspend entrance and rollback. > > I don't think the non-idle situation is serious enough to cause a > > rollback. You should do whatever can be done with the DMA > > controller(such as stop the controller and leave whatever to be done > > to the wake up) and continue with the suspend. > > Ideally yes client should suspend first and dmaengine driver then being idle > when suspend is invoked. But we know we are in idle world! > So, driver should ensure it suspends the active channels and then goes to > suspend and restores that on resume > Hi Vinod, Hi Leo, Is there any other discussions? I think we can have the following solutions for DMA driver: 1, Force terminate the active channels in its suspend and then return. 2, DMA have to wait until the active channels idle. 3, Don't care about the active channels and direct return. 4, Return BUS BUSY error and stop PM progress. I prefer the last one, because I think client should make sure the channel is idle. But also the first one should be works. Can we have a conclusion and suggestion for which one is better? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Dealing with the NMI mess
* Maciej W. Rozycki wrote: > I did some work on this a few years ago, including emulating DR0-7 accesses > in > software down the JTAG handler upon a General Detect fault to keep the kernel > both happy and away from real debug registers. ;) Yes, you can debug any > software with this stuff, including the Linux kernel: set instruction and > data > breakpoints, single-step it, poke at all hardware registers, including > descriptor registers not otherwise accessible (you can set funny modes for > segments, also in the 64-bit mode), etc. One complication though is you > operate > on physical addresses when poking at memory, you can't ask the CPU's MMU to > remap them for you (you can walk page tables manually of course, just as the > MMU > would). Essentially the ICE breakpoint instruction enters SMM mode? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: leds-hp6xx: Use devm_led_classdev_register
On 09/05/2015 09:53 PM, Muhammad Falak R Wani wrote: Use resource-managed function devm_led_classdev_register instead of led_classdev_register to simplify error path. An unnecessary check of ret is replaced with a direct return Also, remove redundant hp6xxled_remove. Signed-off-by: Muhammad Falak R Wani --- drivers/leds/leds-hp6xx.c | 17 ++--- 1 file changed, 2 insertions(+), 15 deletions(-) Merged, thanks. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: leds-ot200: Use devm_led_classdev_register
On 09/05/2015 04:23 PM, Muhammad Falak R Wani wrote: Use resource-managed function devm_led_classdev_register instead of led_classdev_register to make the error path simpler. The goto is replaced with direct return, unneeded label err is dropped. Also, remove redundant ot200_led_remove. Signed-off-by: Muhammad Falak R Wani --- drivers/leds/leds-ot200.c | 21 ++--- 1 file changed, 2 insertions(+), 19 deletions(-) Merged, thanks. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] leds: leds-ipaq-micro: Use devm_led_classdev_register
Hi Muhammad, Please split coding style fixes to a separate patch and leave only devm related changes here. On 09/05/2015 09:55 PM, Muhammad Falak R Wani wrote: Use of resource-managed function devm_led_classdev_register instead of led_classdev_register is preferred, consequently remove redundant function micro_leds_remove. Also some coding style issues are fixed, only two remain, which are left alone to aid better readability. Signed-off-by: Muhammad Falak R Wani --- drivers/leds/leds-ipaq-micro.c | 47 ++ 1 file changed, 20 insertions(+), 27 deletions(-) [...] -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
Am Montag, 7. September 2015, 16:24:53 schrieb Krzysztof Kozlowski: > On 07.09.2015 16:10, Sjoerd Simons wrote: > > Hey Krzysztof, > > > > On Mon, 2015-09-07 at 09:02 +0900, Krzysztof Kozlowski wrote: > >> On 07.09.2015 05:16, Sjoerd Simons wrote: > >>> The DesignWare HS OTG USB 2.0 is used in various SoC families among > >>> wich > >>> the various rockchip SoCs, enable the driver and the PHY glue for > >>> rockchip > >> > >> +Cc Marek and Kukjin, > >> > >> This would conflict with Marek's: > >> [PATCH v2] ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB > >> ethernet gadget > >> http://www.spinics.net/lists/linux-samsung-soc/msg46743.html > >> > >> Probably your series and Marek's change should go together to the > >> same > >> tree. How about rebasing your work on top of it? > > > > Thanks for the pointer! I'm entirely happy to rebase on Mareks patch or > > this one dropped for now until Mareks patch lands. > > > > These patches were based on current linux-next, so i guess Mareks pathc > > didn't land just yet? Tbh, i don't really know what tries multi_v7 > > tends to go through (especially for non-platform specific changes) > > It was too late for Marek's patch to go for v4.3 merge window, so I > applied it but not pushed to my for-next branch. AFAIU, Stephen does not > want v4.4 material during merge window because of mangling with statistics. > > > If you want to rebase (or cherry-pick), you can find Marek's patch here: > branch: defconfig-for-next > repo: git://github.com/krzk/linux.git > > However this *branch will be rebased on v4.3-rc1* (because this is > material for v4.4). After v4.3-rc1 I can prepare a tag for other > interested parties. > > > As for multi_v7_defconfig policy, I got impression from the > Arnd/Olof/Kevin comments on LKML, that platform specific changes should > go through platform tree. However this is multi-platform change so maybe > we can push both patches through arm-soc. > > > Arnd, Olof, Kevin (BTW, you missed to CC him), > > How do you wish to handle this case (USB_DWC2 and two patches: Marek's > and Sjoerd's)? I guess the easiest option would be to just drop the dwc2 from here, only keeping the phy enablement and let everything (Marek's and Sjoerd's patch) come together in the armsoc defconfig branch? As the rest of both patches don't seem to touch common areas, they should be easily mergable from different trees as well. Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: msm: Unregister driver interest for VBUS and ID events
On Mon, 2015-08-24 at 10:11 -0700, Tim Bird wrote:
> On 08/18/2015 12:56 AM, Ivan T. Ivanov wrote:
> > Right now even if driver failed to probe extcon framework will
> > still deliver its VBUS and ID events, which will lead to random
> > exception codes.
> >
> > Fix this by removing driver interest for VBUS and ID events when
> > probe fail.
> >
> > Fixes: 591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID
> > detection")
> >
> > Reported-by: Tim Bird b...@sonymobile.com>
> > Signed-off-by: Ivan T. Ivanov iva...@linaro.org>
> > ---
> > drivers/usb/phy/phy-msm-usb.c | 26 +-
> > 1 file changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
> > index 00c49bb1bd29..a9082567f114 100644
> > --- a/drivers/usb/phy/phy-msm-usb.c
> > +++ b/drivers/usb/phy/phy-msm-usb.c
> > @@ -1581,6 +1581,8 @@ static int msm_otg_read_dt(struct platform_device
> > *pdev, struct msm_otg *motg)
> > ret = extcon_register_interest(&motg->id.conn, ext_id->name,
> >
> > "USB-HOST", &motg->id.nb);
> > if (ret < 0) {
> > + if (!IS_ERR(ext_vbus))
> > +
> > extcon_unregister_interest(&motg->vbus.conn);
> > dev_err(&pdev->dev, "register ID notifier
> > failed\n");
> > return ret;
> > }
> ...
>
> This patch is obsoleted by commit 83b7b67c7, which changes the extcon API
> a bit (from register_interest to register_notifier, among other things).
Ah, sorry, missed this. New version is coming.
Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
On 07.09.2015 16:53, Heiko Stübner wrote: > Am Montag, 7. September 2015, 16:24:53 schrieb Krzysztof Kozlowski: >> On 07.09.2015 16:10, Sjoerd Simons wrote: >>> Hey Krzysztof, >>> >>> On Mon, 2015-09-07 at 09:02 +0900, Krzysztof Kozlowski wrote: On 07.09.2015 05:16, Sjoerd Simons wrote: > The DesignWare HS OTG USB 2.0 is used in various SoC families among > wich > the various rockchip SoCs, enable the driver and the PHY glue for > rockchip +Cc Marek and Kukjin, This would conflict with Marek's: [PATCH v2] ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget http://www.spinics.net/lists/linux-samsung-soc/msg46743.html Probably your series and Marek's change should go together to the same tree. How about rebasing your work on top of it? >>> >>> Thanks for the pointer! I'm entirely happy to rebase on Mareks patch or >>> this one dropped for now until Mareks patch lands. >>> >>> These patches were based on current linux-next, so i guess Mareks pathc >>> didn't land just yet? Tbh, i don't really know what tries multi_v7 >>> tends to go through (especially for non-platform specific changes) >> >> It was too late for Marek's patch to go for v4.3 merge window, so I >> applied it but not pushed to my for-next branch. AFAIU, Stephen does not >> want v4.4 material during merge window because of mangling with statistics. >> >> >> If you want to rebase (or cherry-pick), you can find Marek's patch here: >> branch: defconfig-for-next >> repo: git://github.com/krzk/linux.git >> >> However this *branch will be rebased on v4.3-rc1* (because this is >> material for v4.4). After v4.3-rc1 I can prepare a tag for other >> interested parties. >> >> >> As for multi_v7_defconfig policy, I got impression from the >> Arnd/Olof/Kevin comments on LKML, that platform specific changes should >> go through platform tree. However this is multi-platform change so maybe >> we can push both patches through arm-soc. >> >> >> Arnd, Olof, Kevin (BTW, you missed to CC him), >> >> How do you wish to handle this case (USB_DWC2 and two patches: Marek's >> and Sjoerd's)? > > I guess the easiest option would be to just drop the dwc2 from here, only > keeping the phy enablement and let everything (Marek's and Sjoerd's patch) > come together in the armsoc defconfig branch? As the rest of both patches > don't > seem to touch common areas, they should be easily mergable from different > trees > as well. Yes, I agree. The config PHY_ROCKCHIP_USB does not depend on it directly so this should work fine. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb: phy: msm: Unregister VBUS and ID events notifiers
Right now even if driver failed to probe extcon framework will
still deliver its VBUS and ID events, which will lead to random
exception codes.
Fix this by removing VBUS and ID events notifiers when probe fail.
Fixes: 591fc116f330 ("usb: phy: msm: Use extcon framework for VBUS and ID
detection")
Reported-by: Tim Bird
Signed-off-by: Ivan T. Ivanov
---
Patch reworked to use new extcon API.
drivers/usb/phy/phy-msm-usb.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index c58c3c0dbe35..0fd21c147c7e 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1598,6 +1598,8 @@ static int msm_otg_read_dt(struct platform_device *pdev,
struct msm_otg *motg)
ret = extcon_register_notifier(ext_id, EXTCON_USB_HOST,
&motg->id.nb);
if (ret < 0) {
+ extcon_unregister_notifier(motg->vbus.extcon,
+ EXTCON_USB, &motg->vbus.nb);
dev_err(&pdev->dev, "register ID notifier failed\n");
return ret;
}
@@ -1660,15 +1662,6 @@ static int msm_otg_probe(struct platform_device *pdev)
if (!motg)
return -ENOMEM;
- pdata = dev_get_platdata(&pdev->dev);
- if (!pdata) {
- if (!np)
- return -ENXIO;
- ret = msm_otg_read_dt(pdev, motg);
- if (ret)
- return ret;
- }
-
motg->phy.otg = devm_kzalloc(&pdev->dev, sizeof(struct usb_otg),
GFP_KERNEL);
if (!motg->phy.otg)
@@ -1731,6 +1724,15 @@ static int msm_otg_probe(struct platform_device *pdev)
return motg->irq;
}
+ pdata = dev_get_platdata(&pdev->dev);
+ if (!pdata) {
+ if (!np)
+ return -ENXIO;
+ ret = msm_otg_read_dt(pdev, motg);
+ if (ret)
+ return ret;
+ }
+
regs[0].supply = "vddcx";
regs[1].supply = "v3p3";
regs[2].supply = "v1p8";
@@ -1834,6 +1836,11 @@ disable_clks:
clk_disable_unprepare(motg->clk);
if (!IS_ERR(motg->core_clk))
clk_disable_unprepare(motg->core_clk);
+
+ extcon_unregister_notifier(motg->id.extcon,
+ EXTCON_USB_HOST, &motg->id.nb);
+ extcon_unregister_notifier(motg->vbus.extcon,
+ EXTCON_USB, &motg->vbus.nb);
return ret;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 4/4] iio: chemical: add SGX VZ89x VOC sensor support
On 09/07/2015 06:27 AM, Matt Ranostay wrote: > Thinking this over do we needed a IIO_CHAN_INFO_PROCESSED_OFFSET to > signal that it needs to be after the (value - offset) * scale > calculation? Well, value * scale + offset = (value + offset/scale) * scale. So just scale your offset inversely to the scale. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On Fri, Sep 04, 2015 at 11:29:30PM +0200, Heiko Stuebner wrote:
> Am Freitag, 4. September 2015, 16:06:02 schrieb Rob Herring:
> > On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner wrote:
> > > Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
> > >> Split the dp core driver from exynos directory to bridge
> > >> directory, and rename the core driver to analogix_dp_*,
> > >> leave the platform code to analogix_dp-exynos.
> > >>
> > >> Signed-off-by: Yakir Yang
> > >
> > > [...]
> > >
> > >> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
> > >> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > >> index bed0252..7d62f22 100644
> > >> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > >
> > > [...]
> > >
> > >> connector->polled = DRM_CONNECTOR_POLL_HPD;
> > >>
> > >> ret = drm_connector_init(dp->drm_dev, connector,
> > >>
> > >> - &exynos_dp_connector_funcs,
> > >> + &analogix_dp_connector_funcs,
> > >>
> > >>DRM_MODE_CONNECTOR_eDP);
> > >>
> > >> if (ret) {
> > >>
> > >> DRM_ERROR("Failed to initialize connector with drm\n");
> > >> return ret;
> > >>
> > >> }
> > >>
> > >> - drm_connector_helper_add(connector,
> > >> &exynos_dp_connector_helper_funcs); +
> > >> drm_connector_helper_add(connector,
> > >> + &analogix_dp_connector_helper_funcs);
> > >>
> > >> drm_connector_register(connector);
> > >
> > > this should only run on exynos, as we're doing all our connector
> > > registration in the core driver after all components are bound, so I
> > > guess something like>
> > > the following is needed:
> > >if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
> > >
> > >drm_connector_register(connector);
> >
> > Yuck!
> >
> > Surely there is a better way. From what I've seen of DRM, I have no
> > doubt this is needed, but really a better solution is needed. Surely
> > there can be a more generic way for the driver to determine if it
> > should handle the connector or not. This seems like a common problem
> > including one I have seen. What I'm working on has onchip DSI encoder
> > -> ADV7533 -> HDMI. The DSI encoder can also have a direct attached
> > panel. So I have to check for a bridge in the encoder driver and only
> > register the connector for the panel if a bridge is not attached.
>
> I'm also only a part-time drm meddler, so things may be inaccurate.
>
> This conditional is not meant to prevent the registration of the dp
> connector,
> only delay it for non-exynos drms. The connector registration does publish it
> to userspace, so like i.MX we're doing that for all connectors at the same
> time after all components are bound - to also make x11 happy. Exynos on the
> other hand seems to register its connectors individually and I'm not sure if
> they would be willing to change that.
>
> see d3007dabeff4 ("drm/rockchip: register all connectors after bind") or
> simply rockchip_drm_drv.c line 178.
>
> and e355e7dd607b ("imx-drm: delay publishing sysfs connector entries")
There really shouldn't be a reason for both drivers to behave
differently in this case. Gustavo has done a lot of work on cleaning up
the Exynos driver lately, so perhaps you should sync up with him to see
if this is something that he can integrate with his changes.
If you can't reach an agreement and Exynos must keep the exact behaviour
as it has now, then perhaps a better option would be to have the
Analogix core driver not register the connector but rather leave that up
to users of the helpers. Then you don't have to clutter the core driver
with this type of platform-specific data.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH 15/15] x86/headers: Remove
On Mon, Sep 07, 2015 at 09:37:50AM +0200, Ingo Molnar wrote: > > * Mikko Rapeli wrote: > > > > > +++ b/arch/x86/include/uapi/asm/sigcontext32.h > > > > @@ -3,6 +3,6 @@ > > > > > > > > /* This is a legacy file - all the type definitions are in > > > > sigcontext.h: */ > > > > > > > > -#include > > > > +#include > > > > > > There's no asm/sigcontext.h file anymore if you apply my patches - but we > > > could > > > reintroduce it to make the copy of UAPI headers to user-space work as-is. > > > > Actually there is, in user space :) > > I mean in the kernel arch/x86/include/asm/sigcontext.h is gone (at least in > that > series), we use the UAPI header directly. > > > Then a nice solution would be for the kernel side wrapper to do like you > > said (on top of your changes on master): > > > > --- /dev/null > > +++ b/arch/x86/include/asm/sigcontext.h > > @@ -0,0 +1,6 @@ > > +#ifndef _ASM_X86_SIGCONTEXT_H > > +#define _ASM_X86_SIGCONTEXT_H > > + > > +#include > > + > > +#endif /* _ASM_X86_SIGCONTEXT_H */ > > > > And I guess logically this belongs to commit "x86/headers: Remove > > ". > > Yeah, will do this, plus some comments explaining that this is really just so > that > we can keep the UAPI side compatible with a 'straight user-space copying of > the > header files'. > > This won't affect the kernel as we won't include asm/sigcontext.h directly. > (And > even if we do, there's no harm done.) > > Agreed? Perfect. Thanks for takling this issue! -Mikko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] util-linux v2.27
The util-linux release v2.27 is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.27 Feedback and bug reports, as always, are welcomed. Karel Util-linux 2.27 Release Notes = The command tailf is deprecated in favour of tail -f from coreutils. The command unshare provides a new option --propagation=slave|shared|private|unchanged to control propagation in mount namespaces. The default is "private" now. The new default unifies unshare behavior and makes it independent of distribution default. The unshare supports persistent namespaces too (no process has to run to keep namespace in existence). The command mount(8) supports read-only binds in one step by the options "bind,ro" (command line or fstab). This feature is implemented by additional remount mount(2) syscall and it is not atomic. The commands fdisk and sfdisk can be compiled with GNU readline support to improve their line-editing functionality. The library libsmartcols and the commands findmnt, losetup, lsblk, lslocks, sfdisk and lsipc provide output in JSON format. The command mkfs (deprecated in favour of mkfs.) does not use hard-coded paths, but it follows $PATH. The command script has been massively improved to be more robust and less complex. Now all is implemented by one process which monitors the running session by poll(), signalfd(), etc. The command sulogin supports locked root accounts if the command-line option --force is specified. Read the sulogin man page before you use it! The command agetty reloads the prompt on address changes if network information is displayed. util-linux now supports and enables colors by default. It is possible to change this behavior with --disable-colors-default to be more user-friendly to colorblind people. The colors can still be enabled by editing /etc/terminal-colors.d. See terminal-colors.d(5). The command cfdisk displays more information about the selected partition (partition UUID, filesystem identifiers, mountpoint, etc.). This extra window can be toggled with the 'x' key. The command fdisk provides a new command 'F' to print free, unpartitioned space (gaps) on the disk. The same functionality is provided by sfdisk through the option --list-free. The fdisk command wipes the beginning of the device by default; the new option --protect-boot disables this behavior. The new fdisk command 'i' provides more information about a specified partition. The command cal supports the new options --twelve and --months to display the next twelve or months. The command rtcwake supports a new option --list-modes to list available modes, and a new option --date for human-readable times. rtcwake does not support RTC_ALM_READ and RTC_ALM_SET fallbacks any more. The util-linux code is possible rebuild with --disable-assert now. Security issues --- CVE-2015-5224 - chfn, chsh file name collision due to incorrect mkstemp use if compiled without libuser. [thanks to Qualys Security Advisory team; qualys.com] Stable maintenance releases between v2.26 and v2.27 --- util-linux 2.26.1 [Mar 3 2015] * ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.26/v2.26.1-ReleaseNotes ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.26/v2.26.1-ChangeLog util-linux 2.26.2 [Apr 4 2015] * ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.26/v2.26.2-ReleaseNotes ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.26/v2.26.2-ChangeLog Changes between v2.26 and v2.27 --- For more details see ChangeLog files at: ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.27/ agetty: - Reprompt once the network addresses change if address displayed [Stef Walter] - cleanup plymouth usage [coverity scan] [Karel Zak] - make sure that reload file exists [Karel Zak] - reload issue on --autologin --login-pause too [Karel Zak] - support /usr/lib/os-release too [Karel Zak] bash-completion: - cal add --twelve and --color options [Sami Kerola] - handle comma-separated options [Boris Egorov] - remove unused variables [shellcheck] [Boris Egorov] - sync lscpu completion with code [Boris Egorov] - update few options changed since v2.26 [Sami Kerola] blkid: - another hint to the man page [Karel Zak] - be more precise in the man page [Karel Zak] - don't ignore info about partitions on non-formated devices [Karel Zak] - make zfs detection more robust [Michal Humpula] build-sys: - add --disable-assert [Karel Zak] - add --disable-cal [Karel Zak] - add --disable-colors-default [Karel Zak] - add --enable-usrdir-path [Karel Zak] - add --with-readline [Ondrej Oprala] - add --without-* for all libs [Karel Zak] - add HAVE_LIBMOUNT [Karel Zak] - add TINFO_LIBS_STATIC [Karel Zak] - add new compiler warnings [Karel Zak] - allow autoconf < 2.64 to be used [Kir Kolyshkin] - allo
Re: Dealing with the NMI mess
On Mon, 7 Sep 2015, Ingo Molnar wrote: > > I did some work on this a few years ago, including emulating DR0-7 > > accesses in > > software down the JTAG handler upon a General Detect fault to keep the > > kernel > > both happy and away from real debug registers. ;) Yes, you can debug any > > software with this stuff, including the Linux kernel: set instruction and > > data > > breakpoints, single-step it, poke at all hardware registers, including > > descriptor registers not otherwise accessible (you can set funny modes for > > segments, also in the 64-bit mode), etc. One complication though is you > > operate > > on physical addresses when poking at memory, you can't ask the CPU's MMU to > > remap them for you (you can walk page tables manually of course, just as > > the MMU > > would). > > Essentially the ICE breakpoint instruction enters SMM mode? I didn't do stuff at the probe firmware level so I can't say for sure, but my gut feeling is the debug mode is indeed very close if not the same as SMM. I think duplicating the logic would be an unnecessary waste of silicon. And obviously it's any cause of #DB that enters this mode. The probe can also request it right at the exit from the reset state, so that you can debug software (e.g BIOS startup) right from the reset vector. You don't need working RAM for that. Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Sun, Sep 06, 2015 at 11:59:08AM +0800, Yakir Yang wrote: > Hi Thierry, > > 在 09/03/2015 05:04 PM, Thierry Reding 写道: > >On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote: > >>Hi Rob, > >> > >>在 09/03/2015 04:17 AM, Rob Herring 写道: > >>>On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > Some edp screen do not have hpd signal, so we can't just return > failed when hpd plug in detect failed. > >>>This is a property of the panel (or connector perhaps), so this > >>>property should be located there. At least, it is a common issue and > >>>not specific to this chip. We could have an HDMI connector and failed > >>>to hook up HPD for example. A connector node is also where hpd-gpios > >>>should be located instead (and are already defined by > >>>../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >>>binding, too. > >>Yep, I agree with your front point, it is a property of panel, not specific > >>to eDP controller, so this code should handle in connector logic. > > From your description it sounds more like this is in fact a property of > >the panel. Or maybe I should say "quirk". If the panel doesn't generate > >the HPD signal, then that should be a property of the panel, not the > >connector. The eDP specification mandates that connectors have a HPD > >signal, though it allows the "HPD conductor in the connector cable" to > >be omitted if not used by the source. I'd consider the cable to belong > >to the panel rather than the connector, so absence of HPD, either > >because the cable doesn't have the conductor or because the panel does > >not generate the signal, should be a quirk of the panel. > > > >That said you could have a panel that supports HPD connected via a cable > >that doesn't transmit it, so this would be a per-board variant and hence > >should be a device tree property rather than hard-coded in some panel > >driver. > > > >Conversely, if the panel isn't capable of generating an HPD signal, then > >I don't think it would be appropriate to make it a DT property. It would > >be better to hard-code it in the driver, lest someone forget to set the > >property in DT and get stuck with a device that isn't operational. > > Oh, you're right, if it's a cable quirk, then DT property would be okay, if > it > is a problem of panel, then maybe hard-code in driver would be better. > > After look up for the document of panel "innolux,n116bge", I haven't see > any description of hot plug signal, and even not found in PIN ASSIGNMENT. > So I believe it's a panel problem, that's to say it should handle in panel > driver. The datasheet that I have for that panel lists HPD as pin 17. Also I used to have a setup with that panel and I distinctly remember hotplug working just fine. Perhaps this is an issue with a specific variant of the panel? Or perhaps this is indeed a problem with the cable that's connecting the panel to the board. It could be one of those cases where they left out the HPD conductor to save money. Thierry signature.asc Description: PGP signature
[PATCH v10 0/4] Implement OCOTP driver for Vybrid using NVMEM
Hello, Tested on Greg's tree char-misc-next branch along with Stefan's NAND driver patchset. Sample output on Colibri VF50 root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# uname -a Linux colibri-vf 4.2.0-rc6-9-g1cec223 #5 SMP Mon Sep 7 12:34:37 IST 2015 armv7l GNU/Linux root@colibri-vf:/sys/bus/nvmem/devices/ocotp0# hexdump nvmem 000 * 410 72a6 df64 420 11d4 2006 430 * 450 0280 460 * 880 8f01 890 * 8c0 1300 8d0 320a 0800 8e0 e200 8f0 * c80 bada bada * cc0 * cf0 Changes since v9: 1. Drop clock-names property from DT 2. Rebase on top of latest char-misc-next Changes since v8: 1. Fix three lines over 80 characters 2. Rebase on top of Greg's char-misc-next branch Changes since v7: 1. Add COMPILE_TEST to Kconfig 2. Use GENMASK and BIT macros where applicable 3. Fix a code alignment issue 4. Get the max_register value for regmap config using resource_size() 5. Also add copyright info as the driver logic is based off on ocotp code in barebox 6. Add missing info related to clock in DT binding doc Changes since v6: 1. Use the v9 of NVMEM framework patchset 2. Add a few comments 3. Initialise buffer address not part of the fuse map to 0 instead of only handling buffer locations with valid fuse addresses. Changes since v5: Use NVMEM framework by Srinivas and Maxime Changes since v4: 1. Use devm_* family of functions and use a struct to get rid of global variables (suggested by Joachim Eastwood) 2. Make Kconfig govern the compilation with tristate, instead of earlier bool. Paul Bolle raised a valid point that perhaps this should have been built in with the bool, however I had not taken into consideration generic distro kernels and it makes sense to have this tristated. (comments from Paul Bolle and Andreas Farber) Changes since v3: Instead of using the syscon_regmap_lookup_by_compatible function use a phandle in the device tree along with offsets specified in this phandle node and then read the offset along with the device node in the driver for reading from the required region. Changes since v2: Implement the SoC bus code as a driver in drivers/soc by registering with fsl,mscm-cpucfg as per Arnd's feedback Changes since v1: Sort the headers in alphabetical order Changes since RFC: Use a DT entry for the ROM area while specifying it as syscon. Version 9 patches can be found here https://lkml.org/lkml/2015/8/12/530 Version 8 patches can be found here https://lkml.org/lkml/2015/8/10/566 Version 7 patches can be found here https://lkml.org/lkml/2015/8/6/440 Version 6 RFC patches can be found here http://lkml.iu.edu/hypermail/linux/kernel/1506.2/05123.html Version 5 of the patchset can be found here http://lkml.iu.edu/hypermail/linux/kernel/1506.0/03787.html Version 4 of the patchset can be found here https://lkml.org/lkml/2015/5/26/199 Version 3 of the patchset can be found here http://www.spinics.net/lists/arm-kernel/msg420847.html Version 2 of the patchset can be found here http://www.spinics.net/lists/devicetree/msg80654.html Version 1 of the patchset can be found here http://www.spinics.net/lists/devicetree/msg80257.html The RFC version can be found here https://lkml.org/lkml/2015/5/11/13 Thanks & Regards, Sanchayan Maity. Sanchayan Maity (4): clk: clk-vf610: Add clock for Vybrid OCOTP controller ARM: dts: vfxxx: Add OCOTP node drivers: nvmem: Add Vybrid OCOTP support nvmem: Add DT binding documentation for Vybrid OCOTP driver .../devicetree/bindings/nvmem/vf610-ocotp.txt | 19 ++ arch/arm/boot/dts/vfxxx.dtsi | 8 + drivers/clk/imx/clk-vf610.c| 1 + drivers/nvmem/Kconfig | 10 + drivers/nvmem/Makefile | 2 + drivers/nvmem/vf610-ocotp.c| 302 + include/dt-bindings/clock/vf610-clock.h| 3 +- 7 files changed, 344 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt create mode 100644 drivers/nvmem/vf610-ocotp.c -- 2.5.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 4/4] nvmem: Add DT binding documentation for Vybrid OCOTP driver
Add the devicetree bindings for the Freescale Vybrid On-Chip
OTP driver.
Signed-off-by: Sanchayan Maity
Acked-by: Srinivas Kandagatla
---
.../devicetree/bindings/nvmem/vf610-ocotp.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
new file mode 100644
index 000..56ed481
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt
@@ -0,0 +1,19 @@
+On-Chip OTP Memory for Freescale Vybrid
+
+Required Properties:
+ compatible:
+ - "fsl,vf610-ocotp" for VF5xx/VF6xx
+ #address-cells : Should be 1
+ #size-cells : Should be 1
+ reg : Address and length of OTP controller and fuse map registers
+ clocks : ipg clock we associate with the OCOTP peripheral
+
+Example for Vybrid VF5xx/VF6xx:
+
+ ocotp: ocotp@400a5000 {
+ compatible = "fsl,vf610-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400a5000 0xCF0>;
+ clocks = <&clks VF610_CLK_OCOTP>;
+ };
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 3/4] drivers: nvmem: Add Vybrid OCOTP support
The patch adds support for the On Chip One Time Programmable Peripheral
(OCOTP) on the Vybrid platform.
Signed-off-by: Sanchayan Maity
Acked-by: Srinivas Kandagatla
---
drivers/nvmem/Kconfig | 10 ++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/vf610-ocotp.c | 302
3 files changed, 314 insertions(+)
create mode 100644 drivers/nvmem/vf610-ocotp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 8db2978..1d4f2b4 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -36,4 +36,14 @@ config NVMEM_SUNXI_SID
This driver can also be built as a module. If so, the module
will be called nvmem_sunxi_sid.
+config NVMEM_VF610_OCOTP
+ tristate "VF610 SoC OCOTP support"
+ depends on SOC_VF610 || COMPILE_TEST
+ help
+ This is a driver for the 'OCOTP' peripheral available on Vybrid
+ devices like VF5xx and VF6xx.
+
+ This driver can also be build as a module. If so, the module will
+ be called nvmem-vf610-ocotp.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4328b93..3bdcfd4 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -10,3 +10,5 @@ obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
nvmem_qfprom-y := qfprom.o
obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem_sunxi_sid.o
nvmem_sunxi_sid-y := sunxi_sid.o
+obj-$(CONFIG_NVMEM_VF610_OCOTP)+= nvmem-vf610-ocotp.o
+nvmem-vf610-ocotp-y:= vf610-ocotp.o
diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
new file mode 100644
index 000..8641319
--- /dev/null
+++ b/drivers/nvmem/vf610-ocotp.c
@@ -0,0 +1,302 @@
+/*
+ * Copyright (C) 2015 Toradex AG.
+ *
+ * Author: Sanchayan Maity
+ *
+ * Based on the barebox ocotp driver,
+ * Copyright (c) 2010 Baruch Siach
+ * Orex Computed Radiography
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* OCOTP Register Offsets */
+#define OCOTP_CTRL_REG 0x00
+#define OCOTP_CTRL_SET 0x04
+#define OCOTP_CTRL_CLR 0x08
+#define OCOTP_TIMING 0x10
+#define OCOTP_DATA 0x20
+#define OCOTP_READ_CTRL_REG0x30
+#define OCOTP_READ_FUSE_DATA 0x40
+
+/* OCOTP Register bits and masks */
+#define OCOTP_CTRL_WR_UNLOCK 16
+#define OCOTP_CTRL_WR_UNLOCK_KEY 0x3E77
+#define OCOTP_CTRL_WR_UNLOCK_MASK GENMASK(31, 16)
+#define OCOTP_CTRL_ADDR0
+#define OCOTP_CTRL_ADDR_MASK GENMASK(6, 0)
+#define OCOTP_CTRL_RELOAD_SHADOWS BIT(10)
+#define OCOTP_CTRL_ERR BIT(9)
+#define OCOTP_CTRL_BUSYBIT(8)
+
+#define OCOTP_TIMING_STROBE_READ 16
+#define OCOTP_TIMING_STROBE_READ_MASK GENMASK(21, 16)
+#define OCOTP_TIMING_RELAX 12
+#define OCOTP_TIMING_RELAX_MASKGENMASK(15, 12)
+#define OCOTP_TIMING_STROBE_PROG 0
+#define OCOTP_TIMING_STROBE_PROG_MASK GENMASK(11, 0)
+
+#define OCOTP_READ_CTRL_READ_FUSE 0x1
+
+#define VF610_OCOTP_TIMEOUT10
+
+#define BF(value, field) (((value) << field) & field##_MASK)
+
+#define DEF_RELAX 20
+
+static const int base_to_fuse_addr_mappings[][2] = {
+ {0x400, 0x00},
+ {0x410, 0x01},
+ {0x420, 0x02},
+ {0x450, 0x05},
+ {0x4F0, 0x0F},
+ {0x600, 0x20},
+ {0x610, 0x21},
+ {0x620, 0x22},
+ {0x630, 0x23},
+ {0x640, 0x24},
+ {0x650, 0x25},
+ {0x660, 0x26},
+ {0x670, 0x27},
+ {0x6F0, 0x2F},
+ {0x880, 0x38},
+ {0x890, 0x39},
+ {0x8A0, 0x3A},
+ {0x8B0, 0x3B},
+ {0x8C0, 0x3C},
+ {0x8D0, 0x3D},
+ {0x8E0, 0x3E},
+ {0x8F0, 0x3F},
+ {0xC80, 0x78},
+ {0xC90, 0x79},
+ {0xCA0, 0x7A},
+ {0xCB0, 0x7B},
+ {0xCC0, 0x7C},
+ {0xCD0, 0x7D},
+ {0xCE0, 0x7E},
+ {0xCF0, 0x7F},
+};
+
+struct vf610_ocotp {
+ void __iomem *base;
+ struct clk *clk;
+ struct device *dev;
+ struct nvmem_device *nvmem;
+ int timing;
+};
+
+static int vf610_ocotp_wait_busy(void __iomem *base)
+{
+ int timeout =
[PATCH v10 1/4] clk: clk-vf610: Add clock for Vybrid OCOTP controller
Add clock support for Vybrid On-Chip One Time Programmable
(OCOTP) controller.
While the OCOTP block does not require explicit clock gating,
for programming the OCOTP timing register the clock rate of
ipg clock is required for timing calculations related to fuse
and shadow register read sequence. We explicitly specify the
ipg clock for OCOTP as a result.
Signed-off-by: Sanchayan Maity
---
drivers/clk/imx/clk-vf610.c | 1 +
include/dt-bindings/clock/vf610-clock.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
index bff45ea..d1b1c95 100644
--- a/drivers/clk/imx/clk-vf610.c
+++ b/drivers/clk/imx/clk-vf610.c
@@ -387,6 +387,7 @@ static void __init vf610_clocks_init(struct device_node
*ccm_node)
clk[VF610_CLK_SNVS] = imx_clk_gate2("snvs-rtc", "ipg_bus", CCM_CCGR6,
CCM_CCGRx_CGn(7));
clk[VF610_CLK_DAP] = imx_clk_gate("dap", "platform_bus", CCM_CCSR, 24);
+ clk[VF610_CLK_OCOTP] = imx_clk_gate("ocotp", "ipg_bus", CCM_CCGR6,
CCM_CCGRx_CGn(5));
imx_check_clocks(clk, ARRAY_SIZE(clk));
diff --git a/include/dt-bindings/clock/vf610-clock.h
b/include/dt-bindings/clock/vf610-clock.h
index d197634..56c16aa 100644
--- a/include/dt-bindings/clock/vf610-clock.h
+++ b/include/dt-bindings/clock/vf610-clock.h
@@ -194,6 +194,7 @@
#define VF610_PLL7_BYPASS 181
#define VF610_CLK_SNVS 182
#define VF610_CLK_DAP 183
-#define VF610_CLK_END 184
+#define VF610_CLK_OCOTP 184
+#define VF610_CLK_END 185
#endif /* __DT_BINDINGS_CLOCK_VF610_H */
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 2/4] ARM: dts: vfxxx: Add OCOTP node
Add device tree node for the On-Chip One Time Programmable
controller (OCOTP) on the Vybrid platform.
Signed-off-by: Sanchayan Maity
---
arch/arm/boot/dts/vfxxx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2f4b04d..140d81e 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -403,6 +403,14 @@
status = "disabled";
};
+ ocotp: ocotp@400a5000 {
+ compatible = "fsl,vf610-ocotp";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400a5000 0xCF0>;
+ clocks = <&clks VF610_CLK_OCOTP>;
+ };
+
snvs0: snvs@400a7000 {
compatible = "fsl,sec-v4.0-mon", "simple-bus";
#address-cells = <1>;
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 2/4] mm/kasan: MODULE_VADDR is not available on all archs
Use is_module_address instead
Signed-off-by: Aneesh Kumar K.V
---
mm/kasan/report.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 6c3f82b0240b..d269f2087faf 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
@@ -85,9 +86,11 @@ static void print_error_description(struct kasan_access_info
*info)
static inline bool kernel_or_module_addr(const void *addr)
{
- return (addr >= (void *)_stext && addr < (void *)_end)
- || (addr >= (void *)MODULES_VADDR
- && addr < (void *)MODULES_END);
+ if (addr >= (void *)_stext && addr < (void *)_end)
+ return true;
+ if (is_module_address((unsigned long)addr))
+ return true;
+ return false;
}
static inline bool init_task_stack_addr(const void *addr)
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] devicetree:bindings: add devicetree bindings for Freescale AHCI
From: Tang Yuantian
adds bindings for Freescale QorIQ AHCI SATA controller.
Signed-off-by: Tang Yuantian
---
.../devicetree/bindings/ata/ahci-fsl-qoriq.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
new file mode 100644
index 000..b614e3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -0,0 +1,21 @@
+Binding for Freescale QorIQ AHCI SATA Controller
+
+Required properties:
+ - reg: Physical base address and size of the controller's register area.
+ - compatible: Compatibility string. Must be 'fsl,-ahci', where
+chip could be ls1021a, ls2085a, ls1043a etc.
+ - clocks: Input clock specifier. Refer to common clock bindings.
+ - interrupts: Interrupt specifier. Refer to interrupt binding.
+
+Optional properties:
+ - dma-coherent: Enable ACHI coherency DMA operation.
+ - reg-names: register area names when there are more then 1 regster area.
+
+Examples:
+ sata@320 {
+ compatible = "fsl,ls1021a-ahci";
+ reg = <0x0 0x320 0x0 0x1>;
+ interrupts = ;
+ clocks = <&platform_clk 1>;
+ dma-coherent;
+ };
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/4] mm/kasan: Rename kasan_enabled to kasan_report_enabled
The function only disable/enable reporting. In the later patch
we will be adding a kasan early enable/disable. Rename kasan_enabled
to properly reflect its function.
Reviewed-by: Andrey Ryabinin
Signed-off-by: Aneesh Kumar K.V
---
mm/kasan/kasan.h | 2 +-
mm/kasan/report.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index c242adf6bc85..a6b46cc94907 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -63,7 +63,7 @@ static inline const void *kasan_shadow_to_mem(const void
*shadow_addr)
<< KASAN_SHADOW_SCALE_SHIFT);
}
-static inline bool kasan_enabled(void)
+static inline bool kasan_report_enabled(void)
{
return !current->kasan_depth;
}
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index e07c94fbd0ac..6c3f82b0240b 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -220,7 +220,7 @@ void kasan_report(unsigned long addr, size_t size,
{
struct kasan_access_info info;
- if (likely(!kasan_enabled()))
+ if (likely(!kasan_report_enabled()))
return;
info.access_addr = (void *)addr;
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3 v2] ahci: added a new driver for supporting Freescale AHCI sata
From: Tang Yuantian
Currently Freescale QorIQ series SATA is supported by ahci_platform
driver. Some SoC specific settings have been put in uboot. So whether
SATA works or not heavily depends on uboot.
This patch will add a new driver to support QorIQ sata which removes
the dependency on any other boot loader.
Freescale QorIQ series sata, like ls1021a ls2085a ls1043a, is
compatible with serial ATA 3.0 and AHCI 1.3 specification.
Signed-off-by: Yuantian Tang
---
v2:
- address Hans' comments
drivers/ata/Kconfig | 9 ++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_qoriq.c | 272 +++
3 files changed, 282 insertions(+)
create mode 100644 drivers/ata/ahci_qoriq.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 15e40ee..6aaa3f8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -175,6 +175,15 @@ config AHCI_XGENE
help
This option enables support for APM X-Gene SoC SATA host controller.
+config AHCI_QORIQ
+ tristate "Freescale QorIQ AHCI SATA support"
+ depends on OF
+ help
+ This option enables support for the Freescale QorIQ AHCI SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
depends on FSL_SOC
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index af70919..af45eff 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_ST) += ahci_st.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_TEGRA) += ahci_tegra.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_XGENE) += ahci_xgene.o libahci.o libahci_platform.o
+obj-$(CONFIG_AHCI_QORIQ) += ahci_qoriq.o libahci.o libahci_platform.o
# SFF w/ custom DMA
obj-$(CONFIG_PDC_ADMA) += pdc_adma.o
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
new file mode 100644
index 000..e5e4988
--- /dev/null
+++ b/drivers/ata/ahci_qoriq.c
@@ -0,0 +1,272 @@
+/*
+ * Freescale QorIQ AHCI SATA platform driver
+ *
+ * Copyright 2015 Freescale, Inc.
+ * Tang Yuantian
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ahci.h"
+
+#define DRV_NAME "ahci-qoriq"
+
+/* port register definition */
+#define PORT_PHY1 0xA8
+#define PORT_PHY2 0xAC
+#define PORT_PHY3 0xB0
+#define PORT_PHY4 0xB4
+#define PORT_PHY5 0xB8
+#define PORT_TRANS 0xC8
+
+/* port register default value */
+#define AHCI_PORT_PHY_1_CFG0xa003fffe
+#define AHCI_PORT_PHY_2_CFG0x28183411
+#define AHCI_PORT_PHY_3_CFG0x0e081004
+#define AHCI_PORT_PHY_4_CFG0x00480811
+#define AHCI_PORT_PHY_5_CFG0x192c96a4
+#define AHCI_PORT_TRANS_CFG0x0825
+
+#define SATA_ECC_DISABLE 0x0002
+
+enum ahci_qoriq_type {
+ AHCI_LS1021A,
+ AHCI_LS1043A,
+ AHCI_LS2085A,
+};
+
+struct ahci_qoriq_priv {
+ struct ccsr_ahci *reg_base;
+ enum ahci_qoriq_type type;
+ void __iomem *ecc_addr;
+};
+
+static const struct of_device_id ahci_qoriq_of_match[] = {
+ { .compatible = "fsl,ls1021a-ahci", .data = (void *)AHCI_LS1021A},
+ { .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
+ { .compatible = "fsl,ls2085a-ahci", .data = (void *)AHCI_LS2085A},
+ {},
+};
+MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
+
+static int ahci_qoriq_hardreset(struct ata_link *link, unsigned int *class,
+ unsigned long deadline)
+{
+ const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
+ void __iomem *port_mmio = ahci_port_base(link->ap);
+ u32 px_cmd, px_is, px_val;
+ struct ata_port *ap = link->ap;
+ struct ahci_port_priv *pp = ap->private_data;
+ struct ahci_host_priv *hpriv = ap->host->private_data;
+ struct ahci_qoriq_priv *qoriq_priv = hpriv->plat_data;
+ u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+ struct ata_taskfile tf;
+ bool online;
+ int rc;
+
+ DPRINTK("ENTER\n");
+
+ ahci_stop_engine(ap);
+
+ /*
+* There is a errata on ls1021a Rev1.0 and Rev2.0 which is:
+* A-009042: The device detection initialization sequence
+* mistakenly resets some registers.
+*
+* Workaround for this is:
+* The software should read and store PxCMD and PxIS values
+* before issuing the device detection initialization sequence.
+* After the sequence is complete, software should restore the
+* PxCMD and PxIS with the stored values.
+*/
+
[PATCH 1/3] Revert "ahci: added support for Freescale AHCI sata"
From: Tang Yuantian
This reverts commit 5163fb62541e
("ahci: added support for Freescale AHCI sata")
The reverted patch added Freescale QorIQ AHCI sata support to
ahci_platform driver though, but it left SoC specific settings to uboot.
It leads to QorIQ sata heavily depending on uboot. In order to removing
the dependency we first revert the old patch and then will add a new driver
for QorIQ SATA.
Since there are no LS* platforms that have been upstreamed, So
the revert would not break anything exists.
Signed-off-by: Tang Yuantian
---
Documentation/devicetree/bindings/ata/ahci-platform.txt | 2 --
drivers/ata/ahci_platform.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index a232181..c2340ee 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -16,8 +16,6 @@ Required properties:
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"
- - "fsl,qoriq-ahci" : for qoriq series socs which include ls1021, ls2085, etc.
- - "fsl,-ahci" : chip could be ls1021, ls2085 etc.
- "generic-ahci"
- interrupts:
- reg :
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 1befb11..04975b8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,7 +76,6 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
- { .compatible = "fsl,qoriq-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 4/4] mm/kasan: Prevent deadlock in kasan reporting
When we end up calling kasan_report in real mode, our shadow mapping
for the spinlock variable will show poisoned. This will result
in us calling kasan_report_error with lock_report spin lock held.
To prevent this disable kasan reporting when we are priting
error w.r.t kasan.
Reviewed-by: Andrey Ryabinin
Signed-off-by: Aneesh Kumar K.V
---
mm/kasan/report.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index c5367089703c..7833f074ede8 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -173,12 +173,10 @@ static void print_shadow_for_address(const void *addr)
* function, because generic functions may try to
* access kasan mapping for the passed address.
*/
- kasan_disable_current();
memcpy(shadow_buf, shadow_row, SHADOW_BYTES_PER_ROW);
print_hex_dump(KERN_ERR, buffer,
DUMP_PREFIX_NONE, SHADOW_BYTES_PER_ROW, 1,
shadow_buf, SHADOW_BYTES_PER_ROW, 0);
- kasan_enable_current();
if (row_is_guilty(shadow_row, shadow))
pr_err("%*c\n",
@@ -195,6 +193,10 @@ void kasan_report_error(struct kasan_access_info *info)
{
unsigned long flags;
+ /*
+* Make sure we don't end up in loop.
+*/
+ kasan_disable_current();
spin_lock_irqsave(&report_lock, flags);
pr_err("="
"=\n");
@@ -204,12 +206,17 @@ void kasan_report_error(struct kasan_access_info *info)
pr_err("="
"=\n");
spin_unlock_irqrestore(&report_lock, flags);
+ kasan_enable_current();
}
void kasan_report_user_access(struct kasan_access_info *info)
{
unsigned long flags;
+ /*
+* Make sure we don't end up in loop.
+*/
+ kasan_disable_current();
spin_lock_irqsave(&report_lock, flags);
pr_err("="
"=\n");
@@ -222,6 +229,7 @@ void kasan_report_user_access(struct kasan_access_info
*info)
pr_err("="
"=\n");
spin_unlock_irqrestore(&report_lock, flags);
+ kasan_enable_current();
}
void kasan_report(unsigned long addr, size_t size,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/4] mm/kasan: Don't use kasan shadow pointer in generic functions
We can't use generic functions like print_hex_dump to access kasan
shadow region. This require us to setup another kasan shadow region
for the address passed (kasan shadow address). Some architectures won't
be able to do that. Hence make a copy of the shadow region row and
pass that to generic functions.
Reviewed-by: Andrey Ryabinin
Signed-off-by: Aneesh Kumar K.V
---
mm/kasan/report.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index d269f2087faf..c5367089703c 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -164,14 +164,20 @@ static void print_shadow_for_address(const void *addr)
for (i = -SHADOW_ROWS_AROUND_ADDR; i <= SHADOW_ROWS_AROUND_ADDR; i++) {
const void *kaddr = kasan_shadow_to_mem(shadow_row);
char buffer[4 + (BITS_PER_LONG/8)*2];
+ char shadow_buf[SHADOW_BYTES_PER_ROW];
snprintf(buffer, sizeof(buffer),
(i == 0) ? ">%p: " : " %p: ", kaddr);
-
+ /*
+* We should not pass a shadow pointer to generic
+* function, because generic functions may try to
+* access kasan mapping for the passed address.
+*/
kasan_disable_current();
+ memcpy(shadow_buf, shadow_row, SHADOW_BYTES_PER_ROW);
print_hex_dump(KERN_ERR, buffer,
DUMP_PREFIX_NONE, SHADOW_BYTES_PER_ROW, 1,
- shadow_row, SHADOW_BYTES_PER_ROW, 0);
+ shadow_buf, SHADOW_BYTES_PER_ROW, 0);
kasan_enable_current();
if (row_is_guilty(shadow_row, shadow))
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH RT 0/3] RT: Fix trylock deadlock without msleep() hack
On Sat, 5 Sep 2015, Ingo Molnar wrote:
> * Thomas Gleixner wrote:
>
> > So the problem we need to solve is:
> >
> > retry:
> > lock(B);
> > if (!try_lock(A)) {
> > unlock(B);
> > cpu_relax();
> > goto retry;
> > }
> >
> > So instead of doing that proposed magic boost, we can do something
> > more straight forward:
> >
> > retry:
> > lock(B);
> > if (!try_lock(A)) {
> > lock_and_drop(A, B);
> > unlock(A);
> > goto retry;
> > }
> >
> > lock_and_drop() queues the task as a waiter on A, drops B and then
> > does the PI adjustment on A.
> >
> > Thoughts?
>
> So why not do:
>
> lock(B);
> if (!trylock(A)) {
> unlock(B);
> lock(A);
> lock(B);
> }
>
> ?
>
> Or, if this can be done, why didn't we do:
>
> lock(A);
> lock(B);
>
> to begin with?
>
> i.e. I'm not sure the problem is properly specified.
Right. I omitted some essential information.
lock(y->lock);
x = y->x;
if (!try_lock(x->lock))
Once we drop x->lock, y->x can change. That's why the retry is there.
Now on RT the trylock loop can obviously lead to a live lock if the
try locker preempted the holder of x->lock.
What Steve is trying to do is to boost the holder of x->lock (task A)
without actually queueing the task (task B) on the lock wait queue of
x->lock. To get out of the try-lock loop he calls sched_yield() from
task B.
While this works by some definition of works, I really do not like the
semantical obscurity of this approach.
1) The boosting is not related to anything.
If the priority of taskB changes then nothing changes the boosting
of taskA.
2) The boosting stops
3) sched_yield() makes me shudder
CPU0 CPU1
taskA
lock(x->lock)
preemption
taskC
taskB
lock(y->lock);
x = y->x;
if (!try_lock(x->lock)) {
unlock(y->lock);
boost(taskA);
sched_yield(); <- returns immediately
So, if taskC has higher priority than taskB and therefor than
taskA, taskB will do the lock/trylock/unlock/boost dance in
circles.
We can make that worse. If taskB's code looks like this:
lock(y->lock);
x = y->x;
if (!try_lock(x->lock)) {
unlock(y->lock);
boost(taskA);
sched_yield();
return -EAGAIN;
and at the callsite it decides to do something completely different
than retrying then taskA stays boosted.
So we have already two scenarios where this clearly violates the PI
rules and I really do not have any interest to debug leaked RT
priorites.
I agree with Steve, that the main case where we have this horrible
msleep() right now - dcache - is complex, but we rather sit down and
analyze it proper and come up with semantically well defined
solutions.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/5] perf tools: Enhance parsing events tracepoint error output
hi, enhancing parsing events tracepoint error output. Adding more verbose output when the tracepoint is not found or the tracing event path cannot be access. $ sudo perf record -e sched:sched_krava ls event syntax error: 'sched:sched_krava' \___ unknown tracepoint Error: File /sys/kernel/debug/tracing//tracing/events/sched/sched_krava not found. Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?. Run 'perf list' for a list of valid events ... $ perf record -e sched:sched_krava ls event syntax error: 'sched:sched_krava' \___ can't access trace events Error: No permissions to read /sys/kernel/debug/tracing//tracing/events/sched/sched_krava Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug' Run 'perf list' for a list of valid events ... v2 changes: - debugfs/tracefs changes went already in through separate patchset - more commentary on err.h interface - fixed callers of err.h enhanced functions - added extra tags/cscope fix Also available in: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/tp thanks, jirka --- Jiri Olsa (5): tools: Add err.h with ERR_PTR PTR_ERR interface perf tools: Add tools/include into tags directories perf tools: Propagate error info for the tracepoint parsing perf tools: Propagate error info from tp_format perf tools: Enhance parsing events tracepoint error output tools/include/linux/err.h | 49 + tools/perf/Makefile.perf| 2 +- tools/perf/builtin-trace.c | 19 +++ tools/perf/tests/evsel-tp-sched.c | 10 -- tools/perf/tests/openat-syscall-all-cpus.c | 3 ++- tools/perf/tests/openat-syscall-tp-fields.c | 3 ++- tools/perf/tests/openat-syscall.c | 3 ++- tools/perf/util/evlist.c| 3 ++- tools/perf/util/evsel.c | 11 +-- tools/perf/util/evsel.h | 3 +++ tools/perf/util/parse-events.c | 66 ++ tools/perf/util/parse-events.h | 3 ++- tools/perf/util/parse-events.y | 16 +--- tools/perf/util/trace-event.c | 13 +++-- 14 files changed, 161 insertions(+), 43 deletions(-) create mode 100644 tools/include/linux/err.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] perf tools: Enhance parsing events tracepoint error output
Enhancing parsing events tracepoint error output. Adding
more verbose output when the tracepoint is not found or
the tracing event path cannot be access.
$ sudo perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ unknown tracepoint
Error: File /sys/kernel/debug/tracing//tracing/events/sched/sched_krava not
found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this
feature?.
Run 'perf list' for a list of valid events
...
$ perf record -e sched:sched_krava ls
event syntax error: 'sched:sched_krava'
\___ can't access trace events
Error: No permissions to read
/sys/kernel/debug/tracing//tracing/events/sched/sched_krava
Hint: Try 'sudo mount -o remount,mode=755 /sys/kernel/debug'
Run 'perf list' for a list of valid events
...
Link: http://lkml.kernel.org/n/tip-l0lu26995rir1h6v0e7kq...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/parse-events.c | 35 ---
tools/perf/util/parse-events.y | 16 +---
2 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index c47831c47220..d3fb90be6216 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -387,6 +387,33 @@ int parse_events_add_cache(struct list_head *list, int
*idx,
return add_event(list, idx, &attr, name, NULL);
}
+static void tracepoint_error(struct parse_events_error *error, int err,
+char *sys, char *name)
+{
+ char help[BUFSIZ];
+
+ /*
+* We get error directly from syscall errno ( > 0),
+* or from encoded pointer's error ( < 0).
+*/
+ err = abs(err);
+
+ switch (err) {
+ case EACCES:
+ error->str = strdup("can't access trace events");
+ break;
+ case ENOENT:
+ error->str = strdup("unknown tracepoint");
+ break;
+ default:
+ error->str = strdup("failed to add tracepoint");
+ break;
+ }
+
+ tracing_path__strerror_open_tp(err, help, sizeof(help), sys, name);
+ error->help = strdup(help);
+}
+
static int add_tracepoint(struct list_head *list, int *idx,
char *sys_name, char *evt_name,
struct parse_events_error *error __maybe_unused)
@@ -394,8 +421,10 @@ static int add_tracepoint(struct list_head *list, int *idx,
struct perf_evsel *evsel;
evsel = perf_evsel__newtp_idx(sys_name, evt_name, (*idx)++);
- if (IS_ERR(evsel))
+ if (IS_ERR(evsel)) {
+ tracepoint_error(error, PTR_ERR(evsel), sys_name, evt_name);
return PTR_ERR(evsel);
+ }
list_add_tail(&evsel->node, list);
return 0;
@@ -413,7 +442,7 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
snprintf(evt_path, MAXPATHLEN, "%s/%s", tracing_events_path, sys_name);
evt_dir = opendir(evt_path);
if (!evt_dir) {
- perror("Can't open event dir");
+ tracepoint_error(error, errno, sys_name, evt_name);
return -1;
}
@@ -453,7 +482,7 @@ static int add_tracepoint_multi_sys(struct list_head *list,
int *idx,
events_dir = opendir(tracing_events_path);
if (!events_dir) {
- perror("Can't open event dir");
+ tracepoint_error(error, errno, sys_name, evt_name);
return -1;
}
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 54a3004a8192..8bcc45868457 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -371,28 +371,30 @@ event_legacy_tracepoint:
PE_NAME '-' PE_NAME ':' PE_NAME
{
struct parse_events_evlist *data = _data;
+ struct parse_events_error *error = data->error;
struct list_head *list;
char sys_name[128];
snprintf(&sys_name, 128, "%s-%s", $1, $3);
ALLOC_LIST(list);
- ABORT_ON(parse_events_add_tracepoint(list, &data->idx, &sys_name, $5,
data->error));
+ if (parse_events_add_tracepoint(list, &data->idx, &sys_name, $5,
error)) {
+ if (error)
+ error->idx = @1.first_column;
+ return -1;
+ }
$$ = list;
}
|
PE_NAME ':' PE_NAME
{
struct parse_events_evlist *data = _data;
+ struct parse_events_error *error = data->error;
struct list_head *list;
ALLOC_LIST(list);
- if (parse_events_add_tracepoint(list, &data->idx, $1, $3, data->error))
{
- struct parse_events_error *error = data->error;
-
- if (error) {
+ if (parse_events_add_tracepoint(list, &data->idx, $1, $3, error)) {
+ if (error)
error->idx = @1.first_column;
-
[PATCH 3/5] perf tools: Propagate error info for the tracepoint parsing
Pass 'struct parse_events_error *error' to the parse-event.c
tracepoint adding path. It will be filled with error data
in following patches.
Link: http://lkml.kernel.org/n/tip-las1hm5zf58b0twd27h98...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/util/parse-events.c | 27 ---
tools/perf/util/parse-events.h | 3 ++-
tools/perf/util/parse-events.y | 4 ++--
3 files changed, 20 insertions(+), 14 deletions(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 3840176642f8..1b284b8ad243 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -387,7 +387,8 @@ int parse_events_add_cache(struct list_head *list, int *idx,
}
static int add_tracepoint(struct list_head *list, int *idx,
- char *sys_name, char *evt_name)
+ char *sys_name, char *evt_name,
+ struct parse_events_error *error __maybe_unused)
{
struct perf_evsel *evsel;
@@ -401,7 +402,8 @@ static int add_tracepoint(struct list_head *list, int *idx,
}
static int add_tracepoint_multi_event(struct list_head *list, int *idx,
- char *sys_name, char *evt_name)
+ char *sys_name, char *evt_name,
+ struct parse_events_error *error)
{
char evt_path[MAXPATHLEN];
struct dirent *evt_ent;
@@ -425,7 +427,7 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
if (!strglobmatch(evt_ent->d_name, evt_name))
continue;
- ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name);
+ ret = add_tracepoint(list, idx, sys_name, evt_ent->d_name,
error);
}
closedir(evt_dir);
@@ -433,15 +435,17 @@ static int add_tracepoint_multi_event(struct list_head
*list, int *idx,
}
static int add_tracepoint_event(struct list_head *list, int *idx,
- char *sys_name, char *evt_name)
+ char *sys_name, char *evt_name,
+ struct parse_events_error *error)
{
return strpbrk(evt_name, "*?") ?
- add_tracepoint_multi_event(list, idx, sys_name, evt_name) :
- add_tracepoint(list, idx, sys_name, evt_name);
+ add_tracepoint_multi_event(list, idx, sys_name, evt_name, error)
:
+ add_tracepoint(list, idx, sys_name, evt_name, error);
}
static int add_tracepoint_multi_sys(struct list_head *list, int *idx,
- char *sys_name, char *evt_name)
+ char *sys_name, char *evt_name,
+ struct parse_events_error *error)
{
struct dirent *events_ent;
DIR *events_dir;
@@ -465,7 +469,7 @@ static int add_tracepoint_multi_sys(struct list_head *list,
int *idx,
continue;
ret = add_tracepoint_event(list, idx, events_ent->d_name,
- evt_name);
+ evt_name, error);
}
closedir(events_dir);
@@ -473,12 +477,13 @@ static int add_tracepoint_multi_sys(struct list_head
*list, int *idx,
}
int parse_events_add_tracepoint(struct list_head *list, int *idx,
- char *sys, char *event)
+ char *sys, char *event,
+ struct parse_events_error *error)
{
if (strpbrk(sys, "*?"))
- return add_tracepoint_multi_sys(list, idx, sys, event);
+ return add_tracepoint_multi_sys(list, idx, sys, event, error);
else
- return add_tracepoint_event(list, idx, sys, event);
+ return add_tracepoint_event(list, idx, sys, event, error);
}
static int
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index a09b0e210997..ffee7ece75a6 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -118,7 +118,8 @@ int parse_events__modifier_event(struct list_head *list,
char *str, bool add);
int parse_events__modifier_group(struct list_head *list, char *event_mod);
int parse_events_name(struct list_head *list, char *name);
int parse_events_add_tracepoint(struct list_head *list, int *idx,
- char *sys, char *event);
+ char *sys, char *event,
+ struct parse_events_error *error);
int parse_events_add_numeric(struct parse_events_evlist *data,
struct list_head *list,
u32 type, u64 config,
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 9cd70819c795..54a3004a8192 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -376,7 +376,7 @@ P
[PATCH 4/5] perf tools: Propagate error info from tp_format
Propagate error info from tp_format via ERR_PTR to get
it all the way down to the parse-event.c tracepoint adding
routines. Following functions now return pointer with
encoded error:
- tp_format
- trace_event__tp_format
- perf_evsel__newtp_idx
- perf_evsel__newtp
This affects several other places in perf, that cannot use
pointer check anymore, but must utilize the err.h interface,
when getting error information from above functions list.
Link: http://lkml.kernel.org/n/tip-bzdckgv1zfp2y8up9l7oj...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/perf/builtin-trace.c | 19 +++
tools/perf/tests/evsel-tp-sched.c | 10 --
tools/perf/tests/openat-syscall-all-cpus.c | 3 ++-
tools/perf/tests/openat-syscall-tp-fields.c | 3 ++-
tools/perf/tests/openat-syscall.c | 3 ++-
tools/perf/util/evlist.c| 3 ++-
tools/perf/util/evsel.c | 11 +--
tools/perf/util/evsel.h | 3 +++
tools/perf/util/parse-events.c | 6 +++---
tools/perf/util/trace-event.c | 13 +++--
10 files changed, 53 insertions(+), 21 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 215653274102..93b80f12f35e 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
/* For older distros: */
#ifndef MAP_STACK
@@ -245,13 +246,14 @@ static struct perf_evsel *perf_evsel__syscall_newtp(const
char *direction, void
struct perf_evsel *evsel = perf_evsel__newtp("raw_syscalls", direction);
/* older kernel (e.g., RHEL6) use syscalls:{enter,exit} */
- if (evsel == NULL)
+ if (IS_ERR(evsel))
evsel = perf_evsel__newtp("syscalls", direction);
- if (evsel) {
- if (perf_evsel__init_syscall_tp(evsel, handler))
- goto out_delete;
- }
+ if (IS_ERR(evsel))
+ return NULL;
+
+ if (perf_evsel__init_syscall_tp(evsel, handler))
+ goto out_delete;
return evsel;
@@ -1705,12 +1707,12 @@ static int trace__read_syscall_info(struct trace
*trace, int id)
snprintf(tp_name, sizeof(tp_name), "sys_enter_%s", sc->name);
sc->tp_format = trace_event__tp_format("syscalls", tp_name);
- if (sc->tp_format == NULL && sc->fmt && sc->fmt->alias) {
+ if (IS_ERR(sc->tp_format) && sc->fmt && sc->fmt->alias) {
snprintf(tp_name, sizeof(tp_name), "sys_enter_%s",
sc->fmt->alias);
sc->tp_format = trace_event__tp_format("syscalls", tp_name);
}
- if (sc->tp_format == NULL)
+ if (IS_ERR(sc->tp_format))
return -1;
sc->args = sc->tp_format->format.fields;
@@ -2390,7 +2392,8 @@ static size_t trace__fprintf_thread_summary(struct trace
*trace, FILE *fp);
static bool perf_evlist__add_vfs_getname(struct perf_evlist *evlist)
{
struct perf_evsel *evsel = perf_evsel__newtp("probe", "vfs_getname");
- if (evsel == NULL)
+
+ if (IS_ERR(evsel))
return false;
if (perf_evsel__field(evsel, "pathname") == NULL) {
diff --git a/tools/perf/tests/evsel-tp-sched.c
b/tools/perf/tests/evsel-tp-sched.c
index 52162425c969..790e413d9a1f 100644
--- a/tools/perf/tests/evsel-tp-sched.c
+++ b/tools/perf/tests/evsel-tp-sched.c
@@ -1,3 +1,4 @@
+#include
#include
#include "evsel.h"
#include "tests.h"
@@ -36,8 +37,8 @@ int test__perf_evsel__tp_sched_test(void)
struct perf_evsel *evsel = perf_evsel__newtp("sched", "sched_switch");
int ret = 0;
- if (evsel == NULL) {
- pr_debug("perf_evsel__new\n");
+ if (IS_ERR(evsel)) {
+ pr_debug("perf_evsel__newtp failed with %ld\n", PTR_ERR(evsel));
return -1;
}
@@ -66,6 +67,11 @@ int test__perf_evsel__tp_sched_test(void)
evsel = perf_evsel__newtp("sched", "sched_wakeup");
+ if (IS_ERR(evsel)) {
+ pr_debug("perf_evsel__newtp failed with %ld\n", PTR_ERR(evsel));
+ return -1;
+ }
+
if (perf_evsel__test_field(evsel, "comm", 16, true))
ret = -1;
diff --git a/tools/perf/tests/openat-syscall-all-cpus.c
b/tools/perf/tests/openat-syscall-all-cpus.c
index 495d8126b722..9e104a2e973d 100644
--- a/tools/perf/tests/openat-syscall-all-cpus.c
+++ b/tools/perf/tests/openat-syscall-all-cpus.c
@@ -1,4 +1,5 @@
#include
+#include
#include "evsel.h"
#include "tests.h"
#include "thread_map.h"
@@ -31,7 +32,7 @@ int test__openat_syscall_event_on_all_cpus(void)
CPU_ZERO(&cpu_set);
evsel = perf_evsel__newtp("syscalls", "sys_enter_openat");
- if (evsel == NULL) {
+ if (IS_ERR(evsel)) {
tracing_path__strerror_open_tp(errno, errbuf, sizeof(errbuf),
"syscalls", "sys_enter_openat");
pr_err("%s\n", errbuf);
[PATCH 1/5] tools: Add err.h with ERR_PTR PTR_ERR interface
Adding part of the kernel's interface:
inline void * __must_check ERR_PTR(long error);
inline long __must_check PTR_ERR(__force const void *ptr);
inline bool __must_check IS_ERR(__force const void *ptr);
it will be used to propagate error through pointers
in following patches.
Link: http://lkml.kernel.org/n/tip-ufgnyf683uab69anmmrab...@git.kernel.org
Signed-off-by: Jiri Olsa
---
tools/include/linux/err.h | 49 +++
1 file changed, 49 insertions(+)
create mode 100644 tools/include/linux/err.h
diff --git a/tools/include/linux/err.h b/tools/include/linux/err.h
new file mode 100644
index ..c9ada48f5156
--- /dev/null
+++ b/tools/include/linux/err.h
@@ -0,0 +1,49 @@
+#ifndef __TOOLS_LINUX_ERR_H
+#define __TOOLS_LINUX_ERR_H
+
+#include
+#include
+
+#include
+
+/*
+ * Original kernel header comment:
+ *
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a normal
+ * pointer with the same return value.
+ *
+ * This should be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ *
+ * Userspace note:
+ * The same principle works for userspace, because 'error' pointers
+ * fall down to the unused hole far from user space, as described
+ * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
+ *
+ * - 7fff (=47 bits) user space, different per mm
hole caused by [48:63] sign extension
+ * ffe0 - (=2 MB) unused hole
+ *
+ * It should be the same case for other architectures, because
+ * this code is used in generic kernel code.
+ */
+#define MAX_ERRNO 4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error)
+{
+ return (void *) error;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+ return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+#endif /* _LINUX_ERR_H */
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] perf tools: Add tools/include into tags directories
Adding tools/include into tags directories, to have include definitions reachable via tags/cscope. Link: http://lkml.kernel.org/n/tip-jihvx6xbdoz1xqtxce7cu...@git.kernel.org Signed-off-by: Jiri Olsa --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index d9863cb96f59..6c5c699002cb 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -459,7 +459,7 @@ INSTALL_DOC_TARGETS += quick-install-doc quick-install-man quick-install-html $(DOC_TARGETS): $(QUIET_SUBDIR0)Documentation $(QUIET_SUBDIR1) $(@:doc=all) -TAG_FOLDERS= . ../lib/traceevent ../lib/api ../lib/symbol +TAG_FOLDERS= . ../lib/traceevent ../lib/api ../lib/symbol ../include TAG_FILES= ../../include/uapi/linux/perf_event.h TAGS: -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Sun, Sep 06, 2015 at 04:20:39PM +0800, Yakir Yang wrote: > Hi Rob, > > 在 09/05/2015 05:46 AM, Rob Herring 写道: > >On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote: > >>Hi Rob, > >> > >>在 09/03/2015 04:17 AM, Rob Herring 写道: > >>>On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > Some edp screen do not have hpd signal, so we can't just return > failed when hpd plug in detect failed. > >>>This is a property of the panel (or connector perhaps), so this > >>>property should be located there. At least, it is a common issue and > >>>not specific to this chip. We could have an HDMI connector and failed > >>>to hook up HPD for example. A connector node is also where hpd-gpios > >>>should be located instead (and are already defined by > >>>../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >>>binding, too. > >> > >>Yep, I agree with your front point, it is a property of panel, not specific > >>to eDP controller, so this code should handle in connector logic. > >> > >>But another question, if we just leave this property to connector, > >>then we would need to parse this property in analogix_dp-rockchip.c, > >>and then make an hook in analogix_dp_core.c driver. This is not nice, > >>and if there are some coming platform which alse want to use analogix_dp > >>code and meet this "no-hpd" situation, then they would need duplicate > >>to parse this property and fill the hook in analogix_dp_core.c driver. > >>So it's little bit conflict :-) > >Ideally, you would be able to just retrieve this quirk from the > >connector or panel. Getting this property from your node vs. the port > >you are attached to should not be much harder. Either the connector > >struct can have this info or there can be a DT function that can walk > >the graph and get it. Just don't open code the graph traversal in your > >driver. > > > >>Beside I can not understand your example very well. Do you mean > >>that there are some HDMI monitor which also do not have HPD > >>signal (just like some eDP panel do not have hpd too), and then > >>the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want > >>to help in this case, would you mind show some sample code :-D > >I don't know that there is h/w, but it is always possible HPD is not > >hooked up or hooked up incorrectly some how. > > > >If there is no HPD support, then hpd-gpios is not going to help you. > > > >I think there are 3 cases to handle: > >- HPD handled by bridge chip - The bridge driver knows it has this > >capability. No DT properties are needed and no HPD properties on the > >connector node imply the bridge chip should handle HPD functions. > >- HPD handled by GPIO line (or some other block) - Indicated by > >hpd-gpios present > >- No or broken HPD - Indicated by "hpd-force" property. > > Oh, I think the first/second case isn't suitable in this case, my panel > "cnm,n116bgeea2" haven't included HPD signal. Note that if your panel doesn't signal HPD you're supposed to poll the sink to make sure you catch loss of link integrity. I've always found it odd that people would want to save a couple of bucks on the HPD signal conductor when that means that you will consume more power because you need to periodically poll the link for integrity. > >>>Are there any eDP panels which don't have EDID and need panel details in > >>>DT? > >> > >>Oh, I think you want to collect some info that belong to panel > >>property but no indicate in panel EDID message, so those can > >>be collect in eDP connector binding, is it right ? > >Yes, and as Thierry pointed out we may need to know the exact panel even. > > Yeah, just like I reply to Thierry, this is a panel quirk. And he suggest we > should > handle this in panel driver, but I have no idea how to handle this in common > panel > driver. :) Like I said in another subthread, this panel does have an HPD line in a variant that I've used in the past. So if your variant doesn't have the HPD line, we're dealing with quirks within the same family of panels. That would make this some sort of quirk, and I'm not sure if there is a standard way for defining quirks in DT. Rob, do you know of any precedent for this? I suppose we could always add a variant-specific compatible string that would allow this quirk to be encoded in the driver, though I'm not sure if the model string in datasheets has enough detail to tell them apart. Thierry signature.asc Description: PGP signature
Kernel 4.1.6 Panic due to slab corruption
Hello, On one of our servers I've observed the a kernel pannic happening with the following backtrace: [654405.527070] BUG: unable to handle kernel paging request at 00028001 [654405.527076] IP: [] kmem_cache_alloc_node+0x99/0x1e0 [654405.527085] PGD 14bef58067 PUD 2ab358067 PMD 0 [654405.527089] Oops: [#11] SMP [654405.527093] Modules linked in: xt_multiport tcp_diag inet_diag act_police cls_basic sch_ingress scsi_transport_iscsi ipt_REJECT nf_reject_ipv4 xt_pkttype xt_state veth openvswitch xt_owner xt_conntrack iptable_filter iptable_mangle xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat xt_CT nf_conntrack iptable_raw ip_tables ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr ipv6 ext2 dm_thin_pool dm_bio_prison dm_persistent_data dm_bufio libcrc32c dm_mirror dm_region_hash dm_log iTCO_wdt iTCO_vendor_support sb_edac edac_core i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core ioatdma dca ipmi_devintf ipmi_si ipmi_msghandler mpt2sas scsi_transport_sas raid_class [654405.527145] CPU: 14 PID: 32267 Comm: httpd Tainted: G D L 4.1.6-clouder1 #1 [654405.527147] Hardware name: Supermicro X9DRD-7LN4F(-JBOD)/X9DRD-EF/X9DRD-7LN4F, BIOS 3.0 07/09/2013 [654405.527149] task: 88139d3b1ec0 ti: 8808eda14000 task.ti: 8808eda14000 [654405.527151] RIP: 0010:[] [] kmem_cache_alloc_node+0x99/0x1e0 [654405.527155] RSP: 0018:88407fcc3a98 EFLAGS: 00210246 [654405.527156] RAX: RBX: RCX: 8814ce9acf80 [654405.527157] RDX: 837ad864 RSI: 00050200 RDI: 00018ce0 [654405.527158] RBP: 88407fcc3af8 R08: 88407fcd8ce0 R09: a033d990 [654405.527159] R10: 88058676fdd8 R11: 7b4a R12: 881fff807ac0 [654405.527161] R13: 00028001 R14: 0001 R15: 881fff807ac0 [654405.527162] FS: () GS:88407fcc(0063) knlGS:55c832e0 [654405.527164] CS: 0010 DS: 002b ES: 002b CR0: 80050033 [654405.527165] CR2: 00028001 CR3: 001467b64000 CR4: 000406e0 [654405.527166] Stack: [654405.527167] 881ff2d05000 [654405.527170] 88407fcc3ae8 00050200812b5903 88407fcc3ae8 01a2 [654405.527172] 0001 88058676fc60 88058676fe80 1800 [654405.527175] Call Trace: [654405.527177] [654405.527184] [] ovs_flow_stats_update+0x110/0x160 [openvswitch] [654405.527189] [] ovs_dp_process_packet+0x64/0xf0 [openvswitch] [654405.527193] [] ? netdev_port_receive+0x110/0x110 [openvswitch] [654405.527197] [] ? netdev_port_receive+0x110/0x110 [openvswitch] [654405.527201] [] ovs_vport_receive+0x85/0xb0 [openvswitch] [654405.527207] [] ? blk_mq_free_hctx_request+0x36/0x40 [654405.527209] [] ? blk_mq_free_request+0x31/0x40 [654405.527214] [] ? read_tsc+0x9/0x10 [654405.527220] [] ? ktime_get+0x54/0xc0 [654405.527225] [] ? put_device+0x17/0x20 [654405.527227] [] ? tcf_act_police+0x150/0x210 [act_police] [654405.527232] [] ? tcf_action_exec+0x51/0xa0 [654405.527235] [] ? basic_classify+0x75/0xe0 [cls_basic] [654405.527237] [] ? tc_classify+0x55/0xc0 [654405.527241] [] netdev_port_receive+0x9d/0x110 [openvswitch] [654405.527245] [] netdev_frame_hook+0x34/0x50 [openvswitch] [654405.527250] [] __netif_receive_skb_core+0x206/0x880 [654405.527252] [] __netif_receive_skb+0x27/0x70 [654405.527254] [] process_backlog+0xf1/0x1b0 [654405.527257] [] napi_poll+0xd3/0x1c0 [654405.527259] [] net_rx_action+0x90/0x1c0 [654405.527264] [] __do_softirq+0xfb/0x2a0 [654405.527270] [] do_softirq_own_stack+0x1c/0x30 [654405.527271] [654405.527273] [] do_softirq+0x55/0x60 [654405.527276] [] __local_bh_enable_ip+0x88/0x90 [654405.527279] [] ip_finish_output+0x282/0x490 [654405.527281] [] ip_output+0xab/0xc0 [654405.527283] [] ? ip_finish_output_gso+0x4e0/0x4e0 [654405.527285] [] ip_local_out_sk+0x3b/0x50 [654405.527287] [] ip_queue_xmit+0x14e/0x3c0 [654405.527291] [] tcp_transmit_skb+0x4c2/0x850 [654405.527294] [] tcp_write_xmit+0x19d/0x670 [654405.527298] [] ? copy_user_generic_string+0x31/0x40 [654405.527300] [] __tcp_push_pending_frames+0x32/0xd0 [654405.527302] [] tcp_push+0xf1/0x120 [654405.527304] [] tcp_sendmsg+0x373/0xb60 [654405.527307] [] ? mntput+0x23/0x40 [654405.527310] [] ? path_put+0x22/0x30 [654405.527315] [] inet_sendmsg+0x42/0xb0 [654405.527317] [] ? kmem_cache_alloc+0xee/0x1c0 [654405.527321] [] sock_sendmsg+0x4d/0x60 [654405.527324] [] sock_write_iter+0xb6/0x100 [654405.527328] [] do_iter_readv_writev+0x60/0x90 [654405.527330] [] ? kernel_sendmsg+0x40/0x40 [654405.527332] [] compat_do_readv_writev+0x174/0x1f0 [654405.527337] [] ? rcu_eqs_exit+0x79/0xb0 [654405.527339] [] ? rcu_user_exit+0x13/0x20 [654405.527342] [] compat_SyS_writev+0xc1/0x110 [654405.527346] [] ? context_tracking_user_enter+0x13/0x20 [654405.527349] [] syse
Re: [PATCH 01/11] ARM64 / PCI: introduce struct pci_controller for ACPI
On Mon, Sep 07, 2015 at 05:14:22AM +0100, Ganapatrao Kulkarni wrote: > Hi Hanjun, > > On Wed, May 27, 2015 at 1:51 PM, Hanjun Guo wrote: > > Hi Liviu, > > > > On 2015???05???27??? 01:20, Jiang Liu wrote: > >> > >> On 2015/5/27 0:58, Liviu Dudau wrote: > >>> > >>> On Tue, May 26, 2015 at 01:49:14PM +0100, Hanjun Guo wrote: > > ARM64 ACPI based PCI host bridge init needs a arch dependent > struct pci_controller to accommodate common PCI host bridge > code which is introduced later, or it will lead to compile > errors on ARM64. > >>> > >>> > >>> Hi Hanjun, > >>> > >>> Two questions: why don't you introduce this patch next to the > >>> one that is going to make use of it (or even merge it there)? > > > > > > this is because of this patch is needed by Jiang Liu's patch set > > to fix the compile error on ARM64, I'd rather do that, but It's > > better to let Jiang Liu's patch goes in, and then this one, that's > > why I prepared a single patch for the struct. (I mentioned it > > in the cover letter) > > > >>> Second, why is the whole struct pci_controller not surrounded > >>> by #ifdef CONFIG_ACPI as you are implying that this is needed > >>> only for ACPI? > > > > > > I hope it can be reused, since the NUMA node and segment (domain) > > is both needed for DT and ACPI, if it's not the case foe now, I > > can surrounded them all by #ifdef CONFIG_ACPI. > we can make use of this structure to hold pci to numa node > mapping(pcibus_to_node). > can you please pull node member out of CONFIG_ACPI ifdef. > or you can put only acpi_device under ifdef. That struct disappeared in the latest series: https://lkml.org/lkml/2015/6/8/443 we have to have a common way to handle the NUMA info in DT and ACPI so we should still find a solution that can be shared between the two, it is yet another thing to take into account for PCI ACPI on arm64. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
On Mon, 2015-09-07 at 16:56 +0900, Krzysztof Kozlowski wrote: > On 07.09.2015 16:53, Heiko Stübner wrote: > > Am Montag, 7. September 2015, 16:24:53 schrieb Krzysztof Kozlowski: > > I guess the easiest option would be to just drop the dwc2 from > > here, only > > keeping the phy enablement and let everything (Marek's and Sjoerd's > > patch) > > come together in the armsoc defconfig branch? As the rest of both > > patches don't > > seem to touch common areas, they should be easily mergable from > > different trees > > as well. > > Yes, I agree. The config PHY_ROCKCHIP_USB does not depend on it > directly > so this should work fine. Sounds good, I'll wait a bit longer for more feedback and then send a V2 with patch 4 adjusted to just enable the rockchip PHY. Thanks for the feedback! -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Revert "ahci: added support for Freescale AHCI sata"
Hi,
On 07-09-15 10:23, yuantian.t...@freescale.com wrote:
From: Tang Yuantian
This reverts commit 5163fb62541e
("ahci: added support for Freescale AHCI sata")
The reverted patch added Freescale QorIQ AHCI sata support to
ahci_platform driver though, but it left SoC specific settings to uboot.
It leads to QorIQ sata heavily depending on uboot. In order to removing
the dependency we first revert the old patch and then will add a new driver
for QorIQ SATA.
Since there are no LS* platforms that have been upstreamed, So
the revert would not break anything exists.
Signed-off-by: Tang Yuantian
The entire series looks good to me and is:
Reviewed-by: Hans de Goede
Regards,
Hans
---
Documentation/devicetree/bindings/ata/ahci-platform.txt | 2 --
drivers/ata/ahci_platform.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index a232181..c2340ee 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -16,8 +16,6 @@ Required properties:
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"
- - "fsl,qoriq-ahci" : for qoriq series socs which include ls1021, ls2085, etc.
- - "fsl,-ahci" : chip could be ls1021, ls2085 etc.
- "generic-ahci"
- interrupts:
- reg :
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 1befb11..04975b8 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,7 +76,6 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
{ .compatible = "hisilicon,hisi-ahci", },
- { .compatible = "fsl,qoriq-ahci", },
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: vfxxx: Add iio_hwmon node for ADC temperature channel
Hi Shawn,
On 15-09-06 12:32:32, Shawn Guo wrote:
> On Thu, Aug 06, 2015 at 09:28:22PM +0530, Sanchayan Maity wrote:
> > Add iio_hwmon node to expose the temperature channel on Vybrid
> > as hardware monitor device using the iio_hwmon driver.
> >
> > Signed-off-by: Sanchayan Maity
> > ---
> > arch/arm/boot/dts/vfxxx.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 39173bb..0993d66 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -597,5 +597,10 @@
> > status = "disabled";
> > };
> > };
> > +
> > + iio_hwmon {
>
> Hyphen rather than underscore should be used in node name.
As per iio-bindings.txt I did this. It is the same in imx23.dtsi and imx28.dtsi.
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/iio-bindings.txt#L85
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx23.dtsi#L570
http://lxr.free-electrons.com/source/arch/arm/boot/dts/imx28.dtsi#L1246
So should this be changed?
Thanks.
- Sanchayan.
>
> Shawn
>
> > + compatible = "iio-hwmon";
> > + io-channels = <&adc0 16>;
> > + };
> > };
> > };
> > --
> > 2.5.0
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v0 2/9] suspend: Add getter function to report if freezing is active
On 09/05/2015 04:11 AM, Rafael J. Wysocki wrote:
> On Friday, September 04, 2015 03:34:55 PM Daniel Wagner wrote:
>> Instead encode the FREEZE state via the CPU state we allow the
>> interesting subsystems (MCE, microcode) to query the power
>> subsystem directly.
>
> A use case, please.
The motivation for this change is to reduce the complexity in the
hotplug code. As tried to point out in the cover letter, the FROZEN
bits have only a bunch of users after all those years (2007). So it is
worth to have all the notifier users to handle the FROZEN state?
Don't know if that counts as use case.
>> Most notifiers are not interested at all
>> in this information so rather have explicit calls to freeze_active()
>> instead adding complexity to the rest of the users of the CPU
>> notifiers.
>
> Why does it has anything to do with CPU notifiers?
cpu_{down|up} will call the notifiers with the CPU_TASK_FROZEN bit set
and so most notifiers are doing
switch (actcion ~CPU_TASK_FROZEN)
to filter it out because they don't need to handle the system wide
ongoing freeze operations.
> We don't offline CPUs for suspend-to-idle.
Sure. As I said the motivation is to reduce the complexity in the
hotplug code.
Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] arm64: cpuinfo: reduce cache contention on update_{feature}_support
On Fri, Sep 04, 2015 at 09:36:06AM -0700, David Daney wrote:
> On 09/04/2015 09:04 AM, Yury Norov wrote:
> >This patch is on top of https://lkml.org/lkml/2015/9/2/413
> >
> >In master, there's only a single function -
> > update_mixed_endian_el0_support
> >And similar function is on review mentioned above.
> >
> >The algorithm for them is like this:
> > - there's system-wide boolean marker for the feature that is
> >initially enabled;
> > - there's also updater for the feature that may disable it
> >system-widely if feature is not supported on current CPU.
> > - updater is called for each CPU on bootup.
> >
> >The problem is the way updater does its work. On each CPU, it
> >unconditionally updates system-wide marker. For multi-core
> >system it makes CPU issue invalidate message for a cache
> >line containing marker. This invalidate increases cache
> >contention for nothing, because there's a single marker reset
> >that is really needed, and the others are useless.
> >
> >If the number of system-wide markers of this sort will grow,
> >it may become a trouble on large-scale SOCs. The fix is trivial,
> >though: do system-wide marker update conditionally, and preserve
> >corresponding cache line in shared state for all update() calls,
> >except, probably, one.
> >
> >Signed-off-by: Yury Norov
> >---
> > arch/arm64/kernel/cpuinfo.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> >index 4a6ae31..9972c1e 100644
> >--- a/arch/arm64/kernel/cpuinfo.c
> >+++ b/arch/arm64/kernel/cpuinfo.c
> >@@ -87,12 +87,14 @@ bool system_supports_aarch32_el0(void)
> >
> > static void update_mixed_endian_el0_support(struct cpuinfo_arm64 *info)
> > {
> >-mixed_endian_el0 &=
> >id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0);
> >+if (mixed_endian_el0 &&
> >!id_aa64mmfr0_mixed_endian_el0(info->reg_id_aa64mmfr0))
> >+mixed_endian_el0 = false;
> > }
> >
> > static void update_aarch32_el0_support(struct cpuinfo_arm64 *info)
> > {
> >-aarch32_el0 &= id_aa64pfr0_aarch32_el0(info->reg_id_aa64pfr0);
> >+if (aarch32_el0 && !id_aa64pfr0_aarch32_el0(info->reg_id_aa64pfr0))
> >+aarch32_el0 = false;
> > }
>
> How many times in the lifetime of the kernel are these functions called?
>
> If it is just done at startup, then there is no "steady state" performance
> impact, and the burden of complicating the code may not be worthwhile.
I fully agree. Unless the code is on some hot path, I really don't care
about few cycles potentially saved during boot.
And in general, with any such micro optimisations, I want to see
benchmark results to prove it worth.
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/4] powerpc: PCI: Fix lookup of linux,pci-probe-only property
On Fri, 2015-09-04 at 17:50 +0100, Marc Zyngier wrote: > When find_and_init_phbs() looks for the probe-only property, it seems > to trust the firmware to be correctly written, and assumes that there > is a parameter to the property. > > It is conceivable that the firmware could not be that perfect, and it > could expose this property naked (at least one arm64 platform seems to > exhibit this exact behaviour). The setup code the ends up making > a decision based on whatever the property pointer points to, which > is likely to be junk. > > Instead, switch to the common of_pci.c implementation that doesn't > suffer from this problem and ignore the property if the firmware > couldn't make up its mind. > > Signed-off-by: Marc Zyngier > --- > arch/powerpc/platforms/pseries/setup.c | 14 ++ Thanks. I can't find any powerpc machine that is currently using this, or much info on what ever did use it, so I think it's pretty low impact, and the change looks sane. Acked-by: Michael Ellerman cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: most: MOST and MOSTCORE should depend on HAS_DMA
On Tue, 1 Sep 2015 22:05:58 +0200 Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "dma_free_coherent" [drivers/staging/most/mostcore/mostcore.ko] > undefined! > ERROR: "dma_alloc_coherent" [drivers/staging/most/mostcore/mostcore.ko] > undefined! > > As all MOST sub drivers use DMA functionality, add a dependency on > HAS_DMA to MOSTCORE, and to MOST, which selects MOSTCORE. > > Signed-off-by: Geert Uytterhoeven Acked-by: Christian Gromm > --- > drivers/staging/most/Kconfig | 1 + > drivers/staging/most/mostcore/Kconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/staging/most/Kconfig b/drivers/staging/most/Kconfig > index d50de03de7b98972..0b9b9b539f70562d 100644 > --- a/drivers/staging/most/Kconfig > +++ b/drivers/staging/most/Kconfig > @@ -1,5 +1,6 @@ > menuconfig MOST > tristate "MOST driver" > + depends on HAS_DMA > select MOSTCORE > default n > ---help--- > diff --git a/drivers/staging/most/mostcore/Kconfig > b/drivers/staging/most/mostcore/Kconfig > index 38abf1b21b6623c7..47172546d7280ee6 100644 > --- a/drivers/staging/most/mostcore/Kconfig > +++ b/drivers/staging/most/mostcore/Kconfig > @@ -4,6 +4,7 @@ > > config MOSTCORE > tristate "MOST Core" > + depends on HAS_DMA > > ---help--- > Say Y here if you want to enable MOST support. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Fri, Sep 04, 2015 at 11:20:03AM +0100, Russell King - ARM Linux wrote: > On Thu, Sep 03, 2015 at 11:04:40AM +0200, Thierry Reding wrote: > > Conversely, if the panel isn't capable of generating an HPD signal, then > > I don't think it would be appropriate to make it a DT property. It would > > be better to hard-code it in the driver, lest someone forget to set the > > property in DT and get stuck with a device that isn't operational. > > There is another way to deal with this: DRM supports the idea of connector > forcing - where you can force the connector to think that it's connected > or disconnected. Yes, this could work well for RGB/LVDS or DSI connectors perhaps. For eDP there is added complexity because the HPD interrupt function is also used to signal loss of link integrity. That is, after receiving an HPD interrupt you are supposed to retrain the link (or at least check the link status to see if the interrupt cause is loss of integrity). While the eDP specification makes HPD optional, it also says that if HPD isn't available, then the source must use polling to monitor link integrity instead. DRM does provide a mechanism for that as well. You can set the connector's ->polled field to DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT and have the core actively poll for the connector status (i.e. call ->detect() every 100 ms). I think use of polling would be more appropriate in case of eDP. > One of the problems is that not many ARM DRM drivers implement it - maybe > it should be a requirement for code to be accepted? :) I suspect that many drivers may roll their own. In fact I'm guilty of that myself. On Tegra we have a default implementation for outputs which will default to the state of an HPD GPIO where available and fall back to "always connected" for outputs that have a panel connected. Outputs that have a separate mechanism to signal hotplug detection (such as DP) simply use a custom ->detect() implementation. The overhead of rolling one's own is almost zero and connector forcing has the disadvantage of being available via sysfs and debugfs, so the default set by drivers could be overwritten by users at runtime with no easy way back. Given the above I'm not sure enforcing connector forcing would be beneficial. Thierry signature.asc Description: PGP signature
RE: [PATCH] net: tipc: fix stall during bclink wakeup procedure
If an attempt to wake up users of broadcast link is made when there is
no enough place in send queue than it may hang up inside the
tipc_sk_rcv() function since the loop breaks only after the wake up
queue becomes empty. This can lead to complete CPU stall with the
following message generated by RCU:
INFO: rcu_sched self-detected stall on CPU { 0} (t=2101 jiffies
g=54225 c=54224 q=11465)
Task dump for CPU 0:
tpchR running task0 39949 39948 0x000a
818536c0 88181fa037a0 8106a4be
818536c0 88181fa037c0 8106d8a8 88181fa03800
0001 88181fa037f0 81094a50 88181fa15680
Call Trace:
[] sched_show_task+0xae/0x120
[] dump_cpu_task+0x38/0x40
[] rcu_dump_cpu_stacks+0x90/0xd0
[] rcu_check_callbacks+0x3eb/0x6e0
[] ? account_system_time+0x7f/0x170
[] update_process_times+0x34/0x60
[] tick_sched_handle.isra.18+0x31/0x40
[] tick_sched_timer+0x3c/0x70
[] __run_hrtimer.isra.34+0x3d/0xc0
[] hrtimer_interrupt+0xc5/0x1e0
[] ? native_smp_send_reschedule+0x42/0x60
[] local_apic_timer_interrupt+0x34/0x60
[] smp_apic_timer_interrupt+0x3c/0x60
[] apic_timer_interrupt+0x6b/0x70
[] ? _raw_spin_unlock_irqrestore+0x9/0x10
[] __wake_up_sync_key+0x4f/0x60
[] tipc_write_space+0x31/0x40 [tipc]
[] filter_rcv+0x31f/0x520 [tipc]
[] ? tipc_sk_lookup+0xc9/0x110 [tipc]
[] ? _raw_spin_lock_bh+0x19/0x30
[] tipc_sk_rcv+0x2dc/0x3e0 [tipc]
[] tipc_bclink_wakeup_users+0x2f/0x40 [tipc]
[] tipc_node_unlock+0x186/0x190 [tipc]
[] ? kfree_skb+0x2c/0x40
[] tipc_rcv+0x2ac/0x8c0 [tipc]
[] tipc_l2_rcv_msg+0x38/0x50 [tipc]
[] __netif_receive_skb_core+0x5a3/0x950
[] __netif_receive_skb+0x13/0x60
[] netif_receive_skb_internal+0x1e/0x90
[] napi_gro_receive+0x78/0xa0
[] tg3_poll_work+0xc54/0xf40 [tg3]
[] ? consume_skb+0x2c/0x40
[] tg3_poll_msix+0x41/0x160 [tg3]
[] net_rx_action+0xe2/0x290
[] __do_softirq+0xda/0x1f0
[] irq_exit+0x76/0xa0
[] do_IRQ+0x55/0xf0
[] common_interrupt+0x6b/0x6b
The issue occurs only when tipc_sk_rcv() is used to wake up postponed
senders:
tipc_bclink_wakeup_users()
// wakeupq - is a queue which consists of special
// messages with SOCK_WAKEUP type.
tipc_sk_rcv(wakeupq)
...
while (skb_queue_len(inputq)) {
filter_rcv(skb)
// Here the type of message is checked
// and if it is SOCK_WAKEUP then
// it tries to wake up a sender.
tipc_write_space(sk)
wake_up_interruptible_sync_poll()
}
After the sender thread is woke up it can gather control and perform
an attempt to send a message. But if there is no enough place in send
queue it will call link_schedule_user() function which puts a message
of type SOCK_WAKEUP to the wakeup queue and put the sender to sleep.
Thus the size of the queue actually is not changed and the while()
loop never exits.
The approach I proposed is to wake up only senders for which there is
enough place in send queue so the described issue can't occur.
Moreover the same approach is already used to wake up senders on
unicast links.
I have got into the issue on our product code but to reproduce the
issue I changed a benchmark test application (from
tipcutils/demos/benchmark) to perform the following scenario:
1. Run 64 instances of test application (nodes). It can be done
on the one physical machine.
2. Each application connects to all other using TIPC sockets in
RDM mode.
3. When setup is done all nodes start simultaneously send
broadcast messages.
4. Everything hangs up.
The issue is reproducible only when a congestion on broadcast link
occurs. For example, when there are only 8 nodes it works fine since
congestion doesn't occur. Send queue limit is 40 in my case (I use a
critical importance level) and when 64 nodes send a message at the
same moment a congestion occurs every time.
Signed-off-by: Dmitry S Kolmakov
Reviewed-by: Jon Maloy
Acked-by: Ying Xue
---
v2: Updated after comments from Jon and Ying.
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index c5cbdcb..997dd60 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -169,6 +169,30 @@ static void bclink_retransmit_pkt(struct tipc_net *tn, u32
after, u32 to)
}
/**
+ * bclink_prepare_wakeup - prepare users for wakeup after congestion
+ * @bcl: broadcast link
+ * @resultq: queue for users which can be woken up
+ * Move a number of waiting users, as permitted by available space in
+ * the send queue, from link wait queue to specified queue for wakeup
+ */
+static void bclink_prepare_wakeup(struct tipc_link *bcl, struct sk_
Re: [PATCH v4 07/13] usb: otg: add OTG core
On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
> The OTG core instantiates the OTG Finite State Machine
> per OTG controller and manages starting/stopping the
> host and gadget controllers based on the bus state.
>
> It provides APIs for the following tasks
>
> - Registering an OTG capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
>
> Signed-off-by: Roger Quadros
> ---
> MAINTAINERS |4 +-
> drivers/usb/Kconfig |2 +-
> drivers/usb/Makefile |1 +
> drivers/usb/common/Makefile |3 +-
> drivers/usb/common/usb-otg.c | 1061
> ++
> drivers/usb/common/usb-otg.h | 71 +++
> drivers/usb/core/Kconfig | 11 +-
> include/linux/usb/otg.h | 189 +++-
> 8 files changed, 1321 insertions(+), 21 deletions(-)
> create mode 100644 drivers/usb/common/usb-otg.c
> create mode 100644 drivers/usb/common/usb-otg.h
>
... ...
> +
> +/**
> + * Get OTG device from host or gadget device.
> + *
> + * For non device tree boot, the OTG controller is assumed to be
> + * the parent of the host/gadget device.
This assumption/restriction maybe a problem, as I pointed in your previous
version, usb_create_hcd() use the passed dev as its dev, but,
usb_add_gadget_udc() use the passed dev as its parent dev, so often the
host and gadget don't share the same parent device, at least it doesn't
apply to chipidea case.
> + * For device tree boot, the OTG controller is derived from the
> + * "otg-controller" property.
> + */
> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
> +{
> + struct device *otg_dev;
> +
> + if (!hcd_gcd_dev)
> + return NULL;
> +
> + if (hcd_gcd_dev->of_node) {
> + struct device_node *np;
> + struct platform_device *pdev;
> +
> + np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
> + 0);
> + if (!np)
> + goto legacy;/* continue legacy way */
> +
> + pdev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!pdev) {
> + dev_err(&pdev->dev, "couldn't get otg-controller
> device\n");
> + return NULL;
> + }
> +
> + otg_dev = &pdev->dev;
> + return otg_dev;
> + }
> +
> +legacy:
> + /* otg device is parent and must be registered */
> + otg_dev = hcd_gcd_dev->parent;
> + if (!usb_otg_get_data(otg_dev))
> + return NULL;
> +
> + return otg_dev;
> +}
> +
... ...
> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
> +{
> + struct otg_fsm *fsm = &otgd->fsm;
> + unsigned long tmouts[NUM_OTG_FSM_TIMERS];
> + int i;
> +
> + /* set default timeouts */
> + tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
> + tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
> + tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
> + tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
> + tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
> + tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
> + tmouts[B_SE0_SRP] = TB_SE0_SRP;
> + tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
> +
> + /* set controller provided timeouts */
> + if (timeouts) {
> + for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
> + if (timeouts[i])
> + tmouts[i] = timeouts[i];
> + }
> + }
> +
> + otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
> +&fsm->a_wait_vrise_tmout);
> + otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
> +&fsm->a_wait_vfall_tmout);
> + otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
> +&fsm->a_wait_bcon_tmout);
> + otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
> +&fsm->a_aidl_bdis_tmout);
> + otg_timer_init(A_BIDL_ADIS, otgd, set_tmout, TA_BIDL_ADIS,
> +&fsm->a_bidl_adis_tmout);
> + otg_timer_init(B_ASE0_BRST, otgd, set_tmout, TB_ASE0_BRST,
> +&fsm->b_ase0_brst_tmout);
> +
> + otg_timer_init(B_SE0_SRP, otgd, set_tmout, TB_SE0_SRP,
> +&fsm->b_se0_srp);
> + otg_timer_init(B_SRP_FAIL, otgd, set_tmout, TB_SRP_FAIL,
> +&fsm->b_srp_done);
> +
> + /* FIXME: what about A_WAIT_ENUM? */
Either you init it as other timers, or you remove all of it, otherwise
there will be NULL pointer crash.
> +}
> +
> +/**
> + * OTG FSM ops function to add timer
> + */
> +static void usb_otg_add_timer(struct otg_fsm *fsm, enum otg_fsm_timer id)
> +{
> + struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
> + struct otg_timer *otgtimer = &otgd->timers[id];
> + struct hrtimer *timer = &otgtimer->timer;
> +
> + if (!otgd->fsm_running)
> + return
[PATCH V2] audit: try harder to send to auditd upon netlink failure
There are several reports of the kernel losing contact with auditd when
it is, in fact, still running. When this happens, kernel syslogs show:
"audit: *NO* daemon at audit_pid="
although auditd is still running, and is apparently happy, listening on
the netlink socket. The pid in the "*NO* daemon" message matches the pid
of the running auditd process. Restarting auditd solves this.
The problem appears to happen randomly, and doesn't seem to be strongly
correlated to the rate of audit events being logged. The problem
happens fairly regularly (every few days), but not yet reproduced to
order.
On production kernels, BUG_ON() is a no-op, so any error will trigger
this.
Commit 34eab0a7cd45 ("audit: prevent an older auditd shutdown from
orphaning a newer auditd startup") eliminates one possible cause. This
isn't the case here, since the PID in the error message and the PID of
the running auditd match.
The primary expected cause of error here is -ECONNREFUSED when the audit
daemon goes away, when netlink_getsockbyportid() can't find the auditd
portid entry in the netlink audit table (or there is no receive
function). If -EPERM is returned, that situation isn't likely to be
resolved in a timely fashion without administrator intervention. In
both cases, reset the audit_pid. This does not rule out a race
condition. SELinux is expected to return zero since this isn't an INET
or INET6 socket. Other LSMs may have other return codes. Log the error
code for better diagnosis in the future.
In the case of -ENOMEM, the situation could be temporary, based on local
or general availability of buffers. -EAGAIN should never happen since
the netlink audit (kernel) socket is set to MAX_SCHEDULE_TIMEOUT.
-ERESTARTSYS and -EINTR are not expected since this kernel thread is not
expected to receive signals. In these cases (or any other unexpected
ones for now), report the error and re-schedule the thread, retrying up
to 5 times.
v2:
Removed BUG_ON().
Moved comma in pr_*() statements.
Removed audit_strerror() text.
Reported-by: Vipin Rathor
Reported-by:
Signed-off-by: Richard Guy Briggs
---
kernel/audit.c | 24 +++-
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..18cdfe2 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -407,16 +407,30 @@ static void audit_printk_skb(struct sk_buff *skb)
static void kauditd_send_skb(struct sk_buff *skb)
{
int err;
+ int attempts = 0;
+#define AUDITD_RETRIES 5
+
+restart:
/* take a reference in case we can't send it and we want to hold it */
skb_get(skb);
err = netlink_unicast(audit_sock, skb, audit_nlk_portid, 0);
if (err < 0) {
- BUG_ON(err != -ECONNREFUSED); /* Shouldn't happen */
+ pr_err("netlink_unicast sending to audit_pid=%d returned error:
%d\n",
+ audit_pid, err);
if (audit_pid) {
- pr_err("*NO* daemon at audit_pid=%d\n", audit_pid);
- audit_log_lost("auditd disappeared");
- audit_pid = 0;
- audit_sock = NULL;
+ if (err == -ECONNREFUSED || err == -EPERM
+ || ++attempts >= AUDITD_RETRIES) {
+ audit_log_lost("audit_pid=%d reset");
+ audit_pid = 0;
+ audit_sock = NULL;
+ } else {
+ pr_warn("re-scheduling(#%d) write to
audit_pid=%d\n",
+ attempts, audit_pid);
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule();
+ __set_current_state(TASK_RUNNING);
+ goto restart;
+ }
}
/* we might get lucky and get this in the next auditd */
audit_hold_skb(skb);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC tip/core/rcu 3/9] rcu_sync: Add CONFIG_PROVE_RCU checks
On 08/29/2015 05:35 AM, Paul E. McKenney wrote:
> +extern bool __rcu_sync_is_idle(struct rcu_sync *);
> +
> /**
> * rcu_sync_is_idle() - Are readers permitted to use their fastpaths?
> * @rsp: Pointer to rcu_sync structure to use for synchronization
> @@ -50,7 +52,11 @@ struct rcu_sync {
> */
> static inline bool rcu_sync_is_idle(struct rcu_sync *rsp)
> {
> +#ifdef CONFIG_PROVE_RCU
> + return __rcu_sync_is_idle(rss);
s/rss/rsp?
> +#else
> return !rsp->gp_state; /* GP_IDLE */
> +#endif
> }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH RT 0/3] RT: Fix trylock deadlock without msleep() hack
On Sat, 5 Sep 2015, Steven Rostedt wrote:
> On Sat, 5 Sep 2015 08:18:36 -0400
> Steven Rostedt wrote:
>
> > On Sat, 5 Sep 2015 12:30:59 +0200 (CEST)
> > Thomas Gleixner wrote:
> > >
> > > So instead of doing that proposed magic boost, we can do something
> > > more straight forward:
> > >
> > > retry:
> > > lock(B);
> > > if (!try_lock(A)) {
> > > lock_and_drop(A, B);
> > > unlock(A);
> > > goto retry;
> > > }
> > >
> > > lock_and_drop() queues the task as a waiter on A, drops B and then
> > > does the PI adjustment on A.
> >
> > That was my original solution, and I believe I added patches to do
> > exactly that to the networking code in the past. I remember writing
> > that helper function such that on non PREEMPT_RT it was a nop.
>
> Just to point out again that I misread what you wrote. That's what I
> get for responding to email 10 minutes after I get out of bed ;-)
>
>
> You need to be careful about adding the waiter on A. If the owner of A
> is blocked on B, the pi inheritance may detect that as a deadlock.
That's exactly why I wrote:
> > > lock_and_drop() queues the task as a waiter on A, drops B and then
> > > does the PI adjustment on A.
because the PI adjustment would detect the deadlock.
Now the real question is whether we need that complexity at all. We
need to analyze the life time rules. If we have something like this:
lock(y->lock);
x = y->x;
...
and x cannot go away under us, then we can simply do
lock(y->lock);
x = y->x;
if (!trylock(x->lock)) {
unlock(y->lock);
lock(x->lock);
unlock(x->lock);
goto retry;
}
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
On Fri, Sep 04, 2015 at 05:50:09PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware expose
> this property naked. The driver ends up making a decision based on
> whatever the property pointer points to, which is likely to be junk.
>
> Switch to the common of_pci.c implementation that doesn't suffer
> from this problem.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/pci/host/pci-host-generic.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index 265dd25..224303d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
> int err;
> const char *type;
> const struct of_device_id *of_id;
> - const int *prop;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
> - if (prop) {
> - if (*prop)
> - pci_add_flags(PCI_PROBE_ONLY);
> - else
> - pci_clear_flags(PCI_PROBE_ONLY);
> - }
> + of_pci_check_probe_only();
Looks good to me:
Acked-by: Will Deacon
Thanks, Marc.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 13/13] usb: otg: Add dual-role device (DRD) support
On Mon, Aug 24, 2015 at 04:21:24PM +0300, Roger Quadros wrote:
> DRD mode is a reduced functionality OTG mode. In this mode
> we don't support SRP, HNP and dynamic role-swap.
>
> In DRD operation, the controller mode (Host or Peripheral)
> is decided based on the ID pin status. Once a cable plug (Type-A
> or Type-B) is attached the controller selects the state
> and doesn't change till the cable in unplugged and a different
> cable type is inserted.
>
> As we don't need most of the complex OTG states and OTG timers
> we implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs
> 'id' and 'b_sess_vld'.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/usb/common/usb-otg.c | 178
> +--
> include/linux/usb/otg-fsm.h | 5 ++
> include/linux/usb/otg.h | 2 +
> 3 files changed, 177 insertions(+), 8 deletions(-)
>
... ...
> +/* Called when entering a DRD state */
> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
> +{
> + struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
> +
> + if (fsm->otg->state == new_state)
> + return;
> +
> + fsm->state_changed = 1;
> + dev_dbg(otgd->dev, "otg: set state: %s\n",
> + usb_otg_state_string(new_state));
> + switch (new_state) {
> + case OTG_STATE_B_IDLE:
> + drd_set_protocol(fsm, PROTO_UNDEF);
You didn't address this comment for your previous version.
otg_drv_vbus(fsm, 0);
> + break;
> + case OTG_STATE_B_PERIPHERAL:
> + drd_set_protocol(fsm, PROTO_GADGET);
otg_drv_vbus(fsm, 0);
> + break;
> + case OTG_STATE_A_HOST:
otg_drv_vbus(fsm, 1);
> + drd_set_protocol(fsm, PROTO_HOST);
> + break;
> + case OTG_STATE_UNDEFINED:
> + case OTG_STATE_B_SRP_INIT:
> + case OTG_STATE_B_WAIT_ACON:
> + case OTG_STATE_B_HOST:
> + case OTG_STATE_A_IDLE:
> + case OTG_STATE_A_WAIT_VRISE:
> + case OTG_STATE_A_WAIT_BCON:
> + case OTG_STATE_A_SUSPEND:
> + case OTG_STATE_A_PERIPHERAL:
> + case OTG_STATE_A_WAIT_VFALL:
> + case OTG_STATE_A_VBUS_ERR:
> + default:
> + dev_warn(otgd->dev, "%s: otg: invalid state: %s\n",
> + __func__, usb_otg_state_string(new_state));
> + break;
> + }
> +
> + fsm->otg->state = new_state;
> +}
> +
... ...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: tegra: paz00: use con_id's to refer GPIO's in gpiod_lookup table
30.06.2015 17:15, Dmitry Osipenko пишет:
Commit 72daceb9a10a ("net: rfkill: gpio: Add default GPIO driver mappings
for ACPI") removed possibility to request GPIO by table index for non-ACPI
platforms without changing it users. As result "shutdown" GPIO request
will fail if request for "reset" GPIO succeeded or "reset" will be
requested instead of "shutdown" if "reset" wasn't defined. Fix it by
making gpiod_lookup_table use con_id's instead of indexes.
Signed-off-by: Dmitry Osipenko
Fixes: 72daceb (net: rfkill: gpio: Add default GPIO driver mappings for ACPI)
Cc: # v3.19+
Acked-by: Alexandre Courbot
---
v2: s/GPIO_LOOKUP_IDX/GPIO_LOOKUP/, otherwise "shutdown" GPIO won't be requested
arch/arm/mach-tegra/board-paz00.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/board-paz00.c
b/arch/arm/mach-tegra/board-paz00.c
index fbe74c6..49d1110 100644
--- a/arch/arm/mach-tegra/board-paz00.c
+++ b/arch/arm/mach-tegra/board-paz00.c
@@ -39,8 +39,8 @@ static struct platform_device wifi_rfkill_device = {
static struct gpiod_lookup_table wifi_gpio_lookup = {
.dev_id = "rfkill_gpio",
.table = {
- GPIO_LOOKUP_IDX("tegra-gpio", 25, NULL, 0, 0),
- GPIO_LOOKUP_IDX("tegra-gpio", 85, NULL, 1, 0),
+ GPIO_LOOKUP("tegra-gpio", 25, "reset", 0),
+ GPIO_LOOKUP("tegra-gpio", 85, "shutdown", 0),
{ },
},
};
Ping
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpu: host1x: Fix MLOCK's debug info
28.06.2015 22:27, Dmitry Osipenko пишет:
MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK
owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted
value, while unshifted should be used. Fix it by changing '_F' to '_V'.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/hw/debug_hw.c | 2 +-
drivers/gpu/host1x/hw/hw_host1x01_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x02_sync.h | 8
drivers/gpu/host1x/hw/hw_host1x04_sync.h | 8
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c
index 791de93..cc3f182 100644
--- a/drivers/gpu/host1x/hw/debug_hw.c
+++ b/drivers/gpu/host1x/hw/debug_hw.c
@@ -298,7 +298,7 @@ static void host1x_debug_show_mlocks(struct host1x *host,
struct output *o)
host1x_sync_readl(host, HOST1X_SYNC_MLOCK_OWNER(i));
if (HOST1X_SYNC_MLOCK_OWNER_CH_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by channel %d\n",
- i, HOST1X_SYNC_MLOCK_OWNER_CHID_F(owner));
+ i, HOST1X_SYNC_MLOCK_OWNER_CHID_V(owner));
else if (HOST1X_SYNC_MLOCK_OWNER_CPU_OWNS_V(owner))
host1x_debug_output(o, "%d: locked by cpu\n", i);
else
diff --git a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
index ac704e5..31238c2 100644
--- a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
index 4495401..540c7b6 100644
--- a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
diff --git a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
index ef2275b..3d6c8ec 100644
--- a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
+++ b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
@@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned int
id)
}
#define HOST1X_SYNC_MLOCK_OWNER(id) \
host1x_sync_mlock_owner_r(id)
-static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
+static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
{
- return (v & 0xf) << 8;
+ return (v >> 8) & 0xf;
}
-#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
- host1x_sync_mlock_owner_chid_f(v)
+#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
+ host1x_sync_mlock_owner_chid_v(v)
static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
{
return (r >> 1) & 0x1;
Ping Thierry
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: Re: eata fails to load on post 4.2 kernels
Forwarding without image attachment to get below message size limit of the mailing lists. I've uploaded the image to: http://www.users.on.net/~arthur.marsh/20150907539.jpg Forwarded Message Subject: Re: eata fails to load on post 4.2 kernels Date: Mon, 07 Sep 2015 15:56:02 +0930 From: Arthur Marsh To: Jiang Liu CC: Bjorn Helgaas , t...@linutronix.de, linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org Jiang Liu wrote on 07/09/15 12:36: On 2015/9/7 4:31, Arthur Marsh wrote: Arthur Marsh wrote on 06/09/15 21:07: Arthur Marsh wrote on 06/09/15 18:34: Arthur Marsh wrote on 06/09/15 15:58: Hi, I'm seeing the following on post 4.2 kernels, am currently bisecting to find where it started: First kernel in the bisection that worked without needing irqpoll: [ 73.751482] EATA0: IRQ 10 mapped to IO-APIC IRQ 17. [ 73.776711] EATA/DMA 2.0x: Copyright (C) 1994-2003 Dario Ballabio. [ 73.802005] EATA config options -> tm:1, lc:y, mq:16, rs:y, et:n, ip:n, ep:n, pp:y. [ 73.829175] EATA0: 2.0C, PCI 0xd890, IRQ 17, BMST, SG 122, MB 64. [ 73.82] EATA0: wide SCSI support enabled, max_id 16, max_lun 8. [ 73.881125] EATA0: SCSI channel 0 enabled, host target ID 7. After a git bisect, I get: git bisect good 991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit commit 991de2e59090e55c65a7f59a049142e3c480f7bd Author: Jiang Liu Date: Wed Jun 10 16:54:59 2015 +0800 PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq() To support IOAPIC hotplug, we need to allocate PCI IRQ resources on demand and free them when not used anymore. Implement pcibios_alloc_irq() and pcibios_free_irq() to dynamically allocate and free PCI IRQs. Remove mp_should_keep_irq(), which is no longer used. [bhelgaas: changelog] Signed-off-by: Jiang Liu Signed-off-by: Bjorn Helgaas Acked-by: Thomas Gleixner :04 04 765e2d5232d53247ec260b34b51589c3bccb36ae f680234a27685e94b1a35ae2a7218f8eafa9071a M arch :04 04 d55a682bcde72682e883365e88ad1df6186fd54d f82c470a04a6845fcf5e0aa934512c75628f798d M drivers I'm happy to supply more details if needed. Hi Arthur, Thanks for reporting this. It seems to be an irq misrouting issue. Could you please help to provide: 1) full dmesg with the latest code 2) full dmesg and /proc/interrupts with the latest code and kernel parameter "irqpoll" specified Thanks! Gerry The pc locks up when loading the eata module so I've attached a photo of the monitor screen. Arthur. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0+ (root@victoria) (gcc version 5.2.1 20150903 (Debian 5.2.1-16) ) #29 SMP PREEMPT Mon Sep 7 07:10:45 ACST 2015 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x3ffa] usable [0.00] BIOS-e820: [mem 0x3ffb-0x3ffbdfff] ACPI data [0.00] BIOS-e820: [mem 0x3ffbe000-0x3ffd] ACPI NVS [0.00] BIOS-e820: [mem 0x3ffe-0x3fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xff78-0x] reserved [0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! [0.00] SMBIOS 2.3 present. [0.00] DMI: System manufacturer System Product Name/A8V-MX, BIOS 0503 12/06/2005 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x3ffb0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00 mask FFC000 write-back [0.00] 1 base 00D000 mask FFF000 write-combining [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [c00ff780] [0.00] initial memory mapped: [mem 0x-0
Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
Hello Sjoerd, On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > Enable Rockchip I2C, SPI, PWM, thermal drivers. > > Builtin are: > * I2C as it often controls the pmic. Having I2C as a module will cause more probe deferrals due missing regulators and slow down the boot but it should not cause issues. Or am I missing something? In fact, I think even the PMIC could be built as a module. But I don't have a strong opinion on this so patch looks good: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2,3/6] powerpc: kill mfvtb()
On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote: > This function is only used by get_vtb(). They are almost the same > except the reading from the real register. Move the mfspr() to > get_vtb() and kill the function mfvtb(). With this, we can eliminate > the use of cpu_has_feature() in very core header file like reg.h. > This is a preparation for the use of jump label for cpu_has_feature(). I don't mind this change. But can you elaborate a bit on the issue with using cpu_has_feature() in reg.h? Just so I can understand the problem. I assume you ended up in a big mess of includes when you tried to include jump_label.h from reg.h? cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver
Hello Sjoerd, On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > Active Semi act8846 is used as the PMIC on various Rockchip boards, > enable the ACT8865 driver to support this. > > Signed-off-by: Sjoerd Simons > --- > > arch/arm/configs/multi_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 25a1d574..7058fef 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -401,6 +401,7 @@ CONFIG_MFD_TPS65090=y > CONFIG_MFD_TPS6586X=y > CONFIG_MFD_TPS65910=y > CONFIG_REGULATOR_AB8500=y > +CONFIG_REGULATOR_ACT8865=y Same question than the previous patch, does this really need to be built-in? The Kconfig symbol is tristate. After an explanation why it needs to be built-in or enabling it as a module: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: futex atomic vs ordering constraints
On Sat, Sep 05, 2015 at 06:53:02PM +0100, Peter Zijlstra wrote: > On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote: > > So I think we could possibly relax the requirements (and document this > > very clearly) to say that the futex operation must be totally ordered > > wrt any other _user_space_ accesses by that thread. I suspect a lot of > > architectures can then say "we may be very weakly ordered, but kernel > > entry/exit implies enough synchronization that we do not need any > > futher memory barriers". > > Right, so before sending this email I actually spoke to Ralf about this > option, and he said that this is not actually well defined for MIPS. > > But we could certainly document it such and let archs for which this is > well documented (I would expect this to be most) choose that > implementation. Whilst a control-dependency + exception return forms a barrier of sorts on arm/arm64, it's not required to be transitive [1], so I wouldn't be comfortable making that relaxation on the futex path. Will [1] See, for example, "ISA2+dmb+ctrlisb+dmb" at https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html#ARM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] ARM: multi_v7_defconfig: Enable Rockchip display support
Hello Sjoerd, On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > Enable options needed for HDMI out on rockchip: DRM driver, Rockchip > DesignWare HDMI glue and the rockchip IOMMU (dependency of the DRM > driver). > > Signed-off-by: Sjoerd Simons > --- > > arch/arm/configs/multi_v7_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 7058fef..fb673e2 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -453,6 +453,8 @@ CONFIG_DRM_EXYNOS=m > CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_FIMD=y > CONFIG_DRM_EXYNOS_HDMI=y > +CONFIG_DRM_ROCKCHIP=m > +CONFIG_ROCKCHIP_DW_HDMI=m > CONFIG_DRM_RCAR_DU=m > CONFIG_DRM_TEGRA=y > CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m > @@ -630,6 +632,7 @@ CONFIG_APQ_MMCC_8084=y > CONFIG_MSM_GCC_8660=y > CONFIG_MSM_MMCC_8960=y > CONFIG_MSM_MMCC_8974=y > +CONFIG_ROCKCHIP_IOMMU=y > CONFIG_TEGRA_IOMMU_GART=y > CONFIG_TEGRA_IOMMU_SMMU=y > CONFIG_PM_DEVFREQ=y > Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver
Hi, I guess one could rename that to something like "ARM: multi_v7_defconfig: Enable regulators used on most rockchip boards" and as well add CONFIG_REGULATOR_FAN53555=y CONFIG_MFD_RK808=y CONFIG_REGULATOR_RK808=y fan5355 is the driver providing support for the syr82x used on all rk3288 boards with an act8846. Am Sonntag, 6. September 2015, 22:16:04 schrieb Sjoerd Simons: > Active Semi act8846 is used as the PMIC on various Rockchip boards, > enable the ACT8865 driver to support this. > > Signed-off-by: Sjoerd Simons > --- > > arch/arm/configs/multi_v7_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig index 25a1d574..7058fef 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -401,6 +401,7 @@ CONFIG_MFD_TPS65090=y > CONFIG_MFD_TPS6586X=y > CONFIG_MFD_TPS65910=y > CONFIG_REGULATOR_AB8500=y > +CONFIG_REGULATOR_ACT8865=y > CONFIG_REGULATOR_AS3711=y > CONFIG_REGULATOR_AS3722=y > CONFIG_REGULATOR_AXP20X=y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ARM: multi_v7_defconfig: Enable DW USB2 support and rockchip phy
Hello Sjoerd, On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > The DesignWare HS OTG USB 2.0 is used in various SoC families among wich > the various rockchip SoCs, enable the driver and the PHY glue for > rockchip > > Signed-off-by: Sjoerd Simons > > --- > > arch/arm/configs/multi_v7_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index fb673e2..49c733a 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -514,6 +514,7 @@ CONFIG_USB_STORAGE=y > CONFIG_USB_DWC3=y > CONFIG_USB_CHIPIDEA=y > CONFIG_USB_CHIPIDEA_HOST=y > +CONFIG_USB_DWC2=y > CONFIG_AB8500_USB=y > CONFIG_KEYSTONE_USB_PHY=y > CONFIG_OMAP_USB3=y > @@ -658,6 +659,7 @@ CONFIG_PHY_HIX5HD2_SATA=y > CONFIG_PWM_STI=m > CONFIG_OMAP_USB2=y > CONFIG_TI_PIPE3=y > +CONFIG_PHY_ROCKCHIP_USB=y > CONFIG_PHY_MIPHY28LP=y > CONFIG_PHY_MIPHY365X=y > CONFIG_PHY_RCAR_GEN2=m > After dropping the DWC2 and keeping only the PHY as suggested by Heiko and Krzysztof: Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RT Scheduler - BUG_ON (idx >= MAX_RT_PRIO)
On Mon, Sep 7, 2015 at 12:28 PM, Chinmay V S wrote: > Thanks for your quick response Mike. > >> Try without the proprietary modules. You may also want to audit futex >> fixes if you can't use a maintained stable tree. 3.2 has a bunch that >> 3.1 does not. > > I see that futex.c has 17 patches in 3.2.y that are missing in my tree. > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/kernel/futex.c?h=linux-3.2.y If in doubt please use the mainline kernel and try and reproduce. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RT Scheduler - BUG_ON (idx >= MAX_RT_PRIO)
On Mon, Sep 7, 2015 at 11:00 AM, Chinmay V S wrote: > Hello everyone, > > TL;DR: In Linux RT scheduler, how can rt_nr_running be non-zero AND > active-bitmap NOT have any valid bit set? > > Details: > Recently i encountered the following BUG() within the realtime > scheduler (sched_rt.c) on 3.1.10 kernel. > [101640.492840] kernel BUG at kernel/sched_rt.c:1126! > > This turns out to be > 1126 BUG_ON(idx >= MAX_RT_PRIO); The reason for the stack trace is given below. http://www.spinics.net/lists/newbies/msg08889.html -- -- Sujit K M blog(http://kmsujit.blogspot.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/9] usb: dwc3: add dual-role support
Peter,
On 06/09/15 05:02, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 05:24:16PM +0300, Roger Quadros wrote:
>> Register with the USB OTG core. Since we don't support
>> OTG yet we just work as a dual-role device even
>> if device tree says "otg".
>>
>> +
>> +static int dwc3_drd_init(struct dwc3 *dwc)
>> +{
>> +int ret, id, vbus;
>> +struct usb_otg_caps *otgcaps = &dwc->otg_config.otg_caps;
>> +
>> +otgcaps->otg_rev = 0;
>> +otgcaps->hnp_support = false;
>> +otgcaps->srp_support = false;
>> +otgcaps->adp_support = false;
>> +dwc->otg_config.fsm_ops = &dwc3_drd_ops;
>> +
>> +if (!dwc->edev) {
>> +dev_err(dwc->dev, "No extcon device found for OTG mode\n");
>> +return -ENODEV;
>> +}
>> +
>
> Do All dwc3 platforms id/vbus need to get through extcon? Do the
> SoCs have id/vbus pin?
>
>
Extcon access is in fact not needed from dwc3 driver and I will be getting
rid of this patch. We will support dual-role only via the OTG irq as in patch 5.
The way it works is that the OMAP glue layer dwc3-omap.c requests extcon device
and sets some mailbox register and this causes the VBUS/ID events to come over
OTG irq/status. So this patch is redundant.
The extcon device is not needed for all TI platforms. e.g. we need it for
DRA7 but not for AM437x.
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] xfs: updates for 4.3
Hi Linus,
Can you please pull the XFS updates from the tag below? There isn't
a whole lot to this update - it's mostly bug fixes and they are
spread pretty much all over XFS. There are some corruption fixes,
some fixes for log recovery, some fixes that prevent unount from
hanging, a lockdep annotation rework for inode locking to prevent
false positives and the usual random bunch of cleanups and minor
improvements.
There is a merge conflict with your current tree in
fs/xfs/xfs_aops.c. The merge diff in my tree is this:
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@@ -353,7 -356,8 +353,8 @@@ xfs_end_bio
{
xfs_ioend_t *ioend = bio->bi_private;
- ioend->io_error = bio->bi_error;
- if (!ioend->io_error && !test_bit(BIO_UPTODATE, &bio->bi_flags))
- ioend->io_error = error;
++ if (!ioend->io_error)
++ ioend->io_error = bio->bi_error;
/* Toss bio and pass work off to an xfsdatad thread */
bio->bi_private = NULL;
-Dave.
The following changes since commit bc0195aad0daa2ad5b0d76cce22b167bc3435590:
Linux 4.2-rc2 (2015-07-12 15:10:30 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git
tags/xfs-for-linus-4.3
for you to fetch changes up to 5d54b8cdeaf4679c51a510dea3f8921992d0b064:
Merge branch 'xfs-misc-fixes-for-4.3-4' into for-next (2015-09-01 10:30:11
+1000)
xfs: updates for 4.3-rc1
This update contains:
o large rework of EFI/EFD lifecycle handling to fix log recovery corruption
issues, crashes and unmount hangs
o separate metadata UUID on disk to enable changing boot label UUID for v5
filesystems
o fixes for gcc miscompilation on certain platforms and optimisation levels
o remote attribute allocation and recovery corruption fixes
o inode lockdep annotation rework to fix bugs with too many subclasses
o directory inode locking changes to prevent lockdep false positives
o a handful of minor corruption fixes
o various other small cleanups and bug fixes
Brian Foster (18):
xfs: close xc_cil list_empty() races with cil commit sequence
xfs: validate transaction header length on log recovery
xfs: disentagle EFI release from the extent count
xfs: return committed status from xfs_trans_roll()
xfs: fix efi/efd error handling to avoid fs shutdown hangs
xfs: ensure EFD trans aborts on log recovery extent free failure
xfs: use EFI refcount consistently in log recovery
xfs: don't leave EFIs on AIL on mount failure
xfs: icreate log item recovery and cancellation tracepoints
xfs: fix broken icreate log item cancellation
xfs: checksum log record ext headers based on record size
xfs: clean up root inode properly on mount failure
xfs: fix btree cursor error cleanups
xfs: add helper to conditionally remove items from the AIL
xfs: add missing bmap cancel calls in error paths
xfs: relocate sparse inode mount warning
xfs: swap leaf buffer into path struct atomically during path shift
xfs: flush entire file on dio read/write to cached file
Darrick J. Wong (2):
libxfs: readahead of dir3 data blocks should use the read verifier
libxfs: bad magic number should set da block buffer error
Dave Chinner (20):
xfs: call dax_fault on read page faults for DAX
xfs: remote attribute headers contain an invalid LSN
xfs: remote attributes need to be considered data
xfs: xfs_bunmapi() does not need XFS_BMAPI_METADATA flag
libxfs: add xfs_bit.c
Merge branch 'xfs-misc-fixes-for-4.3' into for-next
Merge branch 'xfs-meta-uuid' into for-next
Merge branch 'xfs-efi-rework' into for-next
xfs: fix sb_meta_uuid usage
xfs: growfs not aware of sb_meta_uuid
xfs: log recovery needs to validate against sb_meta_uuid
xfs: dquots should be stamped with sb_meta_uuid
xfs: clean up inode lockdep annotations
xfs: stop holding ILOCK over filldir callbacks
xfs: inode lockdep annotations broke non-lockdep build
Merge branch 'xfs-misc-fixes-for-4.3-2' into for-next
xfs: lockdep annotations throw warnings on non-debug builds
xfs: fix non-debug build warnings
Merge branch 'xfs-misc-fixes-for-4.3-3' into for-next
Merge branch 'xfs-misc-fixes-for-4.3-4' into for-next
David Jeffery (1):
xfs: return errors from partial I/O failures to files
Eric Sandeen (4):
xfs: create new metadata UUID field and incompat flag
xfs: set XFS_DA_OP_OKNOENT in xfs_attr_get
xfs: collapse allocsize and biosize mount option handling
xfs: fix error gotos in xfs_setattr_nonsize
Jan Kara (4):
xfs: Remove duplicate jumps to the same label
xfs: Fix xfs_attr_leafblock definition
xfs: Fix uninitialized return value in xfs_alloc_fix
Re: [PATCH v4 1/9] usb: dwc3: add dual-role support
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/09/15 12:06, Roger Quadros wrote:
> Felipe,
>
> On 03/09/15 18:44, Felipe Balbi wrote:
>> Hi,
>
>> On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote:
> + dwc->fsm->id = id;
> + dwc->fsm->b_sess_vld = vbus;
> + usb_otg_sync_inputs(dwc->fsm);
> +}
> +
> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
> +{
> + struct device *dev = usb_otg_fsm_to_dev(fsm);
> + struct dwc3 *dwc = dev_get_drvdata(dev);
how about adding a usb_otg_get_drvdata(fsm) ?
>>>
>>> You meant for otg core? That can be done.
>
>> yeah. BTW, I think otg core needs quite a few changes to become actually
>> useful. Currently it's just too much pointer ping-pong going back and
>> forth between phy, otg core, udc and hcd.
>
> Sure, any inputs for improvement appreciated.
>
>
>> Also, I caught a ton of issues with it and suspend/resume. You might
>> want to fix them before adding more users to it.
>
> OK.
>
>
>> It's also rather racy and that needs fixing too. On top of all that, I
>> think there's too much being added to UDC just to get Dual-Role, let's
>> see if we can improve that too.
>
> Would appreciate if you could give all your inputs on the otg core thread
> as early as you can :)
>
>
> @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev)
> hird_threshold = 12;
>
> if (node) {
> + if (of_property_read_bool(node, "extcon"))
> + dwc->edev = extcon_get_edev_by_phandle(dev, 0);
> + else if (of_property_read_bool(dev->parent->of_node, "extcon"))
> + dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0);
why do you need to check the parent ? Why isn't that done on the glue
layer ?
>>>
>>> On DRA7-evm, the extcon device is defined in the glue layer node. But
>>> we need the device both at the glue layer and at the core layer.
>
>> why do you need extcon here ? Glue updates core via UTMI about the
>> states, right ? So you should get proper VBUS and ID status via OTG IRQ.
>> Is that not working ?
>
> I didn't even expect that would work. Let me give that a try.
>
>
>>> We do get the extcon device in dwc3-omap.c
>>>
>>> Any suggestion how to pass the extcon device from glue layer to core.c?
>>> Or should I add the extcon property to dwc3 USB node as well in the DT?
>
>> GPIO toggles
>> dwc3-omap extcon event
>> update status via UTMI STATUS register
>> OTG IRQ on core
>> Horray!
>
>> :-)
>
> That's great. Thanks :)
This approach worked. Had to do the following change to the dwc3-omap glue
to make it work.
From: Roger Quadros
Date: Fri, 4 Sep 2015 15:13:59 +0300
Subject: [PATCH] usb: dwc3: omap: Pass VBUS and ID events transparently
Don't make any decisions regarding VBUS session based on ID
status. That is best left to the OTG core.
Pass ID and VBUS events independent of each other so that OTG
core knows exactly what to do.
This makes dual-role with extcon work with OTG irq on OMAP platforms.
Signed-off-by: Roger Quadros
- ---
drivers/usb/dwc3/dwc3-omap.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b18f2a3..751feee 100644
- --- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -233,19 +233,14 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
}
val = dwc3_omap_read_utmi_ctrl(omap);
- - val &= ~(USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_SESSEND);
- - val |= USBOTGSS_UTMI_OTG_CTRL_SESSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT;
+ val &= ~USBOTGSS_UTMI_OTG_CTRL_IDDIG;
dwc3_omap_write_utmi_ctrl(omap, val);
break;
case OMAP_DWC3_VBUS_VALID:
val = dwc3_omap_read_utmi_ctrl(omap);
val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND;
- - val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
+ val |= USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
| USBOTGSS_UTMI_OTG_CTRL_SESSVALID
| USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT;
dwc3_omap_write_utmi_ctrl(omap, val);
@@ -254,14 +249,16 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
case OMAP_DWC3_ID_FLOAT:
if (omap->vbus_reg)
regulator_disable(omap->vbus_reg);
+ val = dwc3_omap_read_utmi_ctrl(omap);
+ val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG;
+ dwc3_omap_write_utmi_ctrl(omap, val);
case OMAP_DWC3_VBUS_OFF:
val = dwc3_omap_read_utmi_ctrl(omap);
va
[PATCH] sched: fix lose fair sleeper bonus in switch_to_fair()
The sleeper task will be normalized when moved from fair_sched_class, in
order that vruntime will be adjusted either the task is running or sleeping
when moved back. The nomalization in switch_to_fair for sleep task will
result in lose fair sleeper bonus in place_entity() once the vruntime -
cfs_rq->min_vruntime is big when moved from fair_sched_class.
This patch fix it by adjusting vruntime just during migrating as original
codes since the vruntime of the task has usually NOT been normalized in
this case.
Signed-off-by: Wanpeng Li
---
kernel/sched/fair.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d26d3b7..eb9aa35 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -8005,9 +8005,6 @@ static void attach_task_cfs_rq(struct task_struct *p)
/* Synchronize task with its cfs_rq */
attach_entity_load_avg(cfs_rq, se);
-
- if (!vruntime_normalized(p))
- se->vruntime += cfs_rq->min_vruntime;
}
static void switched_from_fair(struct rq *rq, struct task_struct *p)
@@ -8066,14 +8063,20 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#ifdef CONFIG_FAIR_GROUP_SCHED
static void task_move_group_fair(struct task_struct *p)
{
+ struct sched_entity *se = &p->se;
+ struct cfs_rq *cfs_rq = cfs_rq_of(se);
+
detach_task_cfs_rq(p);
set_task_rq(p, task_cpu(p));
#ifdef CONFIG_SMP
/* Tell se's cfs_rq has been changed -- migrated */
- p->se.avg.last_update_time = 0;
+ se->avg.last_update_time = 0;
#endif
attach_task_cfs_rq(p);
+
+ if (!vruntime_normalized(p))
+ se->vruntime += cfs_rq->min_vruntime;
}
void free_fair_sched_group(struct task_group *tg)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 13/13] usb: otg: Add dual-role device (DRD) support
On 07/09/15 10:53, Li Jun wrote:
> On Mon, Aug 24, 2015 at 04:21:24PM +0300, Roger Quadros wrote:
>> DRD mode is a reduced functionality OTG mode. In this mode
>> we don't support SRP, HNP and dynamic role-swap.
>>
>> In DRD operation, the controller mode (Host or Peripheral)
>> is decided based on the ID pin status. Once a cable plug (Type-A
>> or Type-B) is attached the controller selects the state
>> and doesn't change till the cable in unplugged and a different
>> cable type is inserted.
>>
>> As we don't need most of the complex OTG states and OTG timers
>> we implement a lean DRD state machine in usb-otg.c.
>> The DRD state machine is only interested in 2 hardware inputs
>> 'id' and 'b_sess_vld'.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> drivers/usb/common/usb-otg.c | 178
>> +--
>> include/linux/usb/otg-fsm.h | 5 ++
>> include/linux/usb/otg.h | 2 +
>> 3 files changed, 177 insertions(+), 8 deletions(-)
>>
>
> ... ...
>
>> +/* Called when entering a DRD state */
>> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state new_state)
>> +{
>> +struct usb_otg *otgd = container_of(fsm, struct usb_otg, fsm);
>> +
>> +if (fsm->otg->state == new_state)
>> +return;
>> +
>> +fsm->state_changed = 1;
>> +dev_dbg(otgd->dev, "otg: set state: %s\n",
>> +usb_otg_state_string(new_state));
>> +switch (new_state) {
>> +case OTG_STATE_B_IDLE:
>> +drd_set_protocol(fsm, PROTO_UNDEF);
>
> You didn't address this comment for your previous version.
>
> otg_drv_vbus(fsm, 0);
>
>> +break;
>> +case OTG_STATE_B_PERIPHERAL:
>> +drd_set_protocol(fsm, PROTO_GADGET);
>
> otg_drv_vbus(fsm, 0);
>
>> +break;
>> +case OTG_STATE_A_HOST:
>
> otg_drv_vbus(fsm, 1);
>
Sorry, I missed it. Will add in next version.
--
cheers,
-roger
>> +drd_set_protocol(fsm, PROTO_HOST);
>> +break;
>> +case OTG_STATE_UNDEFINED:
>> +case OTG_STATE_B_SRP_INIT:
>> +case OTG_STATE_B_WAIT_ACON:
>> +case OTG_STATE_B_HOST:
>> +case OTG_STATE_A_IDLE:
>> +case OTG_STATE_A_WAIT_VRISE:
>> +case OTG_STATE_A_WAIT_BCON:
>> +case OTG_STATE_A_SUSPEND:
>> +case OTG_STATE_A_PERIPHERAL:
>> +case OTG_STATE_A_WAIT_VFALL:
>> +case OTG_STATE_A_VBUS_ERR:
>> +default:
>> +dev_warn(otgd->dev, "%s: otg: invalid state: %s\n",
>> + __func__, usb_otg_state_string(new_state));
>> +break;
>> +}
>> +
>> +fsm->otg->state = new_state;
>> +}
>> +
> ... ...
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
On 07/09/15 07:46, Naoya Horiguchi wrote:
> On Mon, Sep 07, 2015 at 02:23:44AM +, Horiguchi Naoya(堀口 直也) wrote:
>> On Mon, Sep 07, 2015 at 02:29:53AM +0100, Pádraig Brady wrote:
>>> On 20/08/15 09:26, Naoya Horiguchi wrote:
Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
is inconvenient when we want to know per-task or per-vma base hugetlb
usage.
To solve this, this patch adds a new line for hugetlb usage like below:
Size: 20480 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced:0 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
HugetlbPages: 18432 kB
Swap: 0 kB
KernelPageSize: 2048 kB
MMUPageSize:2048 kB
Locked:0 kB
VmFlags: rd wr mr mw me de ht
Signed-off-by: Naoya Horiguchi
Acked-by: Joern Engel
Acked-by: David Rientjes
---
v3 -> v4:
- suspend Acked-by tag because v3->v4 change is not trivial
- I stated in previous discussion that HugetlbPages line can contain page
size info, but that's not necessary because we already have
KernelPageSize
info.
- merged documentation update, where the current documentation doesn't
mention
AnonHugePages, so it's also added.
---
Documentation/filesystems/proc.txt | 7 +--
fs/proc/task_mmu.c | 29 +
2 files changed, 34 insertions(+), 2 deletions(-)
diff --git v4.2-rc4/Documentation/filesystems/proc.txt
v4.2-rc4_patched/Documentation/filesystems/proc.txt
index 6f7fafde0884..22e40211ef64 100644
--- v4.2-rc4/Documentation/filesystems/proc.txt
+++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
@@ -423,6 +423,8 @@ Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 892 kB
Anonymous: 0 kB
+AnonHugePages: 0 kB
+HugetlbPages: 0 kB
Swap: 0 kB
KernelPageSize:4 kB
MMUPageSize: 4 kB
@@ -440,8 +442,9 @@ indicates the amount of memory currently marked as
referenced or accessed.
"Anonymous" shows the amount of memory that does not belong to any file.
Even
a mapping associated with a file may contain anonymous pages: when
MAP_PRIVATE
and a page is modified, the file page is replaced by a private anonymous
copy.
-"Swap" shows how much would-be-anonymous memory is also used, but out on
-swap.
+"AnonHugePages" shows the ammount of memory backed by transparent
hugepage.
+"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
+"Swap" shows how much would-be-anonymous memory is also used, but out on
swap.
>>>
>>> There is no distinction between "private" and "shared" in this "huge page"
>>> accounting right?
>>
>> Right for current version. And I think that private/shared distinction
>> gives some help.
>>
>>> Would it be possible to account for the huge pages in the
>>> {Private,Shared}_{Clean,Dirty} fields?
>>> Or otherwise split the huge page accounting into shared/private?
>
> Sorry, I didn't catch you properly.
> I think that accounting for hugetlb pages should be done only with
> HugetlbPages
> or any other new field for hugetlb, in order not to break the behavior of
> existing
> fields.
On a more general note I'd be inclined to just account
for hugetlb pages in Rss and {Private,Shared}_Dirty
and fix any tools that double count.
> So splitting HugetlbPages into shared/private looks good to me.
Yes this is the most compatible solution,
and will allow one to accurately determine
how much core mem a process is using.
thanks!
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 04/13] otg-fsm: move usb_bus_start_enum into otg-fsm->ops
On 07/09/15 04:24, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:15PM +0300, Roger Quadros wrote:
>> This is to prevent missing symbol build error if OTG is
>> enabled (built-in) and HCD core (CONFIG_USB) is module.
>>
>> Signed-off-by: Roger Quadros
>> Acked-by: Peter Chen
>> ---
>> drivers/usb/common/usb-otg-fsm.c | 6 --
>> drivers/usb/phy/phy-fsl-usb.c| 2 ++
>> include/linux/usb/otg-fsm.h | 1 +
>> 3 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/common/usb-otg-fsm.c
>> b/drivers/usb/common/usb-otg-fsm.c
>> index a46f29a..6e56c8c 100644
>> --- a/drivers/usb/common/usb-otg-fsm.c
>> +++ b/drivers/usb/common/usb-otg-fsm.c
>> @@ -165,8 +165,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum
>> usb_otg_state new_state)
>> otg_loc_conn(fsm, 0);
>> otg_loc_sof(fsm, 1);
>> otg_set_protocol(fsm, PROTO_HOST);
>> -usb_bus_start_enum(fsm->otg->host,
>> -fsm->otg->host->otg_port);usb_bus_start_enum
>> +if (fsm->ops->start_enum) {
>> +fsm->ops->start_enum(fsm->otg->host,
>> + fsm->otg->host->otg_port);
>> +}
>> break;
>> case OTG_STATE_A_IDLE:
>> otg_drv_vbus(fsm, 0);
>> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
>> index ee3f2c2..19541ed 100644
>> --- a/drivers/usb/phy/phy-fsl-usb.c
>> +++ b/drivers/usb/phy/phy-fsl-usb.c
>> @@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
>>
>> .start_host = fsl_otg_start_host,
>> .start_gadget = fsl_otg_start_gadget,
>> +
>> +.start_enum = usb_bus_start_enum,
>> };
>>
>> /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
>> diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
>> index 672551c..75e82cc 100644
>> --- a/include/linux/usb/otg-fsm.h
>> +++ b/include/linux/usb/otg-fsm.h
>> @@ -199,6 +199,7 @@ struct otg_fsm_ops {
>> void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
>> int (*start_host)(struct otg_fsm *fsm, int on);
>> int (*start_gadget)(struct otg_fsm *fsm, int on);
>> +int (*start_enum)(struct usb_bus *bus, unsigned port_num);
>> };
>>
>>
>
> Get one build warning:
>
> In file included from
> /u/home/b29397/work/projects/usb/drivers/usb/chipidea/udc.c:23:0:
> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning:
> 'struct usb_bus' declared inside parameter list
> int (*start_enum)(struct usb_bus *bus, unsigned port_num);
> ^
> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: warning:
> its scope is only this definition or declaration, which is probably not what
> you want
>
> It probably dues to we should not have struct usb_bus* at udc driver
>
How about changing it to struct otg_fsm instead like the other APIs?
And do we leave usb_bus_start_enum() as it is?
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
On 31.08.2015 13:01, Tomasz Nowicki wrote: On 08.06.2015 17:14, Lorenzo Pieralisi wrote: On Mon, Jun 08, 2015 at 03:57:38AM +0100, Hanjun Guo wrote: [...] Why can't we make use of the ECAM implementation used by pci-host-generic and drivers/pci/access.c? We had that question when I had posted MMCFG patch set separately, please see: https://lkml.org/lkml/2015/3/11/492 Yes, but the real question is, why do we need to have PCI config space up and running before a bus struct is even created ? I think the reason is the PCI configuration address space format (ACPI 6.0, Table 5-27, page 108): "PCI Configuration space addresses must be confined to devices on PCI Segment Group 0, bus 0. This restriction exists to accommodate access to fixed hardware prior to PCI bus enumeration". On HW reduced platforms I do not even think this is required at all, we have to look into this to avoid code duplication that might well turn out useless. This is only for the fixed hardware, which will be not available for ARM64 (reduced hardware mode), but in Generic Hardware Programming Model, we using OEM-provided ACPI Machine Language (AML) code to access generic hardware registers, this will be available for reduced hardware too. So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph) ACPI defines eight address spaces that may be accessed by generic hardware implementations. These include: * System I/O space * System memory space * PCI configuration space * Embedded controller space * System Management Bus (SMBus) space * CMOS * PCI BAR Target * IPMI space So if any device using the PCI address space for control, such as a system reset control device, its address space can be reside in PCI configuration space (who can prevent a OEM do that crazy thing? :) ), and it should be accessible before the PCI bus is created. Us, by changing attitude and questioning features whose usefulness is questionable. I will look into this and raise the point, I am not thrilled by the idea of adding another set of PCI accessor functions and drivers because we have to access a register through PCI before enumerating the bus (and on arm64 this is totally useless since we are not meant to support fixed HW anyway). Maybe we can make acpica code use a "special" stub (ACPI specific, PCI configuration space address space has restrictions anyway), I have to review this set in its entirety to see how to do that (and I would kindly ask you to do it too, before saying it is not possible to implement it). I'm willing to do that, actually, if we don't need a mechanism to access PCI config space before the bus is created, the code can be simplified a lot. After more investigation on the spec and the ACPI core code, I'm still not convinced that accessing to PCI config space before PCI bus creating is impossible, also there is no enough ARM64 hardware to prove that too. But I think we can go in this way, reuse the ECAM implementation by pci-host-generic for now, and implement the PCI accessor functions before enumerating PCI bus when needed in the future, does it make sense? You mean we rewrite the patch to make sure we can use the PCI host generic driver with MCFG and we leave the acpica PCI config call empty stubs on arm64 (as they are now) ? Hi Bjorn, Rafael, Lorenzo pointed out very important problem we are having with PCI config space access for ARM64. Please refer to the above discussion and add your 2 cents. Can we forget about accessing PCI config space (for Hardware Reduced profile) before PCI bus creation? If not, do you see a way to use drivers/pci/access.c accessors here, like acpica change? Any opinion is very appreciated. Kindly remainder. Thanks, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ARM: ls1021a: add platform notifier for dma-coherent requirement
Hi, Shawn,
> On Fri, Aug 07, 2015 at 06:01:59PM +0800, Alison Wang wrote:
> > This patch adds platform notifier for dma-coherent requirement.
> > Structure arm_coherent_dma_ops is used instead of arm_dma_ops.
> >
> > Signed-off-by: Alison Wang
> > ---
> > arch/arm/mach-imx/mach-ls1021a.c | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/arch/arm/mach-imx/mach-ls1021a.c
> > b/arch/arm/mach-imx/mach-ls1021a.c
> > index b89c858..6bfc71b 100644
> > --- a/arch/arm/mach-imx/mach-ls1021a.c
> > +++ b/arch/arm/mach-imx/mach-ls1021a.c
> > @@ -7,10 +7,39 @@
> > * (at your option) any later version.
> > */
> >
> > +#include
> > +#include
> > #include
> >
> > #include "common.h"
> >
> > +static int ls1021a_platform_notifier(struct notifier_block *nb,
> > + unsigned long event, void *__dev) {
> > + struct device *dev = __dev;
> > +
> > + if (event != BUS_NOTIFY_ADD_DEVICE)
> > + return NOTIFY_DONE;
> > +
> > + if (of_device_is_compatible(dev->of_node, "fsl,etsec2"))
> > + set_dma_ops(dev, &arm_coherent_dma_ops);
>
> Why cannot you simply add property dma-coherent for etsec2 node in
> device tree? In that case, of_dma_configure() will just do the job
> from of_platform_device_create_pdata().
[Alison Wang] Yes, you are right. I will change in v2. Thanks.
>
> Shawn
>
> > + else if (of_property_read_bool(dev->of_node, "dma-coherent"))
> > + set_dma_ops(dev, &arm_coherent_dma_ops);
> > +
> > + return NOTIFY_OK;
> > +}
> > +
> > +static struct notifier_block ls1021a_platform_nb = {
> > + .notifier_call = ls1021a_platform_notifier, };
> > +
> > +static void __init ls1021a_init_machine(void) {
> > + bus_register_notifier(&platform_bus_type, &ls1021a_platform_nb);
> > +
> > + of_platform_populate(NULL, of_default_bus_match_table, NULL,
> NULL);
> > +}
> > +
> > static const char * const ls1021a_dt_compat[] __initconst = {
> > "fsl,ls1021a",
> > NULL,
> > @@ -18,5 +47,6 @@ static const char * const ls1021a_dt_compat[]
> > __initconst = {
> >
> > DT_MACHINE_START(LS1021A, "Freescale LS1021A")
> > .smp= smp_ops(ls1021a_smp_ops),
> > + .init_machine = ls1021a_init_machine,
> > .dt_compat = ls1021a_dt_compat,
> > MACHINE_END
> > --
> > 2.1.0.27.g96db324
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT pull] irq updates for 4.3
Linus,
please pull the latest irq-core-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus
The second part of irq related updates:
- Provide EOImode for GIC[V3] irq chips, which is a prerequisite for
direct interrupt handling in [KVM] guests.
Thanks,
tglx
-->
Marc Zyngier (5):
irqchip/GICv3: Convert to EOImode == 1
irqchip/GICv3: Don't deactivate interrupts forwarded to a guest
irqchip/GIC: Convert to EOImode == 1
irqchip/GIC: Don't deactivate interrupts forwarded to a guest
irqchip/GIC: Fix EOImode setting for non-DT/ACPI systems
drivers/irqchip/irq-gic-v3.c | 91 +--
drivers/irqchip/irq-gic.c | 145 +++--
include/linux/irqchip/arm-gic-v3.h | 9 +++
include/linux/irqchip/arm-gic.h| 4 +
4 files changed, 237 insertions(+), 12 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index e406bc5f13e4..7deed6ef54c2 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "irq-gic-common.h"
@@ -50,6 +51,7 @@ struct gic_chip_data {
};
static struct gic_chip_data gic_data __read_mostly;
+static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
#define gic_data_rdist() (this_cpu_ptr(gic_data.rdists.rdist))
#define gic_data_rdist_rd_base() (gic_data_rdist()->rd_base)
@@ -68,6 +70,11 @@ static inline int gic_irq_in_rdist(struct irq_data *d)
return gic_irq(d) < 32;
}
+static inline bool forwarded_irq(struct irq_data *d)
+{
+ return d->handler_data != NULL;
+}
+
static inline void __iomem *gic_dist_base(struct irq_data *d)
{
if (gic_irq_in_rdist(d))/* SGI+PPI -> SGI_base for this CPU */
@@ -231,6 +238,21 @@ static void gic_mask_irq(struct irq_data *d)
gic_poke_irq(d, GICD_ICENABLER);
}
+static void gic_eoimode1_mask_irq(struct irq_data *d)
+{
+ gic_mask_irq(d);
+ /*
+* When masking a forwarded interrupt, make sure it is
+* deactivated as well.
+*
+* This ensures that an interrupt that is getting
+* disabled/masked will not get "stuck", because there is
+* noone to deactivate it (guest is being terminated).
+*/
+ if (forwarded_irq(d))
+ gic_poke_irq(d, GICD_ICACTIVER);
+}
+
static void gic_unmask_irq(struct irq_data *d)
{
gic_poke_irq(d, GICD_ISENABLER);
@@ -296,6 +318,17 @@ static void gic_eoi_irq(struct irq_data *d)
gic_write_eoir(gic_irq(d));
}
+static void gic_eoimode1_eoi_irq(struct irq_data *d)
+{
+ /*
+* No need to deactivate an LPI, or an interrupt that
+* is is getting forwarded to a vcpu.
+*/
+ if (gic_irq(d) >= 8192 || forwarded_irq(d))
+ return;
+ gic_write_dir(gic_irq(d));
+}
+
static int gic_set_type(struct irq_data *d, unsigned int type)
{
unsigned int irq = gic_irq(d);
@@ -322,6 +355,12 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
return gic_configure_irq(irq, type, base, rwp_wait);
}
+static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
+{
+ d->handler_data = vcpu;
+ return 0;
+}
+
static u64 gic_mpidr_to_affinity(u64 mpidr)
{
u64 aff;
@@ -343,15 +382,26 @@ static asmlinkage void __exception_irq_entry
gic_handle_irq(struct pt_regs *regs
if (likely(irqnr > 15 && irqnr < 1020) || irqnr >= 8192) {
int err;
+
+ if (static_key_true(&supports_deactivate))
+ gic_write_eoir(irqnr);
+
err = handle_domain_irq(gic_data.domain, irqnr, regs);
if (err) {
WARN_ONCE(true, "Unexpected interrupt
received!\n");
- gic_write_eoir(irqnr);
+ if (static_key_true(&supports_deactivate)) {
+ if (irqnr < 8192)
+ gic_write_dir(irqnr);
+ } else {
+ gic_write_eoir(irqnr);
+ }
}
continue;
}
if (irqnr < 16) {
gic_write_eoir(irqnr);
+ if (static_key_true(&supports_deactivate))
+ gic_write_dir(irqnr);
#ifdef CONFIG_SMP
handle_IPI(irqnr, regs);
#else
@@ -451,8 +501,13 @@ static void gic_cpu_sys_reg_init(void)
/* Set priority mask register */
gic_write_pmr(DEFAULT_PMR_VALUE);
- /* EOI deactivates interrupt too (mode 0) */
- gic_write_ctlr(ICC_CTLR_EL1_EOImode_drop_dir);
+
Re: [RFC][PATCH RT 0/3] RT: Fix trylock deadlock without msleep() hack
On Mon, 7 Sep 2015, Thomas Gleixner wrote: > 1) The boosting is not related to anything. > >If the priority of taskB changes then nothing changes the boosting >of taskA. > > 2) The boosting stops Scratch that #2. Hit send too fast. #1 and #3 still hold. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/1] Revert "spi/doc: spi_master_put must be followed up by kfree"
On Sun, Sep 06, 2015 at 03:22:43AM +0300, Alexey Klimov wrote: > Sorry. Right now I see how I screwed up. Should I re-send it as single > patch with all info included (marking as RESEND)? No, it's OK - the patch itself was clear enough and I already applied it. signature.asc Description: Digital signature
[GIT PULL] MMC for v.4.3
Hi Linus, Here are the PR for MMC for v4.3. Details about the MMC highlights are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit 2c6625cd545bdd66acff14f3394865d43920a5c7: Linux 4.2-rc7 (2015-08-16 16:34:13 -0700) are available in the git repository at: git://git.linaro.org/people/ulf.hansson/mmc.git tags/mmc-v4.3 for you to fetch changes up to 092b6dbe8a4a24c17f2ebfe86995dc994e61f420: mmc: android-goldfish: remove incorrect __iomem annotation (2015-09-01 14:19:11 +0200) MMC core: - Fix a race condition in the request handling - Skip trim commands for some buggy kingston eMMCs - An optimization and a correction for erase groups - Set CMD23 quirk for some Sandisk cards MMC host: - sdhci: Give GPIO CD higher precedence and don't poll when it's used - sdhci: Fix DMA memory leakage - sdhci: Some updates for clock management - sdhci-of-at91: introduce driver for the Atmel SDMMC - sdhci-of-arasan: Add support for sdhci-5.1 - sdhci-esdhc-imx: Add support for imx7d which also supports HS400 - sdhci: A collection of fixes and improvements for various sdhci hosts - omap_hsmmc: Modernization of the regulator code - dw_mmc: A couple of fixes for DMA and PIO mode - usdhi6rol0: A few fixes and support probe deferral for regulators - pxamci: Convert to use dmaengine - sh_mmcif: Fix the suspend process in a short term solution - tmio: Adjust timeout for commands - sunxi: Fix timeout while gating/ungating clock Adam Lee (1): mmc: sdhci-pci: set the clear transfer mode register quirk for O2Micro Addy Ke (1): mmc: dw_mmc: add quirk for broken data transfer over scheme Alexandre Belloni (1): mmc: atmel-mci: remove useless include Alexey Brodkin (1): mmc: dw_mmc: handle data blocks > than 4kB if IDMAC is used Andreas Fenkart (3): Documentation: dt: update ti,am33xx-hsmmc swakeup workaround mmc: omap_hsmmc: call omap_hsmmc_set_power directly mmc: omap_hsmmc: regulator automatically released by devm Andy Shevchenko (1): mmc: block: don't use parameter prefix if built as module Barry Song (1): mmc: sdhci-sirf: corrent quirk according to real chips Christoph Hellwig (1): mmc: android-goldfish: remove incorrect __iomem annotation Daniel Mack (1): mmc: pxamci: switch over to dmaengine use David Jander (1): mmc: core: Optimize case for exactly one erase-group budget Fabian Frederick (1): mmc: omap: use for_each_sg() for scatterlist parsing Haibo Chen (6): mmc: sdhci: fix dma memory leak in sdhci_pre_req() mmc: sdhci-esdhc-imx: Document new DT bindings for imx7d support mmc: sdhci-esdhc-imx: add imx7d support and support HS400 mmc: sdhci-esdhc-imx: add tuning-step setting support mmc: sdhci-esdhc-imx: set back the burst_length_enable bit to 1 mmc: sdhci-esdhc-imx: change default watermark level and burst length Heiko Stuebner (1): mmc: dw_mmc: fix pio mode when internal dmac is enabled Ivan T. Ivanov (4): mmc: sdhci-msm: Boost controller core clock mmc: sdhci: let GPIO based card detection have higher precedence mmc: sdhci: don't use card state polling when CD GPIO is defined mmc: sdhci: properly check card present state when quirk NO_CARD_NO_RESET is set Jaehoon Chung (3): mmc: dw_mmc: fix the wrong condition checking mmc: dw_mmc: remove the unused blk_setting mmc: dw_mmc: print the message for deprecated property Jialing Fu (1): mmc: core: fix race condition in mmc_wait_data_done Jisheng Zhang (1): mmc: sdhci: also get preset value and driver type for MMC_DDR52 Julia Lawall (2): mmc: omap: fix error return code mmc: usdhi6rol0: fix error return code Kishon Vijay Abraham I (15): mmc: host: omap_hsmmc: use devm_regulator_get_optional() for vmmc mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get mmc: host: omap_hsmmc: cleanup omap_hsmmc_reg_get() mmc: host: omap_hsmmc: use the ocrmask provided by the vmmc regulator mmc: host: omap_hsmmc: use mmc_host's vmmc and vqmmc mmc: host: omap_hsmmc: remove unnecessary pbias set_voltage mmc: host: omap_hsmmc: return error if any of the regulator APIs fail mmc: host: omap_hsmmc: add separate functions for enable/disable supply mmc: host: omap_hsmmc: add separate function to set pbias mmc: host: omap_hsmmc: avoid pbias regulator enable on power off mmc: host: omap_hsmmc: don't use ->set_power to set initial regulator state mmc: host: omap_hsmmc: enable/disable vmmc_aux regulator based on previous state mmc: host: omap_hsmmc: use regulator_is_enabled to find pbias status mmc: host: omap_hsmmc: use ios->vdd for setting vmmc voltage mmc: host: omap_hsmmc: remove CON
Re: Dealing with the NMI mess
On 07/09/2015 10:19, Maciej W. Rozycki wrote: >> > Essentially the ICE breakpoint instruction enters SMM mode? > I didn't do stuff at the probe firmware level so I can't say for sure, > but my gut feeling is the debug mode is indeed very close if not the same > as SMM. I think duplicating the logic would be an unnecessary waste of > silicon. I researched SMM a bit recently in order to implement it in KVM, and the best source of folklore seems to be http://www.rcollins.org/ddj (which I also have on paper :)). The author there says that SMM design was roughly based on the 386's probe/ICE mode design, but it's actually separate. Most notably, on the 386 the state save areas almost mirror each other, but when I say mirror... I do mean mirror: directions are reversed, and what is on top for probe mode is on bottom for SMM. :) In addition, AMD tried reusing ICE mode for SMM, and was sued by Intel who actually won the lawsuit. I couldn't find more information about the lawsuit. It's probably diverged more and more over time, for example because SMM is now considered security-sensitive while probe mode isn't. In addition, the same DDJ article says that Pentium JTAG probe mode "doesn't resemble SMM at all, doesn't use a state save map, or even execute any code of its own", whatever that means. Paolo > And obviously it's any cause of #DB that enters this mode. The probe can > also request it right at the exit from the reset state, so that you can > debug software (e.g BIOS startup) right from the reset vector. You don't > need working RAM for that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 07/13] usb: otg: add OTG core
On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
>
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg device
> in your patch), like chipidea and dwc2.
>
> Then, otg_dev will be glue layer device for chipidea after that.
OK. Let's add a way for the otg controller driver to provide the host and gadget
information to the otg core for such devices like chipidea and dwc2.
This API must be called before the hcd/gadget-driver is added so that the otg
core knows it's linked to an OTG controller.
Any better idea?
cheers,
-roger
>
> Peter
>
>> +if (!otg_dev)
>> +return -EINVAL; /* we're definitely not OTG */
>> +
>> +/* we're otg but otg controller might not yet be registered */
>> +mutex_lock(&otg_list_mutex);
>> +otgd = usb_otg_get_data(otg_dev);
>> +mutex_unlock(&otg_list_mutex);
>> +if (!otgd) {
>> +dev_dbg(hcd_dev,
>> +"otg: controller not yet registered. waiting..\n");
>> +/*
>> + * otg controller might register later. Put the hcd in
>> + * wait list and call us back when ready
>> + */
>> +if (usb_otg_hcd_wait_add(otg_dev, hcd, irqnum, irqflags, ops)) {
>> +dev_dbg(hcd_dev, "otg: failed to add to wait list\n");
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/* HCD will be started by OTG fsm when needed */
>> +mutex_lock(&otgd->fsm.lock);
>> +if (otgd->primary_hcd.hcd) {
>> +/* probably a shared HCD ? */
>> +if (usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host already
>> registered\n");
>> +goto err;
>> +}
>> +
>> +if (hcd->shared_hcd == otgd->primary_hcd.hcd) {
>> +if (otgd->shared_hcd.hcd) {
>> +dev_err(otg_dev, "otg: shared host already
>> registered\n");
>> +goto err;
>> +}
>> +
>> +otgd->shared_hcd.hcd = hcd;
>> +otgd->shared_hcd.irqnum = irqnum;
>> +otgd->shared_hcd.irqflags = irqflags;
>> +otgd->shared_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: shared host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +} else {
>> +dev_err(otg_dev, "otg: invalid shared host %s\n",
>> +dev_name(hcd->self.controller));
>> +goto err;
>> +}
>> +} else {
>> +if (!usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host must be registered
>> first\n");
>> +goto err;
>> +}
>> +
>> +otgd->primary_hcd.hcd = hcd;
>> +otgd->primary_hcd.irqnum = irqnum;
>> +otgd->primary_hcd.irqflags = irqflags;
>> +otgd->primary_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: primary host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +}
>> +
>> +/*
>> + * we're ready only if we have shared HCD
>> + * or we don't need shared HCD.
>> + */
>> +if (otgd->shared_hcd.hcd || !otgd->primary_hcd.hcd->shared_hcd) {
>> +otgd->fsm.otg->host = hcd_to_bus(hcd);
>> +/* FIXME: set bus->otg_port if this is true OTG port with HNP */
>> +
>> +/* start FSM */
>> +usb_otg_start_fsm(&otgd->fsm);
>> +} else {
>> +dev_dbg(otg_dev, "otg: can't start till shared host
>> registers\n");
>> +}
>> +
>> +mutex_unlock(&otgd->fsm.lock);
>> +
>> +return 0;
>> +
>> +err:
>> +mutex_unlock(&otgd->fsm.lock);
>> +return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_otg_register_hcd);
>> +
>> +/**
>> + * usb_otg_unregister_hcd - Unregister Host controller from OTG core
>> + * @hcd:Host controller device
>> + *
>> + * This is used by the USB Host stack to unregister the Host controller
>> + * from the OTG core. Ensures that Host controller is not running
>> + * on succ
Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
On Mon, 2015-09-07 at 11:26 +0200, Javier Martinez Canillas wrote: > Hello Sjoerd, > > On 09/06/2015 10:16 PM, Sjoerd Simons wrote: > > Enable Rockchip I2C, SPI, PWM, thermal drivers. > > > > Builtin are: > > * I2C as it often controls the pmic. > > Having I2C as a module will cause more probe deferrals due missing > regulators and slow down the boot but it should not cause issues. > Or am I missing something? > > In fact, I think even the PMIC could be built as a module. It could in principle. However as a lot of other drivers do need the regulators provided by the pmic, they'll be deferred until that driver is loaded. So e.g. with the i2c/pmic drivers as a module you cannot boot to an NFS rootfs without using an initramfs. > But I don't have a strong opinion on this so patch looks good: > > Reviewed-by: Javier Martinez Canillas > > Best regards, -- Sjoerd Simons Collabora Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH 1/2] i2c: added FUNC flag for unsupported clock stretching
Added I2C_FUNC_NO_CLK_STRETCH, to be used when clock stretching is not
supported.
Signed-off-by: Nicola Corna
---
Documentation/i2c/functionality | 1 +
include/uapi/linux/i2c.h| 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality
index 4aae8ed..f53807e 100644
--- a/Documentation/i2c/functionality
+++ b/Documentation/i2c/functionality
@@ -21,6 +21,7 @@ For the most up-to-date list of functionality constants,
please check
I2C_M_REV_DIR_ADDR and I2C_M_NO_RD_ACK
flags (which modify the I2C protocol!)
I2C_FUNC_NOSTARTCan skip repeated start sequence
+ I2C_FUNC_NO_CLK_STRETCH Does NOT support clock stretching
I2C_FUNC_SMBUS_QUICKHandles the SMBus write_quick command
I2C_FUNC_SMBUS_READ_BYTEHandles the SMBus read_byte command
I2C_FUNC_SMBUS_WRITE_BYTE Handles the SMBus write_byte command
diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index b0a7dd6..59e4b43 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -88,6 +88,7 @@ struct i2c_msg {
#define I2C_FUNC_SMBUS_PEC 0x0008
#define I2C_FUNC_NOSTART 0x0010 /* I2C_M_NOSTART */
#define I2C_FUNC_SLAVE 0x0020
+#define I2C_FUNC_NO_CLK_STRETCH0x0040 /* No check for SCL
low */
#define I2C_FUNC_SMBUS_BLOCK_PROC_CALL 0x8000 /* SMBus 2.0 */
#define I2C_FUNC_SMBUS_QUICK 0x0001
#define I2C_FUNC_SMBUS_READ_BYTE 0x0002
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] selftests: rename jump label to static_keys
On Thu, 2015-08-27 at 16:17 -0600, Shuah Khan wrote: > On 08/14/2015 07:43 AM, Bamvor Jian Zhang wrote: > > commit "2bf9e0a locking/static_keys: Provide a selftest" rename > > jump_label directory to static_keys. > > > > Signed-off-by: Bamvor Jian Zhang > > --- > > tools/testing/selftests/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > I will get this into 4.3-rc2, once the jump_label patch gets > into 4.3-rc1 > > thanks for the fix. Hi Shuah, Currently the selftests don't build in Linus' tree due to this breakage. Can you please pull this fix and send it to Linus? thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] zram: fix possible use after free in zcomp_create()
zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
through comp->stream, which can potentially be pointing to memory that was
freed if these functions returned an error.
Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
Cc: sta...@vger.kernel.org
Signed-off-by: Luis Henriques
---
drivers/block/zram/zcomp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 965d1afb0eaa..f3db8158e172 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -212,6 +212,7 @@ static int zcomp_strm_multi_create(struct zcomp *comp, int
max_strm)
zstrm = zcomp_strm_alloc(comp);
if (!zstrm) {
kfree(zs);
+ comp->stream = NULL;
return -ENOMEM;
}
list_add(&zstrm->list, &zs->idle_strm);
@@ -262,6 +263,7 @@ static int zcomp_strm_single_create(struct zcomp *comp)
zs->zstrm = zcomp_strm_alloc(comp);
if (!zs->zstrm) {
kfree(zs);
+ comp->stream = NULL;
return -ENOMEM;
}
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/3] kvm: use kmalloc() instead of kzalloc() during iodev register/unregister
On 25/08/2015 11:05, Jason Wang wrote: > All fields of kvm_io_range were initialized or copied explicitly > afterwards. So switch to use kmalloc(). > > Cc: Gleb Natapov > Cc: Paolo Bonzini > Cc: Michael S. Tsirkin > Signed-off-by: Jason Wang > --- > virt/kvm/kvm_main.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 8b8a444..0d79fe8 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -3248,7 +3248,7 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum > kvm_bus bus_idx, gpa_t addr, > if (bus->dev_count - bus->ioeventfd_count > NR_IOBUS_DEVS - 1) > return -ENOSPC; > > - new_bus = kzalloc(sizeof(*bus) + ((bus->dev_count + 1) * > + new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count + 1) * > sizeof(struct kvm_io_range)), GFP_KERNEL); > if (!new_bus) > return -ENOMEM; > @@ -3280,7 +3280,7 @@ int kvm_io_bus_unregister_dev(struct kvm *kvm, enum > kvm_bus bus_idx, > if (r) > return r; > > - new_bus = kzalloc(sizeof(*bus) + ((bus->dev_count - 1) * > + new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) * > sizeof(struct kvm_io_range)), GFP_KERNEL); > if (!new_bus) > return -ENOMEM; > Applied this patch for 4.4. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] mmc: sdhci-pxav3: Enable support for PXA1928 SDCHI controller
On Friday 04 September 2015 09:02 PM, Vaibhav Hiremath wrote: PXA1928 SDHCI controller has few differences, for example, PXAxxxPXA1928 ===== SDCLK_DELAY field 0x10A 0x114 SDCLK_DELAY mask0x1F 0x3FF SDCLK_DELAY shift9 8 SDCLK_SEL shift 8 2 (SEL1) So this patch series introduces new compatible device_id (marvell,pxav3-1928-sdhci), and makes use of .data for handling such differences. The series also adds support like, - independent ->set_clock() api, as we need to enable internal clock gate and TX clock - pinctrl configuration based on bus speed. - introduce new quirk SDHCI_QUIRK2_MUST_SET_SDHCI_BUS_POWER SD_BUS_POWER & SD_BUS_VLT bit-fields are used internally to gate the clocks, so it is important to configure them as part of ->set_power() More detailed description is written into commit log. - Enable SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for PXA1928 device_id Please ignore this series, as one residual change (rather typo error). Mistakenly while checking in the code, instead of 1928 compatible property it was 988. I will submit the new series shortly. Thanks, Vaibhav Testing: I have done basic testing on both eMMC and SD card on PXA1928 based platform. Note: I tried to made sure that I do not break any other platform, which used sdhci, except HS200 configuration. Unfortunately I do not have access to any other datasheets, where I can cross check the details on HS200 bit-fields. Probably someone who has access can confirm [PATCH 4/5], whether it impacts other platforms. Kevin Liu (1): mmc: sdhci-pxav3: Fix HS200 mode support Vaibhav Hiremath (4): mmc: sdhci-pxav3: Enable pxa1928 device support mmc: sdhci-pxav3: Add platform specific set_clock ops mmc: sdhci-pxav3: Add pinctl setting according to bus clock mmc: sdhci: add new quirk for setting BUS_POWER & BUS_VLT fields drivers/mmc/host/sdhci-pltfm.c | 3 + drivers/mmc/host/sdhci-pxav3.c | 168 ++--- drivers/mmc/host/sdhci.c | 3 +- drivers/mmc/host/sdhci.h | 2 + 4 files changed, 163 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 4.1.6 Panic due to slab corruption
On Mon, 07 Sep 2015 11:41:17 +0300, Nikolay Borisov wrote: > Hello, > > On one of our servers I've observed the a kernel pannic > happening with the following backtrace: > > [654405.527070] BUG: unable to handle kernel paging request at > 00028001 > [654405.527076] IP: [] kmem_cache_alloc_node+0x99/0x1e0 > [654405.527085] PGD 14bef58067 PUD 2ab358067 PMD 0 Interesting! I can't offer much help but had a similar panic just the other day for no apparent reason while running a bunch of compiles. First time I've seen this with 4.1.6: Sep 5 20:42:02 ragnarok kernel: BUG: unable to handle kernel paging request at 8800e789b740 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: PGD 1aa2067 PUD 61f7fd067 PMD 0 Sep 5 20:42:02 ragnarok kernel: Oops: [#1] SMP Sep 5 20:42:02 ragnarok kernel: Modules linked in: auth_rpcgss oid_registry nfsv4 nfs lockd grace fscache sunrpc autofs4 sch_fq_codel snd_hda_codec_realtek x86_pkg_temp_thermal coretemp snd_hda_codec_generic crc32_pclmul crc32c_intel aesni_intel radeon aes_x86_64 glue_helper snd_hda_codec_hdmi lrw gf128mul ablk_helper cryptd i2c_algo_bit snd_usb_audio uvcvideo snd_hda_intel drm_kms_helper snd_hda_controller snd_hwdep videobuf2_vmalloc snd_usbmidi_lib videobuf2_memops snd_hda_codec videobuf2_core snd_rawmidi i2c_i801 ttm snd_hda_core v4l2_common snd_seq_device videodev snd_pcm usbhid drm snd_timer r8169 snd i2c_core mii soundcore parport_pc parport Sep 5 20:42:02 ragnarok kernel: CPU: 0 PID: 32755 Comm: sh Not tainted 4.1.6 #1 Sep 5 20:42:02 ragnarok kernel: Hardware name: Gigabyte Technology Co., Ltd. P67-DS3-B3/P67-DS3-B3, BIOS F1 05/06/2011 Sep 5 20:42:02 ragnarok kernel: task: 880569712e20 ti: 8804e4d9 task.ti: 8804e4d9 Sep 5 20:42:02 ragnarok kernel: RIP: 0010:[] [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RSP: 0018:8804e4d93d88 EFLAGS: 00010282 Sep 5 20:42:02 ragnarok kernel: RAX: RBX: 8805e7eacce0 RCX: 0001f7e8 Sep 5 20:42:02 ragnarok kernel: RDX: 0001f7e7 RSI: 00d0 RDI: 00018c70 Sep 5 20:42:02 ragnarok kernel: RBP: 8804e4d93dc8 R08: 88061f418c70 R09: Sep 5 20:42:02 ragnarok kernel: R10: 81748318 R11: ea00139bb500 R12: 00d0 Sep 5 20:42:02 ragnarok kernel: R13: 880606890600 R14: 8100d039 R15: 8800e789b740 Sep 5 20:42:02 ragnarok kernel: FS: 7f9c1d2f2700() GS:88061f40() knlGS: Sep 5 20:42:02 ragnarok kernel: CS: 0010 DS: ES: CR0: 80050033 Sep 5 20:42:02 ragnarok kernel: CR2: 8800e789b740 CR3: 0005f68ce000 CR4: 000406f0 Sep 5 20:42:02 ragnarok kernel: Stack: Sep 5 20:42:02 ragnarok kernel: 88061f7e6c00 0002 8805e7eacce0 Sep 5 20:42:02 ragnarok kernel: 880569712e20 01200011 8805e7eacce0 880569712e20 Sep 5 20:42:02 ragnarok kernel: 8804e4d93de8 8100d039 7f9c1d2f29d0 Sep 5 20:42:02 ragnarok kernel: Call Trace: Sep 5 20:42:02 ragnarok kernel: [] arch_dup_task_struct+0x69/0x170 Sep 5 20:42:02 ragnarok kernel: [] copy_process.part.8+0x14f/0x1760 Sep 5 20:42:02 ragnarok kernel: [] ? handle_mm_fault+0xd0f/0x13a0 Sep 5 20:42:02 ragnarok kernel: [] ? get_empty_filp+0xd4/0x1c0 Sep 5 20:42:02 ragnarok kernel: [] ? recalc_sigpending+0x1f/0x60 Sep 5 20:42:02 ragnarok kernel: [] do_fork+0xd7/0x370 Sep 5 20:42:02 ragnarok kernel: [] ? sigprocmask+0x57/0x90 Sep 5 20:42:02 ragnarok kernel: [] SyS_clone+0x16/0x20 Sep 5 20:42:02 ragnarok kernel: [] system_call_fastpath+0x12/0x6a Sep 5 20:42:02 ragnarok kernel: Code: 65 4c 03 05 ee e3 ea 7e 49 83 78 10 00 4d 8b 38 0f 84 b0 00 00 00 4d 85 ff 0f 84 a7 00 00 00 49 63 45 20 48 8d 4a 01 49 8b 7d 00 <49> 8b 1c 07 4c 89 f8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b9 49 63 Sep 5 20:42:02 ragnarok kernel: RIP [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: RSP Sep 5 20:42:02 ragnarok kernel: CR2: 8800e789b740 Sep 5 20:42:02 ragnarok kernel: ---[ end trace e4478715791f5752 ]--- Sep 5 20:42:02 ragnarok kernel: BUG: unable to handle kernel paging request at 8800e789b740 Sep 5 20:42:02 ragnarok kernel: IP: [] kmem_cache_alloc+0x6d/0x160 Sep 5 20:42:02 ragnarok kernel: PGD 1aa2067 PUD 61f7fd067 PMD 0 Sep 5 20:42:02 ragnarok kernel: Oops: [#2] SMP Sep 5 20:42:02 ragnarok kernel: Modules linked in: auth_rpcgss oid_registry nfsv4 nfs lockd grace fscache sunrpc autofs4 sch_fq_codel snd_hda_codec_realtek x86_pkg_temp_thermal coretemp snd_hda_codec_generic crc32_pclmul crc32c_intel aesni_intel radeon aes_x86_64 glue_helper snd_hda_codec_hdmi lrw gf128mul ablk_helper cryptd i2c_algo_bit snd_usb_audio uvcvideo snd_hda_intel drm_kms_helper snd_hda_controller snd_hwdep videobuf2_vmalloc snd_usbmidi_lib videobuf2_memops snd_hda_codec videob
Re: [PATCH 1/4] ARM: multi_v7_defconfig: Enable common Rockchip devices/busses
Hello Sjoerd, On 09/07/2015 12:24 PM, Sjoerd Simons wrote: > On Mon, 2015-09-07 at 11:26 +0200, Javier Martinez Canillas wrote: >> Hello Sjoerd, >> >> On 09/06/2015 10:16 PM, Sjoerd Simons wrote: >>> Enable Rockchip I2C, SPI, PWM, thermal drivers. >>> >>> Builtin are: >>> * I2C as it often controls the pmic. >> >> Having I2C as a module will cause more probe deferrals due missing >> regulators and slow down the boot but it should not cause issues. >> Or am I missing something? >> >> In fact, I think even the PMIC could be built as a module. > > It could in principle. However as a lot of other drivers do need the > regulators provided by the pmic, they'll be deferred until that driver > is loaded. So e.g. with the i2c/pmic drivers as a module you cannot > boot to an NFS rootfs without using an initramfs. > Right, not needing an initramfs is certainly a good reason. If you could add something like that in the commit message of patches 1/4 and 2/4 that would be great. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] ARM: multi_v7_defconfig: Enable ACT8865 PMIC driver
PMIC RK808 used on many rk3288 boards ,such as Popmetal. It is a MFD with function regulator and RTC. So if you plan to enable RK808, please also enable CONFIG_RTC_DRV_RK808. thanks. On 2015年09月07日 17:33, Heiko Stübner wrote: Hi, I guess one could rename that to something like "ARM: multi_v7_defconfig: Enable regulators used on most rockchip boards" and as well add CONFIG_REGULATOR_FAN53555=y CONFIG_MFD_RK808=y CONFIG_REGULATOR_RK808=y fan5355 is the driver providing support for the syr82x used on all rk3288 boards with an act8846. Am Sonntag, 6. September 2015, 22:16:04 schrieb Sjoerd Simons: Active Semi act8846 is used as the PMIC on various Rockchip boards, enable the ACT8865 driver to support this. Signed-off-by: Sjoerd Simons --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 25a1d574..7058fef 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -401,6 +401,7 @@ CONFIG_MFD_TPS65090=y CONFIG_MFD_TPS6586X=y CONFIG_MFD_TPS65910=y CONFIG_REGULATOR_AB8500=y +CONFIG_REGULATOR_ACT8865=y CONFIG_REGULATOR_AS3711=y CONFIG_REGULATOR_AS3722=y CONFIG_REGULATOR_AXP20X=y ___ Linux-rockchip mailing list linux-rockc...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
On 07/09/15 10:52, Pádraig Brady wrote:
> On 07/09/15 07:46, Naoya Horiguchi wrote:
>> On Mon, Sep 07, 2015 at 02:23:44AM +, Horiguchi Naoya(堀口 直也) wrote:
>>> On Mon, Sep 07, 2015 at 02:29:53AM +0100, Pádraig Brady wrote:
On 20/08/15 09:26, Naoya Horiguchi wrote:
> Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB),
> which
> is inconvenient when we want to know per-task or per-vma base hugetlb
> usage.
> To solve this, this patch adds a new line for hugetlb usage like below:
>
> Size: 20480 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced:0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> HugetlbPages: 18432 kB
> Swap: 0 kB
> KernelPageSize: 2048 kB
> MMUPageSize:2048 kB
> Locked:0 kB
> VmFlags: rd wr mr mw me de ht
>
> Signed-off-by: Naoya Horiguchi
> Acked-by: Joern Engel
> Acked-by: David Rientjes
> ---
> v3 -> v4:
> - suspend Acked-by tag because v3->v4 change is not trivial
> - I stated in previous discussion that HugetlbPages line can contain page
> size info, but that's not necessary because we already have
> KernelPageSize
> info.
> - merged documentation update, where the current documentation doesn't
> mention
> AnonHugePages, so it's also added.
> ---
> Documentation/filesystems/proc.txt | 7 +--
> fs/proc/task_mmu.c | 29 +
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git v4.2-rc4/Documentation/filesystems/proc.txt
> v4.2-rc4_patched/Documentation/filesystems/proc.txt
> index 6f7fafde0884..22e40211ef64 100644
> --- v4.2-rc4/Documentation/filesystems/proc.txt
> +++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
> @@ -423,6 +423,8 @@ Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 892 kB
> Anonymous: 0 kB
> +AnonHugePages: 0 kB
> +HugetlbPages: 0 kB
> Swap: 0 kB
> KernelPageSize:4 kB
> MMUPageSize: 4 kB
> @@ -440,8 +442,9 @@ indicates the amount of memory currently marked as
> referenced or accessed.
> "Anonymous" shows the amount of memory that does not belong to any file.
> Even
> a mapping associated with a file may contain anonymous pages: when
> MAP_PRIVATE
> and a page is modified, the file page is replaced by a private anonymous
> copy.
> -"Swap" shows how much would-be-anonymous memory is also used, but out on
> -swap.
> +"AnonHugePages" shows the ammount of memory backed by transparent
> hugepage.
> +"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
> +"Swap" shows how much would-be-anonymous memory is also used, but out on
> swap.
There is no distinction between "private" and "shared" in this "huge page"
accounting right?
>>>
>>> Right for current version. And I think that private/shared distinction
>>> gives some help.
>>>
Would it be possible to account for the huge pages in the
{Private,Shared}_{Clean,Dirty} fields?
Or otherwise split the huge page accounting into shared/private?
>>
>> Sorry, I didn't catch you properly.
>> I think that accounting for hugetlb pages should be done only with
>> HugetlbPages
>> or any other new field for hugetlb, in order not to break the behavior of
>> existing
>> fields.
>
> On a more general note I'd be inclined to just account
> for hugetlb pages in Rss and {Private,Shared}_Dirty
> and fix any tools that double count.
By the same argument I presume the existing THP "AnonHugePages" smaps field
is not accounted for in the {Private,Shared}_... fields?
I.E. AnonHugePages may also benefit from splitting to Private/Shared?
thanks,
Pádraig.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
