Re: [PATCH v13 00/19] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
On Tue, May 13, 2014 at 10:50 PM, Joerg Roedel wrote: > On Mon, May 12, 2014 at 11:44:45AM +0530, Shaik Ameer Basha wrote: >> Cho KyongHo (18): >> iommu/exynos: fix build errors >> iommu/exynos: change error handling when page table update is failed >> iommu/exynos: allocate lv2 page table from own slab >> iommu/exynos: fix L2TLB invalidation >> iommu/exynos: remove prefetch buffer setting >> iommu/exynos: add missing cache flush for removed page table entries >> iommu/exynos: always enable runtime PM >> iommu/exynos: remove dbgname from drvdata of a System MMU >> iommu/exynos: use managed device helper functions >> iommu/exynos: gating clocks of master H/W >> iommu/exynos: remove custom fault handler >> iommu/exynos: change rwlock to spinlock >> iommu/exynos: use exynos-iommu specific typedef >> iommu/exynos: enhanced error messages >> documentation: iommu: add binding document of Exynos System MMU >> iommu/exynos: support for device tree >> iommu/exynos: turn on useful configuration options >> iommu/exynos: apply workaround of caching fault page table entries >> >> .../devicetree/bindings/iommu/samsung,sysmmu.txt | 65 ++ >> drivers/iommu/exynos-iommu.c | 1035 >> >> 2 files changed, 677 insertions(+), 423 deletions(-) >> create mode 100644 >> Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt > > Applied, thanks. Please send another patch to update the documentation > as requested by Arnd. Hi Joerg, Thanks for applying the series. I posted one patch addressing 'Arnd' comments. Please apply it on top of this series. -- documentation/iommu: Add note on existing DT binding status Regards, Shaik > > > Joerg > > > ___ > iommu mailing list > io...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- 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] documentation/iommu: Add note on existing DT binding status
The current dt binding for Exynos System MMU can be changed, if found incompatible with the support for "Generic IOMMU Binding". This patch adds a note to the binding documentation stating the same. Signed-off-by: Shaik Ameer Basha --- .../devicetree/bindings/iommu/samsung,sysmmu.txt |5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt index 15b2a2b..6fa4c73 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -27,6 +27,11 @@ The drivers must consider how to handle those System MMUs. One of the idea is to implement child devices or sub-devices which are the client devices of the System MMU. +Note: +The current DT binding for the Exynos System MMU is incomplete. +The following properties can be removed or changed, if found incompatible with +the "Generic IOMMU Binding" support for attaching devices to the IOMMU. + Required properties: - compatible: Should be "samsung,exynos-sysmmu" - reg: A tuple of base address and size of System MMU registers. -- 1.7.9.5 -- 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 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/13/2014 10:51 PM, Pedro Alves wrote: > I wonder whether people are getting Roland's address from? > > It's frequent that ptrace related patches end up CCed to > rol...@redhat.com, but, he's not been at Red Hat for a few years > now. Roland, do you still want to be CCed on ptrace-related > issues? If so, there's probably a script somewhere in the > kernel that needs updating. If not, well, it'd be good > if it were updated anyway. :-) > > It's a little annoying, as Red Hat's servers outright reject > email sent from a @redhat.com address if one tries to send > an email that includes a CC/FROM to a user that no longer > exists in the @redhat.com domain. Got the email address from some of the previous ptrace related commits. -- 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 9/9] perf, tools, record: Always allow to overide default period v2
On Mon, 12 May 2014 15:51:14 -0700, Andi Kleen wrote: > From: Andi Kleen > > Fix the logic to allow overriding event default periods with -c or -F > on the command line. I'm not sure I understand this if() fully, but > this change makes all cases I tested work (tracepoint with default, default, > ,-c, -F) > > This fixed specifying -c / -F with json event list events, > which have a default period. It should do the same > for trace point events. Hmm.. doesn't that require both -c and -F are given at the same time? Anyway, there was a similar discussion, but I suggested an other way. Please see the line below. https://lkml.org/lkml/2014/2/4/807 Thanks, Namhyung -- 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 v4 3/8] phy: sunxi: Rework phy initialization
Hi,
On Tuesday 13 May 2014 09:14 PM, Maxime Ripard wrote:
> Move the phy initialization and variables declaration to the loop itself,
> since
> it is where it really belongs. Also remove all the temporary variables, we can
> use the structure members directly.
>
> Signed-off-by: Maxime Ripard
> Reviewed-by: Hans de Goede
let me know if I have to queue this and the next patch in my PHY tree.
Cheers
Kishon
> ---
> drivers/phy/phy-sun4i-usb.c | 42 ++
> 1 file changed, 18 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index e6e6c4ba7145..66a87d50512b 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -224,13 +224,8 @@ static int sun4i_usb_phy_probe(struct platform_device
> *pdev)
> struct sun4i_usb_phy_data *data;
> struct device *dev = >dev;
> struct device_node *np = dev->of_node;
> - void __iomem *pmu = NULL;
> struct phy_provider *phy_provider;
> - struct reset_control *reset;
> - struct regulator *vbus;
> struct resource *res;
> - struct phy *phy;
> - char name[16];
> int i;
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> @@ -262,42 +257,41 @@ static int sun4i_usb_phy_probe(struct platform_device
> *pdev)
>
> /* Skip 0, 0 is the phy for otg which is not yet supported. */
> for (i = 1; i < data->num_phys; i++) {
> + struct sun4i_usb_phy *phy = data->phys + i;
> + char name[16];
> +
> snprintf(name, sizeof(name), "usb%d_vbus", i);
> - vbus = devm_regulator_get_optional(dev, name);
> - if (IS_ERR(vbus)) {
> - if (PTR_ERR(vbus) == -EPROBE_DEFER)
> + phy->vbus = devm_regulator_get_optional(dev, name);
> + if (IS_ERR(phy->vbus)) {
> + if (PTR_ERR(phy->vbus) == -EPROBE_DEFER)
> return -EPROBE_DEFER;
> - vbus = NULL;
> + phy->vbus = NULL;
> }
>
> snprintf(name, sizeof(name), "usb%d_reset", i);
> - reset = devm_reset_control_get(dev, name);
> - if (IS_ERR(reset)) {
> + phy->reset = devm_reset_control_get(dev, name);
> + if (IS_ERR(phy->reset)) {
> dev_err(dev, "failed to get reset %s\n", name);
> - return PTR_ERR(reset);
> + return PTR_ERR(phy->reset);
> }
>
> if (i) { /* No pmu for usbc0 */
> snprintf(name, sizeof(name), "pmu%d", i);
> res = platform_get_resource_byname(pdev,
> IORESOURCE_MEM, name);
> - pmu = devm_ioremap_resource(dev, res);
> - if (IS_ERR(pmu))
> - return PTR_ERR(pmu);
> + phy->pmu = devm_ioremap_resource(dev, res);
> + if (IS_ERR(phy->pmu))
> + return PTR_ERR(phy->pmu);
> }
>
> - phy = devm_phy_create(dev, _usb_phy_ops, NULL);
> - if (IS_ERR(phy)) {
> + phy->phy = devm_phy_create(dev, _usb_phy_ops, NULL);
> + if (IS_ERR(phy->phy)) {
> dev_err(dev, "failed to create PHY %d\n", i);
> - return PTR_ERR(phy);
> + return PTR_ERR(phy->phy);
> }
>
> - data->phys[i].phy = phy;
> - data->phys[i].pmu = pmu;
> - data->phys[i].vbus = vbus;
> - data->phys[i].reset = reset;
> - data->phys[i].index = i;
> - phy_set_drvdata(phy, >phys[i]);
> + phy->index = i;
> + phy_set_drvdata(phy->phy, >phys[i]);
> }
>
> dev_set_drvdata(dev, data);
>
--
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 2/3] powerpc, ptrace: Enable support for transactional memory register sets
On 05/13/2014 10:43 PM, Pedro Alves wrote: > On 05/05/14 08:54, Anshuman Khandual wrote: >> This patch enables get and set of transactional memory related register >> sets through PTRACE_GETREGSET/PTRACE_SETREGSET interface by implementing >> four new powerpc specific register sets i.e REGSET_TM_SPR, REGSET_TM_CGPR, >> REGSET_TM_CFPR, REGSET_CVMX support corresponding to these following new >> ELF core note types added previously in this regard. >> >> (1) NT_PPC_TM_SPR >> (2) NT_PPC_TM_CGPR >> (3) NT_PPC_TM_CFPR >> (4) NT_PPC_TM_CVMX > > Sorry that I couldn't tell this from the code, but, what does the > kernel return when the ptracer requests these registers and the > program is not in a transaction? Specifically I'm wondering whether > this follows the same semantics as the s390 port. > Right now, it still returns the saved state of the registers from thread struct. I had assumed that the user must know the state of the transaction before initiating the ptrace request. I guess its better to check for the transaction status before processing the request. In case if TM is not active on that thread, we should return -EINVAL. I am not familiar with the s390 side of code. But if we look at the s390_tdb_get function it checks for (regs->int_code & 0x200) before processing the request. Not sure what 0x200 signifies though. -- 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: [ 080/143] net: rework recvmsg handler msg_name and msg_namelen logic
Hi Luis,
On Tue, May 13, 2014 at 01:44:25PM +0100, Luis Henriques wrote:
> On Mon, May 12, 2014 at 02:33:20AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch. If anyone has any objections, please let me
> > know.
> >
> > --
> >
> > From: Hannes Frederic Sowa
> >
> > [ Upstream commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c ]
> >
>
>
>
> > diff --git a/net/rxrpc/ar-recvmsg.c b/net/rxrpc/ar-recvmsg.c
> > index a39bf97..f779fc3 100644
> > --- a/net/rxrpc/ar-recvmsg.c
> > +++ b/net/rxrpc/ar-recvmsg.c
> > @@ -142,10 +142,12 @@ int rxrpc_recvmsg(struct kiocb *iocb, struct socket
> > *sock,
> >
> > /* copy the peer address and timestamp */
> > if (!continue_call) {
> > - if (msg->msg_name && msg->msg_namelen > 0)
> > + if (msg->msg_name) {
> > + size_t len =
> > + sizeof(call->conn->trans->peer->srx);
> > memcpy(msg->msg_name,
> > - >conn->trans->peer->srx,
> > - sizeof(call->conn->trans->peer->srx));
> > + >conn->trans->peer->srx, len);
> +msg->msg_namelen = len;
>
> This statement^^^ is missing in this backport.
>
> Also missing in this patch are the changes to the following functions:
>
> - pppoe_recvmsg()
> In file drivers/net/pppoe.c instead of drivers/net/ppp/pppoe.c
>
> - pppol2tp_recvmsg()
> In file drivers/net/pppol2tp.c instead of net/l2tp/l2tp_ppp.c
>
> For reference, I'm attaching the backport we have used in our Ubuntu
> kernel. (Note that we added some extra information to the commit
> message to include the CVE number and a link to the CVE bug.)
Just a quick note to let you know that your patch applied well, and
that the diff between the two correctly reports the parts you pointed
above. So I'm taking it instead.
Thanks!
Willy
--
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 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
hi Arnd, On Tuesday 13 May 2014 07:04 PM, Arnd Bergmann wrote: > On Tuesday 13 May 2014 15:27:46 Arnd Bergmann wrote: >> On Tuesday 13 May 2014 18:56:23 Kishon Vijay Abraham I wrote: If you have a case where the outbound translation is a 256MB (i.e. 28bit) section of the CPU address space, that could be represented as ranges = <0x8200 0 0 0xb000 0 0x1000>; or ranges = <0x8200 0 0xb000 0xb000 0 0x1000>; depending on whether you want the BARs to be programmed using a low address 0x0-0x0fff or an address matching the window 0xb000-0xbfff. >>> >>> The problem is, for configuring the window starting at 0xb000, the ATU >>> should be programmed 0x000 (the cpu address for it will be 0xb000 >>> though). >>> >> >> Then use the first of the two? >> > > To clarify: using <0x8200 0 0 0xb000 0 0x1000> will give you > a mem_offset of 0xb000, which should work just fine for this case. > > What I don't understand is why the ATU cares about whether the outbound > address is 0x000 or 0xb000 if it just decodes the lower 28 bit > anyway. Did you mean that we have to program the BARs using low addresses > regardless of what is programmed in the ATU? That would make more sense, > and it also matches what I suggested. No, It's not like it decodes only the lower 28bits. The BARs is programmed with 32 bit value. My pcie dt node has ranges = <0x0800 0 0x20001000 0x20001000 0 0x2000 /* CONFIG */ 0x8100 0 0 0x20003000 0 0x0001 /* IO */ 0x8200 0 0x20013000 0x20013000 0 0xffed000>; /* MEM */ Consider MEM address space.. Here both PCI address and CPU address is 0x20013000. So when there is a write to cpu addr 0x20013000 [writel(virt_addr(0x20013000)], we want it to be translated to PCI addr 0x20013000. So in 'ATU', we would expect *base* to be programmed to *0x20013000* and target to be programmed to *0x20013000*. But that's not the case for DRA7xx. For DRA7xx *base* should be programmed to *0x0013000* and target should be programmed to *0x20013000*. Thanks Kishon -- 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: dts: am335x-bone-common: Add i2c2 definition
On 5/13/14, 8:39 PM, "Pantelis Antoniou"
wrote:
>Hi John,
>
>On May 13, 2014, at 1:24 PM, John Syn wrote:
>
>>
>> On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
>> wrote:
>>
>>> Hello Pantelis,
>>>
>>> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
>>> wrote:
Hi Javier,
On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
> On Tue, May 13, 2014 at 4:22 PM, Matt Porter
> wrote:
>> On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
>> wrote:
>>> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote:
On 05/12/2014 04:57 PM, Robert Nelson wrote:
>>> Either case if fine with me. As who knows when the dtc
>>> "overlay" will
>>> every truly make it mainline, as the capemgr was the only real
>>> kernel
>>> user of the i2c/at24 eeprom information.
>>
>> Sounds like we should keep it disabled though so u-boot can be
>> used
>> to toggle it while waiting for the capemgr. That's because the
>> board
>> has a header for pins, so it's not exactly limited to just the
>> capes.
>>
>> Anybody working on enabling/disabling cape dtb configurations in
>> u-boot?
>
> Well,
>
> Would Tom even approve of that in mainline u-boot? He didn't want
> my
> "invert" the gpio to enable the usb hub on the older beagle xm
> A/B..
>
> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
>
> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>>>
>>> Using fdt set from the bootloader to use the same FDT for similar
>>> boards (like the example with Beagle xM variants) is kind of trying
>>> to
>>> replicate what we used to do from boards files where it was
>>>possible
>>> to manage a set of boards using the same platform code.
>>>
>>> But Device Trees are meant to describe hardware and thus should be
>>> static, if two board are almost identical but slightly different,
>>> then
>>> are two different hardware where each need its proper FDT that
>>> describes it.
>>>
I would think that using the 'fdt' command in U-Boot to add all
properties of every cape found on a running system would drive
someone
to madness quite quickly. Moving all of Pantelis' work for
dynamic
device trees from the kernel to N bootloaders (U-Boot, barebox,
UEFI,
etc) sounds like a step in the wrong direction.
>>>
>>> Agreed. I think that until the device tree overlay and the cape
>>> manager find their way into mainline we should treat capes as if
>>>they
>>> were expansion boards attached to a Computer-on-Module. That is, a
>>> static based board which its own DTS including the BB{B,W} as an
>>>dtsi
>>> and not something that can be added on runtime.
>>
>> It's far more complicated than a SOM plus carrier board. Consider
>>that
>> you can have any 4 of these capes stacked on the BBB/BBW in any
>> combination (assuming no resource conflicts). Capturing all possible
>> combinations in static dtsis is not practical.
>>
>
Since this appears to be all coming back to DT overlays, let me try to
address some points.
>>>
>>> It seems that you misunderstood my comments. I do think that DT
>>> overlays and the cape manager are a great solution for any hardware
>>> that could be expanded on runtime and I really hope that they can
>>> eventually land into mainline.
>>>
>>> In fact if you look on my previous mail you will see that I said:
>>> "until device tree overlay and the cape manager find their way into
>>> mainline..."
>>>
> Right, I forgot that the capes were stackable so is indeed not
> practical to model every single combination as DTS in mainline. Even
> if stacking was not possible there are just too many capes out there
> to have a DTS for every single cape.
>
Each cape does have a DTS as dynamically loaded fragment; it works
absolutely fine.
Trying to come up with a base DTS for all the capes you've stacked up
is an exponential problem.
> My point was that someone who wants to use a BBB + a set of capes can
> today write a DTS for its own stacked setup.
>
No, the guy that designs a cape (or learns how to) can not write a DTS
for
the base board and the cape in question. Doing that he essentially
cuts
himself off from the community.
Let me explain, the point is for people to easily design capes,
open-source their
design as well as their software, and share them to the community.
This requires that things are easily shareable.
Requiring a relative newbie in kernel development
Re: [PATCH 1/5] usb: dwc3: dwc3-omap: Add dwc3_omap_map_offset function
On 5/13/2014 9:32 PM, Felipe Balbi wrote:
Hi,
On Thu, May 08, 2014 at 03:03:03PM +0530, George Cherian wrote:
Calculate the wrapper register offsets in a seperate function.
Improve code readability, decrease the dwc3_probe() size.
Signed-off-by: George Cherian
---
drivers/usb/dwc3/dwc3-omap.c | 80
1 file changed, 44 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 1160ff4..872f065 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -383,6 +383,49 @@ static int dwc3_omap_vbus_notifier(struct notifier_block
*nb,
return NOTIFY_DONE;
}
+static void dwc3_omap_map_offset(struct dwc3_omap *omap)
+{
+ u32 reg;
+ struct device_node *node = omap->dev->of_node;
+ int x_major;
+
+ reg = dwc3_omap_readl(omap->base, USBOTGSS_REVISION);
+ omap->revision = reg;
+ x_major = USBOTGSS_REVISION_XMAJOR(reg);
+
+ /* Differentiate between OMAP5 and AM437x */
+ switch (x_major) {
+ case USBOTGSS_REVISION_XMAJOR1:
+ case USBOTGSS_REVISION_XMAJOR2:
+ omap->irq_eoi_offset = 0;
+ omap->irq0_offset = 0;
+ omap->irqmisc_offset = 0;
+ omap->utmi_otg_offset = 0;
+ omap->debug_offset = 0;
+ break;
+ default:
+ /* Default to the latest revision */
+ omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
+ break;
+ }
+
+ /* For OMAP5(ES2.0) and AM437x x_major is 2 even though there are
+* changes in wrapper registers, Using dt compatible for aegis
+*/
+
+ if (of_device_is_compatible(node, "ti,am437x-dwc3")) {
+ omap->irq_eoi_offset = USBOTGSS_EOI_OFFSET;
+ omap->irq0_offset = USBOTGSS_IRQ0_OFFSET;
+ omap->irqmisc_offset = USBOTGSS_IRQMISC_OFFSET;
+ omap->utmi_otg_offset = USBOTGSS_UTMI_OTG_OFFSET;
+ omap->debug_offset = USBOTGSS_DEBUG_OFFSET;
+ }
can you add a patch before $subject which gets rid of the switch
statement above since it's pretty much useless now that we use
compatible strings to differentiate omap5 and am437x ?'
okay will do in v2.
--
-George
--
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] lib: devres: Mark devm_request_and_ioremap() as deprecated
devm_request_and_ioremap() was obsoleted by devm_ioremap_resource(). (7509657 "lib: devres: Introduce devm_ioremap_resource()") So, let's mark it as deprecated in order to stop using it. Suggested-by: Florian Fainelli Signed-off-by: Jingoo Han Cc: Thierry Reding --- include/linux/device.h |4 ++-- lib/devres.c |1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/device.h b/include/linux/device.h index 67f003a..769c86b 100644 --- a/include/linux/device.h +++ b/include/linux/device.h @@ -627,8 +627,8 @@ extern void *devm_kmemdup(struct device *dev, const void *src, size_t len, gfp_t gfp); void __iomem *devm_ioremap_resource(struct device *dev, struct resource *res); -void __iomem *devm_request_and_ioremap(struct device *dev, - struct resource *res); +void __deprecated __iomem *devm_request_and_ioremap(struct device *dev, + struct resource *res); /* allows to add/remove a custom action to devres stack */ int devm_add_action(struct device *dev, void (*action)(void *), void *data); diff --git a/lib/devres.c b/lib/devres.c index 2f16c13..44c7cb2 100644 --- a/lib/devres.c +++ b/lib/devres.c @@ -147,6 +147,7 @@ EXPORT_SYMBOL(devm_ioremap_resource); * @dev: Generic device to handle the resource for * @res: resource to be handled * + * This is deprecated, please use devm_ioremap_resource() instead. * Takes all necessary steps to ioremap a mem resource. Uses managed device, so * everything is undone on driver detach. Checks arguments, so you can feed * it the result from e.g. platform_get_resource() directly. Returns the -- 1.7.10.4 -- 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 0/5] Add support for SW babble Control
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue->sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-George
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-George
--
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 8/9] perf, tools, test: Add test case for alias and JSON parsing
On Mon, 12 May 2014 15:51:13 -0700, Andi Kleen wrote:
[SNIP]
> +int test__aliases(void)
Just a nitpick. Please use a more descriptive name for the testcase
like test__event_aliases().
> +{
> + int err;
> +
> + /* Download JSON files */
> + /* XXX assumes perf is installed */
> + /* For now user must manually download */
> + if (0 && system("perf download > /dev/null") < 0) {
> + /* Don't error out for this for now */
> + fprintf(stderr, "perf download failed\n");
> + }
> +
> + evlist = perf_evlist__new();
> + if (evlist == NULL)
> + return -ENOMEM;
> +
> + err = pmu_iterate_events(test_event);
> + fprintf(stderr, " Parsed %d events :", num_events);
> + if (failed > 0)
> + fprintf(stderr, " %d events failed", num_events);
s/num_events/failed/ ?
And this kind of detailed information is usually printed when -v option
is given via pr_debug().
Thanks,
Namhyung
> + perf_evlist__delete(evlist);
> + return err;
> +}
--
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/2] mm/page_alloc: DEBUG_VM checks for free_list placement of CMA and RESERVE pages
On Tue, 13 May 2014, Sasha Levin wrote: > On 05/05/2014 11:50 AM, Vlastimil Babka wrote: > > So in the end this VM_DEBUG check probably cannot work anymore for > > MIGRATE_RESERVE, only for CMA. I'm not sure if it's worth keeping it only > > for CMA, what are the CMA guys' opinions on that? > > The way I understood it is that this patch is wrong, but it's still > alive in -mm. Should it still be there? I agree that it should be dropped. I did not follow the discussion, but mmotm soon gives me BUG at mm/page_alloc.c:1242 under swapping load. Hugh -- 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] Please pull powerpc.git merge branch
Hi Linus ! Here are a couple of fixes for 3.15. One from Anton fixes a nasty regression I introduced when trying to fix a loss of irq_work whose consequences is that we can completely lose timer interrupts on a CPU... not pretty. The other one is a change to our PCIe reset hook to use a firmware call instead of direct config space accesses to trigger a fundamental reset on the root port. This is necessary so that the FW gets a chance to disable the link down error monitoring, which would otherwise trip and cause subsequent fatal EEH error. Cheers, Ben. The following changes since commit e4565362c7adc31201135c4b6d649fc1bdc3bf20: powerpc/4xx: Fix section mismatch in ppc4xx_pci.c (2014-04-28 16:32:53 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 8050936caf125fbe54111ba5e696b68a360556ba: powerpc: irq work racing with timer interrupt can result in timer interrupt hang (2014-05-12 14:29:28 +1000) Anton Blanchard (1): powerpc: irq work racing with timer interrupt can result in timer interrupt hang Gavin Shan (1): powerpc/powernv: Reset root port in firmware arch/powerpc/kernel/time.c| 3 --- arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++- 2 files changed, 2 insertions(+), 4 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: [PATCH 5/9] perf, tools: Add perf download to download event files v2
On Mon, 12 May 2014 15:51:10 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Add a downloader to automatically download the right
> files from a download site.
>
> This is implemented as a script calling wget, similar to
> perf archive. The perf driver automatically calls the right
> binary. The downloader is extensible, but currently only
> implements an Intel event download. It would be straightforward
> to add other sites too for other vendors.
>
> The downloaded event files are put into ~/.cache/pmu-events, where the
> builtin event parser in util/* can find them automatically.
>
> Cc: Use ~/.cache
???
[SNIP]
> @@ -0,0 +1,52 @@
> +#!/bin/bash
> +# download event files for current cpu for perf
> +
> +WGETOPT=${WGETOPT:---no-verbose --timeout 5}
Could you please extend this script to support curl also? It seems the
wget is not installed by default on my system.
> +
> +set -e
> +
> +if [ "$1" == "" ] ; then
> + S=$(awk '
> +/^vendor/{ V=$3 }
> +/^model/ && $2 == ":"{ M=$3 }
> +/^cpu family/{ F = $4 }
Inconsistency in using whitespace..
Thanks,
Namhyung
> +END{ printf("%s-%s-%X", V, F, M) }' /proc/cpuinfo)
> +else
> + S="$1"
> +fi
> +V=$(echo $S | ( IFS=- read v f m ; echo $v) )
> +
> +CACHEDIR=${XDG_CACHE_HOME:-~/.cache}
> +[ ! -d $CACHEDIR/pmu-events ] && mkdir -p $CACHEDIR/pmu-events
> +cd $CACHEDIR/pmu-events
> +
> +case "$V" in
> +GenuineIntel)
> + echo "Downloading models file"
> + URLBASE=${URLBASE:-https://download.01.org/perfmon}
> + MAPFILE=${MAPFILE:-mapfile.csv}
> + echo "Downloading readme.txt"
> + wget -N $WGETOPT $URLBASE/readme.txt
> + ;;
> +
> +# Add more CPU vendors here
> +
> +*)
> + echo "Unsupported CPU vendor $V"
> + exit 1
> + ;;
> +esac
> +
> +wget -N $WGETOPT $URLBASE/$MAPFILE
> +
> +echo "Downloading events file"
> +awk -v urlbase=$URLBASE -v cpu="$S" -F, \
> + '$1 == cpu && $4 == "core" { print urlbase $3; exit 0 }' \
> + $MAPFILE > url$$
> +if [ -s url$$ ] ; then
> + wget $WGETOPT -q -i url$$ -O $S-core.json
> +else
> + echo "CPU $S not found"
> +fi
> +rm -f url$$
> +
--
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/9] perf, tools: Add support for reading JSON event files
On Mon, 12 May 2014 15:51:08 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> Add a parser for Intel style JSON event files. This allows
> to use an Intel event list directly with perf. The Intel
> event lists can be quite large and are too big to store
> in unswappable kernel memory.
>
> The parser code knows how to convert the JSON fields
> to perf fields. The conversion code is straight forward.
> It knows (very little) Intel specific information, and can be easily
> extended to handle fields for other CPUs.
>
> The parser code is partially shared with an independent parsing
> library, which is 2-clause BSD licenced. To avoid any conflicts I marked
> those files as BSD licenced too. As part of perf they become GPLv2.
>
> The events are handled using the existing alias machinery.
>
> We output the BriefDescription in perf list.
>
> Right now the json file can be specified as an argument
> to perf stat/record/list. Followon patches will automate this.
I think it'd be good to show an example json event file content in
the changelog and/or comment.
>
> Signed-off-by: Andi Kleen
> ---
> tools/perf/Documentation/perf-list.txt | 6 +
> tools/perf/Documentation/perf-record.txt | 3 +
> tools/perf/Documentation/perf-stat.txt | 3 +
> tools/perf/Makefile.perf | 2 +
> tools/perf/builtin-list.c| 2 +
> tools/perf/builtin-record.c | 3 +
> tools/perf/builtin-stat.c| 2 +
> tools/perf/util/jevents.c| 248
> +++
> tools/perf/util/jevents.h| 3 +
> tools/perf/util/pmu.c| 14 ++
> tools/perf/util/pmu.h| 2 +
> 11 files changed, 288 insertions(+)
> create mode 100644 tools/perf/util/jevents.c
> create mode 100644 tools/perf/util/jevents.h
>
> diff --git a/tools/perf/Documentation/perf-list.txt
> b/tools/perf/Documentation/perf-list.txt
> index 6fce6a6..d399e04 100644
> --- a/tools/perf/Documentation/perf-list.txt
> +++ b/tools/perf/Documentation/perf-list.txt
> @@ -15,6 +15,12 @@ DESCRIPTION
> This command displays the symbolic event types which can be selected in the
> various perf commands with the -e option.
>
> +OPTIONS
> +---
> +--json-file=::
Hmm.. I think the option name should not be tied to the implementation.
How about --event-file or --event-alias then?
> +Specify JSON event list file to use for parsing events.
> +
> +
> [[EVENT_MODIFIERS]]
> EVENT MODIFIERS
> ---
> diff --git a/tools/perf/Documentation/perf-record.txt
> b/tools/perf/Documentation/perf-record.txt
> index c71b0f3..8a1e0d9 100644
> --- a/tools/perf/Documentation/perf-record.txt
> +++ b/tools/perf/Documentation/perf-record.txt
> @@ -213,6 +213,9 @@ if combined with -a or -C options.
> After starting the program, wait msecs before measuring. This is useful to
> filter out the startup phase of the program, which is often very different.
>
> +--json-file=::
> +Specify JSON event list file to use for parsing events.
> +
> SEE ALSO
>
> linkperf:perf-stat[1], linkperf:perf-list[1]
> diff --git a/tools/perf/Documentation/perf-stat.txt
> b/tools/perf/Documentation/perf-stat.txt
> index 29ee857..a946283 100644
> --- a/tools/perf/Documentation/perf-stat.txt
> +++ b/tools/perf/Documentation/perf-stat.txt
> @@ -142,6 +142,9 @@ filter out the startup phase of the program, which is
> often very different.
>
> Print statistics of transactional execution if supported.
>
> +--json-file=::
> +Specify JSON event list file to use for parsing events.
> +
> EXAMPLES
>
>
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 43d4109..8800838 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -302,6 +302,7 @@ LIB_H += ui/ui.h
> LIB_H += util/data.h
> LIB_H += util/jsmn.h
> LIB_H += util/json.h
> +LIB_H += util/jevents.h
>
> LIB_OBJS += $(OUTPUT)util/abspath.o
> LIB_OBJS += $(OUTPUT)util/alias.o
> @@ -377,6 +378,7 @@ LIB_OBJS += $(OUTPUT)util/srcline.o
> LIB_OBJS += $(OUTPUT)util/data.o
> LIB_OBJS += $(OUTPUT)util/jsmn.o
> LIB_OBJS += $(OUTPUT)util/json.o
> +LIB_OBJS += $(OUTPUT)util/jevents.o
>
> LIB_OBJS += $(OUTPUT)ui/setup.o
> LIB_OBJS += $(OUTPUT)ui/helpline.o
> diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
> index 011195e..ca3dd18 100644
> --- a/tools/perf/builtin-list.c
> +++ b/tools/perf/builtin-list.c
> @@ -20,6 +20,8 @@ int cmd_list(int argc, const char **argv, const char
> *prefix __maybe_unused)
> {
> int i;
> const struct option list_options[] = {
> + OPT_STRING(0, "json-file", _file, "json file",
> +"Read event json file"),
> OPT_END()
> };
> const char * const list_usage[] = {
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index e4c85b8..e4a5be0 100644
> --- a/tools/perf/builtin-record.c
> +++
Re: [PATCH RFC net-next] tracing: accelerate tracing filters with BPF
* Alexei Starovoitov wrote: > On Tue, May 13, 2014 at 8:17 PM, Steven Rostedt wrote: > > On Tue, 13 May 2014 19:55:11 -0700 > > Alexei Starovoitov wrote: > > > >> Tracing filters are parsing user supplied character string and constructing > >> a predicate tree. filter_match_preds() was used to walk nodes of the tree > >> to > >> simulate matching of boolean expression. > >> > > > > I applied this on top of net-next, from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > > (master branch) > > > > and got this compile error: > > Sorry I wasn't clear in the log. > This patch depends on JIT patches that were posted separately. > Since this one is RFC, I didn't want to mix them. > JIT patches: > http://patchwork.ozlabs.org/patch/348558/ > http://patchwork.ozlabs.org/patch/348559/ > http://patchwork.ozlabs.org/patch/348560/ Might make sense for you to get a korg account and stick such bits into Git trees, to ease testing. 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 0/3] File Sealing & memfd_create()
On Tue, 15 Apr 2014, David Herrmann wrote: > > This is v2 of the File-Sealing and memfd_create() patches. You can find v1 > with > a longer introduction at gmane: > http://thread.gmane.org/gmane.comp.video.dri.devel/102241 > An LWN article about memfd+sealing is available, too: > https://lwn.net/Articles/593918/ Sorry it's taken so long: at last I managed to set aside a few hours at the weekend, to read through your memfd+sealing work and let it sink in. Good stuff. I've a page of notes which I shall respond with, either later in the week or at the weekend; but they're pretty much trivia, or notes to myself, beside the async I/O issue raised by Tony Battersby. I thought I'd better not wait longer to give warning that I do take that issue seriously. > > Shortlog of changes since v1: > - Dropped the "exclusive reference" idea >Now sealing is a one-shot operation. Once a given seal is set, you cannot >remove this seal again, ever. This allows us to drop all the ref-count >checking and simplifies the code a lot. We also no longer have all the > races >we have to test for. > - The i_writecount fix is now upstream (slightly different, by Al Viro) so I >dropped it from the series. > - Change SHMEM_* prefix to F_* to avoid any API-association to shmem. > - Sealing is disabled on all files by default (even though we still haven't >found any DoS attack). You need to pass MFD_ALLOW_SEALING to memfd_create() >to get an object that supports the sealing API. > - Changed F_SET_SEALS to F_ADD_SEALS. This better reflects the API. You can >never remove seals, you can only add seals. Note that the semantics also >changed slightly: You can now _always_ call F_ADD_SEALS to add _more_ > seals. >However, a new seal was added which "seals sealing" (F_SEAL_SEAL). So once >F_SEAL_SEAL is set, F_ADD_SEAL is no longer allowed. >This feature was requested by the glib developers. > - memfd_create() names are now limited to NAME_MAX instead of 256 hardcoded. > - Rewrote the test suite > > The biggest change in v2 is the removal of the "exclusive reference" idea. It > was a nice optimization, but the implementation was ugly and racy regarding > file-table changes. Linus didn't like it either so we decided to drop it > entirely. Sealing is a one-shot operation now. A sealed file can never be > unsealed, even if you're the only holder. > > I also addressed most of the concerns regarding API naming and semantics. I > got > feedback from glib, EFL, wayland, kdbus, ostree, audio developers and we > discussed many possible use-cases (and also cases that don't make sense). So I > think we're in a very good state right now. > > People requested to make this interface more generic. I renamed the API to > reflect that, but I didn't change the implementation. Thing is, seals cannot > be > removed, ever. Therefore, semantics for sealing on non-volatile storage are > undefined. We don't write them to disc and it is unclear whether a sealed file > can be unlinked/removed again. There're more issues with this and no-one came > up > with a use-case, hence I didn't bother implementing it. > There's also an ongoing discussion about an AIO race, but this also affects > other inode-protections like S_IMMUTABLE/etc. So I don't think we should tie > the fix to this series. I disagree on that. Whatever the bugs or limitations with S_IMMUTABLE, ETXTBSY etc, we have lived with those without complaint for many years. You now propose an entirely new kind of guarantee, but that guarantee is broken by the possibility of outstanding async I/O to a page of the sealed object. I don't see how we can add the new feature while knowing it broken. We have to devise a solution, but I haven't thought of a good solution yet. Checking page counts in a GB file prior to sealing does not appeal at all: we'd be lucky ever to find them all accounted for. Adding overhead to get_user_pages_fast() won't appeal to its adherents, and I'm not even convinced that GUP is the only way in here. Any ideas? > Another discussion was about preventing /proc/self/fd/. But again, no-one > could > tell me _why_, so I didn't bother. On the contrary, I even provided several > use-cases that make use of /proc/self/fd/ to get read-only FDs to pass around. > > If anyone wants to test this, please use 3.15-rc1 as base. The i_writecount > fixes are required for this series. > > Comments welcome! > David > > David Herrmann (3): > shm: add sealing API > shm: add memfd_create() syscall > selftests: add memfd_create() + sealing tests > > arch/x86/syscalls/syscall_32.tbl | 1 + > arch/x86/syscalls/syscall_64.tbl | 1 + > fs/fcntl.c | 5 + > include/linux/shmem_fs.h | 20 + > include/linux/syscalls.h | 1 + > include/uapi/linux/fcntl.h | 15 + > include/uapi/linux/memfd.h | 10 + >
Re: [PATCH RFC net-next] tracing: accelerate tracing filters with BPF
* Alexei Starovoitov wrote: > On Tue, May 13, 2014 at 8:07 PM, Steven Rostedt wrote: > > On Tue, 13 May 2014 19:55:11 -0700 > > Alexei Starovoitov wrote: > > > >> --- a/kernel/trace/Kconfig > >> +++ b/kernel/trace/Kconfig > >> @@ -79,6 +79,7 @@ config FTRACE_NMI_ENTER > >> default y > >> > >> config EVENT_TRACING > >> + depends on NET > >> select CONTEXT_SWITCH_TRACER > >> bool > >> > > > > This part makes me a little nervous. I know a lot of embedded devices > > depend on tracing, but do they all have network? > > I think we may want to split BPF into its own config, since it doesn't > really depend on anything in net. Exactly, that's a good plan. 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 02/34] kbuild: Introduce KCONFIG_AUTOCONFIGDEP variable for conf tool
On Wed, May 14, 2014 at 12:02:57AM +0200, Alexis Berlemont wrote: > From: Jiri Olsa > > Introducing KCONFIG_AUTOCONFIGDEP variable for conf tool > allowing to specify custom auto.conf.cmd file. The change looks good at it complments what we already have of overrides. But please document this in Documentation/kbuild/... Sam -- 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 01/34] kbuild: Introduce KBUILD_AUTOCONF variable for auto.conf include
On Wed, May 14, 2014 at 12:02:56AM +0200, Alexis Berlemont wrote: > From: Jiri Olsa > > Introducing KBUILD_AUTOCONF variable for auto.conf include > allowing to specify custom auto.conf file. What do you need this for? And please remember to documet this variable in Documentation/kbuild/... Have you considered to let kbuild use KCONFIG_AUTOCONFIG that is already used by kconfig for the same purpose? Sam -- 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/9] perf, tools: Add jsmn `jasmine' JSON parser
On Wed, May 14, 2014 at 12:25:44PM +0900, Namhyung Kim wrote: > Hi Andi, > > On Mon, 12 May 2014 15:51:06 -0700, Andi Kleen wrote: > > From: Andi Kleen > > > > I need a JSON parser. This adds the simplest JSON > > parser I could find -- Serge Zaitsev's jsmn `jasmine' -- > > to the perf library. I merely converted it to (mostly) > > Linux style and added support for non 0 terminated input. > > It seems like the original code now also supports it. Sorry I don't want to fork this code. I think we're better of staying near upstream than trying to fix all those (unimportant) nit-picks. Please only point out real errors. Also the code is intentionally not trying to have a lot of dependencies on perf infrastructure. -Andi -- 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] workqueue: Remove deprecated system_nrt[_freezable]_wq
system_nrt[_freezable]_wq were deprecated by 3b07e9c ("workqueue:
deprecate system_nrt[_freezable]_wq") and have been deprecated
for a long time. In addition, these are not used anymore. So,
let's remove these functions.
Signed-off-by: Jingoo Han
---
include/linux/workqueue.h | 14 --
1 file changed, 14 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 1b22c42..11dcc89 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -364,20 +364,6 @@ extern struct workqueue_struct *system_freezable_wq;
extern struct workqueue_struct *system_power_efficient_wq;
extern struct workqueue_struct *system_freezable_power_efficient_wq;
-static inline struct workqueue_struct * __deprecated __system_nrt_wq(void)
-{
- return system_wq;
-}
-
-static inline struct workqueue_struct * __deprecated
__system_nrt_freezable_wq(void)
-{
- return system_freezable_wq;
-}
-
-/* equivlalent to system_wq and system_freezable_wq, deprecated */
-#define system_nrt_wq __system_nrt_wq()
-#define system_nrt_freezable_wq__system_nrt_freezable_wq()
-
extern struct workqueue_struct *
__alloc_workqueue_key(const char *fmt, unsigned int flags, int max_active,
struct lock_class_key *key, const char *lock_name, ...) __printf(1, 6);
--
1.7.10.4
--
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 RESEND] rapidio/tsi721: Use pci_enable_msix_exact() instead of pci_enable_msix()
On Tue, May 13, 2014 at 02:46:34PM -0700, Andrew Morton wrote: > On Tue, 13 May 2014 17:01:32 +0200 Alexander Gordeev > wrote: > > > As result of deprecation of MSI-X/MSI enablement functions > > pci_enable_msix() and pci_enable_msi_block() all drivers > > using these two interfaces need to be updated to use the > > new pci_enable_msi_range() or pci_enable_msi_exact() > > and pci_enable_msix_range() or pci_enable_msix_exact() > > interfaces. > > > > What (if any) runtime effect does this patch have? None. -- Regards, Alexander Gordeev agord...@redhat.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 v3 0/3] TI CPSW Cleanup
From: George Cherian Date: Mon, 12 May 2014 10:21:18 +0530 > This series does some minimal cleanups. > -Conversion of pr_*() to dev_*() > -Convert kzalloc to devm_kzalloc. Series applied to net-next, 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] workqueue: Remove deprecated flush[_delayed]_work_sync()
flush[_delayed]_work_sync() were deprecated by 4382973 ("workqueue:
deprecate flush[_delayed]_work_sync()") and have been deprecated
for a long time. In addition, these are not used anymore. So,
let's remove these functions.
Signed-off-by: Jingoo Han
---
include/linux/workqueue.h | 12
1 file changed, 12 deletions(-)
diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index 1b22c42..aa92d02 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -587,18 +587,6 @@ static inline bool keventd_up(void)
return system_wq != NULL;
}
-/* used to be different but now identical to flush_work(), deprecated */
-static inline bool __deprecated flush_work_sync(struct work_struct *work)
-{
- return flush_work(work);
-}
-
-/* used to be different but now identical to flush_delayed_work(), deprecated
*/
-static inline bool __deprecated flush_delayed_work_sync(struct delayed_work
*dwork)
-{
- return flush_delayed_work(dwork);
-}
-
#ifndef CONFIG_SMP
static inline long work_on_cpu(int cpu, long (*fn)(void *), void *arg)
{
--
1.7.10.4
--
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 v4] gcov: add support for GCC 4.9
From: Yuan Pengfei
This patch handles the gcov-related changes in GCC 4.9:
A new counter (time profile) is added. The total number is 9 now.
A new profile merge function __gcov_merge_time_profile is added.
See gcc/gcov-io.h and libgcc/libgcov-merge.c
For the first change, the layout of struct gcov_info is affected.
For the second one, a dummy function is added to kernel/gcov/base.c similarly.
Signed-off-by: Yuan Pengfei
---
kernel/gcov/base.c| 6 ++
kernel/gcov/gcc_4_7.c | 5 +
2 files changed, 11 insertions(+)
diff --git a/kernel/gcov/base.c b/kernel/gcov/base.c
index f45b75b..b358a80 100644
--- a/kernel/gcov/base.c
+++ b/kernel/gcov/base.c
@@ -85,6 +85,12 @@ void __gcov_merge_ior(gcov_type *counters, unsigned int
n_counters)
}
EXPORT_SYMBOL(__gcov_merge_ior);
+void __gcov_merge_time_profile(gcov_type *counters, unsigned int n_counters)
+{
+ /* Unused. */
+}
+EXPORT_SYMBOL(__gcov_merge_time_profile);
+
/**
* gcov_enable_events - enable event reporting through gcov_event()
*
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index 7465944..7f74b59 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -18,7 +18,12 @@
#include
#include "gcov.h"
+#if __GNUC__ == 4 && __GNUC_MINOR__ >= 9
+#define GCOV_COUNTERS 9
+#else
#define GCOV_COUNTERS 8
+#endif
+
#define GCOV_TAG_FUNCTION_LENGTH 3
static struct gcov_info *gcov_info_head;
--
2.0.0.rc2
--
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: [PATCHSET cgroup/for-3.16] cgroup: iterate cgroup_subsys_states directly
Hi Tejun, On 2014/5/10 5:31, Tejun Heo wrote: > Hello, > > Currently, while csses (cgroup_subsys_states) have ->parent linkage > too, only cgroups form full tree through their ->children and > ->sibling fields and css iterations naturally is implemented by > iterating cgroups and then dereferencing the css for the specified > subsystem. > > There are now use cases where controllers need to iterate through > csses regardless of their online state as long as they have positive What use cases are we talking about here? > reference. This can't easily be achieved by iterating cgroups because > its css pointer array needs to be cleared on offline and there may be > multiple dying csses for a cgroup for the same subsystem and there's > only one pointer per cgroup-subsystem pair. > -- 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] gcov: add support for GCC 4.9
> > > > +void __gcov_merge_time_profile(gcov_type *counters, unsigned int > > n_counters) > > But can you repost please without word wrapping? > > Except for that the patch looks good to me. Sorry. I will configure my email client and send again. -- Yuan, Pengfei Peking University, China -- 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/3] mm: use a light-weight __mod_zone_page_state in mlocked_vma_newpage()
On Tue, 13 May 2014, Jianyu Zhan wrote:
> Andrew, since the previous patch
>
> [PATCH 1/3] mm: add comment for __mod_zone_page_stat
>
> is updated, update this one accordingly.
>
> -<8-
> From 9701fbdb3f9e7730b89780a5bf22effd1580cf35 Mon Sep 17 00:00:00 2001
> From: Jianyu Zhan
> Date: Tue, 13 May 2014 01:48:01 +0800
> Subject: [PATCH] mm: fold mlocked_vma_newpage() into its only call site
>
> In previous commit(mm: use the light version __mod_zone_page_state in
> mlocked_vma_newpage()) a irq-unsafe __mod_zone_page_state is used.
> And as suggested by Andrew, to reduce the risks that new call sites
> incorrectly using mlocked_vma_newpage() without knowing they are adding
> racing, this patch folds mlocked_vma_newpage() into its only call site,
> page_add_new_anon_rmap, to make it open-cocded for people to know what
> is going on.
>
> Suggested-by: Andrew Morton
> Suggested-by: Hugh Dickins
> Signed-off-by: Jianyu Zhan
Acked-by: Hugh Dickins
Yes, much better, thanks: you made and commented the __ change in the
previous patch, and now you just do the move. I'd have probably moved
the VM_BUG_ON_PAGE(PageLRU,) up to the top of page_add_new_anon_rmap(),
where we already document some expectations on entry (or else removed it
completely, given that lru_cache_add() does the same); but that's a nit,
no need to make further change now.
> ---
> mm/internal.h | 29 -
> mm/rmap.c | 20 +---
> 2 files changed, 17 insertions(+), 32 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index d6a4868..29f3dc8 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -184,31 +184,6 @@ static inline void munlock_vma_pages_all(struct
> vm_area_struct *vma)
> }
>
> /*
> - * Called only in fault path, to determine if a new page is being
> - * mapped into a LOCKED vma. If it is, mark page as mlocked.
> - */
> -static inline int mlocked_vma_newpage(struct vm_area_struct *vma,
> - struct page *page)
> -{
> - VM_BUG_ON_PAGE(PageLRU(page), page);
> -
> - if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) != VM_LOCKED))
> - return 0;
> -
> - if (!TestSetPageMlocked(page)) {
> - /*
> - * We use the irq-unsafe __mod_zone_page_stat because
> - * this counter is not modified from interrupt context, and the
> - * pte lock is held(spinlock), which implies preemption
> disabled.
> - */
> - __mod_zone_page_state(page_zone(page), NR_MLOCK,
> - hpage_nr_pages(page));
> - count_vm_event(UNEVICTABLE_PGMLOCKED);
> - }
> - return 1;
> -}
> -
> -/*
> * must be called with vma's mmap_sem held for read or write, and page
> locked.
> */
> extern void mlock_vma_page(struct page *page);
> @@ -250,10 +225,6 @@ extern unsigned long vma_address(struct page *page,
>struct vm_area_struct *vma);
> #endif
> #else /* !CONFIG_MMU */
> -static inline int mlocked_vma_newpage(struct vm_area_struct *v, struct page
> *p)
> -{
> - return 0;
> -}
> static inline void clear_page_mlock(struct page *page) { }
> static inline void mlock_vma_page(struct page *page) { }
> static inline void mlock_migrate_page(struct page *new, struct page *old) { }
> diff --git a/mm/rmap.c b/mm/rmap.c
> index fa73194..386b78f 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1029,11 +1029,25 @@ void page_add_new_anon_rmap(struct page *page,
> __mod_zone_page_state(page_zone(page), NR_ANON_PAGES,
> hpage_nr_pages(page));
> __page_set_anon_rmap(page, vma, address, 1);
> - if (!mlocked_vma_newpage(vma, page)) {
> +
> + VM_BUG_ON_PAGE(PageLRU(page), page);
> + if (likely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) != VM_LOCKED)) {
> SetPageActive(page);
> lru_cache_add(page);
> - } else
> - add_page_to_unevictable_list(page);
> + return;
> + }
> +
> + if (!TestSetPageMlocked(page)) {
> + /*
> + * We use the irq-unsafe __mod_zone_page_stat because
> + * this counter is not modified from interrupt context, and the
> + * pte lock is held(spinlock), which implies preemption
> disabled.
> + */
> + __mod_zone_page_state(page_zone(page), NR_MLOCK,
> + hpage_nr_pages(page));
> + count_vm_event(UNEVICTABLE_PGMLOCKED);
> + }
> + add_page_to_unevictable_list(page);
> }
>
> /**
> --
> 2.0.0-rc1
--
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] sched: wake up task on prev_cpu if not in SD_WAKE_AFFINE domain with cpu
On Tue, 2014-05-13 at 10:08 -0400, Rik van Riel wrote: > OK, after doing some other NUMA stuff, and then looking at the scheduler > again with a fresh mind, I have drawn some more conclusions about what > the scheduler does, and how it breaks NUMA locality :) > > 1) If the node_distance between nodes on a NUMA system is ><= RECLAIM_DISTANCE, we will call select_idle_sibling for >a wakeup of a previously existing task (SD_BALANCE_WAKE) > > 2) If the node distance exceeds RECLAIM_DISTANCE, we will >wake up a task on prev_cpu, even if it is not currently >idle > >This behaviour only happens on certain large NUMA systems, >and is different from the behaviour on small systems. >I suspect we will want to call select_idle_sibling with >prev_cpu in case target and prev_cpu are not in the same >SD_WAKE_AFFINE domain. Sometimes. It's the same can of worms remote as it is local.. latency gain may or may not outweigh cache miss pain. > 3) If wake_wide is false, we call select_idle_sibling with >the CPU number of the code that is waking up the task > > 4) If wake_wide is true, we call select_idle_sibling with >the CPU number the task was previously running on (prev_cpu) > >In effect, the "wake task on waking task's CPU" behaviour >is the default, regardless of how frequently a task wakes up >its wakee, and regardless of impact on NUMA locality. > >This may need to be changed. That behavior also improves the odds of communicating tasks sharing a cache though. > Am I overlooking anything? No, I think you're seeing where the worms live. > What benchmarks should I run to test any changes I make? Mixed bag, it'll affects all, bursty, static, ramp up/down. -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/
Re: [PATCH 1/3] mm: add comment for __mod_zone_page_stat
On Tue, 13 May 2014, Jianyu Zhan wrote:
> >> This means they guarantee that even they are preemted the vm
> >> counter won't be modified incorrectly. Because the counter is page-related
> >> (e.g., a new anon page added), and they are exclusively hold the pte lock.
> >
> >But there are multiple pte locks for numerous page. Another process could
> >modify the counter because the pte lock for a different page was
> >available which would cause counter corruption.
> >
> >
> >> So, as you concludes in the other mail that __modd_zone_page_stat
> >> couldn't be used.
> >> in mlocked_vma_newpage, then what qualifies other call sites for using
> >> it, in the same situation?
>
> Thanks, now everything is clear.
>
> I've renewed the patch, would you please review it? Thanks!
>
> ---<8---
> mm: use the light version __mod_zone_page_state in mlocked_vma_newpage()
>
> mlocked_vma_newpage() is called with pte lock held(a spinlock), which
> implies preemtion disabled, and the vm stat counter is not modified from
> interrupt context, so we need not use an irq-safe mod_zone_page_state() here,
> using a light-weight version __mod_zone_page_state() would be OK.
>
> This patch also documents __mod_zone_page_state() and some of its
> callsites. The comment above __mod_zone_page_state() is from Hugh
> Dickins, and acked by Christoph.
>
> Most credits to Hugh and Christoph for the clarification on the usage of
> the __mod_zone_page_state().
>
> Suggested-by: Andrew Morton
> Signed-off-by: Hugh Dickins
No, I didn't sign it off, just offered some text (which you already
acknowledged graciously). Andrew, please delete that line, but...
> Signed-off-by: Jianyu Zhan
Acked-by: Hugh Dickins
Yes, this is good - and even better is the version which Andrew
has slipped into mmotm, removing the duplicated comment line from
page_remove_rmap(), and reformatting the comments to fit better.
It is a little random, in that we can easily see other
__mod_zone_page_states to which the same comment could be applied;
but that's okay, please leave it as is, you've made the point enough
to help other people get it, and it would get boring to repeat it more.
Hugh
> ---
> mm/internal.h | 7 ++-
> mm/rmap.c | 10 ++
> mm/vmstat.c | 4 +++-
> 3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 07b6736..53d439e 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -196,7 +196,12 @@ static inline int mlocked_vma_newpage(struct
> vm_area_struct *vma,
> return 0;
>
> if (!TestSetPageMlocked(page)) {
> - mod_zone_page_state(page_zone(page), NR_MLOCK,
> + /*
> + * We use the irq-unsafe __mod_zone_page_stat because
> + * this counter is not modified from interrupt context, and the
> + * pte lock is held(spinlock), which implies preemtion disabled.
> + */
> + __mod_zone_page_state(page_zone(page), NR_MLOCK,
> hpage_nr_pages(page));
> count_vm_event(UNEVICTABLE_PGMLOCKED);
> }
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 9c3e773..2fa4375 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -986,6 +986,11 @@ void do_page_add_anon_rmap(struct page *page,
> {
> int first = atomic_inc_and_test(>_mapcount);
> if (first) {
> + /*
> + * We use the irq-unsafe __{inc|mod}_zone_page_stat because
> + * these counters are not modified in interrupt context, and
> + * pte lock(a spinlock) is held, which implies preemtion
> disabled.
> + */
> if (PageTransHuge(page))
> __inc_zone_page_state(page,
> NR_ANON_TRANSPARENT_HUGEPAGES);
> @@ -1077,6 +1082,11 @@ void page_remove_rmap(struct page *page)
> /*
>* Hugepages are not counted in NR_ANON_PAGES nor NR_FILE_MAPPED
>* and not charged by memcg for now.
> + *
> + * We use the irq-unsafe __{inc|mod}_zone_page_stat because
> + * these counters are not modified in interrupt context, and
> + * these counters are not modified in interrupt context, and
> + * pte lock(a spinlock) is held, which implies preemtion disabled.
>*/
> if (unlikely(PageHuge(page)))
> goto out;
> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index 302dd07..704928e 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -207,7 +207,9 @@ void set_pgdat_percpu_threshold(pg_data_t *pgdat,
> }
>
> /*
> - * For use when we know that interrupts are disabled.
> + * For use when we know that interrupts are disabled,
> + * or when we know that preemption is disabled and that
> + * particular counter cannot be updated from interrupt context.
> */
> void __mod_zone_page_state(struct zone *zone, enum zone_stat_item item,
> int delta)
> --
> 2.0.0-rc1
--
To unsubscribe
Re: [PATCH 01/25] asm-generic: Change time_t and clock_t to 64 bit
On 05/13/2014 03:22 AM, James Hogan wrote: >> When we export this posix_types.h file for user software, they need to >> define this config, eg: CONFIG_32BIT_TIME to use 32 bit time. Is this >> what we want to do? > > Yeh, good point, that won't work. How about: #include The asm-generic/types/ directory can be used for all kinds of type templates, like int-ll64.h and the (now removed) former int-l64.h. -hpa -- 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/2] mm/page_alloc: DEBUG_VM checks for free_list placement of CMA and RESERVE pages
On 05/05/2014 11:50 AM, Vlastimil Babka wrote: > So in the end this VM_DEBUG check probably cannot work anymore for > MIGRATE_RESERVE, only for CMA. I'm not sure if it's worth keeping it only for > CMA, what are the CMA guys' opinions on that? The way I understood it is that this patch is wrong, but it's still alive in -mm. Should it still be there? Thanks, Sasha -- 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: tegra: enable console framebuffer rotation
On 05/13/2014 08:00 PM, Alexandre Courbot wrote: ... > Both SHIELD and TN7 come with a locked bootloader and cannot use U-boot. > The bootloader can only boot a kernel from a dedicated, raw boot > partition (Android style), can only pass a device tree from another raw > "dtb" partition, and will fill it with plenty of dirty command-line > options that make mainline unusable. That seems to be a lot for distros > to handle, so at this stage we'd rather advise users to use a root FS > image of their favorite distro along with a self-compiled kernel. I don't know how much effort it's worth putting into this, but it /might/ be possible to port U-Boot to the devices, and use that as the "kernel" image that the binary bootloader boots, and then have U-Boot boot a kernel from a filesystem in the "normal" way. That's kind what I did by porting U-Boot to the Raspberry Pi. It would certainly increase the possibility of a distro supporting these devices in a generic way, as well as avoiding the need for hard-coded command-lines, memory layout, etc. in the DT files. We'd have to make sure that any installer didn't change the GPT layout, since then it'd get out of sync with the tegrapt partitions, which could cause the bootloader to fail. -- 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: dts: am335x-bone-common: Add i2c2 definition
Hi John,
On May 13, 2014, at 1:24 PM, John Syn wrote:
>
> On 5/13/14, 10:51 AM, "Javier Martinez Canillas"
> wrote:
>
>> Hello Pantelis,
>>
>> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
>> wrote:
>>> Hi Javier,
>>>
>>> On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
>>>
On Tue, May 13, 2014 at 4:22 PM, Matt Porter
wrote:
> On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas
> wrote:
>> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote:
>>> On 05/12/2014 04:57 PM, Robert Nelson wrote:
>> Either case if fine with me. As who knows when the dtc
>> "overlay" will
>> every truly make it mainline, as the capemgr was the only real
>> kernel
>> user of the i2c/at24 eeprom information.
>
> Sounds like we should keep it disabled though so u-boot can be
> used
> to toggle it while waiting for the capemgr. That's because the
> board
> has a header for pins, so it's not exactly limited to just the
> capes.
>
> Anybody working on enabling/disabling cape dtb configurations in
> u-boot?
Well,
Would Tom even approve of that in mainline u-boot? He didn't want
my
"invert" the gpio to enable the usb hub on the older beagle xm
A/B..
http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>>
>> Using fdt set from the bootloader to use the same FDT for similar
>> boards (like the example with Beagle xM variants) is kind of trying
>> to
>> replicate what we used to do from boards files where it was possible
>> to manage a set of boards using the same platform code.
>>
>> But Device Trees are meant to describe hardware and thus should be
>> static, if two board are almost identical but slightly different,
>> then
>> are two different hardware where each need its proper FDT that
>> describes it.
>>
>>>
>>> I would think that using the 'fdt' command in U-Boot to add all
>>> properties of every cape found on a running system would drive
>>> someone
>>> to madness quite quickly. Moving all of Pantelis' work for dynamic
>>> device trees from the kernel to N bootloaders (U-Boot, barebox,
>>> UEFI,
>>> etc) sounds like a step in the wrong direction.
>>>
>>
>> Agreed. I think that until the device tree overlay and the cape
>> manager find their way into mainline we should treat capes as if they
>> were expansion boards attached to a Computer-on-Module. That is, a
>> static based board which its own DTS including the BB{B,W} as an dtsi
>> and not something that can be added on runtime.
>
> It's far more complicated than a SOM plus carrier board. Consider that
> you can have any 4 of these capes stacked on the BBB/BBW in any
> combination (assuming no resource conflicts). Capturing all possible
> combinations in static dtsis is not practical.
>
>>>
>>> Since this appears to be all coming back to DT overlays, let me try to
>>> address some points.
>>>
>>
>> It seems that you misunderstood my comments. I do think that DT
>> overlays and the cape manager are a great solution for any hardware
>> that could be expanded on runtime and I really hope that they can
>> eventually land into mainline.
>>
>> In fact if you look on my previous mail you will see that I said:
>> "until device tree overlay and the cape manager find their way into
>> mainline..."
>>
Right, I forgot that the capes were stackable so is indeed not
practical to model every single combination as DTS in mainline. Even
if stacking was not possible there are just too many capes out there
to have a DTS for every single cape.
>>>
>>> Each cape does have a DTS as dynamically loaded fragment; it works
>>> absolutely fine.
>>>
>>> Trying to come up with a base DTS for all the capes you've stacked up
>>> is an exponential problem.
>>>
My point was that someone who wants to use a BBB + a set of capes can
today write a DTS for its own stacked setup.
>>>
>>> No, the guy that designs a cape (or learns how to) can not write a DTS
>>> for
>>> the base board and the cape in question. Doing that he essentially cuts
>>> himself off from the community.
>>>
>>> Let me explain, the point is for people to easily design capes,
>>> open-source their
>>> design as well as their software, and share them to the community.
>>>
>>> This requires that things are easily shareable.
>>>
>>> Requiring a relative newbie in kernel development not only generate his
>>> own
>>> base DT, but also to merge all of the other capes DT into his own is a
>>> nightmare.
>>>
>>> BTW, on another tangent, it's not just the BB people that care about
>>> dynamic
>>>
[PATCH 24/25] x86: Add 32 bit time_t and clock_t
Override time_t and clock_t in include/uapi/asm-generic. Signed-off-by: Ley Foon Tan --- arch/x86/include/uapi/asm/posix_types_32.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/include/uapi/asm/posix_types_32.h b/arch/x86/include/uapi/asm/posix_types_32.h index 8e52505..b6b7e3b 100644 --- a/arch/x86/include/uapi/asm/posix_types_32.h +++ b/arch/x86/include/uapi/asm/posix_types_32.h @@ -20,6 +20,12 @@ typedef unsigned short __kernel_gid_t; typedef unsigned short __kernel_old_dev_t; #define __kernel_old_dev_t __kernel_old_dev_t +typedef long __kernel_time_t; +#define __kernel_time_t __kernel_time_t + +typedef long __kernel_clock_t; +#define __kernel_clock_t __kernel_clock_t + #include #endif /* _ASM_X86_POSIX_TYPES_32_H */ -- 1.8.2.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] mm: remap_file_pages: grab file ref to prevent race while mmaping
A file reference should be held while a file is mmaped, otherwise it might
be freed while being used.
Suggested-by: Hugh Dickins
Signed-off-by: Sasha Levin
---
mm/mmap.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/mm/mmap.c b/mm/mmap.c
index 2a0e0a8..da3c212 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2593,6 +2593,7 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start,
unsigned long, size,
struct vm_area_struct *vma;
unsigned long populate = 0;
unsigned long ret = -EINVAL;
+ struct file *file;
pr_warn_once("%s (%d) uses deprecated remap_file_pages() syscall. "
"See Documentation/vm/remap_file_pages.txt.\n",
@@ -2636,8 +2637,10 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, start,
unsigned long, size,
munlock_vma_pages_range(vma, start, start + size);
}
+ file = get_file(vma->vm_file);
ret = do_mmap_pgoff(vma->vm_file, start, size,
prot, flags, pgoff, );
+ fput(file);
out:
up_write(>mmap_sem);
if (populate)
--
1.7.10.4
--
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] net: Use a more standard macro for INET_ADDR_COOKIE
Missing a colon on definition use is a bit odd so
change the macro for the 32 bit case to declare an
__attribute__((unused)) and __deprecated variable.
The __deprecated attribute will cause gcc to emit
an error if the variable is actually used.
Signed-off-by: Joe Perches
---
include/net/inet_hashtables.h | 8 +---
net/ipv4/inet_hashtables.c| 4 ++--
net/ipv4/udp.c| 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 1bdb477..dd1950a 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -292,12 +292,12 @@ static inline struct sock *inet_lookup_listener(struct
net *net,
#define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
const __addrpair __name = (__force __addrpair) ( \
(((__force __u64)(__be32)(__saddr)) << 32) |
\
- ((__force __u64)(__be32)(__daddr)));
+ ((__force __u64)(__be32)(__daddr)))
#else /* __LITTLE_ENDIAN */
#define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
const __addrpair __name = (__force __addrpair) ( \
(((__force __u64)(__be32)(__daddr)) << 32) |
\
- ((__force __u64)(__be32)(__saddr)));
+ ((__force __u64)(__be32)(__saddr)))
#endif /* __BIG_ENDIAN */
#define INET_MATCH(__sk, __net, __cookie, __saddr, __daddr, __ports, __dif)
\
(((__sk)->sk_portpair == (__ports)) && \
@@ -306,7 +306,9 @@ static inline struct sock *inet_lookup_listener(struct net
*net,
((__sk)->sk_bound_dev_if == (__dif)))&& \
net_eq(sock_net(__sk), (__net)))
#else /* 32-bit arch */
-#define INET_ADDR_COOKIE(__name, __saddr, __daddr)
+#define INET_ADDR_COOKIE(__name, __saddr, __daddr) \
+ const int __name __deprecated __attribute__((unused))
+
#define INET_MATCH(__sk, __net, __cookie, __saddr, __daddr, __ports, __dif) \
(((__sk)->sk_portpair == (__ports)) && \
((__sk)->sk_daddr == (__saddr)) && \
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 8b9cf27..c080aef 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -274,7 +274,7 @@ struct sock *__inet_lookup_established(struct net *net,
const __be32 daddr, const u16 hnum,
const int dif)
{
- INET_ADDR_COOKIE(acookie, saddr, daddr)
+ INET_ADDR_COOKIE(acookie, saddr, daddr);
const __portpair ports = INET_COMBINED_PORTS(sport, hnum);
struct sock *sk;
const struct hlist_nulls_node *node;
@@ -327,7 +327,7 @@ static int __inet_check_established(struct
inet_timewait_death_row *death_row,
__be32 daddr = inet->inet_rcv_saddr;
__be32 saddr = inet->inet_daddr;
int dif = sk->sk_bound_dev_if;
- INET_ADDR_COOKIE(acookie, saddr, daddr)
+ INET_ADDR_COOKIE(acookie, saddr, daddr);
const __portpair ports = INET_COMBINED_PORTS(inet->inet_dport, lport);
struct net *net = sock_net(sk);
unsigned int hash = inet_ehashfn(net, daddr, lport,
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 54ea0a3..f3ce8d0 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1875,7 +1875,7 @@ static struct sock *__udp4_lib_demux_lookup(struct net
*net,
unsigned int hash2 = udp4_portaddr_hash(net, loc_addr, hnum);
unsigned int slot2 = hash2 & udp_table.mask;
struct udp_hslot *hslot2 = _table.hash2[slot2];
- INET_ADDR_COOKIE(acookie, rmt_addr, loc_addr)
+ INET_ADDR_COOKIE(acookie, rmt_addr, loc_addr);
const __portpair ports = INET_COMBINED_PORTS(rmt_port, hnum);
rcu_read_lock();
--
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 net-next] tracing: accelerate tracing filters with BPF
On Tue, May 13, 2014 at 8:17 PM, Steven Rostedt wrote: > On Tue, 13 May 2014 19:55:11 -0700 > Alexei Starovoitov wrote: > >> Tracing filters are parsing user supplied character string and constructing >> a predicate tree. filter_match_preds() was used to walk nodes of the tree to >> simulate matching of boolean expression. >> > > I applied this on top of net-next, from: > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > (master branch) > > and got this compile error: Sorry I wasn't clear in the log. This patch depends on JIT patches that were posted separately. Since this one is RFC, I didn't want to mix them. JIT patches: http://patchwork.ozlabs.org/patch/348558/ http://patchwork.ozlabs.org/patch/348559/ http://patchwork.ozlabs.org/patch/348560/ > kernel/trace/trace_events_filter.c: In function ‘emit_cond’: > kernel/trace/trace_events_filter.c:1361:36: error: ‘__bpf_call_base’ > undeclared (first use in this function) > kernel/trace/trace_events_filter.c:1361:36: note: each undeclared identifier > is reported only once for each function it appears in > kernel/trace/trace_events_filter.c: In function ‘filter_gen_bpf’: > kernel/trace/trace_events_filter.c:1622:2: error: implicit declaration of > function ‘bpf_int_jit_compile’ [-Werror=implicit-function-declaration] > > Config attached. > > -- Steve -- 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: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
On 05/13/2014 10:23 PM, Peter Zijlstra wrote: [snip] > > The point remains though, don't use massive and awkward software stacks > that are impossible to operate. > > I you want to investigate !spinners, replace the ABC with slightly more > complex loads like: https://lkml.org/lkml/2012/6/18/212 That's what we need, may be a little reform to enable multi-threads, or may be add some locks... anyway, will redo the test and see what we could found :) Regards, Michael Wang > -- > 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/ > -- 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 net-next] tracing: accelerate tracing filters with BPF
On Tue, May 13, 2014 at 8:07 PM, Steven Rostedt wrote: > On Tue, 13 May 2014 19:55:11 -0700 > Alexei Starovoitov wrote: > >> --- a/kernel/trace/Kconfig >> +++ b/kernel/trace/Kconfig >> @@ -79,6 +79,7 @@ config FTRACE_NMI_ENTER >> default y >> >> config EVENT_TRACING >> + depends on NET >> select CONTEXT_SWITCH_TRACER >> bool >> > > This part makes me a little nervous. I know a lot of embedded devices > depend on tracing, but do they all have network? I think we may want to split BPF into its own config, since it doesn't really depend on anything in net. > They may, but I would like to hear from others in the embedded space. > > -- Steve -- 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: mm: shmem: NULL ptr deref in shmem_fault
On 05/13/2014 06:20 PM, Hugh Dickins wrote: > I haven't delved into the perf_even_mmap d_path (fs/dcache.c:2947) one, > but the Sys_mremap one on file->f_op->f_unmapped_area sounds like what > we have here: struct file has been freed. > > I believe Al is innocent: I point a quivering finger at... Kirill. > > Just guessing, but we know how fond trinity is of remap_file_pages(), > and comparing old and new emulations shows that interesting > > struct file *file = get_file(vma->vm_file); > addr = mmap_region(...); > fput(file); > > in mm/fremap.c's old emulation, but no get_file() and fput() around > the do_mmap_pgoff() in mm/mmap.c's new emulation. > > Before it puts in the new, do_mmap_pgoff() might unmap the last reference > to vma->vm_file, so emulation needs to take its own reference. I'm not > sure how that plays out nowadays with Al's deferred fput, but it does > look suspicious to me. I've tested it by reverting the remap_file_pages() patch, and the problem seems to have disappeared. Then, I've added it back again, wrapping the do_mmap_pgoff() call with get_file() and fput(), and the problem is still gone. Seems like that was the issue all along. I'll send a patch... Thanks, Sasha -- 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/9] perf, tools: Add jsmn `jasmine' JSON parser
Hi Andi,
On Mon, 12 May 2014 15:51:06 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> I need a JSON parser. This adds the simplest JSON
> parser I could find -- Serge Zaitsev's jsmn `jasmine' --
> to the perf library. I merely converted it to (mostly)
> Linux style and added support for non 0 terminated input.
It seems like the original code now also supports it.
>
> The parser is quite straight forward and does not
> copy any data, just returns tokens with offsets
> into the input buffer. So it's relatively efficient
> and simple to use.
>
> The code is not fully checkpatch clean, but I didn't
> want to completely fork the upstream code.
>
> Original source: http://zserge.bitbucket.org/jsmn.html
>
> In addition I added a simple wrapper that mmaps a json
> file and provides some straight forward access functions.
I know you just ported the original source to perf, but there's some
nitpicks I'd like to point out anyway.. ;-)
>
> Used in follow-on patches to parse event files.
>
> Signed-off-by: Andi Kleen
> ---
> tools/perf/Makefile.perf | 4 +
> tools/perf/util/jsmn.c | 297
> +++
> tools/perf/util/jsmn.h | 65 +++
> tools/perf/util/json.c | 155 +
> tools/perf/util/json.h | 13 +++
> 5 files changed, 534 insertions(+)
> create mode 100644 tools/perf/util/jsmn.c
> create mode 100644 tools/perf/util/jsmn.h
> create mode 100644 tools/perf/util/json.c
> create mode 100644 tools/perf/util/json.h
>
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 2baf61c..43d4109 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -300,6 +300,8 @@ LIB_H += ui/progress.h
> LIB_H += ui/util.h
> LIB_H += ui/ui.h
> LIB_H += util/data.h
> +LIB_H += util/jsmn.h
> +LIB_H += util/json.h
>
> LIB_OBJS += $(OUTPUT)util/abspath.o
> LIB_OBJS += $(OUTPUT)util/alias.o
> @@ -373,6 +375,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
> LIB_OBJS += $(OUTPUT)util/record.o
> LIB_OBJS += $(OUTPUT)util/srcline.o
> LIB_OBJS += $(OUTPUT)util/data.o
> +LIB_OBJS += $(OUTPUT)util/jsmn.o
> +LIB_OBJS += $(OUTPUT)util/json.o
>
> LIB_OBJS += $(OUTPUT)ui/setup.o
> LIB_OBJS += $(OUTPUT)ui/helpline.o
> diff --git a/tools/perf/util/jsmn.c b/tools/perf/util/jsmn.c
> new file mode 100644
> index 000..3e4b711
> --- /dev/null
> +++ b/tools/perf/util/jsmn.c
> @@ -0,0 +1,297 @@
> +/*
> + * Copyright (c) 2010 Serge A. Zaitsev
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> + * of this software and associated documentation files (the "Software"), to
> deal
> + * in the Software without restriction, including without limitation the
> rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> THE
> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + *
> + * Slightly modified by AK to not assume 0 terminated input.
> + */
> +
> +#include
> +#include "jsmn.h"
> +
> +/*
> + * Allocates a fresh unused token from the token pull.
s/pull/pool/ ?
> + */
> +static jsmntok_t *jsmn_alloc_token(jsmn_parser *parser,
> +jsmntok_t *tokens, size_t num_tokens)
> +{
> + jsmntok_t *tok;
> +
> + if ((unsigned)parser->toknext >= num_tokens)
> + return NULL;
> + tok = [parser->toknext++];
> + tok->start = tok->end = -1;
> + tok->size = 0;
> + return tok;
> +}
> +
> +/*
> + * Fills token type and boundaries.
> + */
> +static void jsmn_fill_token(jsmntok_t *token, jsmntype_t type,
> + int start, int end)
> +{
> + token->type = type;
> + token->start = start;
> + token->end = end;
> + token->size = 0;
I think setting size to 0 is not needed here.
> +}
> +
> +/*
> + * Fills next available token with JSON primitive.
> + */
> +static jsmnerr_t jsmn_parse_primitive(jsmn_parser *parser, const char *js,
> + size_t len,
> + jsmntok_t *tokens, size_t num_tokens)
> +{
> + jsmntok_t *token;
> + int start;
> +
> + start = parser->pos;
> +
> + for (; parser->pos < len; parser->pos++) {
> + switch (js[parser->pos]) {
> +#ifndef
[PATCH] dma: pl330: Add support for DMA_PAUSE command
While playing back audio, pmc_dmaengine requests the DMA channel to
stop DMA transmission through DMA_PAUSE command.
Currently PL330 driver doesn't support DMA pause command, leaving
the DMA state inconsistent when the system resumes. Instead, it would
be better to terminate the DMA transfer during suspend and restart
again during resume.
Tested with audio playback across a suspend-resume cycle.
Signed-off-by: Tushar Behera
---
drivers/dma/pl330.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 73fa9b7..cd70f42 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2362,6 +2362,7 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
LIST_HEAD(list);
switch (cmd) {
+ case DMA_PAUSE:
case DMA_TERMINATE_ALL:
spin_lock_irqsave(>lock, flags);
--
1.7.9.5
--
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: dts: am335x-bone-common: Add i2c2 definition
Hi Javier,
On May 13, 2014, at 10:51 AM, Javier Martinez Canillas wrote:
> Hello Pantelis,
>
> On Tue, May 13, 2014 at 7:07 PM, Pantelis Antoniou
> wrote:
>> Hi Javier,
>>
>> On May 13, 2014, at 7:39 AM, Javier Martinez Canillas wrote:
>>
>>> On Tue, May 13, 2014 at 4:22 PM, Matt Porter wrote:
On Tue, May 13, 2014 at 04:06:02PM +0200, Javier Martinez Canillas wrote:
> On Tue, May 13, 2014 at 2:53 PM, Tom Rini wrote:
>> On 05/12/2014 04:57 PM, Robert Nelson wrote:
> Either case if fine with me. As who knows when the dtc "overlay" will
> every truly make it mainline, as the capemgr was the only real kernel
> user of the i2c/at24 eeprom information.
Sounds like we should keep it disabled though so u-boot can be used
to toggle it while waiting for the capemgr. That's because the board
has a header for pins, so it's not exactly limited to just the capes.
Anybody working on enabling/disabling cape dtb configurations in
u-boot?
>>>
>>> Well,
>>>
>>> Would Tom even approve of that in mainline u-boot? He didn't want my
>>> "invert" the gpio to enable the usb hub on the older beagle xm A/B..
>>>
>>> http://lists.denx.de/pipermail/u-boot/2014-January/172154.html
>>>
>>> http://lists.denx.de/pipermail/u-boot/2014-January/172274.html
>
> Using fdt set from the bootloader to use the same FDT for similar
> boards (like the example with Beagle xM variants) is kind of trying to
> replicate what we used to do from boards files where it was possible
> to manage a set of boards using the same platform code.
>
> But Device Trees are meant to describe hardware and thus should be
> static, if two board are almost identical but slightly different, then
> are two different hardware where each need its proper FDT that
> describes it.
>
>>
>> I would think that using the 'fdt' command in U-Boot to add all
>> properties of every cape found on a running system would drive someone
>> to madness quite quickly. Moving all of Pantelis' work for dynamic
>> device trees from the kernel to N bootloaders (U-Boot, barebox, UEFI,
>> etc) sounds like a step in the wrong direction.
>>
>
> Agreed. I think that until the device tree overlay and the cape
> manager find their way into mainline we should treat capes as if they
> were expansion boards attached to a Computer-on-Module. That is, a
> static based board which its own DTS including the BB{B,W} as an dtsi
> and not something that can be added on runtime.
It's far more complicated than a SOM plus carrier board. Consider that
you can have any 4 of these capes stacked on the BBB/BBW in any
combination (assuming no resource conflicts). Capturing all possible
combinations in static dtsis is not practical.
>>>
>>
>> Since this appears to be all coming back to DT overlays, let me try to
>> address some points.
>>
>
> It seems that you misunderstood my comments. I do think that DT
> overlays and the cape manager are a great solution for any hardware
> that could be expanded on runtime and I really hope that they can
> eventually land into mainline.
>
> In fact if you look on my previous mail you will see that I said:
> "until device tree overlay and the cape manager find their way into
> mainline..."
>
>>> Right, I forgot that the capes were stackable so is indeed not
>>> practical to model every single combination as DTS in mainline. Even
>>> if stacking was not possible there are just too many capes out there
>>> to have a DTS for every single cape.
>>>
>>
>> Each cape does have a DTS as dynamically loaded fragment; it works
>> absolutely fine.
>>
>> Trying to come up with a base DTS for all the capes you've stacked up
>> is an exponential problem.
>>
>>> My point was that someone who wants to use a BBB + a set of capes can
>>> today write a DTS for its own stacked setup.
>>>
>>
>> No, the guy that designs a cape (or learns how to) can not write a DTS for
>> the base board and the cape in question. Doing that he essentially cuts
>> himself off from the community.
>>
>> Let me explain, the point is for people to easily design capes, open-source
>> their
>> design as well as their software, and share them to the community.
>>
>> This requires that things are easily shareable.
>>
>> Requiring a relative newbie in kernel development not only generate his own
>> base DT, but also to merge all of the other capes DT into his own is a
>> nightmare.
>>
>> BTW, on another tangent, it's not just the BB people that care about dynamic
>> hardware configuration. There are a number of FPGA people that seem
>> interested
>> as well.
>>
>> The notion of hardware as something static that never changes is obsolete
>> IMHO.
>>
>>> Unfortunately I don't have a solution but what I'm pretty sure is that
>>> mangling
Re: [PATCH v3] gcov: add support for GCC 4.9
"Yuan Pengfei" writes: > This patch handles the gcov-related changes in GCC 4.9: > A new counter (time profile) is added. The total number is 9 now. > A new profile merge function __gcov_merge_time_profile is added. > See gcc/gcov-io.h and libgcc/libgcov-merge.c > For the first change, the layout of struct gcov_info is affected. > For the second one, a dummy function is added to kernel/gcov/base.c > similarly. Thanks for doing that. I tried it too at some point, but failed. > > +void __gcov_merge_time_profile(gcov_type *counters, unsigned int > n_counters) But can you repost please without word wrapping? Except for that the patch looks good to me. -Andi -- a...@linux.intel.com -- Speaking for myself only -- 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: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
On 05/13/2014 09:36 PM, Rik van Riel wrote: [snip] >> >> echo 2048 > /cgroup/c/cpu.shares >> >> Where [ABC].sh are spinners: > > I suspect the "are spinners" is key. > > Infinite loops can run all the time, while dbench spends a lot of > its time waiting for locks. That waiting may interfere with getting > as much CPU as it wants. That's what we are thinking, also we assume that by introducing load decay mechanism, it become harder for the sleepy tasks to gain enough slice, well, that currently just imagination, more investigation is needed ;-) Regards, Michael Wang > -- 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] ASoC: samsung: Add missing pm ops for Snow sound card driver
Adding missing pm ops so that audio playback works across
suspend and resume cycle.
Signed-off-by: Tushar Behera
---
sound/soc/samsung/snow.c |1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c
index 0fa89a4..014c177 100644
--- a/sound/soc/samsung/snow.c
+++ b/sound/soc/samsung/snow.c
@@ -111,6 +111,7 @@ static struct platform_driver snow_driver = {
.driver = {
.name = "snow-audio",
.owner = THIS_MODULE,
+ .pm = _soc_pm_ops,
.of_match_table = snow_of_match,
},
.probe = snow_probe,
--
1.7.9.5
--
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 net-next] tracing: accelerate tracing filters with BPF
On Tue, 13 May 2014 19:55:11 -0700 Alexei Starovoitov wrote: > Tracing filters are parsing user supplied character string and constructing > a predicate tree. filter_match_preds() was used to walk nodes of the tree to > simulate matching of boolean expression. > I applied this on top of net-next, from: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git (master branch) and got this compile error: kernel/trace/trace_events_filter.c: In function ‘emit_cond’: kernel/trace/trace_events_filter.c:1361:36: error: ‘__bpf_call_base’ undeclared (first use in this function) kernel/trace/trace_events_filter.c:1361:36: note: each undeclared identifier is reported only once for each function it appears in kernel/trace/trace_events_filter.c: In function ‘filter_gen_bpf’: kernel/trace/trace_events_filter.c:1622:2: error: implicit declaration of function ‘bpf_int_jit_compile’ [-Werror=implicit-function-declaration] Config attached. -- Steve config.gz Description: application/gzip
[PATCH] mfd: ipaq-micro: Use devm_ioremap_resource()
Use devm_ioremap_resource() because devm_request_and_ioremap() is obsoleted by devm_ioremap_resource(). Signed-off-by: Jingoo Han --- drivers/mfd/ipaq-micro.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/mfd/ipaq-micro.c b/drivers/mfd/ipaq-micro.c index 1763d6d..5d08daf 100644 --- a/drivers/mfd/ipaq-micro.c +++ b/drivers/mfd/ipaq-micro.c @@ -403,17 +403,17 @@ static int micro_probe(struct platform_device *pdev) if (!res) return -EINVAL; - micro->base = devm_request_and_ioremap(>dev, res); - if (!micro->base) - return -ENOMEM; + micro->base = devm_ioremap_resource(>dev, res); + if (IS_ERR(micro->base)) + return PTR_ERR(micro->base); res = platform_get_resource(pdev, IORESOURCE_MEM, 1); if (!res) return -EINVAL; - micro->sdlc = devm_request_and_ioremap(>dev, res); - if (!micro->sdlc) - return -ENOMEM; + micro->sdlc = devm_ioremap_resource(>dev, res); + if (IS_ERR(micro->sdlc)) + return PTR_ERR(micro->sdlc); micro_reset_comm(micro); -- 1.7.10.4 -- 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: [ISSUE] sched/cgroup: Does cpu-cgroup still works fine nowadays?
On 05/13/2014 05:47 PM, Peter Zijlstra wrote:
> On Tue, May 13, 2014 at 11:34:43AM +0800, Michael wang wrote:
>> During our testing, we found that the cpu.shares doesn't work as
>> expected, the testing is:
>>
>
> /me zaps all the kvm nonsense as that's non reproducable and only serves
> to annoy.
>
> Pro-tip: never use kvm to report cpu-cgroup issues.
Make sense.
>
[snip]
> for i in A B C ; do ps -deo pcpu,cmd | grep "${i}\.sh" | awk '{t += $1} END
> {print t}' ; done
Enjoyable :)
> 639.7
> 629.8
> 1127.4
>
> That is of course not perfect, but it's close enough.
Yeah, for cpu intensive work load, the share do work very well, the
issue only appeared when workload start to become some kind of...sleepy.
I will use the tool you mentioned for the following investigation,
thanks for the suggestion.
>
> Now you again.. :-)
And here I am ;-)
Regards,
Michael Wang
>
--
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: [PATCHSET cgroup/for-3.16] cgroup: use css->refcnt for cgroup reference counting
On 2014/5/10 5:13, Tejun Heo wrote:
> Hello,
>
> Currently, cgroup and css (cgroup_subsys_state) are separately
> reference counted. cgroup->refcnt is an atomic_t and css->refcnt is a
> percpu_ref. css is becoming the primary structural block and used
> widely in various operaitons. cgroup already has a css embedded in it
> (cgroup->dummy_css) to use as its proxy in such operations; however,
> there still are quite a few differences between cgroup and css
> handling limitng how cgroup->dummy_css can be used.
>
> This patchset makes cgroup use the embedded css's refcnt for reference
> counting. This closes one of the gaps between an cgroup embedded css,
> which is renamed to cgroup->self early in the patchset, and a normal
> css and will allow more unified handling of cgroups and csses. In
> addition, this makes cgroup refcnting use percpu_ref too, which is a
> lot more scalable than an atomic_t.
>
> Ultimately, it'd make things far simpler to assign a proper
> cgroup_subsys to the cgroup embedded csses and handle them the same as
> other csses; however, we can't yet do it thanks to multiple
> hierarchies as we end up with multiple csses of the same subsystem for
> the same task, but in the very long term, if multiple hierarchies can
> be removed, that's where it's headed.
>
> This patchset contains the following nine patches.
>
> 0001-cgroup-use-restart_syscall-for-mount-retries.patch
> 0002-cgroup-rename-cgroup-dummy_css-to-self-and-move-it-t.patch
> 0003-cgroup-separate-out-cgroup_has_live_children-from-cg.patch
> 0004-cgroup-move-check_for_release-parent-call-to-the-end.patch
> 0005-cgroup-move-cgroup-sibling-unlinking-to-cgroup_put.patch
> 0006-cgroup-remove-cgroup_destory_css_killed.patch
> 0007-cgroup-bounce-css-release-through-css-destroy_work.patch
> 0008-cgroup-enable-refcnting-for-root-csses.patch
> 0009-cgroup-use-cgroup-self.refcnt-for-cgroup-refcnting.patch
>
> 0001-0003 are prep patches.
>
> 0004-0006 remove cgroup_destroy_css_killed(). This brings cgroup's
> destruction path closer to css's so that they can be merged.
>
> 0007-0009 make cgroup use the embedded css's refcnt.
>
> This pachset is on top of
>
> b9a63d0116e8 ("Merge branch 'for-3.16' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu into for-3.16")
> + [1] [PATCHSET v2 cgroup/for-3.16] cgroup: post unified hierarchy fixes and
> updates
> + [2] (REFRESHED) [PATCHSET cgroup/for-3.16] cgroup: implement
> cftype->write()
> + [3] (REFRESHED) [PATCHSET cgroup/for-3.16] cgroup: remove cgroup_tree_mutex
>
> and available in the following git branch.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-use-css-ref
>
> diffstat follows. Thanks.
>
> include/linux/cgroup.h | 25
> kernel/cgroup.c| 284
> ++---
> 2 files changed, 136 insertions(+), 173 deletions(-)
>
With the memory leak fixed:
Acked-by: Li Zefan
--
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: [ANNOUNCE] 3.14.3-rt5
On Tue, 2014-05-13 at 17:40 +0200, Sebastian Andrzej Siewior wrote:
> * Mike Galbraith | 2014-05-10 06:15:03 [+0200]:
>
> >On Fri, 2014-05-09 at 20:12 +0200, Sebastian Andrzej Siewior wrote:
> >
> >> Known issues:
> >>
> >> - bcache is disabled.
> >>
> >> - lazy preempt on x86_64 leads to a crash with some load.
> >
> >That is only with NO_HZ_FUL enabled here. Box blows the stack during
> >task exit, eyeballing hasn't spotted the why.
>
> Even if I disable NO_HZ_FULL it explodes as soon as hackbench starts.
Well good, that makes a hell of a lot more sense. The below is with
NO_HZ_FULL enabled, and hackbench exploding on exit. Every kaboom I've
see has been a dead task exploding on scrambled thread_info.
Accessing per-anti-cpu data doesn't work well from our universe ;-)
crash> bt 6657
PID: 6657 TASK: 8801f947ac00 CPU: 1 COMMAND: "hackbench"
#0 [88022fc86e00] crash_nmi_callback at 8102b8f4
#1 [88022fc86e10] nmi_handle at 8164865a
#2 [88022fc86ea0] default_do_nmi at 81648883
#3 [88022fc86ed0] do_nmi at 81648b50
#4 [88022fc86ef0] end_repeat_nmi at 81647b71
[exception RIP: oops_begin+162]
RIP: 816483e2 RSP: 8800b220d9d8 RFLAGS: 0097
RAX: 0010 RBX: 0010 RCX: 0097
RDX: 8800b220d9d8 RSI: 0018 RDI: 0001
RBP: 816483e2 R8: 816483e2 R9: 0018
R10: 8800b220d9d8 R11: 0097 R12:
R13: 88022700bf00 R14: 0100 R15: 0001
ORIG_RAX: 0001 CS: 0010 SS: 0018
--- ---
#5 [8800b220d9d8] oops_begin at 816483e2
#6 [8800b220d9f0] no_context at 8162ef25
#7 [8800b220da40] __bad_area_nosemaphore at 8162f19d
#8 [8800b220daa0] bad_area_nosemaphore at 8162f1ca
#9 [8800b220dab0] __do_page_fault at 8164a68e
#10 [8800b220dbd0] do_page_fault at 8164ab9e
#11 [8800b220dc00] page_fault at 81647808
[exception RIP: cpuacct_charge+148]
RIP: 810a1874 RSP: 8800b220dcb8 RFLAGS: 00010046
RAX: 0040 RBX: dd08 RCX: 0003
RDX: 0006 RSI: 0006 RDI: 88022700bf00
RBP: 8800b220dcf8 R8: 06c0 R9: 000b
R10: R11: 00013f40 R12: 81c3b180
R13: 8801f947ac00 R14: b220ddd8 R15: 1d64
ORIG_RAX: CS: 0010 SS: 0018
#12 [8800b220dd00] update_curr at 81092451
#13 [8800b220dd60] dequeue_entity at 810928f3
#14 [8800b220ddc0] dequeue_task_fair at 81092d4d
#15 [8800b220de10] dequeue_task at 8108442e
#16 [8800b220de40] deactivate_task at 81084f9e
#17 [8800b220de50] __schedule at 816440d4
#18 [8800b220ded0] schedule at 81644899
#19 [8800b220def0] do_exit at 810530d0
#20 [8800b220df40] do_group_exit at 8105334c
#21 [8800b220df70] sys_exit_group at 810533e2
#22 [8800b220df80] tracesys at 8164f109 (via system_call)
RIP: 7fcc1a078ca8 RSP: 7fff62546c48 RFLAGS: 0246
RAX: ffda RBX: 8164f109 RCX:
RDX: RSI: 003c RDI:
RBP: 7fcc1a355840 R8: 00e7 R9: ffa8
R10: 7fcc1a969700 R11: 0246 R12: 810533e2
R13: 8800b220df78 R14: 01ad9c88 R15: 0001
ORIG_RAX: 00e7 CS: 0033 SS: 002b
crash> struct thread_info 0x8800b220c000
struct thread_info {
task = 0x,
exec_domain = 0x811bae66 <__d_free+70>,
flags = 2,
status = 0,
cpu = 2988498392,
saved_preempt_count = -30720,
preempt_lazy_count = -112742225,
addr_limit = {
seg = 524802
},
restart_block = {
fn = 0x88022fc91358,
{
futex = {
uaddr = 0x80202,
val = 3,
flags = 0,
bitset = 2988490752,
time = 18446744071585425101,
uaddr2 = 0x88022fc91358
},
nanosleep = {
clockid = 524802,
rmtp = 0x3,
compat_rmtp = 0x8800b220c000,
expires = 18446744071585425101
},
poll = {
ufds = 0x80202,
nfds = 3,
has_timeout = 0,
tv_sec = 18446612135302709248,
tv_nsec = 18446744071585425101
}
}
},
sysenter_return = 0x,
sig_on_uaccess_error = 0,
uaccess_err = 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] ARM64: kernel: add compatable cpuinfo
> -Original Message- > From: Neil Zhang [mailto:zhan...@marvell.com] > Sent: 2014年5月14日 11:00 > To: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org > Cc: catalin.mari...@arm.com; will.dea...@arm.com; Neil Zhang > Subject: [PATCH] ARM64: kernel: add compatable cpuinfo > Fix typo in version 2. > Print the necessary features in order to be backwards compatable with > ARMv7 and earlier version. > > Signed-off-by: Neil Zhang > --- > arch/arm64/kernel/setup.c |5 + > 1 file changed, 5 insertions(+) > > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index > 7ec7846..a09ecfe 100644 > --- a/arch/arm64/kernel/setup.c > +++ b/arch/arm64/kernel/setup.c > @@ -451,6 +451,11 @@ static int c_show(struct seq_file *m, void *v) > if (elf_hwcap & (1 << i)) > seq_printf(m, "%s ", hwcap_str[i]); > > +#ifdef CONFIG_COMPAT > + seq_puts(m, "half thumb fastmult edsp tls vfp vfpv3 vfpv4 neon "); > + seq_puts(m, "idiva idivt "); > +#endif > + > seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> > 24); > seq_printf(m, "CPU architecture: AArch64\n"); > seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); > -- > 1.7.9.5 Best Regards, Neil Zhang
[PATCH v2] ARM64: kernel: add compatible cpuinfo
Print the necessary features in order to be backwards compatible with ARMv7 and earlier version. Signed-off-by: Neil Zhang --- arch/arm64/kernel/setup.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 7ec7846..a09ecfe 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -451,6 +451,11 @@ static int c_show(struct seq_file *m, void *v) if (elf_hwcap & (1 << i)) seq_printf(m, "%s ", hwcap_str[i]); +#ifdef CONFIG_COMPAT + seq_puts(m, "half thumb fastmult edsp tls vfp vfpv3 vfpv4 neon "); + seq_puts(m, "idiva idivt "); +#endif + seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24); seq_printf(m, "CPU architecture: AArch64\n"); seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); -- 1.7.9.5 -- 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 net-next] tracing: accelerate tracing filters with BPF
On Tue, 13 May 2014 19:55:11 -0700 Alexei Starovoitov wrote: > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -79,6 +79,7 @@ config FTRACE_NMI_ENTER > default y > > config EVENT_TRACING > + depends on NET > select CONTEXT_SWITCH_TRACER > bool > This part makes me a little nervous. I know a lot of embedded devices depend on tracing, but do they all have network? They may, but I would like to hear from others in the embedded space. -- Steve -- 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 V1] regulator: DA9211 : new regulator driver
This is the driver for the Dialog DA9211 Multi-phase 12A DC-DC Buck
Converter regulator. It communicates via an I2C bus to the device.
Signed-off-by: James Ban
---
Please ignore previous patch since it has a bug on two bucks configuration.
This patch is relative to linux-next repository tag next-20140509
drivers/regulator/Kconfig| 10 +
drivers/regulator/Makefile | 1 +
drivers/regulator/da9211-regulator.c | 922 +++
drivers/regulator/da9211-regulator.h | 271 ++
include/linux/regulator/da9211.h | 81 +++
5 files changed, 1285 insertions(+)
create mode 100644 drivers/regulator/da9211-regulator.c
create mode 100644 drivers/regulator/da9211-regulator.h
create mode 100644 include/linux/regulator/da9211.h
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index b4f57a4..3b0c28d 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -198,6 +198,16 @@ config REGULATOR_DA9210
converter 12A DC-DC Buck controlled through an I2C
interface.
+config REGULATOR_DA9211
+ tristate "Dialog Semiconductor DA9211/DA9212 regulator"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Say y here to support for the Dialog Semiconductor DA9211/DA9212.
+ The DA9211/DA9212 is a multi-phase synchronous step down
+ converter 12A DC-DC Buck controlled through an I2C
+ interface.
+
config REGULATOR_DBX500_PRCMU
bool
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c14696b2..8c0c0e3 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_REGULATOR_DA9052)+= da9052-regulator.o
obj-$(CONFIG_REGULATOR_DA9055) += da9055-regulator.o
obj-$(CONFIG_REGULATOR_DA9063) += da9063-regulator.o
obj-$(CONFIG_REGULATOR_DA9210) += da9210-regulator.o
+obj-$(CONFIG_REGULATOR_DA9211) += da9211-regulator.o
obj-$(CONFIG_REGULATOR_DBX500_PRCMU) += dbx500-prcmu.o
obj-$(CONFIG_REGULATOR_DB8500_PRCMU) += db8500-prcmu.o
obj-$(CONFIG_REGULATOR_FAN53555) += fan53555.o
diff --git a/drivers/regulator/da9211-regulator.c
b/drivers/regulator/da9211-regulator.c
new file mode 100644
index 000..2b1bd90
--- /dev/null
+++ b/drivers/regulator/da9211-regulator.c
@@ -0,0 +1,922 @@
+/*
+ * da9211-regulator.c - Regulator device driver for DA9211
+ * Copyright (C) 2014 Dialog Semiconductor Ltd.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Library General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Library General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "da9211-regulator.h"
+
+#define DA9211_BUCK_MODE_SLEEP 1
+#define DA9211_BUCK_MODE_SYNC 2
+#define DA9211_BUCK_MODE_AUTO 3
+
+/* DA9211 REGULATOR IDs */
+#define DA9211_ID_BUCKA0
+#define DA9211_ID_BUCKB1
+
+struct da9211_conf_reg {
+ int reg;
+ int sel_mask;
+};
+
+struct da9211_volt_reg {
+ int reg_a;
+ int reg_b;
+ int v_mask;
+};
+
+struct da9211_mode_reg {
+ int reg;
+ int mask;
+ int shift;
+};
+
+struct da9211_regulator_info {
+ struct regulator_desc reg_desc;
+ struct da9211_conf_reg conf;
+ struct da9211_volt_reg volt;
+ struct da9211_mode_reg mode;
+ int current_shift;
+};
+
+/* Number of IRQ and IRQ offset */
+enum {
+ DA9211_INT_OFFSET_1 = 0,
+ DA9211_INT_OFFSET_2,
+ DA9211_NUM_IRQ_EVT_REGS
+};
+
+struct da9211_irq {
+ irq_handler_t handler;
+ void *data;
+};
+
+struct da9211 {
+ struct device *dev;
+ struct regmap *regmap;
+ struct da9211_pdata *pdata;
+ struct da9211_regulator_info *info;
+ struct regulator_dev *rdev[DA9211_MAX_REGULATORS];
+ int num_regulator;
+ /* Interrupt handling */
+ struct work_struct irq_work;
+ struct task_struct *irq_task;
+ struct mutex irq_mutex; /* IRQ table mutex */
+ struct da9211_irq irq[DA9211_NUM_IRQ];
+ int chip_irq;
+};
+
+struct da9211_regulator {
+ struct da9211 *da9211;
+ struct da9211_regulator_info *info;
+ struct regulator_dev *rdev;
+ enum da9211_gpio_rsel_select reg_rselect;
+};
+
+static const struct regmap_config da9211_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+/* Default limits measured in millivolts and milliamps */
+#define DA9211_MIN_MV 300
+#define DA9211_MAX_MV 1570
+#define DA9211_STEP_MV 10
+
+/*
perfevents: irq loop stuck!
I've gotten the following warning a few times now with the perf_fuzzer. In each case it looks like the culprit might be the fixed-counter 0 value being fffe I have a somewhat repeatable trace and it looks like the problem event is: pe[32].type=PERF_TYPE_HARDWARE; pe[32].size=80; pe[32].config=PERF_COUNT_HW_INSTRUCTIONS; pe[32].sample_period=0xc0bd; Should it be possible to open an event with a large negative sample_period like that? I tried tracing through the sample_period setting code and there are places that cast from u64 to s64 and other dubious things, but as always I find the code very hard to follow. This is on a Haswell machine. [ 425.815773] [ cut here ] [ 425.821212] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/cpu/perf_event_intel.c:1373 intel_pmu_handle_irq+0x2a4/0x3c0() [ 425.833692] perfevents: irq loop stuck! [ 425.839116] Modules linked in: fuse x86_pkg_temp_thermal intel_powerclamp coretemp kvm snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul snd_hda_intel i915 glue_helper snd_hda_controller snd_hda_codec snd_hwdep snd_pcm drm_kms_helper snd_seq snd_timer snd_seq_device ablk_helper snd cryptd ppdev iTCO_wdt iTCO_vendor_support lpc_ich drm soundcore mei_me parport_pc mfd_core evdev i2c_algo_bit i2c_i801 i2c_core button processor video battery wmi mei parport psmouse serio_raw pcspkr tpm_tis tpm sd_mod sr_mod crc_t10dif crct10dif_common cdrom ahci ehci_pci libahci e1000e ehci_hcd xhci_hcd libata ptp crc32c_intel usbcore scsi_mod pps_core usb_common thermal fan thermal_sys [ 425.930947] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc1+ #104 [ 425.937876] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014 [ 425.945817] 0009 88011ea06cb0 81649ca0 88011ea06cf8 [ 425.953957] 88011ea06ce8 810646ad 0064 88011ea0cbe0 [ 425.961986] 8800cd1f4800 0040 88011ea0cde0 88011ea06d48 [ 425.970169] Call Trace: [ 425.972858][] dump_stack+0x45/0x56 [ 425.979150] [] warn_slowpath_common+0x7d/0xa0 [ 425.985617] [] warn_slowpath_fmt+0x4c/0x50 [ 425.991770] [] intel_pmu_handle_irq+0x2a4/0x3c0 [ 425.998417] [] perf_event_nmi_handler+0x2b/0x50 [ 426.005116] [] nmi_handle.isra.5+0xa8/0x150 [ 426.011428] [] ? nmi_handle.isra.5+0x5/0x150 [ 426.017729] [] do_nmi+0xd8/0x340 [ 426.022979] [] end_repeat_nmi+0x1e/0x2e [ 426.028917] [] ? native_write_msr_safe+0xa/0x10 [ 426.035514] [] ? native_write_msr_safe+0xa/0x10 [ 426.042139] [] ? native_write_msr_safe+0xa/0x10 [ 426.048752] <>[] intel_pmu_enable_event+0x21d/0x240 [ 426.057185] [] x86_pmu_start+0x7a/0x100 [ 426.063125] [] x86_pmu_enable+0x295/0x310 [ 426.069206] [] perf_pmu_enable+0x2f/0x40 [ 426.075185] [] x86_pmu_commit_txn+0x7a/0xa0 [ 426.081423] [] ? debug_object_activate+0x17b/0x220 [ 426.088298] [] ? __lock_acquire.isra.29+0x3bd/0xb90 [ 426.095245] [] ? event_sched_in.isra.76+0x150/0x1e0 [ 426.102269] [] group_sched_in+0x1c0/0x1e0 [ 426.108394] [] __perf_event_enable+0x255/0x260 [ 426.114976] [] remote_function+0x40/0x50 [ 426.120916] [] generic_smp_call_function_single_interrupt+0x5d/0x100 [ 426.129515] [] smp_trace_call_function_single_interrupt+0x2d/0xb0 [ 426.137854] [] trace_call_function_single_interrupt+0x6d/0x80 [ 426.145827][] ? cpuidle_enter_state+0x52/0xc0 [ 426.153044] [] ? cpuidle_enter_state+0x48/0xc0 [ 426.159612] [] cpuidle_enter+0x17/0x20 [ 426.165411] [] cpu_startup_entry+0x2c0/0x3d0 [ 426.171810] [] rest_init+0xb6/0xc0 [ 426.177259] [] ? rest_init+0x5/0xc0 [ 426.182778] [] start_kernel+0x43d/0x448 [ 426.188647] [] ? repair_env_string+0x5c/0x5c [ 426.195040] [] ? early_idt_handlers+0x120/0x120 [ 426.201643] [] x86_64_start_reservations+0x2a/0x2c [ 426.208575] [] x86_64_start_kernel+0x143/0x152 [ 426.215176] ---[ end trace 515d2dd21a07f5dd ]--- [ 426.220078] [ 426.221698] CPU#0: ctrl: [ 426.226591] CPU#0: status: [ 426.231480] CPU#0: overflow: [ 426.236361] CPU#0: fixed: 00b8 [ 426.241211] CPU#0: pebs: [ 426.246076] CPU#0: active: 00030002 [ 426.250948] CPU#0: gen-PMC0 ctrl: 001300c5 [ 426.256392] CPU#0: gen-PMC0 count: 00088ff0 [ 426.261838] CPU#0: gen-PMC0 left: fff77328 [ 426.267273] CPU#0: gen-PMC1 ctrl: 00530254 [ 426.272727] CPU#0: gen-PMC1 count: 0001 [ 426.279307] CPU#0: gen-PMC1 left: [ 426.285847] CPU#0: gen-PMC2 ctrl: 0013412e [ 426.292354] CPU#0: gen-PMC2 count: 00010545 [ 426.298874] CPU#0: gen-PMC2 left: fffefb07 [ 426.305405] CPU#0: gen-PMC3 ctrl: 001300c0 [ 426.311913] CPU#0:
[PATCH] ARM64: kernel: add compatable cpuinfo
Print the necessary features in order to be backwards compatable with ARMv7 and earlier version. Signed-off-by: Neil Zhang --- arch/arm64/kernel/setup.c |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 7ec7846..a09ecfe 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -451,6 +451,11 @@ static int c_show(struct seq_file *m, void *v) if (elf_hwcap & (1 << i)) seq_printf(m, "%s ", hwcap_str[i]); +#ifdef CONFIG_COMPAT + seq_puts(m, "half thumb fastmult edsp tls vfp vfpv3 vfpv4 neon "); + seq_puts(m, "idiva idivt "); +#endif + seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24); seq_printf(m, "CPU architecture: AArch64\n"); seq_printf(m, "CPU variant\t: 0x%x\n", (read_cpuid_id() >> 20) & 15); -- 1.7.9.5 -- 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 RFC net-next] tracing: accelerate tracing filters with BPF
Tracing filters are parsing user supplied character string and constructing
a predicate tree. filter_match_preds() was used to walk nodes of the tree to
simulate matching of boolean expression.
BPF program obsoletes predicate tree walker. It is generated on the fly out
of predicate tree.
Tested with built-in FTRACE_STARTUP_TEST.
The same 24 tests from trace_events_filter.c were used as boot-time benchmark.
Performance on x86_64:
predicate BPF JITed
tree walking interpreter BPF
test #0:8244 4nsec per call
test #1:60 9 3nsec per call
test #2:8345 4nsec per call
test #3:8245 5nsec per call
test #4:8126 5nsec per call
test #5:60 9 4nsec per call
test #6:9511 3nsec per call
test #7: 14449 6nsec per call
test #8: 13947 6nsec per call
test #9: 13924 5nsec per call
test #10: 11318 4nsec per call
test #11: 13721 6nsec per call
test #12: 18041 5nsec per call
test #13: 8639 4nsec per call
test #14: 10112 4nsec per call
test #15: 12145 5nsec per call
test #16: 10315 4nsec per call
test #17: 8739 4nsec per call
test #18: 10112 4nsec per call
test #19: 16141 6nsec per call
test #20: 15940 6nsec per call
test #21: 20663 6nsec per call
test #22: 16039 6nsec per call
test #23: 20459 6nsec per call
test #24: 16039 6nsec per call
Example 1:
string filter "field1 == 1 || field2 == 2" is converted into BPF:
r6 = r1
r0 = *(u16 *)(r6 +0) // field1.offset = 0, field1.size = 2
if r0 == 0x1 goto pc+3
r0 = *(u8 *)(r6 +2) // field2.offset = 2, field2.size = 1
if r0 == 0x2 goto pc+1
goto pc+2
r0 = 1
exit
r0 = 0
exit
Example 2:
filter "name ~ eth* && field2 == 1" is converted:
r6 = r1
r2 = 1234 // upper 32-bits of predicate addr
r2 <<= 32
r1 = 5678 // lower 32-bits of predicate addr
r1 |= r2
r2 = r6
// call wrapper around filter_pred_strloc(struct filter_pred *pred, void
*event)
call bpf_filter_pred_strloc
if r0 == 0x0 goto pc+5
r0 = *(u32 *)(r6 +16) // field2.offset = 16, field2.size = 4
if r0 == 0x1 goto pc+1
goto pc+2
r0 = 1
exit
r0 = 0
exit
Internal BPF has 'bpf_call' instruction for function calls from BPF program
into in-kernel helper functions. It is used to do 'regex'-style filter matching
in the example above. All generated BPF programs can be JITed.
Signed-off-by: Alexei Starovoitov
---
The patches for x64_64 BPF JIT were sent separately. This one is an RFC.
kernel/trace/Kconfig |1 +
kernel/trace/trace.h |4 +-
kernel/trace/trace_events_filter.c | 624
3 files changed, 343 insertions(+), 286 deletions(-)
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 8639819f6cef..a192acd8ae58 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -79,6 +79,7 @@ config FTRACE_NMI_ENTER
default y
config EVENT_TRACING
+ depends on NET
select CONTEXT_SWITCH_TRACER
bool
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 2e29d7ba5a52..bb73c0243f86 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -970,12 +970,15 @@ struct ftrace_event_field {
int is_signed;
};
+struct sk_filter;
+
struct event_filter {
int n_preds;/* Number assigned */
int a_preds;/* allocated */
struct filter_pred *preds;
struct filter_pred *root;
char*filter_string;
+ struct sk_filter*bpf_prog;
};
struct event_subsystem {
@@ -1032,7 +1035,6 @@ struct filter_pred {
filter_pred_fn_tfn;
u64 val;
struct regexregex;
- unsigned short *ops;
struct ftrace_event_field *field;
int offset;
int not;
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index 8a8631926a07..19cc2b94bc15 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "trace.h"
#include "trace_output.h"
@@ -139,62 +140,6 @@ struct pred_stack {
int index;
};
-#define DEFINE_COMPARISON_PRED(type) \
-static int filter_pred_##type(struct filter_pred *pred, void *event) \
-{
Re: Does perf support different length of user-space hw_breakpoint?
于 2014/5/13 23:06, Frederic Weisbecker 写道: > On Tue, May 13, 2014 at 02:00:46PM +0200, Jiri Olsa wrote: >> On Mon, May 12, 2014 at 03:52:54PM +0800, xiakaixu wrote: >>> Hi guys, >>> >>> Does perf support different length of user-space hw_breakpoint, >>> such as HW_BREAKPOINT_LEN_1/HW_BREAKPOINT_LEN_2/HW_BREAKPOINT_LEN_4/ >>> HW_BREAKPOINT_LEN_8? >>> >>> Seems perf only support HW_BREAKPOINT_LEN_4/sizeof(long) >>> by default from the source code and simple test. >> >> right.. >> >> /* >> * We should find a nice way to override the access length >> * Provide some defaults for now >> */ >> if (attr.bp_type == HW_BREAKPOINT_X) >> attr.bp_len = sizeof(long); >> else >> attr.bp_len = HW_BREAKPOINT_LEN_4; >> >>> >>> May I have your opinions if I want to trace different bytes of >>> hw_breakpoint addr? >> >> I guess that depends on what you want to do ;-) > > Ah, I have a patchset from Jacob Shin and Suravee Suthikulpanit that does > that. Also it has been hanging around for too long by my fault. I'm posting > it now. Thanks for your reply! Hopefully I can get it ASAP. > . > -- 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/9] cgroup: use restart_syscall() for mount retries
On 2014/5/10 5:13, Tejun Heo wrote:
> cgroup_mount() uses dumb delay-and-retry logic to wait for cgroup_root
> which is being destroyed. The retry currently loops inside
> cgroup_mount() proper. This patch makes it return with
> restart_syscall() instead so that retry travels out to userland
> boundary.
>
> This slightly simplifies the logic and more importantly makes the
> retry logic behave better when the wait for some reason becomes
> lengthy or infinite by allowing the operation to be suspended or
> terminated from userland.
>
> Signed-off-by: Tejun Heo
> ---
> kernel/cgroup.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 3083c5a..2755f33 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -1681,7 +1681,7 @@ static struct dentry *cgroup_mount(struct
> file_system_type *fs_type,
> ret = parse_cgroupfs_options(data, );
> if (ret)
> goto out_unlock;
> -retry:
> +
> /* look for a matching existing root */
> if (!opts.subsys_mask && !opts.none && !opts.name) {
> cgrp_dfl_root_visible = true;
> @@ -1740,8 +1740,7 @@ retry:
> if (!atomic_inc_not_zero(>cgrp.refcnt)) {
> mutex_unlock(_mutex);
> msleep(10);
> - mutex_lock(_mutex);
> - goto retry;
> + return ERR_PTR(restart_syscall());
We leak memory allocated in parse_cgroupfs_options().
--
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 5/5] mcpm: exynos: populate suspend and powered_up callbacks
Hi Lorenzo,
On 13 May 2014 22:44, Lorenzo Pieralisi wrote:
> On Tue, May 13, 2014 at 12:43:31PM +0100, Chander Kashyap wrote:
>
> [...]
>
>> >> +static void exynos_suspend(u64 residency)
>> >> +{
>> >> + unsigned int mpidr, cpunr;
>> >> +
>> >> + mpidr = read_cpuid_mpidr();
>> >> + cpunr = exynos_pmu_cpunr(mpidr);
>> >
>> > If I were to be picky, I would compute these values only if they
>> > are needed, ie move the computation after exynos_power_down().
>>
>> Yes thats make sense. I will realign it.
>>
>> >
>> > There is another quite horrible issue here. We know this code works
>> > because the processors A15/A7 hit the caches with C bit in SCTLR cleared.
>> >
>> > On processors where this is not true, this sequence would explode
>> > if power down fails (in case core is gated but L2 is still powered on,
>> > the stack is stuck in L2) since it is going to read stack data that is
>> > in L2 but can't be read.
>> >
>> > It is not related to this sequence only, but it is an issue in general
>> > and wanted to mention that on the lists for public awareness.
>> >
>>
>> Can you please elaborate. I didn't understand.
>
> It is not related to this patch only. This function carries out writes to the
> stack (which might end up in eg L2) and then disables the C bit in SCTLR
> through MCPM.
>
> A15 and A7 processors hit the cache with the C bit clear in the SCTLR
> so the processor still "hits" the stack values if the power down fails.
> On processors where caches are not hit with the C bit clear (eg A9) this code
> would fail since the stack values that sit in the caches cannot be read with
> the C bit clear in SCTLR until the SCTLR is restored, so it will have to
> be implemented in assembly with no stack usage (or better, no cacheable data
> usage).
>
> So, all I am saying is, to avoid copy'n'paste havoc and to avoid running
> this code on Exynos platforms where it must not be run as-is, please add
> a comment along the line:
>
> "This function requires the stack data to be visible through power down
> and can only be executed on processors like A15 and A7 that hit the cache
> with the C bit clear in the SCTLR register."
>
> Please let me know if that's clear.
It all clear now.
Thanks a lot.
>
> Lorenzo
>
>>
>> > The gist of what I am saying is, please add a comment to that extent,
>> > here and it should be added in exynos_power_down() too.
>> >
>> >> + __raw_writel(virt_to_phys(mcpm_entry_point), ns_sram_base_addr +
>> >> 0x1c);
>> >
>> > No magic numbers please (0x1c). You can add a macro/wrapper, as TC2 does.
>>
>> Yes i will remove it.
>>
>> >
>> >> + exynos_power_down();
>> >> +
>> >> + /*
>> >> + * Execution reaches here only if cpu did not power down.
>> >> + * Hence roll back the changes done in exynos_power_down function.
>> >> + */
>> >> + exynos_cpu_powerup(cpunr);
>> >
>> > Please be aware that if this function returns MCPM will soft reboot, and
>> > the CPUidle driver will have no way to detect a state entry failure.
>> >
>> > I am just flagging this up, since fixing this behaviour is not easy, and
>> > honestly, since power down failure should be the exception not the rule,
>> > the idle stats should not be affected much.
>> >
>> > I think this is the proper way of implementing the sequence but please
>> > all keep in mind what I wrote above.
>> >
>> > Lorenzo
>> >
>> >> +}
>> >> +
>> >> static const struct mcpm_platform_ops exynos_power_ops = {
>> >> .power_up = exynos_power_up,
>> >> .power_down = exynos_power_down,
>> >> .power_down_finish = exynos_power_down_finish,
>> >> + .suspend= exynos_suspend,
>> >> + .powered_up = exynos_powered_up,
>> >> };
>> >>
>> >> static void __init exynos_mcpm_usage_count_init(void)
>> >> --
>> >> 1.7.9.5
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> with warm regards,
>> Chander Kashyap
>>
>
--
with warm regards,
Chander Kashyap
--
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/
Filesystem lockup with CONFIG_PREEMPT_RT
Hi, I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT patched kernel. I have currently only triggered it using dpkg. Dave Chinner on the XFS mailing list suggested that it was a rt-kernel workqueue issue as opposed to a XFS problem after looking at the kernel messages. $ uname -a Linux vpc5 3.10.24-rt22abs #15 SMP PREEMPT RT Tue May 13 14:42:22 PDT 2014 x86_64 GNU/Linux The only modification to the kernel besides the RT patch is that I have applied tglx's "genirq: Sanitize spurious interrupt detection of threaded irqs" patch. Any ideas on what could be wrong? Is there any information that I can pull before I reboot the machine that would be useful? I have the output of triggering sysrq with l and t if that would be useful. Attached is the kernel blocked task message output. Thanks, Austin vpc5_xfs_lockup_locks Description: Binary data
RE: [PATCH v4] ARM: perf: save/restore pmu registers in pm notifier
> -Original Message-
> From: Will Deacon [mailto:will.dea...@arm.com]
> Sent: 2014年5月14日 2:45
> To: Neil Zhang
> Cc: Sudeep Holla; 'li...@arm.linux.org.uk';
> 'linux-arm-ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org';
> 'devicet...@vger.kernel.org'
> Subject: Re: [PATCH v4] ARM: perf: save/restore pmu registers in pm notifier
>
> On Mon, May 12, 2014 at 11:22:09AM +0100, Neil Zhang wrote:
> > > > The device tree bindings for power domains is under discussion [1]
> > >
> > > Thanks for the information.
> > > But it currently for device only, core related stuff are not supported.
> > > And is it really good to register power provider for core and let
> > > vfp / pmu etc to get it?
> > >
> >
> > What's your suggestion about it?
> > Is it OK that I add it under the PMU node?
>
> I don't really mind. I just want to avoid re-inventing the wheel in a
> PMU-specific way and having to maintain that code forever because it ended
> up in our DT description.
>
> Will
I will prepare another patch to add DT description under PMU since there is
no generic power domain support for pm notifier if no other concerns.
We can change the manner if there is generic power domain support for pm
notifier later.
Thanks.
Best Regards,
Neil Zhang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH 00/34] perf and kconfig / kbuild
On 5/13/14, 4:02 PM, Alexis Berlemont wrote: Hello, A few months ago, I tried to make a proposal to introduce Kconfig in perf's generation procedure. (cf. https://lkml.org/lkml/2013/12/20/511) I started from David Ahern's work; I was not aware that Jiri Olsa pushed further the idea and proposed an alternative which integrated kbuild too. So, here is another proposal based on Jiri Olsa work (from April 2013). * Most of the NO_* and HAVE_* makefile variables were removed on behalf of Kconfig's ones (CONFIG_*); perf source code was modified accordingly; * These changes make the glue files tools/perf/config/Makefile.fix-* useless * The build test cases now relies on generated configuration files (in tools/perf/tests/configs); Thanks for picking this up. I skimmed through all of the patches and conceptually looks good. I doubt I will have time for a detailed review any time soon. Looks like they apply to Linus' top of tree but with a few errors -- see below. You should always run checkpatch.pl before sending out: Applying: kbuild: Introduce KBUILD_AUTOCONF variable for auto.conf include Applying: kbuild: Introduce KCONFIG_AUTOCONFIGDEP variable for conf tool Applying: perf tools: Kbuild builtin source related fixies Applying: perf tools: Kbuild source related fixies Applying: perf tools: Add kbuild support into Makefile.kbuild Applying: perf kbuild: fix recursive invocation of config/features-checks Applying: perf kbuild: store in config-detected missing variables (libdir, ...) Applying: perf kbuild: remove useless #ifdef directives Applying: perf kbuild: fix a link issue if BUILTIN_TRACE is disabled Applying: perf kbuild: add missing files and missing flags in Kbuild files /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:30: trailing whitespace. CFLAGS_Context.o += -Wno-redundant-decls -Wno-strict-prototypes /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:137: trailing whitespace. CFLAGS_trace-event-perl.o += -Wno-redundant-decls -Wno-strict-prototypes /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:138: trailing whitespace. CFLAGS_trace-event-perl.o += -Wno-unused-parameter -Wno-shadow -Wno-undef /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:143: trailing whitespace. CFLAGS_trace-event-python.o += -Wno-redundant-decls -Wno-strict-prototypes warning: 4 lines applied after fixing whitespace errors. Applying: perf kbuild: update kbuild files according to last changes Applying: perf kbuild: remove legacy slang-related build variables Applying: perf kbuild: remove legacy libaudit-related build variables Applying: perf kbuild: remove legacy libgtk2-related build variables /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:204: trailing whitespace. #else warning: 1 line applied after fixing whitespace errors. Applying: perf kbuild: remove legacy libperl-related build variables Applying: perf kbuild: remove legacy timerfd-related build variable Applying: perf kbuild: remove legacy demangle-related build variables Applying: perf kbuild: remove legacy on_exit-related build variable Applying: perf kbuild: remove legacy backtrace-related build variable Applying: perf kbuild: remove legacy numa-related build variable Applying: perf kbuild: remove legacy bionic-related build variable Applying: perf kbuild: remove legacy libelf-related build variables (1st part) Applying: perf kbuild: remove legacy libelf-related build variables (2nd part) Applying: perf kbuild: remove legacy libdwarf-related build variables /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:342: trailing whitespace. endif # CONFIG_LIBDWARF_UNWIND warning: 1 line applied after fixing whitespace errors. Applying: perf kbuild: remove legacy libunwind-related build variables Applying: perf kbuild: remove legacy libpython-related build variable Applying: perf kbuild: add generated Kconfig build-test cases Applying: perf kbuild: fix installation of traceevent plugins /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:74: trailing whitespace. make_pure := warning: 1 line applied after fixing whitespace errors. Applying: perf kbuild: fix tarpkg target in tests/make Applying: perf kbuild: update Kbuild files with new and removed sources Applying: perf kbuild: update build test configurations /Users/dsa/sw/perf/ahern.git/.git/rebase-apply/patch:773: trailing whitespace. warning: 1 line applied after fixing whitespace errors. Applying: perf kbuild: relocate the configs generating script Applying: perf kbuild: minor changes Applying: perf kbuild: remove Makefile.perf David -- 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/
HID Sensor support for True/Magnetic North usage attributes
Dear IIO/HID maintainers, I have a device, Surface Pro, that has the hid-sensor-hub and many sensors attached. With the help of Srinivas I was able to get them all working except for the magnometer. It uses the hid-magn-3d driver as it should but it does not contain an axis (X, Y, Z) usage attributes. Instead it only has a True North usage attribute. I see two solutions to this problem and was inquiring which one would work best? 1) Modify the hid-magn-3d driver to handle True North attribute. I realize there might not be many devices that have this so not sure if appropriate. I think this could be done; by passing a variable amount of IIO Channels when setting up the hid-magn-3d driver, depending on how many axis and/or if it find True/Magnetic North usage attribute. 2) Create a whole new driver that handles True/Magnetic North. This would not work on my device as it is set to Compass 3D Usage Attribute. This could be resolved by adding another quirk for the Surface to ensure it used the new driver. For both options I think we'd need a new IIO_MOD_NORTH for the iio_chan_spec, as the current ones don't really apply. I like the first solution as it could allow for handling of devices with only one or two axis present. I do realize if the hid-mangn-3d driver was changed it's name would not make sense anymore and the pattern I'm notcing is a driver for each HID Usage. Here's a link to the hid report description with some labels for my device: Bug 73321 Comment 7 https://bugzilla.kernel.org/show_bug.cgi?id=73321#c7 I'd be willing to work on this. Just wanted to know what would work best Thank You, Reyad Attiyat -- 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 2/2] ARM: ioremap: Add IO mapping space reused support.
On Tue, May 13, 2014 at 4:43 PM, Arnd Bergmann wrote: > On Tuesday 13 May 2014 09:45:08 Richard Lee wrote: >> > On Mon, May 12, 2014 at 3:51 PM, Arnd Bergmann wrote: >> > On Monday 12 May 2014 10:19:55 Richard Lee wrote: >> >> For the IO mapping, for the same physical address space maybe >> >> mapped more than one time, for example, in some SoCs: >> >> 0x2000 ~ 0x20001000: are global control IO physical map, >> >> and this range space will be used by many drivers. >> >> And then if each driver will do the same ioremap operation, we >> >> will waste to much malloc virtual spaces. >> >> >> >> This patch add IO mapping space reused support. >> >> >> >> Signed-off-by: Richard Lee >> > >> > What happens if the first driver then unmaps the area? >> > >> >> If the first driver will unmap the area, it shouldn't do any thing >> except decreasing the 'used' counter. > > Ah, for some reason I didn't see your first patch that introduces > that counter. > It's "[PATCH 1/2] mm/vmalloc: Add IO mapping space reused". Thanks, BRs Richard > Arnd -- 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] pinctrl: add params in disable_setting to differ difference usage
On 05/14/2014 09:54 AM, f...@marvell.com wrote:
From: Fan Wu
The patch added params in disable_setting to differ the two possible usage,
1.Only want to disable the pin setting in SW aspect, param can be set to "0"
2.Want to disable the pin setting in both HW and SW aspect, param can be set to
"1";
The reason why to do this is that:
To avoid duplicated enable_setting operation without disabling operation which
will
let Pin's desc->mux_usecount keep being added.
In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in the two state is same, like the following
one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_grp_setting _grp_setting>;
pinctrl-1 = <_grp_setting _grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switch the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1)The switch change is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without
being
decreased, due to the original reason mentioned in this patch.
According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the Same Pins setting ahead of
enable them.
Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old
state should be
marked as "disabled" in my understanding.
Conclusion:
Thus, the patch handle the issue mentioned above by disabling the c_grp_setting
in SW asepct without
touch the HW corresponding register to avoid unnecessary Pin's mux
function change.
Change-Id: Ib3f7e7b6d4b401796733f5fbf52da73973f2efff
Signed-off-by: Fan Wu
---
drivers/pinctrl/core.c | 17 +++--
drivers/pinctrl/pinmux.c |4 ++--
drivers/pinctrl/pinmux.h |2 +-
3 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..42877c3 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -891,7 +891,7 @@ static void pinctrl_free_setting(bool disable_setting,
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
if (disable_setting)
- pinmux_disable_setting(setting);
+ pinmux_disable_setting(setting, 1);
pinmux_free_setting(setting);
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
@@ -998,20 +998,9 @@ int pinctrl_select_state(struct pinctrl *p, struct
pinctrl_state *state)
* safe/disabled state.
*/
list_for_each_entry(setting, >state->settings, node) {
- bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
- list_for_each_entry(setting2, >settings, node) {
- if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2->data.mux.group ==
- setting->data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_disable_setting(setting);
+ pinmux_disable_setting(setting, 0);
}
}
@@ -1055,7 +1044,7 @@ unapply_new_state:
* are free to be muxed by another apply_setting.
*/
if (setting2->type == PIN_MAP_TYPE_MUX_GROUP)
- pinmux_disable_setting(setting2);
+ pinmux_disable_setting(setting2, 1);
}
/* There's no infinite
Re: [PATCH] gpio: make of_get_named_gpiod_flags() private
On Tue, May 13, 2014 at 10:23 PM, Alexandre Courbot wrote: > On Tue, May 13, 2014 at 10:17 PM, Linus Walleij > wrote: >> On Sun, May 4, 2014 at 5:45 AM, Alexandre Courbot >> wrote: >> >>> of_get_named_gpiod_flags() is visible and directly usable by GPIO >>> consumers, but it really should not as the gpiod interface relies >>> on the simpler gpiod_get() to provide properly-configured GPIOs. >>> >>> of_get_named_gpiod_flags() is just used internally by gpiolib to >>> implement gpiod_get(), and by the old of_get_named_gpio_flags() >>> function, therefore it makes sense to make it gpiolib-private. >>> >>> As a side-effect, the unused (and unneeded) of_get_gpiod_flags() >>> inline function is also removed, and of_get_named_gpio_flags() is moved >>> from a static inline function to a regular one in gpiolib-of.c >>> >>> This results in all references to gpiod_* functions in of_gpio.h being >>> gone, which is the way it should be since this file is part of the old >>> integer GPIO interface. >>> >>> Signed-off-by: Alexandre Courbot >> >> This patch broke a lot of drivers so I had to take it out again... > > That's unexpected - what happens with it? I double-checked the patch and tested it on some ARM boards, couldn't find anything wrong during compilation and runtime. Would appreciate some specifics about what broke so I can address the issue. Thanks, Alex. -- 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] ARM: tegra: enable joystick in tegra_defconfig
NVIDIA SHIELD embeds a USB joystick device. Enable the corresponding support in tegra_defconfig. Signed-off-by: Alexandre Courbot --- Changes since v1: - Have support built-in instead of as a module - Fixed wording in commit message arch/arm/configs/tegra_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig index 8c1625b78034..1faa68f8988b 100644 --- a/arch/arm/configs/tegra_defconfig +++ b/arch/arm/configs/tegra_defconfig @@ -114,6 +114,7 @@ CONFIG_USB_NET_SMSC95XX=y CONFIG_BRCMFMAC=m CONFIG_RT2X00=y CONFIG_RT2800USB=m +CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y CONFIG_KEYBOARD_GPIO=y CONFIG_KEYBOARD_TEGRA=y -- 1.9.2 -- 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.12 000/182] 3.12.20-stable review
On 05/13/2014 03:26 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.20 release. There are 182 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Thu May 15 09:25:52 2014 Anything received after that time might be too late. The whole patch series can be found in one patch at: http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.20-rc1.xz and the diffstat can be found below. thanks, js Compiled and booted on my test system. No dmesg regressions. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- 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] pinctrl: add params in disable_setting for different usage
From: Fan Wu
The patch added params in disable_setting to differ the two possible usage,
1.Only want to disable the pin setting in SW aspect, param can be set to "0"
2.Want to disable the pin setting in both HW and SW aspect, param can be set to
"1";
The reason why to do this is that:
To avoid duplicated enable_setting operation without disabling operation which
will
let Pin's desc->mux_usecount keep being added.
In the following case, the issue can be reproduced:
1)There is a driver need to switch Pin state dynamicly, E.g. b/t "sleep" and
"default" state
2)The Pin setting configuration in the two state is same, like the following
one:
component a {
pinctrl-names = "default", "sleep";
pinctrl-0 = <_grp_setting _grp_setting>;
pinctrl-1 = <_grp_setting _grp_setting>;
}
The "c_grp_setting" config node is totaly same, maybe like following one:
c_grp_setting: c_grp_setting {
pinctrl-single,pins = ;
MFP_DEFAULT;
}
3)When switch the Pin state in the following official Pinctrl sequence:
pin = pinctrl_get();
state = pinctrl_lookup_state(wanted_state);
pinctrl_select_state(state);
pinctrl_put();
Test Result:
1)The switch change is completed as expectation, that is: component's
Pins configuration are changed according to the description in the
"wanted_state" group setting
2)The "desc->mux_usecount" of corresponding Pins in "c_group" is added without
being
decreased, due to the original reason mentioned in this patch.
According to the comments in the original code, only the setting, in old state
but not in new state, will be "disable"(calling pinmux_disable_setting), which
is correct logic but not intact. We still need consider case that the setting
is in both old state and new state.
We can do this in the following two ways:
1) Avoid "enable"(calling pinmux_enable_setting) the Same Pins setting
repeatedly.
2) "Disable"(calling pinmux_disable_setting) the Same Pins setting ahead of
enable them.
Analysis:
1.The solution 2# is better because it can avoid too much iteration.
2.If we disable all of the setting in the old state and one/ones of the
setting(s) is/are
existed in the new state, the Pin's mux function change may happen when
some SoC vendors defined the "pinctrl-single,function-off" in their DTS file.
old_setting=>disabled_setting=>new_setting.
3.In the pinmux framework, when Pin state is switched, the setting in the old
state should be
marked as "disabled" in my understanding.
Conclusion:
Thus, the patch handle the issue mentioned above by disabling the c_grp_setting
in SW asepct without
touch the HW corresponding register to avoid unnecessary Pin's mux
function change.
Change-Id: Ib3f7e7b6d4b401796733f5fbf52da73973f2efff
Signed-off-by: Fan Wu
---
drivers/pinctrl/core.c | 17 +++--
drivers/pinctrl/pinmux.c |4 ++--
drivers/pinctrl/pinmux.h |2 +-
3 files changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index c0fe609..42877c3 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -891,7 +891,7 @@ static void pinctrl_free_setting(bool disable_setting,
switch (setting->type) {
case PIN_MAP_TYPE_MUX_GROUP:
if (disable_setting)
- pinmux_disable_setting(setting);
+ pinmux_disable_setting(setting, 1);
pinmux_free_setting(setting);
break;
case PIN_MAP_TYPE_CONFIGS_PIN:
@@ -998,20 +998,9 @@ int pinctrl_select_state(struct pinctrl *p, struct
pinctrl_state *state)
* safe/disabled state.
*/
list_for_each_entry(setting, >state->settings, node) {
- bool found = false;
if (setting->type != PIN_MAP_TYPE_MUX_GROUP)
continue;
- list_for_each_entry(setting2, >settings, node) {
- if (setting2->type != PIN_MAP_TYPE_MUX_GROUP)
- continue;
- if (setting2->data.mux.group ==
- setting->data.mux.group) {
- found = true;
- break;
- }
- }
- if (!found)
- pinmux_disable_setting(setting);
+ pinmux_disable_setting(setting, 0);
}
}
@@ -1055,7 +1044,7 @@ unapply_new_state:
* are free to be muxed by another apply_setting.
*/
if (setting2->type == PIN_MAP_TYPE_MUX_GROUP)
- pinmux_disable_setting(setting2);
+ pinmux_disable_setting(setting2, 1);
}
/* There's no infinite recursive loop here because p->state is NULL */
diff --git
Re: [PATCH] ARM: tegra: enable console framebuffer rotation
On 05/14/2014 05:16 AM, Andreas Färber wrote: Am 09.05.2014 17:24, schrieb Stephen Warren: On 05/09/2014 08:20 AM, Andreas Färber wrote: Am 08.05.2014 01:40, schrieb Alex Courbot: On 05/08/2014 12:57 AM, Stephen Warren wrote: On 05/06/2014 09:18 PM, Alexandre Courbot wrote: Console rotation is needed for devices like Tegra Note 7 and NVIDIA SHIELD to get the boot console in the expected orientation. I've squashed this into Tegra's for-3.16/defconfig branch. Can you please also update multi_v7_defconfig, and send that change to arm-soc (a...@kernel.org) to be applied. Thanks. I omitted doing this for now because the devices that require this option (TN7/SHIELD) need a custom build with appended DTB and/or command-line anyway. Therefore they cannot use a multi-mach kernel What does appending a .dtb have to do with whether or not to use a multi-mach kernel? We package zImage/uImage and .dtbs separately, so surely the multi_v7_defconfig should be kept working with Tegra devices. Appending a .dtb only comes into play for preparing installation images. That would be a reasonable argument if generic distro installers or kernel packages were likely to support the TN7 and SHIELD. However, given the bootloader situation there and the need for a custom kernel anyway for APPENDED_DTB, I assume that's not the case on this particular device? The Shield we probably don't, the TN7 I don't know. I was more concerned about the shortened justification. If you do intend to support this device with SuSe installer and kernel packages, could you give an outline of how you do so? I gave a presentation at embedded world Conference 2014 on how standard distributions work on ARM/AArch64, but I fear the slides are not online. As far as possible, we use a single kernel source and a "default" or "lpae" v7 multi-platform config with lots of modules enabled. http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl [*] I just double-checked, and we do have CONFIG_ARM_APPENDED_DTB=y enabled. It does not restrict supplying the .dtb the "normal" way AIUI. Our Open Build Service instance then builds a kernel-default .rpm package containing zImage and modules. The .dts files are separately compiled and packaged as, e.g., dtb-tegra2 for /boot/dtb/tegra20-*.dtb. For building initrd, U-Boot boot.scr (including kernel command line) and installation image, we use Kiwi. Anyway, we don't rely on the defconfigs for our distro, so do as you see fit; just gently reminding that it's not feasible for everyone to build kernels per device, as the above comment seemed to suggest. To be completely clear, we didn't expect these devices to be of interest to distros, due to the limitation of their bootloaders. Both SHIELD and TN7 come with a locked bootloader and cannot use U-boot. The bootloader can only boot a kernel from a dedicated, raw boot partition (Android style), can only pass a device tree from another raw "dtb" partition, and will fill it with plenty of dirty command-line options that make mainline unusable. That seems to be a lot for distros to handle, so at this stage we'd rather advise users to use a root FS image of their favorite distro along with a self-compiled kernel. That being said I only have a short-range view of the issue, so if you know of a way a distro installer could handle this and think it is worth doing, I'll be happy to cooperate here. Thanks, Alex. -- 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 17/25] parisc: Add 32 bit time_t and clock_t
On Wed, May 14, 2014 at 4:17 AM, Helge Deller wrote: > Hi Ley, > > On 05/13/2014 11:06 AM, Ley Foon Tan wrote: >> Override time_t and clock_t in include/uapi/asm-generic. >> >> Signed-off-by: Ley Foon Tan >> --- >> arch/parisc/include/uapi/asm/posix_types.h | 8 >> 1 file changed, 8 insertions(+) >> >> diff --git a/arch/parisc/include/uapi/asm/posix_types.h >> b/arch/parisc/include/uapi/asm/posix_types.h >> index b934425..21fcf1c 100644 >> --- a/arch/parisc/include/uapi/asm/posix_types.h >> +++ b/arch/parisc/include/uapi/asm/posix_types.h >> @@ -19,6 +19,14 @@ typedef int__kernel_suseconds_t; >> typedef long long__kernel_off64_t; >> typedef unsigned long long __kernel_ino64_t; >> >> +#ifndef CONFIG_64BIT > > We can't use CONFIG_64BIT for a userspace header file. Please use > #if !defined(__LP64__) > instead. > But even then I'm not sure if it's all correct... Okay, will change to this. Maybe can try compile and boot with this change. Thanks. Regards Ley Foon -- 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 04/25] avr32: Add 32 bit time_t and clock_t
On Wed, May 14, 2014 at 4:19 AM, Hans-Christian Egtvedt wrote: > Around Tue 13 May 2014 17:02:49 +0800 or thereabout, Ley Foon Tan wrote: >> Override time_t and clock_t in include/uapi/asm-generic. >> >> Signed-off-by: Ley Foon Tan > > Acked-by: Hans-Christian Egtvedt > > > Quickly looked over some of the other patches in the series, and they all > seem to add the same. Could this be generic, with the possibility for arch to > override? In this patchset, the generic one will be 64 bit (long long). So, the existing 32 bit users need to override this. Regards Ley Foon -- 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] HID: hid-sensor-hub: Fix lockdep warning for dynamic callback locks.
Here is a sample of the kernel lockdep warning I got after turingon
dynamic debugging:
https://bugzilla.kernel.org/show_bug.cgi?id=73321#c3
On Tue, May 13, 2014 at 8:03 PM, Reyad Attiyat wrote:
> Changes all dyn_callback_lock spinlocks to spinlocks that disable
> interrupts. The dynamic callback lock (dyn_callback_lock) must not be
> interrupted when locked as it is used in an interrupt handler
> function, sensor_hub_raw_event.
> ---
> drivers/hid/hid-sensor-hub.c | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index af8244b..1e1644c 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -133,10 +133,11 @@ static struct hid_sensor_hub_callbacks
> *sensor_hub_get_callback(
> struct hid_sensor_hub_device **hsdev,
> void **priv)
> {
> + unsigned long flags;
> struct hid_sensor_hub_callbacks_list *callback;
> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
>
> - spin_lock(>dyn_callback_lock);
> + spin_lock_irqsave(>dyn_callback_lock, flags);
> list_for_each_entry(callback, >dyn_callback_list, list)
> if (callback->usage_id == usage_id &&
> (collection_index >=
> @@ -145,10 +146,10 @@ static struct hid_sensor_hub_callbacks
> *sensor_hub_get_callback(
> callback->hsdev->end_collection_index)) {
> *priv = callback->priv;
> *hsdev = callback->hsdev;
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
> return callback->usage_callback;
> }
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
>
> return NULL;
> }
> @@ -157,19 +158,20 @@ int sensor_hub_register_callback(struct
> hid_sensor_hub_device *hsdev,
> u32 usage_id,
> struct hid_sensor_hub_callbacks *usage_callback)
> {
> + unsigned long flags;
> struct hid_sensor_hub_callbacks_list *callback;
> struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
>
> - spin_lock(>dyn_callback_lock);
> + spin_lock_irqsave(>dyn_callback_lock, flags);
> list_for_each_entry(callback, >dyn_callback_list, list)
> if (callback->usage_id == usage_id &&
> callback->hsdev == hsdev) {
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
> return -EINVAL;
> }
> callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
> if (!callback) {
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
> return -ENOMEM;
> }
> callback->hsdev = hsdev;
> @@ -177,7 +179,7 @@ int sensor_hub_register_callback(struct
> hid_sensor_hub_device *hsdev,
> callback->usage_id = usage_id;
> callback->priv = NULL;
> list_add_tail(>list, >dyn_callback_list);
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
>
> return 0;
> }
> @@ -186,10 +188,11 @@ EXPORT_SYMBOL_GPL(sensor_hub_register_callback);
> int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
> u32 usage_id)
> {
> + unsigned long flags;
> struct hid_sensor_hub_callbacks_list *callback;
> struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
>
> - spin_lock(>dyn_callback_lock);
> + spin_lock_irqsave(>dyn_callback_lock, flags);
> list_for_each_entry(callback, >dyn_callback_list, list)
> if (callback->usage_id == usage_id &&
> callback->hsdev == hsdev) {
> @@ -197,7 +200,7 @@ int sensor_hub_remove_callback(struct
> hid_sensor_hub_device *hsdev,
> kfree(callback);
> break;
> }
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
>
> return 0;
> }
> @@ -376,34 +379,36 @@ EXPORT_SYMBOL_GPL(sensor_hub_input_get_attribute_info);
> #ifdef CONFIG_PM
> static int sensor_hub_suspend(struct hid_device *hdev, pm_message_t message)
> {
> + unsigned long flags;
> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
> struct hid_sensor_hub_callbacks_list *callback;
>
> hid_dbg(hdev, " sensor_hub_suspend\n");
> - spin_lock(>dyn_callback_lock);
> + spin_lock_irqsave(>dyn_callback_lock, flags);
> list_for_each_entry(callback, >dyn_callback_list, list) {
> if (callback->usage_callback->suspend)
> callback->usage_callback->suspend(
> callback->hsdev, callback->priv);
> }
> - spin_unlock(>dyn_callback_lock);
> + spin_unlock_irqrestore(>dyn_callback_lock, flags);
>
> return 0;
> }
>
> static int sensor_hub_resume(struct hid_device *hdev)
> {
> + unsigned long flags;
> struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
> struct hid_sensor_hub_callbacks_list *callback;
>
> hid_dbg(hdev, " sensor_hub_resume\n");
> - spin_lock(>dyn_callback_lock);
> + spin_lock_irqsave(>dyn_callback_lock, flags);
> list_for_each_entry(callback, >dyn_callback_list, list) {
> if (callback->usage_callback->resume)
> callback->usage_callback->resume(
> callback->hsdev, callback->priv);
> }
> - spin_unlock(>dyn_callback_lock);
> +
[PATCH] HID: hid-sensor-hub: Add Microsoft Surface Pro 2 HID ID and set report quirk
---
drivers/hid/hid-ids.h| 3 +++
drivers/hid/hid-sensor-hub.c | 9 +
2 files changed, 12 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 34bb220..18e2099 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -633,6 +633,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_45000x076c
+#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER0x3201
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index be14b56..eefaaf6 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -711,6 +711,15 @@ static const struct hid_device_id sensor_hub_devices[] = {
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB,
USB_VENDOR_ID_TEXAS_INSTRUMENTS,
USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_SURFACE_PRO_2),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_TYPE_COVER_2),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
HID_ANY_ID) },
{ }
--
1.9.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/
[ANN] Squashfs tools 4.3 released
Hi, I'm pleased to announce the release of Squashfs tools 4.3. This is the first release in over 3 years, and there are substantial improvements to stability, new compression options and compressors, speed optimisations, new options for Mksquashfs/Unsquashfs, and fixes for CVE-2012-4024 and CVE-2012-4025. The new release can be downloaded here: http://sourceforge.net/projects/squashfs/files/latest/download?source=files Changes in Squashfs-tools 4.3 - 1. Stability improvements. Better checking of user input for out of range/invalid values. Better handling of corrupted Squashfs filesystems (Mksquashfs append mode, and Unsquashfs). Better handling of buffer overflow/underflow. 2. GZIP compressor now supports compression options, allowing different compression levels to be used. 3. Rewritten LZO compressor with compression options, allowing different LZO algorithms and different compression levels to be used. 4. New LZ4 compressor (note not yet in mainline kernel) 5. Better default memory usage for Mksquashfs. Mksquashfs by default now uses 25% of physical memory. 6. Duplicate checking in Mksquashfs further optimised. With certain "problem filesystems" greater than 2x performance improvement. Filesystems with a lot of duplicates should see at least 10-20% speed improvement. 7. The -stat option in Unsquashfs now displays the compression options used to generate the original filesystem. Previously -stat only displayed the compression algorithm used. 8. The file being compressed/uncompressed in Mksquashfs/Unsquashfs is now displayed if CTRL-\ (SIGQUIT from keyboard) typed. 9. The status of the internal queues/caches in Mksquashfs/Unsquashfs is now displayed if CTRL-\ (SIGQUIT from keyboard) is typed twice within one second. Normally only useful for "power users", but it can be used to discover if there's any bottlenecks affecting performance (the bottleneck will normally be the compressors/fragment compressors). 10. Miscellaneous new options for Mksquashfs/Unsquashfs to fine tune behaviour. 11. Fixes for CVE-2012-4024 and CVE-2012-4025. Compatiblity Mksquashfs 4.3 generates 4.0 filesystems. These filesystems are fully compatible/interchangable with filesystems generated by Mksquashfs 4.0 and are mountable on 2.6.29 and later kernels. Compressors --- New compression options and compressors are now supported. The new options and compressors are: 1. gzip -Xcompression-level should be 1 .. 9 (default 9) -Xwindow-size should be 8 .. 15 (default 15) -Xstrategy strategy1,strategy2,...,strategyN Compress using strategy1,strategy2,...,strategyN in turn and choose the best compression. Available strategies: default, filtered, huffman_only, run_length_encoded and fixed 2. lzo -Xalgorithm Where is one of: lzo1x_1 lzo1x_1_11 lzo1x_1_12 lzo1x_1_15 lzo1x_999 (default) -Xcompression-level should be 1 .. 9 (default 8) Only applies to lzo1x_999 algorithm 3. lz4 -Xhc Compress using LZ4 High Compression The compression specific options are, obviously, specific to the compressor in question, and you should read the compressor documentation and check their web sites to understand their behaviour. In general the defaults used by Mksquashfs for each compressor are optimised to give the best performance for each compressor, where what constitutes best depends on the compressor. For gzip/xz best means highest compression (trying multiple filters/strategies can improve compression, but this is extremely expensive computationally, and hence, not suitable for the defaults), for LZO/LZ4 best means a tradeoff between compression and (de)-compression overhead (LZO/LZ4 by definition are intended for weaker processors). New Mksquashfs options -- 1. -mem Set the amount of memory used by Mksquashfs to bytes. G/M and K post-fixes are supported. By default Mksquashfs uses 25% of the physical memory. Increasing this with the -mem option can increase performance (note it does not have any effect on compression). Reducing it can prevent thrashing if the system is busy and there is not 25% of physical memory free (again, note it does not have any effect on compression). 2. -exit-on-error By default Mksquashfs treats certain errors as benign, if these errors occur Mksquashfs prints the error on the console but continues. These errors are typically failure to read a file from the source filesystem. This is deliberate, in many cases users prefer Mksquashfs to flag the error but continue rather than abort what may be hours of
Re: [E1000-devel] [PATCH] e1000: remove the check: skb->len<=0
The check is not right, it should be "(int)(skb->len) <= 0", or we
just remove this check if "skb->len will never be negative or 0".
2014-05-13 22:57 GMT+08:00 Ronciak, John :
>> -Original Message-
>> From: xuyongjia...@gmail.com [mailto:xuyongjia...@gmail.com]
>> Sent: Monday, May 12, 2014 10:07 PM
>> To: eric.duma...@gmail.com
>> Cc: e1000-de...@lists.sourceforge.net; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; Yongjian Xu
>> Subject: [E1000-devel] [PATCH] e1000: remove the check: skb->len<=0
>>
>> From: Yongjian Xu
>>
>> There is no case skb->len would be 0 or 'negative'.
>> Remove the check.
>>
>> Signed-off-by: Yongjian Xu
>> ---
>> drivers/net/ethernet/intel/e1000/e1000_main.c | 5 -
>> 1 file changed, 5 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> index 27058df..660971f 100644
>> --- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>> +++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>> @@ -3105,11 +3105,6 @@ static netdev_tx_t e1000_xmit_frame(struct
>> sk_buff *skb,
>>*/
>> tx_ring = adapter->tx_ring;
>>
>> - if (unlikely(skb->len <= 0)) {
>> - dev_kfree_skb_any(skb);
>> - return NETDEV_TX_OK;
>> - }
>> -
>> /* On PCI/PCI-X HW, if packet size is less than ETH_ZLEN,
>>* packets may get corrupted during padding by HW.
>>* To WA this issue, pad all small packets manually.
>> --
>> 1.9.1
> What is the exact problem that this is fixing? Did you have a test case that
> showed a problem with it?
>
> Cheers,
> John
>
>
--
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: [RESEND v2 PATCH 0/2] Bug fix in aio ring page migration
Hi Greg, Thanks for your attention on this thread. On 05/14/2014 07:58 AM, Greg Kroah-Hartman wrote: > On Thu, Mar 13, 2014 at 05:45:42PM +0800, Gu Zheng wrote: >> This patchset has been applied to linux-next, and these problems also exist >> in 3.12.y and 3.13.y stable tree. >> So please merge this patchset to 3.12.y and 3.13.y stable tree. >> >> commit 692c9b8c5ee8d263bb8348171f0bebd3d84eb2c1 >> Author: Tang Chen >> Date: Mon Mar 10 16:15:33 2014 +0800 >> >> aio, memory-hotplug: Fix confliction when migrating and accessing ring >> pages. >> >> commit e0f5e0add36d2e3c456cf2f4283673ed834b3c24 >> Author: Tang Chen >> Date: Mon Mar 10 16:15:34 2014 +0800 >> >> aio, mem-hotplug: Add memory barrier to aio ring page migration. >> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/aio.c?id=692c9b8c5ee8d263bb8348171f0bebd3d84eb2c1 >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/aio.c?id=e0f5e0add36d2e3c456cf2f4283673ed834b3c24 >> >> https://lkml.org/lkml/2014/3/10/56 >> https://lkml.org/lkml/2014/3/10/58 > > I don't see these in Linus's tree, what happened? These two patches were replaced by the better one from Benjamin, and it has been merged into upstream. commit fa8a53c39f3fdde98c9eace6a9b412143f0f6ed6 Author: Benjamin LaHaise Date: Fri Mar 28 10:14:45 2014 -0400 aio: v4 ensure access to ctx->ring_pages is correctly serialised for migration And I have already received the notify that it has been applied into stable tree. Best regards, Gu > > thanks, > > greg k-h > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to majord...@kvack.org. For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"a...@kvack.org;>a...@kvack.org > . > -- 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/
kernel crash in bus_find_device
While scanning devices on pci_bus_type I ran into the crash below. The immediate cause of the crash is that bus_find_device is trying to resume a scan starting from a device that has been unregistered (and whose knode_bus has already been klist_del' ed). The main issue seems to be that when resuming a scan the caller should be holding a reference to the klist_node, but instead it relies on holding a reference to the device. I played with a couple of narrow fixes, but a clean solution would affect quite a bit of code. Has anybody run into this before? Thanks, Francesco Ruggeri [ cut here ] WARNING: at /bld/EosKernel/Artools-rpmbuild/linux-3.4/include/linux/kref.h:41 klist_iter_init_node+0x30/0x38() Modules linked in: pci_scan(O) sch_prio sand_dma(PO) arista_bde(PO) macvlan ip6table_mangle iptable_mangle msr nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_LOG xt_limit ipt_REJECT xt_hl xt_state xt_multiport xt_tcpudp kbfd(O) 8021q garp stp llc tun scd_em_driver(O) nf_conntrack_tftp iptable_raw iptable_filter ip_tables xt_NOTRACK nf_conntrack xt_mark ip6table_raw ip6table_filter ip6_tables x_tables scd(O) k8temp amd64_edac_mod hwmon kvm_amd kvm Pid: 6861, comm: pci_scan_0 Tainted: P O 3.4.43.Ar-1797671.flbocafruggeri #1 Call Trace: [] warn_slowpath_common+0x80/0x98 [] ? pci_do_find_bus+0x49/0x49 [] warn_slowpath_null+0x15/0x17 [] klist_iter_init_node+0x30/0x38 [] bus_find_device+0x48/0x90 [] pci_get_dev_by_id+0x5e/0x81 [] pci_get_subsys+0x5c/0x7f [] pci_get_device+0x11/0x13 [] pci_scan+0x39/0x8a [pci_scan] [] ? init_module+0x3c/0x3c [pci_scan] [] kthread+0x84/0x8c [] kernel_thread_helper+0x4/0x10 [] ? __init_kthread_worker+0x37/0x37 [] ? gs_change+0xb/0xb ---[ end trace 79cea1ec476672fe ]--- [ cut here ] WARNING: at /bld/EosKernel/Artools-rpmbuild/linux-3.4/lib/klist.c:189 klist_release+0x2b/0xeb() Modules linked in: pci_scan(O) sch_prio sand_dma(PO) arista_bde(PO) macvlan ip6table_mangle iptable_mangle msr nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_LOG xt_limit ipt_REJECT xt_hl xt_state xt_multiport xt_tcpudp kbfd(O) 8021q garp stp llc tun scd_em_driver(O) nf_conntrack_tftp iptable_raw iptable_filter ip_tables xt_NOTRACK nf_conntrack xt_mark ip6table_raw ip6table_filter ip6_tables x_tables scd(O) k8temp amd64_edac_mod hwmon kvm_amd kvm Pid: 6861, comm: pci_scan_0 Tainted: PW O 3.4.43.Ar-1797671.flbocafruggeri #1 Call Trace: [] warn_slowpath_common+0x80/0x98 [] ? bus_get_device_klist+0x10/0x10 [] warn_slowpath_null+0x15/0x17 [] klist_release+0x2b/0xeb [] klist_dec_and_del+0x1e/0x25 [] klist_next+0x35/0xc9 [] ? pci_do_find_bus+0x49/0x49 [] next_device+0x9/0x19 [] bus_find_device+0x6c/0x90 [] pci_get_dev_by_id+0x5e/0x81 [] pci_get_subsys+0x5c/0x7f [] pci_get_device+0x11/0x13 [] pci_scan+0x39/0x8a [pci_scan] [] ? init_module+0x3c/0x3c [pci_scan] [] kthread+0x84/0x8c [] kernel_thread_helper+0x4/0x10 [] ? __init_kthread_worker+0x37/0x37 [] ? gs_change+0xb/0xb ---[ end trace 79cea1ec476672ff ]--- general protection fault: [#1] PREEMPT SMP CPU 1 Modules linked in: pci_scan(O) sch_prio sand_dma(PO) arista_bde(PO) macvlan ip6table_mangle iptable_mangle msr nf_conntrack_ipv6 nf_defrag_ipv6 ip6t_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_LOG xt_limit ipt_REJECT xt_hl xt_state xt_multiport xt_tcpudp kbfd(O) 8021q garp stp llc tun scd_em_driver(O) nf_conntrack_tftp iptable_raw iptable_filter ip_tables xt_NOTRACK nf_conntrack xt_mark ip6table_raw ip6table_filter ip6_tables x_tables scd(O) k8temp amd64_edac_mod hwmon kvm_amd kvm Pid: 6861, comm: pci_scan_0 Tainted: PW O 3.4.43.Ar-1797671.flbocafruggeri #1 RIP: 0010:[] [] klist_release+0x49/0xeb RSP: 0018:88001c55bd50 EFLAGS: 00010293 RAX: dead00200200 RBX: 880030949e78 RCX: 8810 RDX: dead00100100 RSI: RDI: dead00200200 RBP: 88001c55bd70 R08: dead00100100 R09: 000a R10: R11: 81619920 R12: 880030949e90 R13: 880030949e78 R14: 8120de13 R15: 880027e717e0 FS: () GS:88013fb0() knlGS:f73bc6d0 CS: 0010 DS: ES: CR0: 8005003b CR2: 09012644 CR3: 69f9e000 CR4: 07e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process pci_scan_0 (pid: 6861, threadinfo 88001c55a000, task 880032ffd340) Stack: 880030949e78 88001c55bde0 dead00100100 880030949e78 88001c55bd80 813a44ec 88001c55bdc0 813a4528 88001c55bde0 880027e717e0 811b57f1 88001c55bde0 Call Trace: [] klist_dec_and_del+0x1e/0x25 [] klist_next+0x35/0xc9 [] ? pci_do_find_bus+0x49/0x49 [] next_device+0x9/0x19 [] bus_find_device+0x6c/0x90 [] pci_get_dev_by_id+0x5e/0x81 [] pci_get_subsys+0x5c/0x7f
Re: [PATCH] HID: hid-sensor-hub: Add and set report quirk for Microsoft Surface Pro 2
Ignore this patch I'll have to resend
On Tue, May 13, 2014 at 7:53 PM, Reyad Attiyat wrote:
> ---
> drivers/hid/hid-ids.h| 3 +++
> drivers/hid/hid-sensor-hub.c | 8
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 34bb220..18e2099 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -633,6 +633,9 @@
> #define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
> #define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
> #define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
> +#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
> +#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
> +#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
>
> #define USB_VENDOR_ID_MOJO 0x8282
> #define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
> diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
> index be14b56..f6dc7ea 100644
> --- a/drivers/hid/hid-sensor-hub.c
> +++ b/drivers/hid/hid-sensor-hub.c
> @@ -710,6 +710,14 @@ static const struct hid_device_id sensor_hub_devices[] =
> {
> .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB,
> USB_VENDOR_ID_TEXAS_INSTRUMENTS,
> USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_SURFACE_PRO_2),
> + .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_TOUCH_COVER_2),
> + .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> + { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
> + USB_DEVICE_ID_MS_TYPE_COVER_2),
> .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
> { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
> HID_ANY_ID) },
> --
> 1.9.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] HID: hid-sensor-hub: Fix lockdep warning for dynamic callback locks.
Changes all dyn_callback_lock spinlocks to spinlocks that disable
interrupts. The dynamic callback lock (dyn_callback_lock) must not be
interrupted when locked as it is used in an interrupt handler
function, sensor_hub_raw_event.
---
drivers/hid/hid-sensor-hub.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index af8244b..1e1644c 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -133,10 +133,11 @@ static struct hid_sensor_hub_callbacks
*sensor_hub_get_callback(
struct hid_sensor_hub_device **hsdev,
void **priv)
{
+ unsigned long flags;
struct hid_sensor_hub_callbacks_list *callback;
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
- spin_lock(>dyn_callback_lock);
+ spin_lock_irqsave(>dyn_callback_lock, flags);
list_for_each_entry(callback, >dyn_callback_list, list)
if (callback->usage_id == usage_id &&
(collection_index >=
@@ -145,10 +146,10 @@ static struct hid_sensor_hub_callbacks
*sensor_hub_get_callback(
callback->hsdev->end_collection_index)) {
*priv = callback->priv;
*hsdev = callback->hsdev;
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return callback->usage_callback;
}
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return NULL;
}
@@ -157,19 +158,20 @@ int sensor_hub_register_callback(struct
hid_sensor_hub_device *hsdev,
u32 usage_id,
struct hid_sensor_hub_callbacks *usage_callback)
{
+ unsigned long flags;
struct hid_sensor_hub_callbacks_list *callback;
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
- spin_lock(>dyn_callback_lock);
+ spin_lock_irqsave(>dyn_callback_lock, flags);
list_for_each_entry(callback, >dyn_callback_list, list)
if (callback->usage_id == usage_id &&
callback->hsdev == hsdev) {
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return -EINVAL;
}
callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
if (!callback) {
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return -ENOMEM;
}
callback->hsdev = hsdev;
@@ -177,7 +179,7 @@ int sensor_hub_register_callback(struct
hid_sensor_hub_device *hsdev,
callback->usage_id = usage_id;
callback->priv = NULL;
list_add_tail(>list, >dyn_callback_list);
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return 0;
}
@@ -186,10 +188,11 @@ EXPORT_SYMBOL_GPL(sensor_hub_register_callback);
int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,
u32 usage_id)
{
+ unsigned long flags;
struct hid_sensor_hub_callbacks_list *callback;
struct sensor_hub_data *pdata = hid_get_drvdata(hsdev->hdev);
- spin_lock(>dyn_callback_lock);
+ spin_lock_irqsave(>dyn_callback_lock, flags);
list_for_each_entry(callback, >dyn_callback_list, list)
if (callback->usage_id == usage_id &&
callback->hsdev == hsdev) {
@@ -197,7 +200,7 @@ int sensor_hub_remove_callback(struct
hid_sensor_hub_device *hsdev,
kfree(callback);
break;
}
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return 0;
}
@@ -376,34 +379,36 @@ EXPORT_SYMBOL_GPL(sensor_hub_input_get_attribute_info);
#ifdef CONFIG_PM
static int sensor_hub_suspend(struct hid_device *hdev, pm_message_t message)
{
+ unsigned long flags;
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
struct hid_sensor_hub_callbacks_list *callback;
hid_dbg(hdev, " sensor_hub_suspend\n");
- spin_lock(>dyn_callback_lock);
+ spin_lock_irqsave(>dyn_callback_lock, flags);
list_for_each_entry(callback, >dyn_callback_list, list) {
if (callback->usage_callback->suspend)
callback->usage_callback->suspend(
callback->hsdev, callback->priv);
}
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return 0;
}
static int sensor_hub_resume(struct hid_device *hdev)
{
+ unsigned long flags;
struct sensor_hub_data *pdata = hid_get_drvdata(hdev);
struct hid_sensor_hub_callbacks_list *callback;
hid_dbg(hdev, " sensor_hub_resume\n");
- spin_lock(>dyn_callback_lock);
+ spin_lock_irqsave(>dyn_callback_lock, flags);
list_for_each_entry(callback, >dyn_callback_list, list) {
if (callback->usage_callback->resume)
callback->usage_callback->resume(
callback->hsdev, callback->priv);
}
- spin_unlock(>dyn_callback_lock);
+ spin_unlock_irqrestore(>dyn_callback_lock, flags);
return 0;
}
--
1.9.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] HID: Debug: Add labels for HID Sensor Usages
---
drivers/hid/hid-debug.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c
index 53b771d..25cc71c 100644
--- a/drivers/hid/hid-debug.c
+++ b/drivers/hid/hid-debug.c
@@ -272,6 +272,85 @@ static const struct hid_usage_entry hid_usage_table[] = {
{0, 0xAA, "Shared_Parameter_Blocks"},
{0, 0xAB, "Create_New_Effect_Report"},
{0, 0xAC, "RAM_Pool_Available"},
+ { 0x20, 0, "Sensor" },
+{ 0x20, 0x01, "Sensor" },
+{ 0x20, 0x10, "Biometric" },
+ { 0x20, 0x11, "BiometricHumanPresence" },
+ { 0x20, 0x12, "BiometricHumanProximity" },
+ { 0x20, 0x13, "BiometricHumanTouch" },
+{ 0x20, 0x20, "Electrical" },
+ { 0x20, 0x21, "ElectricalCapacitance" },
+ { 0x20, 0x22, "ElectricalCurrent" },
+ { 0x20, 0x23, "ElectricalPower" },
+ { 0x20, 0x24, "ElectricalInductance" },
+ { 0x20, 0x25, "ElectricalResistance" },
+ { 0x20, 0x26, "ElectricalVoltage" },
+ { 0x20, 0x27, "ElectricalPoteniometer" },
+ { 0x20, 0x28, "ElectricalFrequency" },
+ { 0x20, 0x29, "ElectricalPeriod" },
+{ 0x20, 0x30, "Environmental" },
+ { 0x20, 0x31, "EnvironmentalAtmosphericPressure" },
+ { 0x20, 0x32, "EnvironmentalHumidity" },
+ { 0x20, 0x33, "EnvironmentalTemperature" },
+ { 0x20, 0x34, "EnvironmentalWindDirection" },
+ { 0x20, 0x35, "EnvironmentalWindSpeed" },
+{ 0x20, 0x40, "Light" },
+ { 0x20, 0x41, "LightAmbientLight" },
+ { 0x20, 0x42, "LightConsumerInfrared" },
+{ 0x20, 0x50, "Location" },
+ { 0x20, 0x51, "LocationBroadcast" },
+ { 0x20, 0x52, "LocationDeadReckoning" },
+ { 0x20, 0x53, "LocationGPS" },
+ { 0x20, 0x54, "LocationLookup" },
+ { 0x20, 0x55, "LocationOther" },
+ { 0x20, 0x56, "LocationStatic" },
+ { 0x20, 0x57, "LocationTriangulation" },
+{ 0x20, 0x60, "Mechanical" },
+ { 0x20, 0x61, "MechanicalBooleanSwitch" },
+ { 0x20, 0x62, "MechanicalBooleanSwitchArray" },
+ { 0x20, 0x63, "MechanicalMultivalueSwitch" },
+ { 0x20, 0x64, "MechanicalForce" },
+ { 0x20, 0x65, "MechanicalPressure" },
+ { 0x20, 0x66, "MechanicalStrain" },
+ { 0x20, 0x67, "MechanicalWeight" },
+ { 0x20, 0x68, "MechanicalHapticVibrator" },
+ { 0x20, 0x69, "MechanicalHallEffectSwitch" },
+{ 0x20, 0x70, "Motion" },
+ { 0x20, 0x71, "MotionAccelerometer1D" },
+ { 0x20, 0x72, "MotionAccelerometer2D" },
+ { 0x20, 0x73, "MotionAccelerometer3D" },
+ { 0x20, 0x74, "MotionGyrometer1D" },
+ { 0x20, 0x75, "MotionGyrometer2D" },
+ { 0x20, 0x76, "MotionGyrometer3D" },
+ { 0x20, 0x77, "MotionMotionDetector" },
+ { 0x20, 0x78, "MotionSpeedometer" },
+ { 0x20, 0x79, "MotionAccelerometer" },
+ { 0x20, 0x7A, "MotionGyrometer" },
+{ 0x20, 0x80, "Orientation" },
+ { 0x20, 0x81, "OrientationCompass1D" },
+ { 0x20, 0x82, "OrientationCompass2D" },
+ { 0x20, 0x83, "OrientationCompass3D" },
+ { 0x20, 0x84, "OrientationInclinometer1D" },
+ { 0x20, 0x85, "OrientationInclinometer2D" },
+ { 0x20, 0x86, "OrientationInclinometer3D" },
+ { 0x20, 0x87, "OrientationDistance1D" },
+ { 0x20, 0x88, "OrientationDistance2D" },
+ { 0x20, 0x89, "OrientationDistance3D" },
+ { 0x20, 0x8A, "OrientationDeviceOrientation" },
+ { 0x20, 0x8B, "OrientationCompass" },
+ { 0x20, 0x8C, "OrientationInclinometer" },
+ { 0x20, 0x8D, "OrientationDistance" },
+{ 0x20, 0x90, "Scanner" },
+ { 0x20, 0x91, "ScannerBarcode" },
+ { 0x20, 0x91, "ScannerRFID" },
+ { 0x20, 0x91, "ScannerNFC" },
+{ 0x20, 0xA0, "Time" },
+ { 0x20, 0xA1, "TimeAlarmTimer" },
+ { 0x20, 0xA2, "TimeRealTimeClock" },
+{ 0x20, 0xE0, "Other" },
+ { 0x20, 0xE1, "OtherCustom" },
+ { 0x20, 0xE2, "OtherGeneric" },
+ { 0x20, 0xE3, "OtherGenericEnumerator" },
{ 0x84, 0, "Power Device" },
{ 0x84, 0x02, "PresentStatus" },
{ 0x84, 0x03, "ChangeStatus" },
--
1.9.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] HID: hid-sensor-hub: Add and set report quirk for Microsoft Surface Pro 2
---
drivers/hid/hid-ids.h| 3 +++
drivers/hid/hid-sensor-hub.c | 8
2 files changed, 11 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 34bb220..18e2099 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -633,6 +633,9 @@
#define USB_DEVICE_ID_MS_PRESENTER_8K_USB 0x0713
#define USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K 0x0730
#define USB_DEVICE_ID_MS_COMFORT_MOUSE_4500 0x076c
+#define USB_DEVICE_ID_MS_SURFACE_PRO_2 0x0799
+#define USB_DEVICE_ID_MS_TOUCH_COVER_2 0x07a7
+#define USB_DEVICE_ID_MS_TYPE_COVER_20x07a9
#define USB_VENDOR_ID_MOJO 0x8282
#define USB_DEVICE_ID_RETRO_ADAPTER 0x3201
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index be14b56..f6dc7ea 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -710,6 +710,14 @@ static const struct hid_device_id sensor_hub_devices[] = {
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB,
USB_VENDOR_ID_TEXAS_INSTRUMENTS,
USB_DEVICE_ID_TEXAS_INSTRUMENTS_LENOVO_YOGA),
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_SURFACE_PRO_2),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_TOUCH_COVER_2),
+ .driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
+ { HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, USB_VENDOR_ID_MICROSOFT,
+ USB_DEVICE_ID_MS_TYPE_COVER_2),
.driver_data = HID_SENSOR_HUB_ENUM_QUIRK},
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_SENSOR_HUB, HID_ANY_ID,
HID_ANY_ID) },
--
1.9.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 5/7] clk: sunxi: add PRCM (Power/Reset/Clock Management) clks support
Quoting Boris BREZILLON (2014-05-09 04:11:49)
> +struct clk_ops ar100_ops = {
> + .recalc_rate = ar100_recalc_rate,
> + .determine_rate = ar100_determine_rate,
> + .set_parent = ar100_set_parent,
> + .get_parent = ar100_get_parent,
> + .set_rate = ar100_set_rate,
> +};
I might be having a brain fart, but is there a valid case for having
both a .recalc_rate and a .determine_rate? I believe that the former
will never be used and the latter will always be used by the clock
framework core.
Regards,
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/
Re: [PATCH net] bridge: notify user space of fdb port change
(2014/05/13 16:55), Jon Maxwell wrote:
> From: Jon Maxwell
>
> There has been a number incidents recently where customers running KVM have
> reported that VM hosts on different Hypervisors are unreachable. Based on
> pcap traces we found that the bridge was broadcasting the ARP request out
> onto the network. However some NICs have an inbuilt switch which on occasions
> were broadcasting the VMs ARP request back through the physical NIC on the
> Hypervisor. This resulted in the bridge changing ports and incorrectly
> learning
> that the VMs mac address was external. As a result the ARP reply was directed
> back onto the external network and VM never updated it's ARP cache. This
> patch
> will notify the bridge command to identify such port toggling.
>
> Signed-off-by: Jon Maxwell
> ---
> net/bridge/br_fdb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index 9203d5a..37742e2 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -507,6 +507,8 @@ void br_fdb_update(struct net_bridge *br, struct
> net_bridge_port *source,
> source->dev->name);
> } else {
> /* fastpath: update of existing entry */
> + if (source->port_no != fdb->dst->port_no)
It seems that we don't need to fetch port_no and it is enough to compare
source and fdb->dst.
> + fdb_notify(br, fdb, RTM_NEWNEIGH);
> fdb->dst = source;
> fdb->updated = jiffies;
> if (unlikely(added_by_user))
>
This notifies fdb entry before updating existing entry. Is this on purpose?
I think we should notify the updated fdb entry.
Similar code fdb_add_entry() does after updating it.
Also, isn't it better to move update of dst into "if" block?
if (source != fdb->dst) {
fdb->dst = source;
modified = true;
}
...
if (modified) ...
Thanks,
Toshiaki Makita
--
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 tip/core/rcu 1/1] rcu: Variable name changed in tree_plugin.h and used in tree.c
From: Uma Sharma
The variable and struct both having the name "rcu_state" confuses
sparse in some situations, so this commit changes the variable to
"rcu_state_p" in order to avoid this confusion. This also makes
things easier for human readers.
Signed-off-by: Uma Sharma
[ paulmck: Changed the declaration and several additional uses. ]
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c| 16
kernel/rcu/tree_plugin.h | 16
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 3bbe48939e47..3e3f13e8b429 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -101,7 +101,7 @@ DEFINE_PER_CPU(struct rcu_data, sname##_data)
RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
RCU_STATE_INITIALIZER(rcu_bh, 'b', call_rcu_bh);
-static struct rcu_state *rcu_state;
+static struct rcu_state *rcu_state_p;
LIST_HEAD(rcu_struct_flavors);
/* Increase (but not decrease) the CONFIG_RCU_FANOUT_LEAF at boot time. */
@@ -275,7 +275,7 @@ EXPORT_SYMBOL_GPL(rcu_batches_completed_bh);
*/
void rcu_force_quiescent_state(void)
{
- force_quiescent_state(rcu_state);
+ force_quiescent_state(rcu_state_p);
}
EXPORT_SYMBOL_GPL(rcu_force_quiescent_state);
@@ -327,7 +327,7 @@ void rcutorture_get_gp_data(enum rcutorture_type test_type,
int *flags,
switch (test_type) {
case RCU_FLAVOR:
- rsp = rcu_state;
+ rsp = rcu_state_p;
break;
case RCU_BH_FLAVOR:
rsp = _bh_state;
@@ -910,7 +910,7 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
* we will beat on the first one until it gets unstuck, then move
* to the next. Only do this for the primary flavor of RCU.
*/
- if (rdp->rsp == rcu_state &&
+ if (rdp->rsp == rcu_state_p &&
ULONG_CMP_GE(jiffies, rdp->rsp->jiffies_resched)) {
rdp->rsp->jiffies_resched += 5;
resched_cpu(rdp->cpu);
@@ -2660,7 +2660,7 @@ EXPORT_SYMBOL_GPL(call_rcu_bh);
void kfree_call_rcu(struct rcu_head *head,
void (*func)(struct rcu_head *rcu))
{
- __call_rcu(head, func, rcu_state, -1, 1);
+ __call_rcu(head, func, rcu_state_p, -1, 1);
}
EXPORT_SYMBOL_GPL(kfree_call_rcu);
@@ -2787,7 +2787,7 @@ unsigned long get_state_synchronize_rcu(void)
* time-consuming work between get_state_synchronize_rcu()
* and cond_synchronize_rcu().
*/
- return smp_load_acquire(_state->gpnum);
+ return smp_load_acquire(_state_p->gpnum);
}
EXPORT_SYMBOL_GPL(get_state_synchronize_rcu);
@@ -2813,7 +2813,7 @@ void cond_synchronize_rcu(unsigned long oldstate)
* Ensure that this load happens before any RCU-destructive
* actions the caller might carry out after we return.
*/
- newstate = smp_load_acquire(_state->completed);
+ newstate = smp_load_acquire(_state_p->completed);
if (ULONG_CMP_GE(oldstate, newstate))
synchronize_rcu();
}
@@ -3354,7 +3354,7 @@ static int rcu_cpu_notify(struct notifier_block *self,
unsigned long action, void *hcpu)
{
long cpu = (long)hcpu;
- struct rcu_data *rdp = per_cpu_ptr(rcu_state->rda, cpu);
+ struct rcu_data *rdp = per_cpu_ptr(rcu_state_p->rda, cpu);
struct rcu_node *rnp = rdp->mynode;
struct rcu_state *rsp;
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 2e579c38bd91..29977ae84e7e 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -116,7 +116,7 @@ static void __init rcu_bootup_announce_oddness(void)
#ifdef CONFIG_TREE_PREEMPT_RCU
RCU_STATE_INITIALIZER(rcu_preempt, 'p', call_rcu);
-static struct rcu_state *rcu_state = _preempt_state;
+static struct rcu_state *rcu_state_p = _preempt_state;
static int rcu_preempted_readers_exp(struct rcu_node *rnp);
@@ -947,7 +947,7 @@ void exit_rcu(void)
#else /* #ifdef CONFIG_TREE_PREEMPT_RCU */
-static struct rcu_state *rcu_state = _sched_state;
+static struct rcu_state *rcu_state_p = _sched_state;
/*
* Tell them what RCU they are running.
@@ -1468,11 +1468,11 @@ static int __init rcu_spawn_kthreads(void)
for_each_possible_cpu(cpu)
per_cpu(rcu_cpu_has_work, cpu) = 0;
BUG_ON(smpboot_register_percpu_thread(_cpu_thread_spec));
- rnp = rcu_get_root(rcu_state);
- (void)rcu_spawn_one_boost_kthread(rcu_state, rnp);
+ rnp = rcu_get_root(rcu_state_p);
+ (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
if (NUM_RCU_NODES > 1) {
- rcu_for_each_leaf_node(rcu_state, rnp)
- (void)rcu_spawn_one_boost_kthread(rcu_state, rnp);
+ rcu_for_each_leaf_node(rcu_state_p, rnp)
+ (void)rcu_spawn_one_boost_kthread(rcu_state_p, rnp);
}
return 0;
}
@@ -1480,12 +1480,12 @@
Re: [PATCH v2 4/7] drivers/base: Add interface framework
On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
> On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Some drivers, such as graphics drivers in the DRM subsystem, do not have
> > a real device that they can bind to. They are often composed of several
> > devices, each having their own driver. The master/component framework
> > can be used in these situations to collect the devices pertaining to one
> > logical device, wait until all of them have registered and then bind
> > them all at once.
> >
> > For some situations this is only a partial solution. An implementation
> > of a master still needs to be registered with the system somehow. Many
> > drivers currently resort to creating a dummy device that a driver can
> > bind to and register the master against. This is problematic since it
> > requires (and presumes) knowledge about the system within drivers.
> >
> > Furthermore there are setups where a suitable device already exists, but
> > is already bound to a driver. For example, on Tegra the following device
> > tree extract (simplified) represents the host1x device along with child
> > devices:
> >
> > host1x {
> > display-controller {
> > ...
> > };
> >
> > display-controller {
> > ...
> > };
> >
> > hdmi {
> > ...
> > };
> >
> > dsi {
> > ...
> > };
> >
> > csi {
> > ...
> > };
> >
> > video-input {
> > ...
> > };
> > };
> >
> > Each of the child devices is in turn a client of host1x, in that it can
> > request resources (command stream DMA channels and syncpoints) from it.
> > To implement the DMA channel and syncpoint infrastructure, host1x comes
> > with its own driver. Children are implemented in separate drivers. In
> > Linux this set of devices would be exposed by DRM and V4L2 drivers.
> >
> > However, neither the DRM nor the V4L2 drivers have a single device that
> > they can bind to. The DRM device is composed of the display controllers
> > and the various output devices, whereas the V4L2 device is composed of
> > one or more video input devices.
> >
> > This patch introduces the concept of an interface and drivers that can
> > bind to a given interface. An interface can be exposed by any device,
> > and interface drivers can bind to these interfaces. Multiple drivers can
> > bind against a single interface. When a device is removed, interfaces
> > exposed by it will be removed as well, thereby removing the drivers that
> > were bound to those interfaces.
> >
> > In the example above, the host1x device would expose the "tegra-host1x"
> > interface. DRM and V4L2 drivers can then bind to that interface and
> > instantiate the respective subsystem objects from there.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Note that I'd like to merge this through the Tegra DRM tree so that the
> > changes to the Tegra DRM driver later in this series can be merged at
> > the same time and are not delayed for another release cycle.
> >
> > In particular that means that I'm looking for an Acked-by from Greg.
> >
> > drivers/base/Makefile | 2 +-
> > drivers/base/interface.c | 186
> > ++
> > include/linux/interface.h | 40 ++
> > 3 files changed, 227 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/base/interface.c
> > create mode 100644 include/linux/interface.h
>
> Hm, this interface stuff smells like bus drivers light. Should we instead
> have a pile of helpers to make creating new buses with match methods more
> trivial? There's a fairly big pile of small use-cases where this might be
> useful. In your case here all the host1x children would sit on a host1x
> bus. Admittedly I didn't look into the details.
I have no problem adding such "bus-light" functions, to make it easier
to create and implement a bus in the driver core, as I know it's really
heavy. That's been on my "todo" list for over a decade now...
thanks,
greg k-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/
Re: [patch 1/3] rtmutex: Add missing deadlock check
On Tue, May 13, 2014 at 07:53:36PM -0400, Steven Rostedt wrote: > On Tue, 13 May 2014 16:27:11 -0700 > "Paul E. McKenney" wrote: > > > On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote: > > > On Tue, 13 May 2014 15:00:09 -0700 > > > "Paul E. McKenney" wrote: > > > > > > > > > > Good points -- I was indeed thinking about stress testing instead of > > > > algorithmic testing. > > > > > > But doesn't lockdep use algorithmic tests too? > > > > I suppose you could argue that there is no such thing as non-algorithmic > > testing, given that all test code uses an algorithm of some sort. Perhaps > > with the exception of letting your pet walk across the keyboard. ;-) > > > > Perhaps I should have instead said that I was thinking about random > > testing instead of formal testing? > > Actually it still applies, but I was mistaken, it's not lockdep itself, > it's the LOCKING_API_SELFTESTS. They are a form of formal testing as > suppose to random testing. > > See lib/locking-selftest.c. > > That looks more like something we can do for the rtmutex code, or even > add to it. Ah, got it! That could work, though I would be tempted to try automatically generating the C code/tables/whatever from some behavioral specification. Of course, there is always the speculation about how I might feel about that approach after giving into such temptation... ;-) Thanx, Paul -- 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 v3] gcov: add support for GCC 4.9
From: Yuan Pengfei
This patch handles the gcov-related changes in GCC 4.9:
A new counter (time profile) is added. The total number is 9 now.
A new profile merge function __gcov_merge_time_profile is added.
See gcc/gcov-io.h and libgcc/libgcov-merge.c
For the first change, the layout of struct gcov_info is affected.
For the second one, a dummy function is added to kernel/gcov/base.c
similarly.
Signed-off-by: Yuan Pengfei
---
kernel/gcov/base.c| 6 ++
kernel/gcov/gcc_4_7.c | 5 +
2 files changed, 11 insertions(+)
diff --git a/kernel/gcov/base.c b/kernel/gcov/base.c
index f45b75b..b358a80 100644
--- a/kernel/gcov/base.c
+++ b/kernel/gcov/base.c
@@ -85,6 +85,12 @@ void __gcov_merge_ior(gcov_type *counters, unsigned int
n_counters)
}
EXPORT_SYMBOL(__gcov_merge_ior);
+void __gcov_merge_time_profile(gcov_type *counters, unsigned int
n_counters)
+{
+ /* Unused. */
+}
+EXPORT_SYMBOL(__gcov_merge_time_profile);
+
/**
* gcov_enable_events - enable event reporting through gcov_event()
*
diff --git a/kernel/gcov/gcc_4_7.c b/kernel/gcov/gcc_4_7.c
index 7465944..7f74b59 100644
--- a/kernel/gcov/gcc_4_7.c
+++ b/kernel/gcov/gcc_4_7.c
@@ -18,7 +18,12 @@
#include
#include "gcov.h"
+#if __GNUC__ == 4 && __GNUC_MINOR__ >= 9
+#define GCOV_COUNTERS 9
+#else
#define GCOV_COUNTERS 8
+#endif
+
#define GCOV_TAG_FUNCTION_LENGTH 3
static struct gcov_info *gcov_info_head;
--
2.0.0.rc2
--
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] sched,numa: move processes with load difference
Currently the numa balancing code refuses to move a task from a heavily loaded node to a much less heavily loaded node, if the difference in load between them is large enough. If the source load is larger than the destination load after the swap, moving the task is fine. Chances are the load balancer would move tasks in the same direction, anyway. Signed-off-by: Rik van Riel --- kernel/sched/fair.c | 4 1 file changed, 4 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6d9474c..98a018f 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1224,10 +1224,6 @@ static void task_numa_compare(struct task_numa_env *env, src_load += load; } - /* make src_load the smaller */ - if (dst_load < src_load) - swap(dst_load, src_load); - if (src_load * env->imbalance_pct < dst_load * 100) goto unlock; -- 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] Documentation/dma-buf-sharing.txt: update API descriptions
Update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim --- Documentation/dma-buf-sharing.txt | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..aadd901 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,10 +56,10 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a - pointer to the same. It also associates an anonymous file with this buffer, - so it can be exported. On failure to allocate the dma_buf object, it returns - NULL. + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and + returns a pointer to the same. It also associates an anonymous file with this + buffer, so it can be exported. On failure to allocate the dma_buf object, + it returns NULL. 'exp_name' is the name of exporter - to facilitate information while debugging. @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. "dma_buf->ops->" indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5 -- 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: [RESEND v2 PATCH 0/2] Bug fix in aio ring page migration
On Thu, Mar 13, 2014 at 05:45:42PM +0800, Gu Zheng wrote: > This patchset has been applied to linux-next, and these problems also exist > in 3.12.y and 3.13.y stable tree. > So please merge this patchset to 3.12.y and 3.13.y stable tree. > > commit 692c9b8c5ee8d263bb8348171f0bebd3d84eb2c1 > Author: Tang Chen > Date: Mon Mar 10 16:15:33 2014 +0800 > > aio, memory-hotplug: Fix confliction when migrating and accessing ring > pages. > > commit e0f5e0add36d2e3c456cf2f4283673ed834b3c24 > Author: Tang Chen > Date: Mon Mar 10 16:15:34 2014 +0800 > > aio, mem-hotplug: Add memory barrier to aio ring page migration. > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/aio.c?id=692c9b8c5ee8d263bb8348171f0bebd3d84eb2c1 > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/fs/aio.c?id=e0f5e0add36d2e3c456cf2f4283673ed834b3c24 > > https://lkml.org/lkml/2014/3/10/56 > https://lkml.org/lkml/2014/3/10/58 I don't see these in Linus's tree, what happened? thanks, greg k-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/
Re: [patch 1/3] rtmutex: Add missing deadlock check
On Tue, 13 May 2014 16:27:11 -0700 "Paul E. McKenney" wrote: > On Tue, May 13, 2014 at 06:44:30PM -0400, Steven Rostedt wrote: > > On Tue, 13 May 2014 15:00:09 -0700 > > "Paul E. McKenney" wrote: > > > > > > > Good points -- I was indeed thinking about stress testing instead of > > > algorithmic testing. > > > > But doesn't lockdep use algorithmic tests too? > > I suppose you could argue that there is no such thing as non-algorithmic > testing, given that all test code uses an algorithm of some sort. Perhaps > with the exception of letting your pet walk across the keyboard. ;-) > > Perhaps I should have instead said that I was thinking about random > testing instead of formal testing? Actually it still applies, but I was mistaken, it's not lockdep itself, it's the LOCKING_API_SELFTESTS. They are a form of formal testing as suppose to random testing. See lib/locking-selftest.c. That looks more like something we can do for the rtmutex code, or even add to it. -- Steve -- 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] Documentation/dma-buf-sharing.txt: update API descriptions
Thank you for advice. I will send a fixed patch soon. > -Original Message- > From: Thierry Reding [mailto:thierry.red...@gmail.com] > Sent: Tuesday, May 13, 2014 5:45 PM > To: gioh.kim > Cc: Sumit Semwal; Randy Dunlap; linux-me...@vger.kernel.org; > dri-de...@lists.freedesktop.org; linux- > d...@vger.kernel.org; linux-kernel@vger.kernel.org; gunho@lge.com > Subject: Re: [PATCH] Documentation/dma-buf-sharing.txt: update API > descriptions > > On Mon, May 12, 2014 at 08:48:12PM +0900, gioh.kim wrote: > > From: "gioh.kim" > > It might be good to fix your setup to make this be the same as the name > and email used in the Signed-off-by line below. > > > update some descriptions for API arguments and descriptions. > > Nit: "Update" since it's the beginning of a sentence. > > > Signed-off-by: Gioh Kim > > --- > > Documentation/dma-buf-sharing.txt | 10 ++ > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > diff --git a/Documentation/dma-buf-sharing.txt > > b/Documentation/dma-buf-sharing.txt > > index 505e711..1ea89b8 100644 > > --- a/Documentation/dma-buf-sharing.txt > > +++ b/Documentation/dma-buf-sharing.txt > > @@ -56,7 +56,7 @@ The dma_buf buffer sharing API usage contains the > > following steps: > > size_t size, int flags, > > const char *exp_name) > > > > - If this succeeds, dma_buf_export allocates a dma_buf structure, and > > returns a > > + If this succeeds, dma_buf_export_named allocates a dma_buf structure, > > and returns a > > Perhaps reformat this so that the lines don't exceed 80 characters? > > > pointer to the same. It also associates an anonymous file with this > > buffer, > > so it can be exported. On failure to allocate the dma_buf object, it > > returns > > NULL. > > @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the > > following steps: > > > > Exporting modules which do not wish to provide any specific name may > > use the > > helper define 'dma_buf_export()', with the same arguments as above, but > > - without the last argument; a __FILE__ pre-processor directive will be > > + without the last argument; a KBUILD_MODNAME pre-processor directive > > will be > > inserted in place of 'exp_name' instead. > > This was already fixed in commit 2e33def0339c (dma-buf: update exp_name > when using dma_buf_export()). Perhaps you should rebase this patch on > top of the latest linux-next. > > Otherwise looks good. > > Thierry -- 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 -stable] x86,preempt: Fix preemption for i386
On Wed, Apr 09, 2014 at 09:38:45PM +0200, Peter Zijlstra wrote: > On Wed, Apr 09, 2014 at 12:19:31PM -0700, Greg KH wrote: > > On Wed, Apr 09, 2014 at 07:36:23AM -0700, Linus Torvalds wrote: > > > On Wed, Apr 9, 2014 at 7:24 AM, Peter Zijlstra > > > wrote: > > > > > > > > I'm not entirely clear on how acceptable it is to propose a different > > > > patch for -stable than what we have upstream. > > > > > > It's not all that common, but it certainly happens. > > > > > > It's fine, as long as it mentions the commits that fix it upstream. > > > And as long as it's well tested, of course. > > > > I agree, I can take this as long as you say it's correct and tested... > > As far as I understand the issue the patch is indeed correct and I have > 3 independent people who confirm their previously reported issues are > now cured (as testified by the Tested-by tags). > > There has also been confirmation that upstream does no longer suffer the > problem. Now applied, thanks. greg k-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/
