Re: [Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware
On Mon, Apr 28, 2014 at 12:10:27PM +1000, Ben Skeggs wrote: > On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot > wrote: > > nvc0_graph_ctor() would only let the graphics engine be enabled if its > > oclass has a proper microcode linked to it. This prevents GR from being > > enabled at all on chips that rely exclusively on external firmware, even > > though such a use-case is valid. > > > > Relax the conditions enabling the GR engine to also include the case > > where an external firmware has also been loaded. > I'm happy to take this patch as-is. I do wonder if we should do > something like this though: > > if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", oclass->fecs.ucode == NULL)) > > Which will automatically switch to external firmware if there's no > internal implementation available. I think that makes a lot of sense. Perhaps outputting a warning or so at runtime when this happens would be helpful in reminding people that the goal is to make the GPU run with nouveau firmware rather than external firmware, and hence that there's some work left to do. Thierry pgpSsljc5Zh0g.pgp Description: PGP signature
linux-next: Tree for Apr 28
Hi all, This tree still fails (more than usual) the powerpc allyesconfig build. Changes since 20140424: The mvebu tree gained a conflict against the arm tree. The powerpc tree still had its build failure. The libata tree lost its build failure. The net-next tree gained conflicts against the net tree. The wireless-next tree lost its build failure. The mfd-lj tree still had its build failure so I used the version from next-20140423. The usb-gadget tree gained a conflict against the usb tree. Non-merge commits (relative to Linus' tree): 3092 2868 files changed, 105988 insertions(+), 71520 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 216 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (ec6931b28179 word-at-a-time: avoid undefined behaviour in zero_bytemask macro) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2) Merging arm-current/fixes (d93003e8e4e1 ARM: 8042/1: iwmmxt: allow to build iWMMXt on Marvell PJ4B) Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for v3.14-rc1) Merging metag-fixes/fixes (a798c10faf62 Linux 3.15-rc2) Merging powerpc-merge/merge (cc4f265ad9a3 powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self) Merging sparc/master (a798c10faf62 Linux 3.15-rc2) Merging net/master (85350871317a sctp: reset flowi4_oif parameter on route lookup) Merging ipsec/master (a32452366b72 vti4: Don't count header length twice.) CONFLICT (content): Merge conflict in net/ipv4/ip_vti.c Merging sound-current/for-linus (8dc9abb93dde ALSA: hda/realtek - Add headset Mic support for Dell machine) Merging pci-current/for-linus (f5d3352b2751 PCI: tegra: Use new OF interrupt mapping when possible) Merging wireless/master (38f3106a9b98 Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth) Merging driver-core.current/driver-core-linus (0c8c77d35582 s390/ccwgroup: Fix memory corruption) Merging tty.current/tty-linus (7deb39ed8d94 serial_core: fix uart PORT_UNKNOWN handling) Merging usb.current/usb-linus (34f972d6156f usb: option: add and update a number of CMOTech devices) Merging usb-gadget-fixes/fixes (a31a942a148e usb: phy: am335x-control: wait 1ms after power-up transitions) Merging staging.current/staging-linus (2704f807f949 staging: comedi: usbdux: bug fix for accessing 'ao_chanlist' in private data) Merging char-misc.current/char-misc-linus (a798c10faf62 Linux 3.15-rc2) Merging input-current/for-linus (c16134976fb2 Input: tca8418 - fix loading this driver as a module from a device tree) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (eb4a5346e777 hwrng: bcm2835 - fix oops when rng h/w is accessed during registration) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (9ec36cafe43b of/irq: do irq resolution in platform_get_irq) Merging rr-fixes/fixes (132e9a68a579 Fix: tracing: use 'E' instead of 'X' for unsigned module t
Re: [PATCH 1/6] drivers: net: cpts: Remove hardcoded clock name for CPTS
On Mon, Apr 28, 2014 at 09:40:20AM +0530, George Cherian wrote: > CPTS refclk name is hardcoded, which makes it fail in case of DRA7x > Remove the hardcoded clock name for CPTS refclk and get the same from DT. Patch ordering - doesn't this patch depend on patch #2? Thanks, Richard -- 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 is a bunch of post-merge window fixes that have been accumulating in patchwork while I was on vacation or buried under other stuff last week. We have the now usual batch of LE fixes from Anton (sadly some new stuff that went into this merge window had endian issues, we'll try to make sure we do better next time) Some fixes and cleanups to the new 24x7 performance monitoring stuff (mostly typos and cleaning up printk's) A series of fixes for an issue with our runlatch bit, which wasn't set properly for offlined threads/cores and under KVM, causing potentially some counters to misbehave along with possible power management issues. A fix for kexec nasty race where the new kernel wouldn't "see" the secondary processors having reached back into firmware in time. And finally a few other misc (and pretty simple) bug fixes. Cheers, Ben. The following changes since commit a798c10faf62a505d24e5f6213fbaf904a39623f: Linux 3.15-rc2 (2014-04-20 11:08:50 -0700) 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 e4565362c7adc31201135c4b6d649fc1bdc3bf20: powerpc/4xx: Fix section mismatch in ppc4xx_pci.c (2014-04-28 16:32:53 +1000) Alistair Popple (1): powerpc/4xx: Fix section mismatch in ppc4xx_pci.c Aneesh Kumar K.V (1): powerpc/mm: Fix tlbie to add AVAL fields for 64K pages Anton Blanchard (11): powerpc/powernv: Fix little endian issues in OPAL flash code powerpc/powernv: Use uint64_t instead of size_t in OPAL APIs powerpc/powernv: Remove some OPAL function declaration duplication powerpc/powernv: Fix little endian issues with opal_do_notifier calls powerpc/powernv: Fix little endian issues in OPAL error log code powerpc/powernv: Create OPAL sglist helper functions and fix endian issues powerpc/powernv: Fix little endian issues in OPAL dump code powerpc: Rename duplicate COMMAND_LINE_SIZE define powerpc: Bump COMMAND_LINE_SIZE to 2048 powerpc: Bump BOOT_COMMAND_LINE_SIZE to 2048 powerpc: Fix error return in rtas_flash module init Benjamin Herrenschmidt (1): powerpc/powernv: Fix kexec races going back to OPAL Cody P Schafer (6): powerpc/perf/hv_24x7: Probe errors changed to pr_debug(), padding fixed powerpc/perf/hv_gpci: Probe failures use pr_debug(), and padding reduced powerpc/perf/hv-gpci: Make device attr static powerpc/perf/hv-24x7: Use (unsigned long) not (u32) values when calling plpar_hcall_norets() powerpc/perf/hv-24x7: Remove [static 4096], sparse chokes on it powerpc/perf/hv-24x7: Catalog version number is be64, not be32 Jeff Mahoney (1): powerpc: Export flush_icache_range Joel Stanley (5): powerpc/powernv: Fix sysparam sysfs error handling powerpc/powernv: Use ssize_t for sysparam return values powerpc/powernv: Check sysfs size before copying powerpc/powernv: Fix typos in sysparam code powerpc/powernv: Check sysparam size before creation Li Zhong (2): powerpc: Fix Oops in rtas_stop_self() powerpc/pseries: Protect remove_memory() with device hotplug lock Preeti U Murthy (3): ppc/powernv: Set the runlatch bits correctly for offline cpus ppc/kvm: Set the runlatch bit of a CPU just before starting guest ppc/kvm: Clear the runlatch bit of a vcpu before napping Wei Yang (2): powerpc/powernv: Reduce multi-hit of iommu_add_device() powerpc/powernv: Release the refcount for pci_dev arch/powerpc/boot/main.c| 8 +- arch/powerpc/boot/ops.h | 2 +- arch/powerpc/boot/ps3.c | 4 +- arch/powerpc/include/asm/opal.h | 42 - arch/powerpc/include/uapi/asm/setup.h | 7 +- arch/powerpc/kernel/ppc_ksyms.c | 1 + arch/powerpc/kernel/rtas_flash.c| 2 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 18 +++- arch/powerpc/mm/hash_native_64.c| 38 arch/powerpc/perf/hv-24x7.c | 35 --- arch/powerpc/perf/hv-gpci.c | 6 +- arch/powerpc/platforms/powernv/opal-dump.c | 94 +++ arch/powerpc/platforms/powernv/opal-elog.c | 11 ++- arch/powerpc/platforms/powernv/opal-flash.c | 118 ++-- arch/powerpc/platforms/powernv/opal-sysparam.c | 32 +-- arch/powerpc/platforms/powernv/opal.c | 69 +- arch/powerpc/platforms/powernv/pci-ioda.c | 3 +- arch/powerpc/platforms/powernv/setup.c | 48 +- arch/powerpc/platforms/powernv/smp.c| 3 + arch/powerpc/platforms/pseries/hotplug-cpu.c| 5 +- arch/powerpc/platforms/pseries/hotplug-memory.c | 10 +- arch/powerpc/sysdev/ppc4xx_pci.c| 2 +- 22 files cha
Re: [PATCH RT 2/4] net: gianfar: do not try to cleanup TX packets if they are not done
On 04/27/2014 04:31 PM, Steven Rostedt wrote:
> diff --git a/drivers/net/ethernet/freescale/gianfar.c
> b/drivers/net/ethernet/freescale/gianfar.c
> index 5c0efcc..8aecc1d 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -2856,10 +2855,14 @@ static int gfar_poll(struct napi_struct *napi, int
> budget)
> tx_queue = priv->tx_queue[i];
> /* run Tx cleanup to completion */
> if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx]) {
> - gfar_clean_tx_ring(tx_queue);
> - has_tx_work = 1;
> + int ret;
> +
> + ret = gfar_clean_tx_ring(tx_queue);
> + if (ret)
> + has_tx_work++;
> }
> }
> + work_done += has_tx_work;
>
> for_each_set_bit(i, &gfargrp->rx_bit_map, priv->num_rx_queues) {
> /* skip queue if not active */
The 3.14-RT version of the patch should have an additional return
statement here which I forgot initially.
Sebastian
--
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/3] uprobes/x86: Simplify riprel_{pre,post}_xol() and make them similar
* Oleg Nesterov [2014-04-27 18:52:30]: > Ignoring the "correction" logic riprel_pre_xol() and riprel_post_xol() > are very similar but look quite differently. > > 1. Add the "UPROBE_FIX_RIP_AX | UPROBE_FIX_RIP_CX" check at the start >of riprel_pre_xol(), like the same check in riprel_post_xol(). > > 2. Add the trivial scratch_reg() helper which returns the address of >scratch register pre_xol/post_xol need to change. > > 3. Change these functions to use the new helper and avoid copy-and-paste >under if/else branches. > > Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju -- 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: how to include already compiled object files to kernel
Hi Dirk/Everyone,
First of all I would like to apologize for sending this e-mail out on LKML. It
was not intended to come here but was for an internal group. My mail client
seems to have auto predicted the wrong group and I was stupid enough not to
verify this before hitting the send button (I guess the late Friday push was
too hard).
I promise to be more careful next time.
Thanks & Regards,
Ram
-Original Message-
From: Hohndel, Dirk
Sent: Saturday, April 26, 2014 3:31 AM
To: linux-kernel@vger.kernel.org
Cc: Pallala, Ramakrishna
Subject: Re: how to include already compiled object files to kernel
On Fri, 2014-04-25 at 16:24 +, Pallala, Ramakrishna wrote:
> HI All,
>
> I have received few kernel library .o (object files) from third party and I
> am planning to include in our kernel tree. As the library contains some
> proprietary algorithms the sources are not shared.
>
> How can I include this library .o files to my kernel and if this kernel is
> release to customers will there be any license issues? Third party says the
> sources are under GPL.
>
Oh joy. Just what I wanted to read today...
Our apologies; this is not a question or issue that should have been posted to
LKML. Legal questions (such as what is permitted by any particular license) by
Intel employees are supposed to be directed to Intel's legal department and not
to public mailing lists. Intel also has a technical and business review
process for reviewing *all* Open Source software activities, including all
Linux kernel contributions, and the very first response from that review
process would have been to direct questions about license interpretation and
permissible licensing models to Intel's Legal Department.
We'll be following up with the development of this not-yet-released product to
ensure that it is fully compliant with the GPL and other open source licenses
as well as community-accepted practices, that it follows Intel's normal review
processes, and that all the developers involved are familiar with Intel's
policies for working with open source.
For those who have responded to the original mail, both privately and
publicly: thank you for your diligence and suggestions; we have been working
internally for the last few hours (literally since WE saw it on the mailing
list). But it's good to see that the community is as responsive to these issues
as we are.
And now back to our regularly scheduled emergencies.
/D
--
Dirk Hohndel
Chief Linux and Open Source Technologist Intel Open Source Technology Center
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 2/3] uprobes/x86: Kill the "autask" arg of riprel_pre_xol()
* Oleg Nesterov [2014-04-27 18:52:27]: > default_pre_xol_op() passes ¤t->utask->autask to riprel_pre_xol() > and this is just ugly because it still needs to load current->utask to > read ->vaddr. > > Remove this argument, change riprel_pre_xol() to use current->utask. > > Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju -- 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] uprobes/x86: Rename *riprel* helpers to make the naming consistent
* Oleg Nesterov [2014-04-27 18:52:23]: > handle_riprel_insn(), pre_xol_rip_insn() and handle_riprel_post_xol() > look confusing and inconsistent. Rename them into riprel_analyze(), > riprel_pre_xol(), and riprel_post_xol() respectively. > > No changes in compiled code. > > Signed-off-by: Oleg Nesterov Acked-by: Srikar Dronamraju -- 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 v4] i2c: exynos5: configure fifo_depth based on HSI2C module variant
Hello Wolfram, On 13 March 2014 00:50, Wolfram Sang wrote: > On Fri, Feb 07, 2014 at 10:13:15AM +0530, Naveen Krishna Chatradhi wrote: >> fifo_depth of the HSI2C is not constant >> Exynos5420 and Exynos5250 supports fifo_depth of 64bytes >> Exynos5260 supports fifo_depth of 16bytes. >> >> This patch configures the fifo_depth based on HSI2C modules version. >> >> Signed-off-by: Naveen Krishna Chatradhi >> [For finding out the difference and initial contribution] >> Signed-off-by: Pankaj Dubey > > I know Tomasz said differently, but I prefer the patches squashed (and > the commit message extended). Please accept my apologies for coming back late on this CL. Will squash and fix the compilation error and submit. Thanks, > -- Shine bright, (: Nav :) -- 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: [GIT PULL 0/4] phy: fixes for 3.15 -rc2
Hi, On Friday 25 April 2014 01:24 AM, Greg KH wrote: > On Sat, Apr 19, 2014 at 08:51:40AM +0530, Kishon Vijay Abraham I wrote: >> Hi Greg, >> >> Here's the PULL requeust for PHY subsystem for this -rc cycle. It consissts >> of >> a bunch of critical fixes in PHY. >> >> Let me know if I have to change anything. > > Now all applied. Thanks :-) > >> The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: >> >> Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git >> tags/for-3.15-rc2 > > Ah crap, I took them as patches, not as a git pull request, very sorry > about that, my fault. no problem. -Kishon > > 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/
[PATCH 2/2] virtio_scsi: space required before open parenthesis
Fix coding style warnings from checkpatch
Signed-off-by: Jerry Snitselaar
---
drivers/scsi/virtio_scsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 9f2fccc..9248a1e 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -723,7 +723,7 @@ static struct scsi_host_template
virtscsi_host_template_multi = {
do { \
typeof(((struct virtio_scsi_config *)0)->fld) __val = (val); \
virtio_cwrite(vdev, struct virtio_scsi_config, fld, &__val); \
- } while(0)
+ } while (0)
static void __virtscsi_set_affinity(struct virtio_scsi *vscsi, bool affinity)
{
@@ -771,7 +771,7 @@ static int virtscsi_cpu_callback(struct notifier_block *nfb,
{
struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
- switch(action) {
+ switch (action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
case CPU_DEAD:
--
2.0.0.rc0
--
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 1/2] virtio_scsi: blank line after declaration cleanup
Clean up of coding style warnings from checkpatch
Signed-off-by: Jerry Snitselaar
---
drivers/scsi/virtio_scsi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 16bfd50..fa0b25f 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -498,8 +498,8 @@ static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
{
struct virtio_scsi_cmd *cmd;
int ret;
-
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
+
BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
/* TODO: check feature bit and fail if unsupported? */
@@ -661,6 +661,7 @@ static int virtscsi_target_alloc(struct scsi_target
*starget)
{
struct virtio_scsi_target_state *tgt =
kmalloc(sizeof(*tgt), GFP_KERNEL);
+
if (!tgt)
return -ENOMEM;
@@ -675,6 +676,7 @@ static int virtscsi_target_alloc(struct scsi_target
*starget)
static void virtscsi_target_destroy(struct scsi_target *starget)
{
struct virtio_scsi_target_state *tgt = starget->hostdata;
+
kfree(tgt);
}
@@ -768,6 +770,7 @@ static int virtscsi_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
struct virtio_scsi *vscsi = container_of(nfb, struct virtio_scsi, nb);
+
switch(action) {
case CPU_ONLINE:
case CPU_ONLINE_FROZEN:
--
2.0.0.rc0
--
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 v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework.
Signed-off-by: Vivek Gautam
---
Changes from v6:
- Addressed review comments:
-- Sorted config entries in Kconfig and Makefile
-- Made #define to_usbdrd_phy(inst) to a static inline routine.
-- Restructured exynos5_rate_to_clk() as suggested.
-- Amended 'val' field for regmap_update_bits() in the routine
exynos5_usbdrd_phy_isol().
-- Removed sentinel entry from exynos5_usbdrd_phy_cfg[] struct.
-- Removed check for 'match' entry in probe().
.../devicetree/bindings/phy/samsung-phy.txt| 40 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usbdrd.c | 627
4 files changed, 679 insertions(+)
create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..51efe4c 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,43 @@ Example:
compatible = "samsung,exynos-sataphy-i2c";
reg = <0x38>;
};
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+ - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+ - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+ used for register access.
+ - ref: PHY's reference clock (usually crystal clock), used for
+ PHY operations, associated by phy name. It is used to
+ determine bit values for clock settings register.
+ For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+ control pmu registers for power isolation.
+- samsung,pmu-offset: phy power control register offset to
pmu-system-controller
+ base.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+ 0 - UTMI+ type phy,
+ 1 - PIPE3 type phy,
+
+Example:
+ usb3_phy: usbphy@1210 {
+ compatible = "samsung,exynos5250-usbdrd-phy";
+ reg = <0x1210 0x100>;
+ clocks = <&clock 286>, <&clock 1>;
+ clock-names = "phy", "ref";
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,pmu-offset = <0x704>;
+ #phy-cells = <1>;
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..daa1707 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -159,6 +159,17 @@ config PHY_EXYNOS5250_USB2
particular SoC is compiled in the driver. In case of Exynos 5250 four
phys are available - device, host, HSIC0 and HSIC.
+config PHY_EXYNOS5_USBDRD
+ tristate "Exynos5 SoC series USB DRD PHY driver"
+ depends on ARCH_EXYNOS5 && OF
+ depends on HAS_IOMEM
+ select GENERIC_PHY
+ select MFD_SYSCON
+ help
+ Enable USB DRD PHY support for Exynos 5 SoC series.
+ This driver provides PHY interface for USB 3.0 DRD controller
+ present on Exynos5 SoC series.
+
config PHY_XGENE
tristate "APM X-Gene 15Gbps PHY support"
depends on HAS_IOMEM && OF && (ARM64 || COMPILE_TEST)
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..333ba98 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_PHY_SAMSUNG_USB2)+=
phy-samsung-usb2.o
obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
+obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
new file mode 100644
index 000..bc381e3
--- /dev/null
+++ b/drivers/phy/phy-exyno
[PATCH v7 2/2] phy: exynos5-usbdrd: Add facility for VBUS supply
Adding support to enable/disable VBUS controlled by a
regulator, to enable vbus supply on the port.
Signed-off-by: Vivek Gautam
---
Changes from v6:
- Rebased on top of [PATCH v7 1/2] phy: Add new Exynos5 USB 3.0 PHY driver.
drivers/phy/phy-exynos5-usbdrd.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index bc381e3..6e8540e 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
/* Exynos USB PHY registers */
#define EXYNOS5_FSEL_9MHZ6 0x0
@@ -170,6 +171,7 @@ struct exynos5_usbdrd_phy {
} phys[EXYNOS5_DRDPHYS_NUM];
u32 extrefclk;
struct clk *ref_clk;
+ struct regulator *vbus;
};
static inline
@@ -438,6 +440,7 @@ static int exynos5_usbdrd_phy_exit(struct phy *phy)
static int exynos5_usbdrd_phy_power_on(struct phy *phy)
{
+ int ret;
struct phy_usb_instance *inst = phy_get_drvdata(phy);
struct exynos5_usbdrd_phy *phy_drd = to_usbdrd_phy(inst);
@@ -445,10 +448,24 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
+ /* Enable VBUS supply */
+ if (phy_drd->vbus) {
+ ret = regulator_enable(phy_drd->vbus);
+ if (ret) {
+ dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
+ goto fail_vbus;
+ }
+ }
+
/* Power-on PHY*/
inst->phy_cfg->phy_isol(inst, 0);
return 0;
+
+fail_vbus:
+ clk_disable_unprepare(phy_drd->ref_clk);
+
+ return ret;
}
static int exynos5_usbdrd_phy_power_off(struct phy *phy)
@@ -461,6 +478,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Power-off the PHY */
inst->phy_cfg->phy_isol(inst, 1);
+ /* Disable VBUS supply */
+ if (phy_drd->vbus)
+ regulator_disable(phy_drd->vbus);
+
clk_disable_unprepare(phy_drd->ref_clk);
return 0;
@@ -583,6 +604,17 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return ret;
}
+ /* Get Vbus regulator */
+ phy_drd->vbus = devm_regulator_get(dev, "vbus");
+ if (IS_ERR(phy_drd->vbus)) {
+ ret = PTR_ERR(phy_drd->vbus);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, "Failed to get VBUS supply regulator\n");
+ phy_drd->vbus = NULL;
+ }
+
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
for (i = 0; i < EXYNOS5_DRDPHYS_NUM; i++) {
--
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: [BUG] x86: reboot doesn't reboot
> I'll contact > the people I know in Dell and see if I can find anyone from the firmware > division who'll actually talk to us. What about now? As a side note, OT, but: http://arstechnica.com/gadgets/2014/04/fast-but-compromised-gigabytes-amd-powered-mini-gaming-pc-reviewed/?comments=1 (notice the Editor's Pick!)-- 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 25/28] nios2: ptrace support
On Sat, Apr 26, 2014 at 7:52 AM, Pedro Alves wrote: > Does this support PTRACE_GETREGSET / PTRACE_SETREGSET ? > > IMO, the kernel shouldn't accept ports without those anymore. > > And IMHO, we shouldn't even allow new ports having PTRACE_GETREGS. > > http://sourceware.org/ml/archer/2010-q3/msg00193.html > It doesn't support PTRACE_GETREGSET / PTRACE_SETREGSET now. We will look into 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: [RFC] /dev/random for in-kernel use
Am Sonntag, 27. April 2014, 20:19:41 schrieb Theodore Ts'o: Hi Theodore, > On Sun, Apr 27, 2014 at 08:49:48PM +0200, Stephan Mueller wrote: > > With the heavy update of random.c during the 3.13 development, the > > re-seeding of the nonblocking_pool from the input_pool is now prevented > > for a duration of random_min_urandom_seed seconds. Furthermore, the > > nonblocking_pool can be read from user space such that it acts as a > > deterministic RNG due to the non- blocking behavior if more data is > > pulled than is delivered by the noise sources. As the nonblocking_pool is > > used when a in-kernel user invokes get_random_bytes, the described > > deterministic behavior also applies to this function. > > This actually wasn't a major change. If you are drawing sufficiently > heavily from /dev/urandom (and some crypto libraries draw _very_ > heavily; the Chrome browser in particular draws from /dev/urandom > quite liberally), then you'll end up drawing from the input pool > faster than it can be filled from noise sources anyway. So the rate > limiting wasn't making a material difference as far as the quality of > /dev/urandom and get_random_bytes() is concerned. What it does do is > allow users of /dev/random (such as gpg key generaiton) to complete in > a reasonable time. Thanks for clarifying this. I agree that the change is immaterial considering a "random number hog" in user space with respect to the deterministic behavior. > > However, given that we're reseeding once a minute (or as needed), it's > actually not a deterministic RNG (per SP 800-90A, section 8.6.5, a > DRBG is forbidden to reseed itself automatically). To be honest, I do not read that in this section. Moreover, a DRBG must reseed itself -- the caller shall only have the ability to add additional data or trigger a reseeding earlier (the proposed DRBG implementation directly draws from get_random_bytes automatically). But this is a different topic and we should disregard it for the moment. > > > Now, get_random_bytes is the only function inside the kernel that can > > deliver entropy. For most use cases, the described approach is just fine. > > However, when using well defined deterministic RNGs, like the already > > existing ANSI X9.31 or the suggested SP800-90A DRBG, seeding these DRNGs > > from the DRNG of the nonblocking_pool is typically not a suggested way. > > This is visible in user space where /dev/random is preferred when seeding > > deterministic RNGs (see libgcrypt as an example). > > Well, as far as SP800-90A DRBG is concerned, using either the logical > equivalent of /dev/random or /dev/urandom is not allowed, since > neither is a "approved" entropy source. (Then again, given that NIST > approved Dual-EC, I'm not sure how much I'm impressed by a NIST > approval, but whatever. :-) But if your goal is to get the NIST Well spoken words :-) Considering that approved entropy sources have to comply with SP800-90B and C, I have prepared already some analyses of random.c whether the blocking or the nonblocking pool meets these requirements. Using several system tap scripts, the statistical behavior of the noise sources and the pool distributions look appropriate. In addition, some theoretical analyses showed that the blocking pool (considering the blocking behavior) would meet the requirements of SP800-90B/C whereas the nonblocking pool does not. Anticipating that the compliance to SP800-90B/C would be required for a successful FIPS validation somewhen in the future, making the blocking behavior available to in-kernel users would be of interest. > certification, which IMHO should only matter if you are selling to the > US government, it really can really only use RDRAND on Intel platforms > --- i.e., get_random_bytes_arch(). I am not too convinced of RDRAND due to the lack of usable source code (i.e. source code that I can build myself). But that is my personal taste :-) > > That being said, if some kernel module really wants to get its hands > on entropy extracted from the blocking pool, I don't see any reason > why we shouldn't deny them that functionality. > > > Therefore may I propose the implementation of the blocking concept of > > /dev/random as a provider of entropy to in-kernel callers like DRNGs? I > > would recommend a function of > > > > void get_blocking_bytes_nowait(void *buf, int nbytes, > > > > void (*cb)(void *buf, int buflen)) > > Let me make a counter proposal. Let's instead provide a blocking > interface: [...] Thanks for these suggestions. Shall I take these suggestions and turn them into a full patch? Moreover, I read that even for in-kernel users we should use the blocking pool. Or shall we conceive of a third output pool, say, a kernel pool that is independent of the output pools to user space? Adding such a pool more or less only requires to define a new struct entropy_pool instance. Ciao Stephan -- | Cui bono? | -- To unsubscribe from this list: send the line
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
Christoph Hellwig writes: > This doesn't address any or the previous points: > > - common implementation instead of the godawful boilerplate code >(and we even fixed most of this for Posix ACL by now, so even less >reason to do the same crap again!) We already do that with richacl. Richacl already have most of the details implemented in common code. Comparing to recent posix acl changes we could still simplify chmod and xattr bits. I will do that in the next update. > - common data structure with Posix ACLs > Can you explain this ?. Why do we want to do that ? > And of course no real explanation why we need the braindead access/deny > scheme at how it will get properly integrated with the system. > > So in this for a clear NAK. -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz,
On Sat, Apr 26, 2014 at 4:33 AM, Tomasz Figa wrote:
> Hi Vivek,
>
>
> On 22.04.2014 10:03, Vivek Gautam wrote:
>>
>> Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
>> The new driver uses the generic PHY framework and will interact
>> with DWC3 controller present on Exynos5 series of SoCs.
>> Thereby, removing old phy-samsung-usb3 driver and related code
>> used untill now which was based on usb/phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> .../devicetree/bindings/phy/samsung-phy.txt| 40 ++
>> drivers/phy/Kconfig| 11 +
>> drivers/phy/Makefile |1 +
>> drivers/phy/phy-exynos5-usbdrd.c | 629
>>
>> 4 files changed, 681 insertions(+)
>> create mode 100644 drivers/phy/phy-exynos5-usbdrd.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> index b422e38..51efe4c 100644
>> --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> @@ -114,3 +114,43 @@ Example:
>> compatible = "samsung,exynos-sataphy-i2c";
>> reg = <0x38>;
>> };
>> +
>> +Samsung Exynos5 SoC series USB DRD PHY controller
[snip]
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 3bb05f1..8a5d2b4 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -166,4 +166,15 @@ config PHY_XGENE
>> help
>> This option enables support for APM X-Gene SoC multi-purpose
>> PHY.
>>
>> +config PHY_EXYNOS5_USBDRD
>> + tristate "Exynos5 SoC series USB DRD PHY driver"
>> + depends on ARCH_EXYNOS5 && OF
>> + depends on HAS_IOMEM
>> + select GENERIC_PHY
>> + select MFD_SYSCON
>> + help
>> + Enable USB DRD PHY support for Exynos 5 SoC series.
>> + This driver provides PHY interface for USB 3.0 DRD controller
>> + present on Exynos5 SoC series.
>> +
>
>
> I think you should probably keep the entries sorted, so this one should be
> somewhere around other EXYNOS PHYs.
Right, thanks for pointing this out.
Will move this along with other PHY_EXYNOS USB* configs.
>
>
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 2faf78e..31baa0c 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) +=
>> phy-exynos4210-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS4X12_USB2) += phy-exynos4x12-usb2.o
>> obj-$(CONFIG_PHY_EXYNOS5250_USB2) += phy-exynos5250-usb2.o
>> obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
>> +obj-$(CONFIG_PHY_EXYNOS5_USBDRD) += phy-exynos5-usbdrd.o
>
>
> Ditto.
Ok
>
>
>> diff --git a/drivers/phy/phy-exynos5-usbdrd.c
>> b/drivers/phy/phy-exynos5-usbdrd.c
>> new file mode 100644
>> index 000..89d7ae8
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos5-usbdrd.c
>> @@ -0,0 +1,629 @@
>> +/*
>> + * Samsung EXYNOS5 SoC series USB DRD PHY driver
>> + *
>> + * Phy provider for USB 3.0 DRD controller on Exynos5 SoC series
>> + *
>> + * Copyright (C) 2014 Samsung Electronics Co., Ltd.
>> + * Author: Vivek Gautam
>> + *
[snip]
>> + } phys[EXYNOS5_DRDPHYS_NUM];
>> + unsigned int extrefclk;
>> + struct clk *ref_clk;
>> + unsigned long ref_rate;
>> +};
>> +
>> +#define to_usbdrd_phy(inst) \
>> + container_of((inst), struct exynos5_usbdrd_phy, \
>> +phys[(inst)->index]);
>
>
> This should be made a static inline to enforce type checking.
Ok, will make this as static inline routine, so that compiler don't
skip type checking.
>
>
>> +
>> +/*
>> + * exynos5_rate_to_clk() converts the supplied clock rate to the value
>> that
>> + * can be written to the phy register.
>> + */
>> +static unsigned int exynos5_rate_to_clk(unsigned long rate)
>> +{
>> + unsigned int clksel;
>> +
>> + /* EXYNOS5_FSEL_MASK */
>> +
>> + switch (rate) {
>> + case 9600 * KHZ:
>> + clksel = EXYNOS5_FSEL_9MHZ6;
>> + break;
>> + case 10 * MHZ:
>> + clksel = EXYNOS5_FSEL_10MHZ;
>> + break;
>> + case 12 * MHZ:
>> + clksel = EXYNOS5_FSEL_12MHZ;
>> + break;
>> + case 19200 * KHZ:
>> + clksel = EXYNOS5_FSEL_19MHZ2;
>> + break;
>> + case 20 * MHZ:
>> + clksel = EXYNOS5_FSEL_20MHZ;
>> + break;
>> + case 24 * MHZ:
>> + clksel = EXYNOS5_FSEL_24MHZ;
>> + break;
>> + case 50 * MHZ:
>> + clksel = EXYNOS5_FSEL_50MHZ;
>> + break;
>> + default:
>> + clksel = -EINVAL;
>
>
> Based on clksel (and return value of this function) being unsigned I don't
> think this is a good idea. You should probably adapt the approach f
[PATCH v2 1/1] Driver for Beckhoff CX5020 EtherCAT master module.
Changes since v1:
* added endianess annotation to descriptors' structures
* killed checkpath warnings about string literals being split into multiple
lines
>88<
This driver adds support for EtherCAT master module located on CCAT
FPGA found on Beckhoff CX series industrail PCs. The driver exposes
EtherCAT master as an ethernet interface.
EtherCAT is a filedbus protocol defined on top of ethernet and Beckhoff
CX5020 PCs come with built-in EtherCAT master module located on a FPGA,
which in turn is connected to a PCI bus.
Signed-off-by: Dariusz Marcinkiewicz
---
drivers/net/ethernet/Kconfig | 11 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/ec_bh.c | 768 +
3 files changed, 780 insertions(+)
create mode 100644 drivers/net/ethernet/ec_bh.c
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 39b26fe..a81611d 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -35,6 +35,17 @@ source "drivers/net/ethernet/calxeda/Kconfig"
source "drivers/net/ethernet/chelsio/Kconfig"
source "drivers/net/ethernet/cirrus/Kconfig"
source "drivers/net/ethernet/cisco/Kconfig"
+
+config CX_ECAT
+ tristate "Beckhoff CX5020 EtherCAT master support"
+ ---help---
+ Driver for EtherCAT master module located on CCAT FPGA
+ that can be found on Beckhoff CX5020, and possibly other of CX
+ Beckhoff CX series industrial PCs.
+
+ To compile this driver as a module, choose M here. The module
+ will be called ec_bh.
+
source "drivers/net/ethernet/davicom/Kconfig"
config DNET
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 545d0b3..1712c87 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_NET_CALXEDA_XGMAC) += calxeda/
obj-$(CONFIG_NET_VENDOR_CHELSIO) += chelsio/
obj-$(CONFIG_NET_VENDOR_CIRRUS) += cirrus/
obj-$(CONFIG_NET_VENDOR_CISCO) += cisco/
+obj-$(CONFIG_CX_ECAT) += ec_bh.o
obj-$(CONFIG_DM9000) += davicom/
obj-$(CONFIG_DNET) += dnet.o
obj-$(CONFIG_NET_VENDOR_DEC) += dec/
diff --git a/drivers/net/ethernet/ec_bh.c b/drivers/net/ethernet/ec_bh.c
new file mode 100644
index 000..cc63af4
--- /dev/null
+++ b/drivers/net/ethernet/ec_bh.c
@@ -0,0 +1,768 @@
+/*
+ * drivers/net/ethernet/beckhoff/ec_bh.c
+ *
+ * Copyright (C) 2014 Darek Marcinkiewicz
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+/* This is a driver for EtherCAT master module present on CCAT FPGA.
+ * Those can be found on Bechhoff CX50xx industrial PCs.
+ */
+
+#if 0
+#define DEBUG
+#endif
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TIMER_INTERVAL_NSEC2
+
+#define INFO_BLOCK_SIZE0x10
+#define INFO_BLOCK_TYPE0x0
+#define INFO_BLOCK_REV 0x2
+#define INFO_BLOCK_BLK_CNT 0x4
+#define INFO_BLOCK_TX_CHAN 0x4
+#define INFO_BLOCK_RX_CHAN 0x5
+#define INFO_BLOCK_OFFSET 0x8
+
+#define EC_MII_OFFSET 0x4
+#define EC_FIFO_OFFSET 0x8
+#define EC_MAC_OFFSET 0xc
+
+#define MAC_FRAME_ERR_CNT 0x0
+#define MAC_RX_ERR_CNT 0x1
+#define MAC_CRC_ERR_CNT0x2
+#define MAC_LNK_LST_ERR_CNT0x3
+#define MAC_TX_FRAME_CNT 0x10
+#define MAC_RX_FRAME_CNT 0x14
+#define MAC_TX_FIFO_LVL0x20
+#define MAC_DROPPED_FRMS 0x28
+#define MAC_CONNECTED_CCAT_FLAG0x78
+
+#define MII_MAC_ADDR 0x8
+#define MII_MAC_FILT_FLAG 0xe
+#define MII_LINK_STATUS0xf
+
+#define FIFO_TX_REG0x0
+#define FIFO_TX_RESET 0x8
+#define FIFO_RX_REG0x10
+#define FIFO_RX_RESET 0x18
+
+#define DMA_CHAN_OFFSET0x1000
+#define DMA_CHAN_SIZE 0x8
+
+static struct pci_device_id ids[] = {
+ { PCI_DEVICE(0x15ec, 0x5000), },
+ { 0, }
+};
+MODULE_DEVICE_TABLE(pci, ids);
+
+struct rx_header {
+#define RXHDR_NEXT_ADDR_MASK 0xffu
+#define RXHDR_NEXT_VALID (1u << 31)
+ __le32 next;
+#define RXHDR_NEXT_RECV_FLAG 0x1
+ __le32 recv;
+#define RXHDR_LEN_MASK 0xfffu
+ __le16 len;
+ __le16 port;
+ __le32 reserved;
+ u8 timestamp[8];
+} __packed;
+
+struct rx_desc {
+ struct rx_header header;
+#define RX_PAYLOAD_SIZE0x7e8
+ u8 data[RX_PAYLOAD_SIZE];
+} __packed;
+
+struct tx_
[PATCH 2/2] Regulators: TPS65917: Add Regulator driver for TPS65917 PMIC
This patch adds support for TPS65917 PMIC regulators.
The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Keerthy
---
drivers/regulator/Kconfig | 12 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps65917-regulator.c | 903
3 files changed, 916 insertions(+)
create mode 100644 drivers/regulator/tps65917-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 6a79328..5ddb220 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -384,6 +384,18 @@ config REGULATOR_PALMAS
on the muxing. This is handled automatically in the driver by
reading the mux info from OTP.
+config REGULATOR_TPS65917
+ tristate "TI TPS65917 PMIC Regulators"
+ depends on MFD_TPS65917
+ help
+ If you wish to control the regulators on the TPS65917 series of
+ chips say Y here. This will enable support for all the software
+ controllable SMPS/LDO regulators.
+
+ The regulators available on TPS65917 series chips vary depending
+ on the muxing. This is handled automatically in the driver by
+ reading the mux info from OTP.
+
config REGULATOR_PCAP
tristate "Motorola PCAP2 regulator driver"
depends on EZX_PCAP
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 979f9dd..381dfd3 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o
obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65917) += tps65917-regulator.o
obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
obj-$(CONFIG_REGULATOR_TPS51632) += tps51632-regulator.o
obj-$(CONFIG_REGULATOR_PCAP) += pcap-regulator.o
diff --git a/drivers/regulator/tps65917-regulator.c
b/drivers/regulator/tps65917-regulator.c
new file mode 100644
index 000..be94a7a
--- /dev/null
+++ b/drivers/regulator/tps65917-regulator.c
@@ -0,0 +1,903 @@
+/*
+ * Driver for Regulator part of TPS65917 PMIC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct regs_info {
+ char*name;
+ char*sname;
+ u8 vsel_addr;
+ u8 ctrl_addr;
+ int sleep_id;
+};
+
+static const struct regs_info tps65917_regs_info[] = {
+ {
+ .name = "SMPS1",
+ .sname = "smps1-in",
+ .vsel_addr = TPS65917_SMPS1_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+ },
+ {
+ .name = "SMPS2",
+ .sname = "smps2-in",
+ .vsel_addr = TPS65917_SMPS2_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS2_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+ },
+ {
+ .name = "SMPS3",
+ .sname = "smps3-in",
+ .vsel_addr = TPS65917_SMPS3_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS3_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+ },
+ {
+ .name = "SMPS4",
+ .sname = "smps4-in",
+ .vsel_addr = TPS65917_SMPS4_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS4_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
+ },
+ {
+ .name = "SMPS5",
+ .sname = "smps5-in",
+ .vsel_addr = TPS65917_SMPS5_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS5_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
+ },
+ {
+ .name = "LDO1",
+ .sname = "ldo1-in",
+ .vsel_addr = TPS65917_LDO1_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO1,
+
[PATCH 0/2] TPS65917: Drivers for TPS65917 PMIC
The TPS65917 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - GPADC. - Over Temperature warning and Shut down. This patch series adds support for TPS65917 mfd device. At this time only the regulator functionality is made available. The closest drivers are PALMAS series drivers. The register set is changed. Bit-field defenitions are changed. Hence based on the PALMAS drivers and created a new set of drivers with code changes as required. The patches are boot tested on DRA7-EVM. Keerthy (2): MFD: TPS65917: Add driver for the TPS65917 PMIC Regulators: TPS65917: Add Regulator driver for TPS65917 PMIC drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile |1 + drivers/mfd/tps65917.c | 542 drivers/regulator/Kconfig | 12 + drivers/regulator/Makefile |1 + drivers/regulator/tps65917-regulator.c | 903 +++ include/linux/mfd/tps65917.h | 1508 7 files changed, 2977 insertions(+) create mode 100644 drivers/mfd/tps65917.c create mode 100644 drivers/regulator/tps65917-regulator.c create mode 100644 include/linux/mfd/tps65917.h -- 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 -V1 00/22] New ACL format for better NFSv4 acl interoperability
Dave Chinner writes: > On Sun, Apr 27, 2014 at 09:44:31PM +0530, Aneesh Kumar K.V wrote: >> Hi >> >> As per LSF/MM summit discussion I am reposting the richacl patchset for >> upstream inclusion. The patchset includes minimal changes required to >> implement >> a new acl model similar to NFSv4 ACL. The acl model selection is based on >> file system feature flag. >> >> The following set of patches implements VFS and ext4 changes needed to >> implement >> a new acl model for linux. Rich ACLs are an implementation of NFSv4 ACLs, >> extended by file masks to fit into the standard POSIX file permission model. >> They are designed to work seamlessly locally as well as across the NFSv4 and >> CIFS/SMB2 network file system protocols. >> >> A user-space utility for displaying and changing richacls is available at [1] >> (a number of examples can be found at >> http://acl.bestbits.at/richacl/examples.html). >> >> [1] git://github.com/kvaneesh/richacl-tools.git master >> >> To test richacl on ext4, create the file sytem with richacl feature flag >> (mkfs.ext4 -O richacl or tune2fs -O richacl). With richacl feature enabled >> using mount option "acl" will switch to using richacl instead of posixacl. > > No mount options, please. The ACL configuration needs to be > determined solely by the superblock feature bit - we cannot support > filesystems with mixed ACL types, and that's what this mount option > does. For ext4 since acls are enabled by default we really don't need to speciy -o acl in mount. What i meant by above is that using "acl/noacl" mount option will now enabe/disable POSIX or RICHacl based on the superblock feature bit. > >> More details regarding richacl can be found at >> http://acl.bestbits.at/richacl/ >> >> Previous posting of the patchset can be found at: >> http://mid.gmane.org/1319391835-5829-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com >> "[PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability" >> >> The complete patchset can also be found at: >> https://github.com/kvaneesh/linux/commits/richacl-for-upstream > > Where are the tests? We need comprehensive coverage in xfstests so > we can validate that it works the way it is supposed to and that we > don't break it in future, and that all filesystems behave the same > way > https://github.com/kvaneesh/richacl-tools/tree/master/test -aneesh -- 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/
linux-next: manual merge of the usb-gadget tree with the usb tree
Hi Felipe,
Today's linux-next merge of the usb-gadget tree got a conflict in
drivers/usb/phy/phy-mv-u3d-usb.c between commit 543cab640279 ("usb: phy:
mv_u3d: Remove usb phy driver for mv_u3d") from the usb tree and commit
041832565e40 ("usb: phy: mv-u3d: switch over to writel/readl") from the
usb-gadget tree.
I fixed it up (the former removes the file, so I did that) and can carry
the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpzi6j4N6KKP.pgp
Description: PGP signature
Re: [PATCH] rwsem: Support optimistic spinning
ping?
On Tue, 2014-04-22 at 15:19 -0700, Davidlohr Bueso wrote:
> We have reached the point where our mutexes are quite fine tuned
> for a number of situations. This includes the use of heuristics
> and optimistic spinning, based on MCS locking techniques.
>
> Exclusive ownership of read-write semaphores are, conceptually,
> just about the same as mutexes, making them close cousins. To
> this end we need to make them both perform similarly, and
> right now, rwsems are simply not up to it. This was discovered
> by both reverting commit 4fc3f1d6 (mm/rmap, migration: Make
> rmap_walk_anon() and try_to_unmap_anon() more scalable) and
> similarly, converting some other mutexes (ie: i_mmap_mutex) to
> rwsems. This creates a situation where users have to choose
> between a rwsem and mutex taking into account this important
> performance difference. Specifically, biggest difference between
> both locks is when we fail to acquire a mutex in the fastpath,
> optimistic spinning comes in to play and we can avoid a large
> amount of unnecessary sleeping and overhead of moving tasks in
> and out of wait queue. Rwsems do not have such logic.
>
> This patch, based on the work from Tim Chen and I, adds support
> for write-side optimistic spinning when the lock is contended.
> It also includes support for the recently added cancelable MCS
> locking for adaptive spinning.
>
> Allowing optimistic spinning before putting the writer on the wait
> queue reduces wait queue contention and provided greater chance
> for the rwsem to get acquired. With these changes, rwsem is on par
> with mutex. The performance benefits can be seen on a number of
> workloads. For instance, on a 8 socket, 80 core 64bit Westmere box,
> aim7 shows the following improvements in throughput:
>
> +--+-+-+
> | Workload | throughput-increase | number of users |
> +--+-+-+
> | alltests | 20% | >1000 |
> | custom | 27%, 60%| 10-100, >1000 |
> | high_systime | 36%, 30%| >100, >1000 |
> | shared | 58%, 29%| 10-100, >1000 |
> +--+-+-+
>
> There was also improvement on smaller systems, such as a quad-core
> x86-64 laptop running a 30Gb PostgreSQL (pgbench) workload for up
> to +60% in throughput for over 50 clients. Additionally, benefits
> were also noticed in exim (mail server) workloads. Furthermore, no
> performance regression have been seen at all.
>
> Signed-off-by: Davidlohr Bueso
> Signed-off-by: Tim Chen
> ---
> include/linux/rwsem.h | 9 +-
> kernel/locking/rwsem-xadd.c | 213
> +++-
> kernel/locking/rwsem.c | 31 ++-
> 3 files changed, 231 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
> index 03f3b05..6f992e2 100644
> --- a/include/linux/rwsem.h
> +++ b/include/linux/rwsem.h
> @@ -16,6 +16,7 @@
>
> #include
>
> +struct optimistic_spin_queue;
> struct rw_semaphore;
>
> #ifdef CONFIG_RWSEM_GENERIC_SPINLOCK
> @@ -26,6 +27,10 @@ struct rw_semaphore {
> longcount;
> raw_spinlock_t wait_lock;
> struct list_headwait_list;
> +#ifdef CONFIG_SMP
> + struct task_struct *owner; /* write owner */
> + struct optimistic_spin_queue *osq; /* spinner MCS lock */
> +#endif
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> struct lockdep_map dep_map;
> #endif
> @@ -58,7 +63,9 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
> #define __RWSEM_INITIALIZER(name)\
> { RWSEM_UNLOCKED_VALUE, \
> __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock), \
> - LIST_HEAD_INIT((name).wait_list) \
> + LIST_HEAD_INIT((name).wait_list), \
> + NULL, /* owner */ \
> + NULL /* mcs lock */ \
> __RWSEM_DEP_MAP_INIT(name) }
>
> #define DECLARE_RWSEM(name) \
> diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
> index 1d66e08..b6a67fe 100644
> --- a/kernel/locking/rwsem-xadd.c
> +++ b/kernel/locking/rwsem-xadd.c
> @@ -5,12 +5,18 @@
> *
> * Writer lock-stealing by Alex Shi
> * and Michel Lespinasse
> + *
> + * Optimistic spinning by Tim Chen
> + * and Davidlohr Bueso . Based on mutexes.
> */
> #include
> #include
> #include
> +#include
> #include
>
> +#include "mcs_spinlock.h"
> +
> /*
> * Initialize an rwsem:
> */
> @@ -27,6 +33,10 @@ void __init_rwsem(struct rw_semaphore *sem, const char
> *name,
> sem->count = RWSEM_UNLOCKED_VALUE;
> raw_spin_lock_init(&sem->wait_lock);
> INIT_LIST_HEAD(&sem->wait_list);
> +#ifdef CONFIG_SMP
> + sem->owner = NULL;
> + sem->osq = NULL;
> +#endif
> }
>
> EXPORT_SYMBOL(__init_rwsem);
>
Re: [ANNOUNCE] 3.14-rt1
Hi Nicholas, On Sat, 2014-04-26 at 15:58 +0200, Mike Galbraith wrote: > On Sat, 2014-04-26 at 10:38 +0200, Mike Galbraith wrote: > > On Fri, 2014-04-25 at 09:40 +0200, Mike Galbraith wrote: > > > > > Hotplug can still deadlock in rt trees too, and will if you beat it > > > hard. > > > > Box actually deadlocks like so. > > ... > > 3.12-rt looks a bit busted migrate_disable/enable() wise. > > /me eyeballs 3.10-rt (looks better), confirms 3.10-rt hotplug works, > swipes working code, confirms 3.12-rt now works. Yup, that was it. My boxen, including 64 core DL980 that ran hotplug stress for 3 hours yesterday with pre-pushdown rwlocks, say the migrate_disable/enable pushdown patches are very definitely busted. Instead of whacking selective bits, as I did to verify that the rwlock changes were indeed causing hotplug stress deadlock woes, I'm eyeballing the lot, twiddling primitives to look like I think they should, after which I'll let my boxen express their opinions of the result. -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 V3] Add support for flag status register on Micron chips.
On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote: > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote: > > > > > the drivers may fills this hook itself, so the code should like this: > > > > >-- > > > > > > > > > > if ((info->flags & USE_FSR) && > > > > > > > > > > nor->wait_till_ready == spi_nor_wait_till_fsr_ready) > > > > > > > > > > nor->wait_till_ready = spi_nor_wait_till_fsr_ready; > > > > > > > > > >-- > > > > > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and > > > > the driver compete for a function pointer here ? I guess one should > > > > have precedence in some way then ... and also, they should be two > > > > different pointers, where the subsystem decides which to use. > > > > > > the subsystem do not decides which one to use, the driver decides which > > > one to use. > > > > > > If driver has its own @wait_till_ready , it means the driver knows the > > > feature, and has implemented it in its own @wait_till_ready. > > > > > > If the driver does not fill any wait_till_ready, it means the driver > > > will use the default @wait_till_ready. We can treat the > > > spi_nor_wait_till_fsr_ready as a default hook too. > > > > I see the driver overwriting a hook previously set by the subsystem. This > > not sure ;) > > The driver set the hooks before the subsystem set these hooks. > > If the driver has already set the @wait_till_ready hook before it calls > the spi_nor_scan, the subsystem will not set the hook anymore. > > Please see the spi_nor_check(). Two things competing over the same pointer looks misdesigned to me. I will need to dig into this one more time ... Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] KVM: nVMX: additional checks on vmxon region
Currently, the vmxon region isn't used in the nested case.
However, according to the spec, the vmxon instruction performs
additional sanity checks on this region and the associated
pointer. Modify emulated vmxon to better adhere to the spec
requirements
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 53 +
1 file changed, 53 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c18fe9a4..d5342c7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -354,6 +354,7 @@ struct vmcs02_list {
struct nested_vmx {
/* Has the level1 guest done vmxon? */
bool vmxon;
+ gpa_t vmxon_ptr;
/* The guest-physical address of the current VMCS L1 keeps for L2 */
gpa_t current_vmptr;
@@ -5840,9 +5841,19 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
struct kvm_segment cs;
struct vcpu_vmx *vmx = to_vmx(vcpu);
struct vmcs *shadow_vmcs;
+ gva_t gva;
+ gpa_t vmptr;
+ struct x86_exception e;
+ struct page *page;
+
const u64 VMXON_NEEDED_FEATURES = FEATURE_CONTROL_LOCKED
| FEATURE_CONTROL_VMXON_ENABLED_OUTSIDE_SMX;
+ /* Guest physical Address Width */
+ struct kvm_cpuid_entry2 *best =
+ kvm_find_cpuid_entry(vcpu, 0x8008, 0);
+
+
/* The Intel VMX Instruction Reference lists a bunch of bits that
* are prerequisite to running VMXON, most notably cr4.VMXE must be
* set to 1 (see vmx_set_cr4() for when we allow the guest to set this).
@@ -5865,6 +5876,46 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
kvm_inject_gp(vcpu, 0);
return 1;
}
+
+ if (get_vmx_mem_address(vcpu, vmcs_readl(EXIT_QUALIFICATION),
+ vmcs_read32(VMX_INSTRUCTION_INFO), &gva))
+ return 1;
+
+ if (kvm_read_guest_virt(&vcpu->arch.emulate_ctxt, gva, &vmptr,
+ sizeof(vmptr), &e)) {
+ kvm_inject_page_fault(vcpu, &e);
+ return 1;
+ }
+
+ /* Don't bailout if best is NULL */
+ WARN_ON(!best);
+
+ /*
+* SDM 3: 24.11.5
+* VMXON pointer must be 4KB aligned
+* VMXON pointer must not set any bits beyond processor's
+* physical address width
+* The first 4 bytes of VMXON region contain the supported
+* VMCS revision identifier
+*
+* Note - IA32_VMX_BASIC[48] will never be 1 for the nested case;
+* which replaces physical address width with 32
+*/
+ if (!IS_ALIGNED(vmptr, PAGE_SIZE) || (best &&
+ (vmptr >> (best->eax & 0xff {
+ nested_vmx_failInvalid(vcpu);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
+ page = nested_get_page(vcpu, vmptr);
+ if ((page == NULL) || ((*(u32 *)kmap(page) != VMCS12_REVISION))) {
+ nested_vmx_failInvalid(vcpu);
+ kunmap(page);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmx->nested.vmxon) {
nested_vmx_failValid(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
skip_emulated_instruction(vcpu);
@@ -5896,9 +5947,11 @@ static int handle_vmon(struct kvm_vcpu *vcpu)
vmx->nested.preemption_timer.function = vmx_preemption_timer_fn;
vmx->nested.vmxon = true;
+ vmx->nested.vmxon_ptr = vmptr;
skip_emulated_instruction(vcpu);
nested_vmx_succeed(vcpu);
+ kunmap(page);
return 1;
}
--
1.8.3.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 3/3] KVM: nVMX: fail on invalid vmclear/vmptrld pointer
The spec mandates that if the vmptrld or vmclear
address is equal to the vmxon region pointer, the
instruction should fail with error "VMPTRLD with
VMXON pointer" or "VMCLEAR with VMXON pointer"
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index d5342c7..8864fa1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6069,6 +6069,12 @@ static int handle_vmclear(struct kvm_vcpu *vcpu)
return 1;
}
+ if (vmptr == vmx->nested.vmxon_ptr) {
+ nested_vmx_failValid(vcpu, VMXERR_VMCLEAR_VMXON_POINTER);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmptr == vmx->nested.current_vmptr) {
nested_release_vmcs12(vmx);
vmx->nested.current_vmptr = -1ull;
@@ -6412,6 +6418,12 @@ static int handle_vmptrld(struct kvm_vcpu *vcpu)
return 1;
}
+ if (vmptr == vmx->nested.vmxon_ptr) {
+ nested_vmx_failValid(vcpu, VMXERR_VMPTRLD_VMXON_POINTER);
+ skip_emulated_instruction(vcpu);
+ return 1;
+ }
+
if (vmx->nested.current_vmptr != vmptr) {
struct vmcs12 *new_vmcs12;
struct page *page;
--
1.8.3.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 1/3] KVM: nVMX: rearrange get_vmx_mem_address
handle_vmon will call this function to get the vmxon region
pointer in the next patch
Signed-off-by: Bandan Das
---
arch/x86/kvm/vmx.c | 106 ++---
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 1f68c58..c18fe9a4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5775,6 +5775,59 @@ static enum hrtimer_restart
vmx_preemption_timer_fn(struct hrtimer *timer)
}
/*
+ * Decode the memory-address operand of a vmx instruction, as recorded on an
+ * exit caused by such an instruction (run by a guest hypervisor).
+ * On success, returns 0. When the operand is invalid, returns 1 and throws
+ * #UD or #GP.
+ */
+static int get_vmx_mem_address(struct kvm_vcpu *vcpu,
+unsigned long exit_qualification,
+u32 vmx_instruction_info, gva_t *ret)
+{
+ /*
+* According to Vol. 3B, "Information for VM Exits Due to Instruction
+* Execution", on an exit, vmx_instruction_info holds most of the
+* addressing components of the operand. Only the displacement part
+* is put in exit_qualification (see 3B, "Basic VM-Exit Information").
+* For how an actual address is calculated from all these components,
+* refer to Vol. 1, "Operand Addressing".
+*/
+ int scaling = vmx_instruction_info & 3;
+ int addr_size = (vmx_instruction_info >> 7) & 7;
+ bool is_reg = vmx_instruction_info & (1u << 10);
+ int seg_reg = (vmx_instruction_info >> 15) & 7;
+ int index_reg = (vmx_instruction_info >> 18) & 0xf;
+ bool index_is_valid = !(vmx_instruction_info & (1u << 22));
+ int base_reg = (vmx_instruction_info >> 23) & 0xf;
+ bool base_is_valid = !(vmx_instruction_info & (1u << 27));
+
+ if (is_reg) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
+
+ /* Addr = segment_base + offset */
+ /* offset = base + [index * scale] + displacement */
+ *ret = vmx_get_segment_base(vcpu, seg_reg);
+ if (base_is_valid)
+ *ret += kvm_register_read(vcpu, base_reg);
+ if (index_is_valid)
+ *ret += kvm_register_read(vcpu, index_reg)<> 7) & 7;
- bool is_reg = vmx_instruction_info & (1u << 10);
- int seg_reg = (vmx_instruction_info >> 15) & 7;
- int index_reg = (vmx_instruction_info >> 18) & 0xf;
- bool index_is_valid = !(vmx_instruction_info & (1u << 22));
- int base_reg = (vmx_instruction_info >> 23) & 0xf;
- bool base_is_valid = !(vmx_instruction_info & (1u << 27));
-
- if (is_reg) {
- kvm_queue_exception(vcpu, UD_VECTOR);
- return 1;
- }
-
- /* Addr = segment_base + offset */
- /* offset = base + [index * scale] + displacement */
- *ret = vmx_get_segment_base(vcpu, seg_reg);
- if (base_is_valid)
- *ret += kvm_register_read(vcpu, base_reg);
- if (index_is_valid)
- *ret += kvm_register_read(vcpu, index_reg)
[PATCH 0/3] Emulate VMXON region correctly
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=54521 The vmxon region is unused by nvmx, but adding these checks are probably harmless and may detect buggy L1 hypervisors in the future! Bandan Das (3): KVM: nVMX: rearrange get_vmx_mem_address KVM: nVMX: additional checks on vmxon region KVM: nVMX: fail on invalid vmclear/vmptrld pointer arch/x86/kvm/vmx.c | 171 - 1 file changed, 118 insertions(+), 53 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
On 04/27/2014 09:47 PM, Benjamin Herrenschmidt wrote: On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote: The catalog version number was changed from a be32 (with proceeding 32bits of padding) to a be64, update the code to treat it as a be64 Signed-off-by: Cody P Schafer -- Have you tested this ? It doesn't build for me: arch/powerpc/perf/hv-24x7.c: In function 'catalog_read': arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type 'int', but argument 2 has type 'uint64_t' [-Werror=format] cc1: all warnings being treated as errors I have, and I wasn't initially sure how I managed to miss that warning-as-error. On examination: My config (for some reason) has CONFIG_PPC_DISABLE_WERROR=y set (probably because it's a variation of a distro config). Must have been piping the warnings to a file and forgotten to check the file. I'll fix that up in my tree. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] acerhdf/thermal: adding new models and appropriate governor
Hi,
On Mon, Apr 28, 2014 at 01:13:19AM +0200, Peter Feuerer wrote:
> Hi,
>
> Andreas Mohr writes:
>
> > { "Acer", "AOA1", &aao_reg_map_AOAxxx_Acer_orig_version },
> >
> > Of course you then have the indirection of device name <-> specific
> > register values (quote: "really ugly and hard to read"?),
> > but IMHO that's ok since normally you wouldn't be too focused
> > on looking up register values (...right!?).
> >
> > And if the next interface-breaking config change came along,
> > you'd otherwise have to add yet another register index pair...
> > (at which point some 100+ char line monsters
> > would be breathing down our neck...)
>
> I think we have been discussing this solution a year ago or something and
> seems like it is really time to implement it. As I wrote in the other mail
> to Boris, I'd like to just do a minor modification for now and then when
> those 4 patches have been applied concentrate on implementing the splitted
> structs.
Yup, to get things out of the way now :)
[[BTW your mail environment seems configured to have trailing blanks -
might want to "optimize" that away...]]
> > - depends on THERMAL && ACPI
> > + depends on THERMAL && ACPI && THERMAL_GOV_BANG_BANG
> > Do we actively depend on THERMAL (code-wise, I mean?) Or is it now an
> > implicit dependency given that we request THERMAL_GOV_BANG_BANG? If
> > implicit, then THERMAL probably ought to be removed. But if we use
> > generic thermal APIs (which we probably do), then of course we do have
> > that dependency
>
> There's an implicit dependency due to the request of THERMAL_GOV_BANG_BANG, so
> yes, we could remove THERMAL here.
ok. Does not seem too risky, and reduces the need for future updates.
> > "used to force thermal" --> misleading ("we used to do this, but it's
> > bad so we better do that").
> >
> > "intended to"? "established to"? "added to"? or some simpler wording?
>
> What do you think about this wording:
> /*
> * this struct is used to instruct thermal layer to use bang_bang instead of
> * default governor for acerhdf
> */
Nicely detailed.
About the _t typedef: it's said that use of "_t" is undesirable anyway
due to being reserved for POSIX.
https://en.wikipedia.org/wiki/Typedef
http://stackoverflow.com/questions/1186072/naming-scheme-for-typedefs
As an alternative using a full "_type" is ok right?
(that's what I've been doing...)
Andreas
--
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 6/6] powerpc/perf/hv-24x7: catalog version number is be64, not be32
On Tue, 2014-04-15 at 10:10 -0700, Cody P Schafer wrote:
> The catalog version number was changed from a be32 (with proceeding
> 32bits of padding) to a be64, update the code to treat it as a be64
>
> Signed-off-by: Cody P Schafer
> --
Have you tested this ?
It doesn't build for me:
arch/powerpc/perf/hv-24x7.c: In function 'catalog_read':
arch/powerpc/perf/hv-24x7.c:223:3: error: format '%d' expects argument of type
'int', but argument 2 has type 'uint64_t' [-Werror=format]
cc1: all warnings being treated as errors
I'll fix that up in my tree.
Cheers,
Ben.
> arch/powerpc/perf/hv-24x7.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index 95a67f8..9d4badc 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -171,7 +171,7 @@ static unsigned long h_get_24x7_catalog_page_(unsigned
> long phys_4096,
> }
>
> static unsigned long h_get_24x7_catalog_page(char page[],
> - u32 version, u32 index)
> + u64 version, u32 index)
> {
> return h_get_24x7_catalog_page_(virt_to_phys(page),
> version, index);
> @@ -185,7 +185,7 @@ static ssize_t catalog_read(struct file *filp, struct
> kobject *kobj,
> ssize_t ret = 0;
> size_t catalog_len = 0, catalog_page_len = 0, page_count = 0;
> loff_t page_offset = 0;
> - uint32_t catalog_version_num = 0;
> + uint64_t catalog_version_num = 0;
> void *page = kmem_cache_alloc(hv_page_cache, GFP_USER);
> struct hv_24x7_catalog_page_0 *page_0 = page;
> if (!page)
> @@ -197,7 +197,7 @@ static ssize_t catalog_read(struct file *filp, struct
> kobject *kobj,
> goto e_free;
> }
>
> - catalog_version_num = be32_to_cpu(page_0->version);
> + catalog_version_num = be64_to_cpu(page_0->version);
> catalog_page_len = be32_to_cpu(page_0->length);
> catalog_len = catalog_page_len * 4096;
>
> @@ -255,7 +255,7 @@ e_free:
> \
> static DEVICE_ATTR_RO(_name)
>
> PAGE_0_ATTR(catalog_version, "%lld\n",
> - (unsigned long long)be32_to_cpu(page_0->version));
> + (unsigned long long)be64_to_cpu(page_0->version));
> PAGE_0_ATTR(catalog_len, "%lld\n",
> (unsigned long long)be32_to_cpu(page_0->length) * 4096);
> static BIN_ATTR_RO(catalog, 0/* real length varies */);
--
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] ASoC: samsung: Add sound card driver for Snow board
Added machine driver to instantiate I2S based sound card on Snow
board. It has MAX98095 audio codec on board.
There are some other variants for Snow board which have MAX98090
audio codec. Hence support for MAX98090 is also added to this
driver.
Signed-off-by: Tushar Behera
---
Changes for V3:
1. Updated documentation (I2S0 -> I2S)
2. Removed 'Capture' DAI and renamed 'Playback' DAI as 'Primary'.
3. Updated patch subject to match sub-system naming style.
Changes for V2:
Addressed various comments from Mark Brown.
1. Moved DAIFMT flags to dai_link. Removed snd_soc_dai_set_fmt calls.
2. Removed BCLK settings.
3. Moved sysclk settings to late_probe.
4. Removed now empty snow_hw_params.
5. Removed snow_init
6. Used devm_snd_soc_register_card. Also removed empty remove function.
7. Removed non-DT handling as the driver is DT only.
Additional nits:
1. Renamed snow_driver_probe to snow_probe
2. Removed unused pm_ops.
3. Updated clock settings for I2S block (Earlier it was I2S_CDCLK,
whereas it should be I2S_RCLKSRC_0).
4. Removed 'card-name' DT property as it was not used in earlier
sound-card driver DT bindings. Will be added later.
Documentation/devicetree/bindings/sound/snow.txt | 17 +++
sound/soc/samsung/Kconfig| 10 ++
sound/soc/samsung/Makefile |2 +
sound/soc/samsung/snow.c | 122 ++
4 files changed, 151 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/snow.txt
create mode 100644 sound/soc/samsung/snow.c
diff --git a/Documentation/devicetree/bindings/sound/snow.txt
b/Documentation/devicetree/bindings/sound/snow.txt
new file mode 100644
index 000..678b191
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/snow.txt
@@ -0,0 +1,17 @@
+Audio Binding for Snow boards
+
+Required properties:
+- compatible : Can be one of the following,
+ "google,snow-audio-max98090" or
+ "google,snow-audio-max98095"
+- samsung,i2s-controller: The phandle of the Samsung I2S controller
+- samsung,audio-codec: The phandle of the audio codec
+
+Example:
+
+sound {
+ compatible = "google,snow-audio-max98095";
+
+ samsung,i2s-controller = <&i2s0>;
+ samsung,audio-codec = <&max98095>;
+};
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index f2e2891..50aa289 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -231,3 +231,13 @@ config SND_SOC_LITTLEMILL
select SND_SAMSUNG_I2S
select MFD_WM8994
select SND_SOC_WM8994
+
+config SND_SOC_SNOW
+ tristate "Audio support for Google Snow boards"
+ depends on SND_SOC_SAMSUNG
+ select SND_SOC_MAX98090
+ select SND_SOC_MAX98095
+ select SND_SAMSUNG_I2S
+ help
+ Say Y if you want to add audio support for various Snow
+ boards based on Exynos5 series of SoCs.
diff --git a/sound/soc/samsung/Makefile b/sound/soc/samsung/Makefile
index 86715d8..6d0212b 100644
--- a/sound/soc/samsung/Makefile
+++ b/sound/soc/samsung/Makefile
@@ -34,6 +34,7 @@ snd-soc-h1940-uda1380-objs := h1940_uda1380.o
snd-soc-rx1950-uda1380-objs := rx1950_uda1380.o
snd-soc-smdk-wm8580-objs := smdk_wm8580.o
snd-soc-smdk-wm8994-objs := smdk_wm8994.o
+snd-soc-snow-objs := snow.o
snd-soc-smdk-wm9713-objs := smdk_wm9713.o
snd-soc-s3c64xx-smartq-wm8987-objs := smartq_wm8987.o
snd-soc-goni-wm8994-objs := goni_wm8994.o
@@ -58,6 +59,7 @@ obj-$(CONFIG_SND_SOC_SAMSUNG_H1940_UDA1380) +=
snd-soc-h1940-uda1380.o
obj-$(CONFIG_SND_SOC_SAMSUNG_RX1950_UDA1380) += snd-soc-rx1950-uda1380.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8580) += snd-soc-smdk-wm8580.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994) += snd-soc-smdk-wm8994.o
+obj-$(CONFIG_SND_SOC_SNOW) += snd-soc-snow.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_WM9713) += snd-soc-smdk-wm9713.o
obj-$(CONFIG_SND_SOC_SMARTQ) += snd-soc-s3c64xx-smartq-wm8987.o
obj-$(CONFIG_SND_SOC_SAMSUNG_SMDK_SPDIF) += snd-soc-smdk-spdif.o
diff --git a/sound/soc/samsung/snow.c b/sound/soc/samsung/snow.c
new file mode 100644
index 000..0fa89a4
--- /dev/null
+++ b/sound/soc/samsung/snow.c
@@ -0,0 +1,122 @@
+/*
+ * ASoC machine driver for Snow boards
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+
+#include "i2s.h"
+
+#define FIN_PLL_RATE 2400
+
+static struct snd_soc_dai_link snow_dai[] = {
+ {
+ .name = "Primary",
+ .stream_name = "Primary",
+ .codec_dai_
Re: [PATCH -V1 00/22] New ACL format for better NFSv4 acl interoperability
This doesn't address any or the previous points: - common implementation instead of the godawful boilerplate code (and we even fixed most of this for Posix ACL by now, so even less reason to do the same crap again!) - common data structure with Posix ACLs And of course no real explanation why we need the braindead access/deny scheme at how it will get properly integrated with the system. So in this for a clear NAK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] ARM: dts: am33xx: Add clock names for cpsw and cpts
Add CPSW fck and CPTS clock and clock names
Signed-off-by: George Cherian
---
arch/arm/boot/dts/am33xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9770e35..d1e2b36 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -665,6 +665,8 @@
mac: ethernet@4a10 {
compatible = "ti,cpsw";
ti,hwmods = "cpgmac0";
+ clocks = <&cpsw_125mhz_gclk>, <&cpsw_cpts_rft_clk>;
+ clock-names = "fck", "cpts";
cpdma_channels = <8>;
ale_entries = <1024>;
bd_ram_size = <0x2000>;
--
1.8.3.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 0/6] Add CPTS support for AM437x
The series adds CPTS support for AM4372. Patch 1 - CPTS clock name harcoding in the driver is removed. Easier to pass the clock name from dt rather than hardcoding in driver. Also in prepration for DRA7x CPTS support. Patch 2 - DT changes w.r.t clock changes for AM33xx. Patch 3 - Enable the CPTS support for both DRA7x and AM4372 in the driver. Patch 4 - Enable the Annexe F for L2 PTP for AM437x and DRA7x. Patch 5 - Change the default clocksource to dpll_core_m5 Patch 6 - DT changes for AM4372. George Cherian (6): drivers: net: cpts: Remove hardcoded clock name for CPTS ARM: dts: am33xx: Add clock names for cpsw and cpts drivers: net: cpsw: Enable CPTS for DRA7xx and AM4372 drivers: net: cpsw: Enable Annexe F Time sync ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk ARM: dts: am4372: Add clock names for cpsw and cpts arch/arm/boot/dts/am33xx.dtsi | 2 ++ arch/arm/boot/dts/am4372.dtsi | 2 ++ drivers/clk/ti/clk-43xx.c | 16 drivers/net/ethernet/ti/cpsw.c | 15 ++- drivers/net/ethernet/ti/cpts.c | 11 --- 5 files changed, 34 insertions(+), 12 deletions(-) -- 1.8.3.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 4/6] drivers: net: cpsw: Enable Annexe F Time sync
Enable the Annex F Time Sync explicitly for DRA7x and AM4372.
With this enabled the L2 PTP is working.
while at that rename TS_BIT8 to TS_TTL_NONZERO
Signed-off-by: George Cherian
---
drivers/net/ethernet/ti/cpsw.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 085ffb5..af1423b 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -248,7 +248,8 @@ struct cpsw_ss_regs {
#define TS_131 (1<<11) /* Time Sync Dest IP Addr 131 enable */
#define TS_130 (1<<10) /* Time Sync Dest IP Addr 130 enable */
#define TS_129 (1<<9) /* Time Sync Dest IP Addr 129 enable */
-#define TS_BIT8 (1<<8) /* ts_ttl_nonzero? */
+#define TS_TTL_NONZERO (1<<8) /* Time Sync Time To Live Non-zero enable
*/
+#define TS_ANNEX_F_EN (1<<6) /* Time Sync Annex F enable */
#define TS_ANNEX_D_EN (1<<4) /* Time Sync Annex D enable */
#define TS_LTYPE2_EN(1<<3) /* Time Sync LTYPE 2 enable */
#define TS_LTYPE1_EN(1<<2) /* Time Sync LTYPE 1 enable */
@@ -256,8 +257,9 @@ struct cpsw_ss_regs {
#define TS_RX_EN(1<<0) /* Time Sync Receive Enable */
#define CTRL_TS_BITS \
- (TS_320 | TS_319 | TS_132 | TS_131 | TS_130 | TS_129 | TS_BIT8 | \
-TS_ANNEX_D_EN | TS_LTYPE1_EN)
+ (TS_320 | TS_319 | TS_132 | TS_131 | TS_130 | TS_129 |\
+TS_TTL_NONZERO | TS_ANNEX_F_EN | TS_ANNEX_D_EN |\
+TS_LTYPE1_EN)
#define CTRL_ALL_TS_MASK (CTRL_TS_BITS | TS_TX_EN | TS_RX_EN)
#define CTRL_TX_TS_BITS (CTRL_TS_BITS | TS_TX_EN)
--
1.8.3.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 5/6] ARM: AM43xx: clk: Change the cpts ref clock source to dpll_core_m5 clk
cpsw_cpts_rft_clk has got the choice of 3 clocksources
-dpll_core_m4_ck
-dpll_core_m5_ck
-dpll_disp_m2_ck
By default dpll_core_m4_ck is selected, witn this as clock
source the CPTS doesnot work properly. It gives clockcheck errors
while running PTP.
clockcheck: clock jumped backward or running slower than expected!
By selecting dpll_core_m5_ck as the clocksource fixes this issue.
In AM335x dpll_core_m5_ck is the default clocksource.
Signed-off-by: George Cherian
---
drivers/clk/ti/clk-43xx.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..b4877e0 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -110,9 +110,25 @@ static struct ti_dt_clk am43xx_clks[] = {
int __init am43xx_dt_clk_init(void)
{
+ struct clk *clk1, *clk2;
+
ti_dt_clocks_register(am43xx_clks);
omap2_clk_disable_autoidle_all();
+ /*
+* cpsw_cpts_rft_clk has got the choice of 3 clocksources
+* dpll_core_m4_ck, dpll_core_m5_ck and dpll_disp_m2_ck.
+* By default dpll_core_m4_ck is selected, witn this as clock
+* source the CPTS doesnot work properly. It gives clockcheck errors
+* while running PTP.
+* clockcheck: clock jumped backward or running slower than expected!
+* By selecting dpll_core_m5_ck as the clocksource fixes this issue.
+* In AM335x dpll_core_m5_ck is the default clocksource.
+*/
+ clk1 = clk_get_sys(NULL, "cpsw_cpts_rft_clk");
+ clk2 = clk_get_sys(NULL, "dpll_core_m5_ck");
+ clk_set_parent(clk1, clk2);
+
return 0;
}
--
1.8.3.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 6/6] ARM: dts: am4372: Add clock names for cpsw and cpts
Add CPSW fck and CPTS clock and clock names for AM4372 Signed-off-by: George Cherian --- arch/arm/boot/dts/am4372.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 36d523a..c2779f6 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -489,6 +489,8 @@ #address-cells = <1>; #size-cells = <1>; ti,hwmods = "cpgmac0"; + clocks = <&cpsw_125mhz_gclk>, <&cpsw_cpts_rft_clk>; + clock-names = "fck", "cpts"; status = "disabled"; cpdma_channels = <8>; ale_entries = <1024>; -- 1.8.3.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 3/6] drivers: net: cpsw: Enable CPTS for DRA7xx and AM4372
Enable cpts hardware time stamping for Dra7xx and AM4372. This enables PTPv2 for DRA7xx and AM4372. Signed-off-by: George Cherian --- drivers/net/ethernet/ti/cpsw.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index 36aa109..085ffb5 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -1398,7 +1398,8 @@ static int cpsw_hwtstamp_set(struct net_device *dev, struct ifreq *ifr) struct hwtstamp_config cfg; if (priv->version != CPSW_VERSION_1 && - priv->version != CPSW_VERSION_2) + priv->version != CPSW_VERSION_2 && + priv->version != CPSW_VERSION_3) return -EOPNOTSUPP; if (copy_from_user(&cfg, ifr->ifr_data, sizeof(cfg))) @@ -1443,6 +1444,7 @@ static int cpsw_hwtstamp_set(struct net_device *dev, struct ifreq *ifr) cpsw_hwtstamp_v1(priv); break; case CPSW_VERSION_2: + case CPSW_VERSION_3: cpsw_hwtstamp_v2(priv); break; default: @@ -1459,7 +1461,8 @@ static int cpsw_hwtstamp_get(struct net_device *dev, struct ifreq *ifr) struct hwtstamp_config cfg; if (priv->version != CPSW_VERSION_1 && - priv->version != CPSW_VERSION_2) + priv->version != CPSW_VERSION_2 && + priv->version != CPSW_VERSION_3) return -EOPNOTSUPP; cfg.flags = 0; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 1/5] ACPICA: OSL: Add direct inclusion of extra header.
Hi, Rafael > From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] > Sent: Monday, April 28, 2014 5:34 AM > > On Wednesday, April 23, 2014 02:53:52 PM Lv Zheng wrote: > > This is a linuxized result of an ACPICA commit to upgrade the extra > > header mechanism. > > > > This patch enhances the extra header solution to allow Linux to use > > ACPI_USE_NATIVE_INTERFACE_HEADER and the file name can be automatically > > replaced during ACPICA release process. Using this way, the rest of the > > ACPICA users needn't know the name of the extra header file. Lv Zheng. > > > > Signed-off-by: Lv Zheng > > --- > > include/acpi/acpi.h |4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/include/acpi/acpi.h b/include/acpi/acpi.h > > index ca0cb60..682398b 100644 > > --- a/include/acpi/acpi.h > > +++ b/include/acpi/acpi.h > > @@ -62,8 +62,8 @@ > > #include /* Resource Descriptor structs */ > > #include /* OSL interfaces (ACPICA-to-OS) */ > > #include/* ACPI core subsystem external > > interfaces */ > > -#ifdef ACPI_NATIVE_INTERFACE_HEADER > > -#include ACPI_NATIVE_INTERFACE_HEADER > > +#ifdef ACPI_USE_NATIVE_INTERFACE_HEADER > > +#include > > #endif > > > > #endif /* __ACPI_H__ */ > > Well, I still think there's a better way. > > Introduce into ACPICA and put this into it: > > #if defined(_LINUX) || defined(__linux__) > #include > > #endif > > and then move stuff you want in acpi/acpi_opt.h into > acpi/platform/aclinuxex.h. > > Then, you'll have in acpi.h: > > #include /* Resource Descriptor structs */ > #include /* OSL interfaces (ACPICA-to-OS) */ > #include /* ACPI core subsystem external > interfaces */ > #include /* Extra environment-specific items */ > > > That should work I suppose, shouldn't it? I think this should work. I'll modify this patch according the above suggestion. Thanks and best regards -Lv > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center.
[PATCH 1/6] drivers: net: cpts: Remove hardcoded clock name for CPTS
CPTS refclk name is hardcoded, which makes it fail in case of DRA7x
Remove the hardcoded clock name for CPTS refclk and get the same from DT.
Signed-off-by: George Cherian
---
drivers/net/ethernet/ti/cpts.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 2435139..0b6f6f7 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -236,13 +236,11 @@ static void cpts_overflow_check(struct work_struct *work)
schedule_delayed_work(&cpts->overflow_work, CPTS_OVERFLOW_PERIOD);
}
-#define CPTS_REF_CLOCK_NAME "cpsw_cpts_rft_clk"
-
-static void cpts_clk_init(struct cpts *cpts)
+static void cpts_clk_init(struct device *dev, struct cpts *cpts)
{
- cpts->refclk = clk_get(NULL, CPTS_REF_CLOCK_NAME);
+ cpts->refclk = devm_clk_get(dev, "cpts");
if (IS_ERR(cpts->refclk)) {
- pr_err("Failed to clk_get %s\n", CPTS_REF_CLOCK_NAME);
+ pr_err("Failed to get cpts refclk\n");
cpts->refclk = NULL;
return;
}
@@ -252,7 +250,6 @@ static void cpts_clk_init(struct cpts *cpts)
static void cpts_clk_release(struct cpts *cpts)
{
clk_disable(cpts->refclk);
- clk_put(cpts->refclk);
}
static int cpts_match(struct sk_buff *skb, unsigned int ptp_class,
@@ -390,7 +387,7 @@ int cpts_register(struct device *dev, struct cpts *cpts,
for (i = 0; i < CPTS_MAX_EVENTS; i++)
list_add(&cpts->pool_data[i].list, &cpts->pool);
- cpts_clk_init(cpts);
+ cpts_clk_init(dev, cpts);
cpts_write32(cpts, CPTS_EN, control);
cpts_write32(cpts, TS_PEND_EN, int_enable);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] A new CPU load metric for power-efficient scheduler: CPU ConCurrency
On Fri, Apr 25, 2014 at 03:53:34PM +0100, Morten Rasmussen wrote: > I fully agree. My point was that there is more to task consolidation > than just observing the degree of task parallelism. The system topology > has a lot to say when deciding whether or not to pack. That was the > motivation for proposing to have a power model for the system topology > to help making that decision. > > We do already have some per-task metric available that may be useful for > determining whether a workload is eligible for task packing. The > load_avg_contrib gives us an indication of the tasks cpu utilization and > we also count task wake-ups. If we tracked task wake-ups over time > (right now we only have the sum) we should be able to reason about the > number of wake-ups that a task causes. Lots of wake-ups and low > load_avg_contrib would indicate the task power is likely to be dominated > by the wake-up costs if it is placed on a cpu in a deep idle state. > > I fully agree that measuring the workloads while they are running is the > way to go. I'm just wondering if the proposed cpu concurrency measure > is sufficient to make the task packing decision for all system > topologies or if we need something that incorporates more system > topology information. If the latter, we may want to roll it all into > something like an energy_diff(src_cpu, dst_cpu, task) helper function > for use in load-balancing decisions. > Thank you. After CC, in the consolidation part, we do 1) attach the CPU topology to "help making that decision" and to be adaptive beyond our experimental platforms, and 2) intercept the current load balance for load and load balancing containment. Maybe, the way we consolidate workload differs from previous is: 1) we don't do it per task. We only see how many concurrent CPUs needed (on average and on prediction at power gated units) for the workload, and simply consolidate. 2) I am not sure it is sufficient either, :). But I can offer another two ways of how to interpret CC. 2.1) the current work-conserving load balance also uses CC, but instantaneous CC (similar to what PeterZ said to Vincent?). 2.2) CC vs. CPU utilization. CC is runqueue-length-weighted CPU utilization. If we change: "a = sum(concurrency * time) / period" to "a' = sum(1 * time) / period". Then a' is just about the CPU utilization. And the way we weight runqueue-length is the simplest one (excluding the exponential decays, and you may have other ways). The workloads they (not me) used to evaluate the "Workload Consolidation" is 1) 50+ perf/ux benchmarks (almost all of the magazine ones), and 2) ~10 power workloads, of course, they are the easiest ones, such as browsing, audio, video, recording, imaging, etc. Thanks, Yuyang -- 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 5/5] ACPICA: Remove deprecated _LINUX definitions for ACPICA.
Hi, Rafael
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Monday, April 28, 2014 5:39 AM
>
> On Wednesday, April 23, 2014 02:54:22 PM Lv Zheng wrote:
> > There are _LINUX defined so that when Linux kernel is compiled using broken
> > compilers that having not __linux__ defined can still include
> > from .
> >
> > This behavior is deprecated as all drivers/acpi/acpica files are compiled
> > without including , thus without _LINUX defined. As there is
> > no issues encountered when we compile ACPICA code without _LINUX defined,
> > it is OK to remove _LINUX from now.
> >
> > Signed-off-by: Lv Zheng
> > ---
> > include/linux/acpi.h |4
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> > index 7a8f2cd..9c559f7 100644
> > --- a/include/linux/acpi.h
> > +++ b/include/linux/acpi.h
> > @@ -31,10 +31,6 @@
> >
> > #ifdef CONFIG_ACPI
> >
> > -#ifndef _LINUX
> > -#define _LINUX
> > -#endif
> > -
> > #include
> > #include
>
> What about ? Should it still check if _LINUX is
> defined
> after this change?
If you mean these lines:
#if defined(_LINUX) || defined(__linux__)
#include
After deleting "_LINUX" from , acenv.h still can include
aclinux.h because of "__linux__".
Actually all drivers/acpi/acpica source files are compiled without including
, so "_LINUX" defined in this file is useless to Linux.
We needn't delete "_LINUX" from acenv.h.
"_LINUX" is only used in ACPICA makefiles, Linux never uses it:
https://github.com/acpica/acpica/blob/master/generate/unix/Makefile.config
ACPICA can be compiled using the following make command:
make HOST=_LINUX
I think this is the only usage of "_LINUX" for now.
Thanks and best regards
-Lv
>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH] sound: usb: Fix format string mismatch in mixer.c
Fix format string mismatch in parse_audio_selector_unit(). Signed-off-by: Masanari Iida --- sound/usb/mixer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index d40a285..6fe83e4 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1986,7 +1986,7 @@ static int parse_audio_selector_unit(struct mixer_build *state, int unitid, void if (! len && check_input_term(state, desc->baSourceID[i], &iterm) >= 0) len = get_term_name(state, &iterm, namelist[i], MAX_ITEM_NAME_LEN, 0); if (! len) - sprintf(namelist[i], "Input %d", i); + sprintf(namelist[i], "Input %u", i); } kctl = snd_ctl_new1(&mixer_selectunit_ctl, cval); -- 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 v8 2/2] usb: ehci-exynos: Change to use phy provided by the generic phy framework
Hi,
On Fri, Apr 25, 2014 at 8:11 PM, Alan Stern wrote:
> On Fri, 25 Apr 2014, Vivek Gautam wrote:
>
>> From: Kamil Debski
>>
>> Add the phy provider, supplied by new Exynos-usb2phy using
>> Generic phy framework.
>> Keeping the support for older USB phy intact right now, in order
>> to prevent any functionality break in absence of relevant
>> device tree side change for ehci-exynos.
>> Once we move to new phy in the device nodes for ehci, we can
>> remove the support for older phys.
>>
>> Signed-off-by: Kamil Debski
>> [gautam.vi...@samsung.com: Addressed review comments from mailing list]
>> [gautam.vi...@samsung.com: Kept the code for old usb-phy, and just
>> added support for new exynos5-usb2phy in generic phy framework]
>> [gautam.vi...@samsung.com: Edited the commit message]
>> Signed-off-by: Vivek Gautam
>
>> +static int exynos_ehci_phyg_off(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>
> Same comment as in the OHCI driver about ret.
Ok, will change this.
>
>> @@ -175,6 +269,7 @@ skip_phy:
>> fail_add_hcd:
>> if (exynos_ehci->phy)
>> usb_phy_shutdown(exynos_ehci->phy);
>> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
>> fail_io:
>> clk_disable_unprepare(exynos_ehci->clk);
>> fail_clk:
>> @@ -195,6 +290,8 @@ static int exynos_ehci_remove(struct platform_device
>> *pdev)
>> if (exynos_ehci->phy)
>> usb_phy_shutdown(exynos_ehci->phy);
>>
>> + exynos_ehci_phyg_off(exynos_ehci->phy_g);
>> +
>
> In both these places, you need to test exynos_ehci->phyg before calling
> exynos_ehci_phyg_off().
>
> Maybe it would help to add exynos_ehci_phy_enable/disable routines,
> like in the OHCI driver.
Will move these statements as a part of enable()/disable() routines,
put necessary check there.
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 1/2] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework
Hi,
On Fri, Apr 25, 2014 at 8:06 PM, Alan Stern wrote:
> On Fri, 25 Apr 2014, Vivek Gautam wrote:
>
>> Add support to consume phy provided by Generic phy framework.
>> Keeping the support for older usb-phy intact right now, in order
>> to prevent any functionality break in absence of relevant
>> device tree side change for ohci-exynos.
>> Once we move to new phy in the device nodes for ohci, we can
>> remove the support for older phys.
>>
>> Signed-off-by: Vivek Gautam
>> Cc: Jingoo Han
>> Cc: Alan Stern
>
>
>> +static int exynos_ohci_phyg_on(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_on(phy[i]);
>> + if (ret)
>> + for (i--; i >= 0; i--)
>> + if (phy[i])
>> + phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>> +
>> +static int exynos_ohci_phyg_off(struct phy *phy[])
>> +{
>> + int i;
>> + int ret = 0;
>> +
>> + for (i = 0; ret == 0 && i < PHY_NUMBER; i++)
>> + if (phy[i])
>> + ret = phy_power_off(phy[i]);
>> +
>> + return ret;
>> +}
>
> You probably shouldn't break out of this loop if ret is nonzero; you
> should continue to power off the remaining phys.
ok, will remove the 'ret' check in for loop.
>
> I'd be inclined to put these two routines directly into
> exynos_ohci_phy_enable() and exynos_ohci_phy_disable(), since they
> aren't used anywhere else.
Sure, will make these routines as a part of exynos_ohci_phy_enable()
and exynos_ohci_phy_disable().
>
>> @@ -151,6 +253,7 @@ skip_phy:
>>
>> fail_add_hcd:
>> exynos_ohci_phy_disable(pdev);
>> + exynos_ohci_phyg_off(exynos_ohci->phy_g);
>
> Why did you add this line? It doesn't do anything useful, because
> exynos_ohci_phy_disable() already calls exynos_ohci_phyg_off().
Ah ! my bad, will remove this.
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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] linux/interrupt.h: fix new kernel-doc warnings
From: Randy Dunlap Fix new kernel-doc warnings in : Warning(include/linux/interrupt.h:219): No description found for parameter 'cpumask' Warning(include/linux/interrupt.h:219): Excess function parameter 'mask' description in 'irq_set_affinity' Warning(include/linux/interrupt.h:236): No description found for parameter 'cpumask' Warning(include/linux/interrupt.h:236): Excess function parameter 'mask' description in 'irq_force_affinity' Signed-off-by: Randy Dunlap --- include/linux/interrupt.h |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- lnx-315-rc3.orig/include/linux/interrupt.h +++ lnx-315-rc3/include/linux/interrupt.h @@ -210,7 +210,7 @@ extern int __irq_set_affinity(unsigned i /** * irq_set_affinity - Set the irq affinity of a given irq * @irq: Interrupt to set affinity - * @mask: cpumask + * @cpumask: cpumask * * Fails if cpumask does not contain an online CPU */ @@ -223,7 +223,7 @@ irq_set_affinity(unsigned int irq, const /** * irq_force_affinity - Force the irq affinity of a given irq * @irq: Interrupt to set affinity - * @mask: cpumask + * @cpumask: cpumask * * Same as irq_set_affinity, but without checking the mask against * online cpus. -- 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/
Linux 3.15-rc3
Another week, another rc. So far, no big scares, and rc3 is
appropriately smaller than rc2 was, so we're following the right
trajectory here.
The statistics look fairly normal too, with half drivers (input, usb,
gpu, acpi, regulator..) and a third arch updates (much of it again arm
dts files, but other arm and some um updates too). The rest is misc,
but mainly concentrated in filesystem updates (btrfs and ext4).
Linus
---
Adam Thomson (1):
Input: da9055_onkey - remove use of regmap_irq_get_virq()
Alan Stern (1):
[SCSI] Fix command result state propagation
Alec Berg (1):
iio: querying buffer scan_mask should return 0/1
Alex Deucher (7):
drm/radeon: disable dpm on rv770 by default
drm/radeon/aux: fix hpd assignment for aux bus
drm/radeon: fix count in cik_sdma_ring_test()
drm/radeon: properly unregister hwmon interface (v2)
drm/radeon/pm: don't walk the crtc list before it has been
initialized (v2)
drm/radeon: fix ATPX detection on non-VGA GPUs
drm/radeon: don't allow runpm=1 on systems with out ATPX
Alex Elder (1):
ARM: spear: add __init to spear_clocksource_init()
Alexander Gordeev (3):
ahci: Ensure "MSI Revert to Single Message" mode is not enforced
ahci: Use pci_enable_msi_exact() instead of pci_enable_msi_range()
ahci: Do not receive interrupts sent by dummy ports
Alexander Shiyan (1):
ARM: 8024/1: Keep DEBUG_UART_{PHYS,VIRT} entries sorted
Alexander Stein (2):
spi: atmel: Fix scheduling while atomic bug
Input: ads7846 - fix device usage within attribute show
Alexandre Belloni (5):
iio: adc: at91_adc: Repair broken platform_data support
ARM: at91: at91sam9g45: change at91_adc name
ARM: at91: at91sam9260: change at91_adc name
iio: adc: at91_adc: correct default shtim value
iio: adc: mxs-lradc: fix warning when buidling on avr32
Andrea Adami (1):
ARM: pxa: hx4700.h: include "irqs.h" for PXA_NR_BUILTIN_GPIO
Andrew Lunn (2):
ARM: Kirkwood: Fix Atmel vendor prefix
ARM: Kirkwood: DT: Add missing vendor prefix
Andy Lutomirski (1):
x86, vdso: Make the vdso linker script compatible with Gold
Anton Ivanov (2):
um: Missing pipe handling
um: Memory corruption on startup
Arnd Bergmann (1):
phy: exynos: fix building as a module
Axel Lin (2):
regulator: pbias: Fix is_enabled callback implementation
regulator: pbias: Convert to use regmap helper functions
Azat Khuzhin (2):
ext4: initialize multi-block allocator before checking block descriptors
ext4: fix ext4_count_free_clusters() with EXT4FS_DEBUG and
bigalloc enabled
Bartlomiej Zolnierkiewicz (3):
pata_at91: fix ata_host_activate() failure handling
pata_arasan_cf: fix ata_host_activate() failure handling
pata_samsung_cf: fix ata_host_activate() failure handling
Beomho Seo (1):
iio: cm32181: Fix read integration time function
Bjorn Helgaas (1):
PNP: Work around BIOS defects in Intel MCH area reporting
Bjørn Mork (6):
usb: qcserial: add Sierra Wireless EM7355
usb: qcserial: add Sierra Wireless MC73xx
usb: qcserial: add Sierra Wireless MC7305/MC7355
usb: option: add Olivetti Olicard 500
usb: option: add Alcatel L800MA
usb: option: add and update a number of CMOTech devices
Chanho Min (1):
arm64: init: Move of_clk_init to time_init
Chao Bi (1):
usb: gadget: ffs: race between ffs_epfile_io() and ffs_func_eps_disable()
Chen Gang (1):
ext4: fix 64-bit number truncation warning
Chris Mason (1):
Btrfs: limit the path size in send to PATH_MAX
Christian Borntraeger (1):
s390/ccwgroup: Fix memory corruption
Christian König (2):
drm/radeon: use fixed PPL ref divider if needed
drm/radeon: improve PLL limit handling in post div calculation
Christoph Hellwig (2):
[SCSI] don't reference freed command in scsi_init_sgtable
[SCSI] don't reference freed command in scsi_prep_return
Christoph Jaeger (2):
btrfs: fix use-after-free in mount_subvol()
intel_idle: fix IVT idle state table setting
Dan Carpenter (1):
clk: vexpress: NULL dereference on error path
Dan Williams (1):
libata/ahci: accommodate tag ordered controllers
Daniel Mack (2):
usb: musb: dsps: move debugfs_remove_recursive()
usb: phy: am335x-control: wait 1ms after power-up transitions
David Cohen (1):
usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM
David Milburn (1):
ahci: do not request irq for dummy port
David Sterba (1):
btrfs: replace error code from btrfs_drop_extents
Denis Turischev (1):
xhci: Switch Intel Lynx Point ports to EHCI on shutdown.
Dmitry Monakhov (2):
ext4: fix error handling in ext4_ext_shift_extents
ext4: always check ext4_ext_find_extent result
Domenico Andreoli (1):
ARM: Tidy up DTB Makefile entries
Doug Anderson (3):
serial: samsung:
[PATCH] block: Fix format string mismatch in cfq-iosched.c
Fix format string mismatch in cfq_var_show()
Signed-off-by: Masanari Iida
---
block/cfq-iosched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index 5063a0b..22dffeb 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -4460,7 +4460,7 @@ out_free:
static ssize_t
cfq_var_show(unsigned int var, char *page)
{
- return sprintf(page, "%d\n", var);
+ return sprintf(page, "%u\n", var);
}
static ssize_t
--
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/
[PATCH v2] irqchip: vt8500: Switch to a simple write clear for Interrupt Status Register
According to the datasheet, the attribute of Interrupt Status Register is RW0S,
which means:
Software can read the register.
Software can also "write 1 to clear". "write 0" has no effect.
So the read/modify/write cycle is no necessary, switch to a simple write clear
instead.
Signed-off-by: Axel Lin
---
v2: Update commit log, this is a code simplification rather than bug fix.
drivers/irqchip/irq-vt8500.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/irqchip/irq-vt8500.c b/drivers/irqchip/irq-vt8500.c
index eb6e91e..a0085bc 100644
--- a/drivers/irqchip/irq-vt8500.c
+++ b/drivers/irqchip/irq-vt8500.c
@@ -87,14 +87,10 @@ static void vt8500_irq_mask(struct irq_data *d)
void __iomem *base = priv->base;
void __iomem *stat_reg = base + VT8500_ICIS + (d->hwirq < 32 ? 0 : 4);
u8 edge, dctr;
- u32 status;
edge = readb(base + VT8500_ICDC + d->hwirq) & VT8500_EDGE;
if (edge) {
- status = readl(stat_reg);
-
- status |= (1 << (d->hwirq & 0x1f));
- writel(status, stat_reg);
+ writel(BIT(d->hwirq & 0x1f), stat_reg);
} else {
dctr = readb(base + VT8500_ICDC + d->hwirq);
dctr &= ~VT8500_INT_ENABLE;
--
1.8.3.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] irqchip: vt8500: Switch to a simple write clear for Interrupt Status Register
2014-04-28 2:34 GMT+08:00 Thomas Gleixner : > On Sun, 27 Apr 2014, Axel Lin wrote: > >> According to the datasheet, the attribute of Interrupt Status Register is >> RW0S, >> which means: >> Software can read the register. >> Software can also "write 1 to clear". "write 0" has no effect. >> Thus switch the read/modify/write to a simple write clear. >> >> A read/modify/write does not make sense for an irq status register like this, >> since otherwise a read/modify/write can race with a device raising an >> interrupt >> and then clear the pending bit unintentionally. > > That's right, but what you are not seeing is that this is the mask > callback which is supposed to mask the interrupt at the interrupt > controller level. > > I have a hard time to see (even without reading the data sheet) how > clearing a potentially pending interrupt in the status register will > mask the interrupt line. ok, I'll send a v2 to update the commit log. Thanks for the review. Regards, Axel -- 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 6/6] cgroup, memcg: implement css->id and convert css_from_id() to use it
On 2014/4/25 5:02, Tejun Heo wrote: > Until now, cgroup->id has been used to identify all the associated > csses and css_from_id() takes cgroup ID and returns the matching css > by looking up the cgroup and then dereferencing the css associated > with it; however, now that the lifetimes of cgroup and css are > separate, this is incorrect and breaks on the unified hierarchy when a > controller is disabled and enabled back again before the previous > instance is released. > > This patch adds css->id which is a subsystem-unique ID and converts > css_from_id() to look up by the new css->id instead. memcg is the > only user of css_from_id() and also converted to use css->id instead. > netprio_cgroup also needs to be updated. > For traditional hierarchies, this shouldn't make any functional > difference. > > Signed-off-by: Tejun Heo > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Jianyu Zhan > --- > include/linux/cgroup.h | 9 > kernel/cgroup.c| 59 > -- > mm/memcontrol.c| 4 ++-- > 3 files changed, 49 insertions(+), 23 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 0/3] Fix several sparc64 THP bugs.
From: mr...@linux.ee Date: Sat, 26 Apr 2014 23:14:59 +0300 (EEST) >> Meelis and Aaro, I've found and fixed several THP bugs for sparc64 >> over the last week or so. >> >> I cannot %100 account for the exit_mmap() WARN_ON that you two have >> been able to trigger, however I'd like you both to test the changes >> nonetheless. >> >> They are against 3.15 but they should apply cleanly all the way back >> to 3.13 >> >> Thanks in advance for testing. > > Tried it on Netra X1, Ultra 2 and V100 that were online (applied the > patches and enabled THP with defaulting to always). > > Ultra 2 did not boot up (will see on Monday). > > Netra X1 performed a simple dist-upgrade fine with this kernel. > > V100 boots up fine but as soon as I start aptitude, it just hangs with > nothing on console (tried it twice). Sigh, thanks for testing... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-BR] Re: [RFC] Only a.out QMAGIC format is working
Geyslan Gregório Bem writes: > > There should be chance to fix it. > > I think it too. If it's randomization the following could help: echo 0 > /proc/sys/kernel/randomize_va_space Does it? -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: [PATCH v2 3/5] ACPICA: Add to remove mis-ordered inclusion of from .
Hi, Rafael
> From: linux-acpi-ow...@vger.kernel.org
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Monday, April 28, 2014 5:37 AM
> To: Zheng, Lv
>
> On Wednesday, April 23, 2014 02:54:06 PM Lv Zheng wrote:
> > There is a mis-order inclusion for .
> >
> > As we will enforce including for all Linux ACPI users, we
> > can find the inclusion order is as follows:
> >
> >
> >
> >
> > (acenv.h before including aclinux.h)
> >
> > ...
> > (aclinux.h before including asm/acpi.h)
> > @Redundant@
> > (ACPICA specific stuff)
> > ...
> > ...
> > (Linux ACPI specific stuff) ? - - - - - - - - - - - - +
> > (aclinux.h after including asm/acpi.h) @Invisible@ |
> > (acenv.h after including aclinux.h) @Invisible@ |
> >other ACPICA headers @Invisible@ |
> > |..
> >|
> >|
> >(Excluded) |
> >(Linux ACPI specific stuff) ! <- - - - - - - - - - - - - +
> >
> > NOTE that, in ACPICA, is more like Kconfig
> > generated for Linux, it is meant to be included
> > before including any ACPICA code.
> >
> > In the above figure, there is a question mark for "Linux ACPI specific
> > stuff" in which should be included after including all other
> > ACPICA header files. Thus they really need to be moved to the position
> > marked with exclaimation mark or the definitions in the blocks marked with
> > "@Invisible@" will be invisible to such architecture specific "Linux ACPI
> > specific stuff" header blocks. This leaves 2 issues:
> > 1. All environmental definitions in these blocks should have a copy in the
> >area marked with "@Redundant@" if they are required by the "Linux ACPI
> >specific stuff".
> > 2. We cannot use any ACPICA defined types in .
> >
> > This patch splits architecture specific ACPICA stuff from to
> > fix this issue.
> >
> > Signed-off-by: Lv Zheng
> > Cc: Tony Luck
> > Cc: Fenghua Yu
> > Cc: linux-i...@vger.kernel.org
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Peter Anvin"
> > Cc: x...@kernel.org
> > ---
> > arch/ia64/include/asm/acenv.h | 71
> > +++
> > arch/ia64/include/asm/acpi.h| 50 ---
> > arch/x86/include/asm/acenv.h| 65 +++
> > arch/x86/include/asm/acpi.h | 45 -
> > include/acpi/platform/aclinux.h |2 +-
>
> Please rename the files first (in a separate patch) and then modify the
> renamed ones. That will make changes much easier to follow.
This patch doesn't provide a rename.
Currently, includes:
1. arch specific ACPI stuff
2. arch specific ACPICA stuff
This patch moves "2" to a separate file , thus no renaming happens
here.
Thanks and best regards
-Lv
>
> > 5 files changed, 137 insertions(+), 96 deletions(-)
> > create mode 100644 arch/ia64/include/asm/acenv.h
> > create mode 100644 arch/x86/include/asm/acenv.h
> >
> > diff --git a/arch/ia64/include/asm/acenv.h b/arch/ia64/include/asm/acenv.h
> > new file mode 100644
> > index 000..e0896eb
> > --- /dev/null
> > +++ b/arch/ia64/include/asm/acenv.h
> > @@ -0,0 +1,71 @@
> > +/*
> > + * IA64 specific ACPICA environments and implementation
> > + *
> > + * Copyright (C) 2014, Intel Corporation
> > + * Author: Lv Zheng
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef _ASM_IA64_ACENV_H
> > +#define _ASM_IA64_ACENV_H
> > +
> > +#include
> > +
> > +#define COMPILER_DEPENDENT_INT64 long
> > +#define COMPILER_DEPENDENT_UINT64 unsigned long
> > +
> > +/*
> > + * Calling conventions:
> > + *
> > + * ACPI_SYSTEM_XFACE- Interfaces to host OS (handlers, threads)
> > + * ACPI_EXTERNAL_XFACE - External ACPI interfaces
> > + * ACPI_INTERNAL_XFACE - Internal ACPI interfaces
> > + * ACPI_INTERNAL_VAR_XFACE - Internal variable-parameter list interfaces
> > + */
> > +#define ACPI_SYSTEM_XFACE
> > +#define ACPI_EXTERNAL_XFACE
> > +#define ACPI_INTERNAL_XFACE
> > +#define ACPI_INTERNAL_VAR_XFACE
> > +
> > +/* Asm macros */
> > +
> > +#define ACPI_FLUSH_CPU_CACHE()
> > +
> > +#ifdef CONFIG_ACPI
> > +
> > +static inline int
> > +ia64_acpi_acquire_global_lock(unsigned int *lock)
> > +{
> > + unsigned int old, new, val;
> > + do {
> > + old = *lock;
> > + new = (((old & ~0x3) + 2) + ((old >> 1) & 0x1));
> > +
[PATCH] sched/deadline: remove dl_new checking condition from dl_task_timer()
From: "yjay.kim" yield_task_dl() sets dl.dl_new as 1 and dequeue current dl task. After that it expects that next bandwidth timer callback `dl_task_timer()` will replenish budget of dl task and enqueue it again. But current dl_task_timer() does nothing in case dl.dl_new is 1. So when dl task calls sched_yield(), it will never be scheduled again. dl_task_timer() should works in case dl_new is 1. Signed-off-by: yjay.kim --- kernel/sched/deadline.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 27ef409..6fb4004 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -522,7 +522,7 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer *timer) * different from SCHED_DEADLINE or changed its reservation * parameters (through sched_setscheduler()). */ - if (!dl_task(p) || dl_se->dl_new) + if (!dl_task(p)) goto unlock; sched_clock_tick(); -- 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/
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/netlink/af_netlink.c between commit 5187cd055b6e ("netlink: Rename
netlink_capable netlink_allowed") from the net tree and commit
4f520900522f ("netlink: have netlink per-protocol bind function return an
error code") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc net/netlink/af_netlink.c
index 81dca96d2be6,92f4b6915e89..
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@@ -1492,8 -1445,8 +1510,8 @@@ static int netlink_bind(struct socket *
return -EINVAL;
/* Only superuser is allowed to listen multicasts */
- if (nladdr->nl_groups) {
+ if (groups) {
- if (!netlink_capable(sock, NL_CFG_F_NONROOT_RECV))
+ if (!netlink_allowed(sock, NL_CFG_F_NONROOT_RECV))
return -EPERM;
err = netlink_realloc_groups(sk);
if (err)
pgpTQOjua2zR4.pgp
Description: PGP signature
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/altera/altera_sgdma.c between commit 37c0ffaad214
("Altera TSE: Work around unaligned DMA receive packet issue with Altera
SGDMA") from the net tree and commit d42f157b3498 ("Altera TSE: Remove
unnecessary cast of void pointers") from the net-next tree.
I fixed it up (the former removes the code updated by the latter, so I
did that) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgptr72LElx8R.pgp
Description: PGP signature
Re: [PATCH] acpi: try to trust cpu_index from x86_cpu_to_apicid
On 04/21/14 at 10:51pm, Rafael J. Wysocki wrote:
> On Tuesday, April 15, 2014 07:55:54 AM Baoquan He wrote:
> > In smp with multi cpus, when enter into kdump kernel with only 1 cpu,
> > a warning message is printed out:
> >
> > acpi LNXCPU:0a: BIOS reported wrong ACPI id 0 for the processor
> >
> > In this case kdump kernel use the same ACPI tables as 1st kernel,
> > means lapic information is got from MADT. The acpi_id related to
> > this cpu index and lapic_id may not be 0, so the code to assign
> > value to cpu_index is not correct in this case per cpu0_initialized.
> > cpu index stored in x86_cpu_to_apicid need be respected.
> >
> > Now fix it in this patch per boot_cpu_physical_apicid. When cpu index
> > related to boot_cpu_physical_apicid is not stored in x86_cpu_to_apicid,
> > then we can say this is UP system running SMP kernel with no LAPIC in MADT
>
> Why don't you fix the warning message instead to cover this case too?
>
> > Signed-off-by: Baoquan He
> > ---
> > drivers/acpi/acpi_processor.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
> > index c29c2c3..1ae460c 100644
> > --- a/drivers/acpi/acpi_processor.c
> > +++ b/drivers/acpi/acpi_processor.c
> > @@ -267,7 +267,7 @@ static int acpi_processor_get_info(struct acpi_device
> > *device)
> > pr->apic_id = apic_id;
> >
> > cpu_index = acpi_map_cpuid(pr->apic_id, pr->acpi_id);
> > - if (!cpu0_initialized) {
> > + if (!cpu0_initialized && (boot_cpu_physical_apicid == pr->apic_id)) {
Self NACK this patch.
Since this check should be limited on no LAPIC in MADT, so acpi_lapic is
better for this. Will repost after test.
Hi Rafael,
Do you have any suggestion on this fix?
Thanks
Baoquan
--
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/
[Bugfix v2] sched: fix possible invalid memory access caused by CPU hot-addition
Intel platforms with Nehalem/Westmere/IvyBridge CPUs may support socket
hotplug/online at runtime. The CPU hot-addition flow is:
1) handle CPU hot-addition event
1.a) gather platform specific information
1.b) associate hot-added CPU with NUMA node
1.c) create CPU device
2) online hot-added CPU through sysfs:
2.a)cpu_up()
2.b)->try_online_node()
2.c)->hotadd_new_pgdat()
2.d)->node_set_online()
Between 1.b and 2.c, hot-added CPUs are associated with NUMA nodes
but those NUMA nodes may still be in offlined state. So we should
check node_online(nid) before calling kmalloc_node(nid) and friends,
otherwise it may cause invalid memory access as below.
[ 3663.324476] BUG: unable to handle kernel paging request at 1f08
[ 3663.332348] IP: [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.339719] PGD 82fe10067 PUD 82ebef067 PMD 0
[ 3663.344773] Oops: [#1] SMP
[ 3663.348455] Modules linked in: shpchp gpio_ich x86_pkg_temp_thermal
intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul
ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper
cryptd microcode joydev sb_edac edac_core lpc_ich ipmi_si tpm_tis
ipmi_msghandler ioatdma wmi acpi_pad mac_hid lp parport ixgbe isci mpt2sas dca
ahci ptp libsas libahci raid_class pps_core scsi_transport_sas mdio hid_generic
usbhid hid
[ 3663.394393] CPU: 61 PID: 2416 Comm: cron Tainted: GW3.14.0-rc5+
#21
[ 3663.402643] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRIVTIN1.86B.0047.F03.1403031049 03/03/2014
[ 3663.414299] task: 88082fe54b00 ti: 880845fba000 task.ti:
880845fba000
[ 3663.422741] RIP: 0010:[] []
__alloc_pages_nodemask+0xb9/0x2d0
[ 3663.432857] RSP: 0018:880845fbbcd0 EFLAGS: 00010246
[ 3663.439265] RAX: 1f00 RBX: RCX:
[ 3663.447291] RDX: RSI: 0a8d RDI: 81a8d950
[ 3663.455318] RBP: 880845fbbd58 R08: 880823293400 R09: 0001
[ 3663.463345] R10: 0001 R11: R12: 002052d0
[ 3663.471363] R13: 880854c07600 R14: 0002 R15:
[ 3663.479389] FS: 7f2e8b99e800() GS:88105a40()
knlGS:
[ 3663.488514] CS: 0010 DS: ES: CR0: 80050033
[ 3663.495018] CR2: 1f08 CR3: 0008237b1000 CR4: 001407e0
[ 3663.503476] Stack:
[ 3663.505757] 811bd74d 880854c01d98 880854c01df0
880854c01dd0
[ 3663.514167] 0003208ca420 00075a5d84d0 88082fe54b00
811bb35f
[ 3663.522567] 880854c07600 0003 1f00
880845fbbd48
[ 3663.530976] Call Trace:
[ 3663.533753] [] ? deactivate_slab+0x41d/0x4f0
[ 3663.540421] [] ? new_slab+0x3f/0x2d0
[ 3663.546307] [] new_slab+0xa5/0x2d0
[ 3663.552001] [] __slab_alloc+0x35d/0x54a
[ 3663.558185] [] ? local_clock+0x25/0x30
[ 3663.564686] [] ? __do_page_fault+0x4ec/0x5e0
[ 3663.571356] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.578609] [] ? __raw_spin_lock_init+0x21/0x60
[ 3663.585570] [] kmem_cache_alloc_node_trace+0xa6/0x1d0
[ 3663.593112] [] ? alloc_fair_sched_group+0xc4/0x190
[ 3663.600363] [] alloc_fair_sched_group+0xc4/0x190
[ 3663.607423] [] sched_create_group+0x3f/0x80
[ 3663.613994] [] sched_autogroup_create_attach+0x3f/0x1b0
[ 3663.621732] [] sys_setsid+0xea/0x110
[ 3663.628020] [] system_call_fastpath+0x1a/0x1f
[ 3663.634780] Code: 00 44 89 e7 e8 b9 f8 f4 ff 41 f6 c4 10 74 18 31 d2 be 8d
0a 00 00 48 c7 c7 50 d9 a8 81 e8 70 6a f2 ff e8 db dd 5f 00 48 8b 45 c8 <48> 83
78 08 00 0f 84 b5 01 00 00 48 83 c0 08 44 89 75 c0 4d 89
[ 3663.657032] RIP [] __alloc_pages_nodemask+0xb9/0x2d0
[ 3663.664491] RSP
[ 3663.668429] CR2: 1f08
[ 3663.672659] ---[ end trace df13f08ed9de18ad ]---
Signed-off-by: Jiang Liu
---
Hi all,
We have improved log messages according to Peter's suggestion,
no code changes.
Thanks!
Gerry
---
kernel/sched/fair.c | 12 +++-
kernel/sched/rt.c | 11 +++
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 7570dd969c28..71be1b96662e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7487,7 +7487,7 @@ int alloc_fair_sched_group(struct task_group *tg, struct
task_group *parent)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se;
- int i;
+ int i, nid;
tg->cfs_rq = kzalloc(sizeof(cfs_rq) * nr_cpu_ids, GFP_KERNEL);
if (!tg->cfs_rq)
@@ -7501,13 +7501,15 @@ int alloc_fair_sched_group(struct task_group *tg,
struct task_group *parent)
init_cfs_bandwidth(tg_cfs_bandwidth(tg));
for_each_possible_cpu(i) {
- cfs_rq = kzalloc_node(sizeof(struct cfs_rq),
- GFP_KERNEL, cpu_to_node(i));
+ nid = c
[PATCH 0/1] ftrace/ring_buffer: reset reader page after consuming read
Reading from the 'trace' file after force stopping (by signal) consuming read reveals there are stale trace entries in the output, this patch fixes the bug by resetting read/write pointers of reader page after the consuming read is stopped by force. The issue can be reproduced as below: echo 0 > tracing_on echo function > current_tracer echo 1 > tracing_on 1, read the trace file as normal cat trace | head -n 20 ... cat trace | head -n 20 The trace entries are changing at the head of the output. NOTE: If it's not changing at the start please repeat the reading several times because the tracer need time to fill up the whole buffer. 2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C cat trace_pipe Ctrl-C cat trace | head -n 200 ... cat trace | head -n 200 The trace entries at the head of the output stop changing, followed by changing trace entries. NOTE: Please carefully check the time stamps of the trace entries, the time stamps of some of them at the head stop changing in the consecutive read. The results of test 1 and 2 are not consistent with respect to the updating of trace buffers, some part of the trace buffers are not updated in the test 2 while all of them are updated in the test 1. And the result of test 1 is correct because the trace entries supposed to be changed for the reason the tracer works under overwrite mode by default. Thanks Shan Hai -- 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 1/1] ftrace/ring_buffer: reset reader page after consuming read was performed to the page
Reset the reader page to avoid reading old trace entries repeatedly
in non-consuming read after a force stopped(by signal) consuming read.
The force stopped reader might left the reader page half filled by the
writer while the commit and tail pages are on the page when it is stopped.
The reader page holds the old trace entries until next consuming reader
swaps the page into ring buffer because the reader page is not part of
ring buffer. The non-consuming reader gets the old data repeatedly because
the reading of ring buffer starts from reader page and the reader would not
swap the reader page into ring buffer for its non-consuming nature.
The issue can be reproduced as below:
echo 0 > tracing_on
echo function > current_tracer
echo 1 > tracing_on
1, read the trace file as normal
cat trace | head -n 20
...
cat trace | head -n 20
The trace entries are changing at the head of the output.
NOTE:
If it's not changing at the start please repeat the reading
several times because the tracer need time to fill up the
whole buffer.
2, read the trace file after stopping 'cat trace_pipe' by Ctrl-C
cat trace_pipe
Ctrl-C
cat trace | head -n 200
...
cat trace | head -n 200
The trace entries at the head of the output stop changing,
followed by changing trace entries.
NOTE:
Please carefully check the time stamps of the trace entries,
the time stamps of some of them at the head stop changing
in the consecutive read.
The results of test 1 and 2 are not consistent with respect to the
updating of trace buffers, some part of the trace buffers are
not updated in the test 2 while all of them are updated in the
test 1.
And the result of test 1 is correct because the trace entries
supposed to be changed for the reason the tracer works under
overwrite mode by default.
Cc: sta...@vger.kernel.org
Signed-off-by: Shan Hai
---
kernel/trace/ring_buffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index c634868..76cf402 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -3364,6 +3364,14 @@ static void rb_iter_reset(struct ring_buffer_iter *iter)
return;
iter->head = iter->head_page->read;
} else {
+ /* Reset the pointers because a force stopped(by signal)
+* consuming reader might left the page half filled.
+*/
+ local_set(&cpu_buffer->reader_page->write, 0);
+ local_set(&cpu_buffer->reader_page->entries, 0);
+ local_set(&cpu_buffer->reader_page->page->commit, 0);
+ cpu_buffer->reader_page->read = 0;
+
iter->head_page = cpu_buffer->reader_page;
iter->head = cpu_buffer->reader_page->read;
}
--
1.8.5.2.233.g932f7e4
--
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: add OProfile support
On 2014/4/26 18:22, Ding Tianhong wrote: > On 2014/4/26 17:23, Catalin Marinas wrote: >> On 26 Apr 2014, at 09:38, Ding Tianhong wrote: >>> Add OProfile support for arm64, using the perf backend, and failing back >>> to generic timer based sampling if PMU interrupt is not supported. >>> >>> I have test this patch on Cortex-A53 and Cortex-A57 motherboard, the >>> OProfile >>> could work well by PMU irq or arch timer irq. >> >> This came up before a few times and we also had an implementation but >> decided not to merge it. We should rather get the user space oprofile to >> use the perf kernel API. >> >> That’s an old thread, it may have even made it into mainline oprofile >> but I haven’t followed the development: >> >> http://marc.info/?l=oprofile-list&m=133002515616302&w=2 >> >> Catalin >> Hi Cadtalin: Sorry I could not find the implementation that not to merge the orpfile support for aarch64 till now, and I still have questions that the existing code only support oprofile by arch timer event, but not PMU event, this patch only add HW PMU support for oprofile, it is more accurate and stable, can you give me more advise and appreciate for your help. Regards Ding > Ok, I will check it and then decide the next step, thanks for your feedback. > > Regards > Ding > -- 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 2/4] staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table
From: Dmitry Eremin
Local variable 'hash' is never used
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c
b/drivers/staging/lustre/lnet/lnet/api-ni.c
index 85b8d81..3f1fdaa 100644
--- a/drivers/staging/lustre/lnet/lnet/api-ni.c
+++ b/drivers/staging/lustre/lnet/lnet/api-ni.c
@@ -127,8 +127,7 @@ lnet_create_remote_nets_table(void)
static void
lnet_destroy_remote_nets_table(void)
{
- int i;
- struct list_head*hash;
+ int i;
if (the_lnet.ln_remote_nets_hash == NULL)
return;
@@ -137,7 +136,8 @@ lnet_destroy_remote_nets_table(void)
LASSERT(list_empty(&the_lnet.ln_remote_nets_hash[i]));
LIBCFS_FREE(the_lnet.ln_remote_nets_hash,
- LNET_REMOTE_NETS_HASH_SIZE * sizeof(*hash));
+ LNET_REMOTE_NETS_HASH_SIZE *
+ sizeof(the_lnet.ln_remote_nets_hash[0]));
the_lnet.ln_remote_nets_hash = NULL;
}
--
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 v3 3/4] staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected
From: Dmitry Eremin
Null pointer 'cp' that comes from line 2544 may be dereferenced
at line 2618.
found by Klocwork Insight tool
Signed-off-by: Dmitry Eremin
Reviewed-on: http://review.whamcloud.com/9386
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4629
Reviewed-by: John L. Hammond
Reviewed-by: Isaac Huang
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
index 6173e74..9bf6c94 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c
@@ -2609,13 +2609,17 @@ kiblnd_rejected (kib_conn_t *conn, int reason, void
*priv, int priv_nob)
case IBLND_REJECT_MSG_QUEUE_SIZE:
CERROR("%s rejected: incompatible message queue
depth %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_queue_depth,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_queue_depth :
+ IBLND_MSG_QUEUE_SIZE(rej->ibr_version),
IBLND_MSG_QUEUE_SIZE(conn->ibc_version));
break;
case IBLND_REJECT_RDMA_FRAGS:
CERROR("%s rejected: incompatible # of RDMA
fragments %d, %d\n",
- libcfs_nid2str(peer->ibp_nid),
cp->ibcp_max_frags,
+ libcfs_nid2str(peer->ibp_nid),
+ cp != NULL ? cp->ibcp_max_frags :
+ IBLND_RDMA_FRAGS(rej->ibr_version),
IBLND_RDMA_FRAGS(conn->ibc_version));
break;
--
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 v3 0/4] Lustre Klocwork fixes
This is just splitting big lnet fixes patch from Klocwork static analysis tool into smaller bits. Reworked according to previous comments. Also, this time with correct CC list. Dmitry Eremin (2): staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected Oleg Drokin (2): staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips staging/lustre/lnet: fix potential null pointer dereference drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++-- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c| 4 drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++--- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 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 v3 4/4] staging/lustre/lnet: fix potential null pointer dereference
Pointer 'ni' checked for NULL at line 1569 may be passed to function and may be dereferenced there by passing argument 1 to function 'lnet_ni_notify_locked' at line 1621. found by Klocwork Insight tool Signed-off-by: Oleg Drokin CC: Dmitry Eremin CC: Liang Zhen --- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c index 995f509..926923a 100644 --- a/drivers/staging/lustre/lnet/lnet/router.c +++ b/drivers/staging/lustre/lnet/lnet/router.c @@ -145,7 +145,7 @@ lnet_ni_notify_locked(lnet_ni_t *ni, lnet_peer_t *lp) * NB individual events can be missed; the only guarantee is that you * always get the most recent news */ - if (lp->lp_notifying) + if (lp->lp_notifying || ni == NULL) return; lp->lp_notifying = 1; -- 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 v3 1/4] staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips
It should never be NULL because our interface list is up to date,
and even if it does, we'll just crash anyway so we are no better off.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 21d36ee..a391d13 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -793,8 +793,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
ip = peer->ksnp_passive_ips[i];
best_iface = ksocknal_ip2iface(peer->ksnp_ni, ip);
- /* peer passive ips are kept up to date */
- LASSERT(best_iface != NULL);
} else {
/* choose a new interface */
LASSERT (i == peer->ksnp_n_passive_ips);
@@ -835,8 +833,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
peer->ksnp_n_passive_ips = i+1;
}
- LASSERT (best_iface != NULL);
-
/* mark the best matching peer IP used */
j = ksocknal_match_peerip(best_iface, peerips, n_peerips);
peerips[j] = 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/
Re: [PATCH] module: remove warning about waiting module removal.
Lucas De Marchi writes:
> Hi Rusty,
>
> On Thu, Apr 24, 2014 at 3:24 AM, Rusty Russell wrote:
>> We remove the waiting module removal in commit 3f2b9c9cdf38 (September
>> 2013), but it turns out that modprobe in kmod (< version 16) was
>> asking for waiting module removal. Noone noticed since modprobe would
>> check for 0 usage immediately before trying to remove the module, and
>> the race is unlikely.
>>
>> However, it means that anyone running old (but not ancient) kmod
>> versions is hitting the printk designed to see if anyone was running
>> "rmmod -w". All reports so far have been false positives, so remove
>> the warning.
>>
>> Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517
>> Reported-by: Valerio Vanni
>> Cc: Elliott, Robert (Server Storage)
>> Cc: sta...@kernel.org
>> Signed-off-by: Rusty Russell
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 11869408f79b..ae7821898bf2 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -815,9 +815,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
>> name_user,
>> return -EFAULT;
>> name[MODULE_NAME_LEN-1] = '\0';
>>
>> - if (!(flags & O_NONBLOCK))
>> - pr_warn("waiting module removal not supported: please
>> upgrade\n");
>> -
>> if (mutex_lock_interruptible(&module_mutex) != 0)
>> return -EINTR;
>>
>
> Ack.
>
> If you are going to apply this, do you think it'd be still good to
> patch kmod on distros, so at least modprobe -r uses O_NONBLOCK? Or
> having this patch in kernel is sufficient?
I think it's sufficient: distros will get this patch via stable. kmod
updates can occur at a natural pace.
Thanks,
Rusty.
--
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] ftrace/module: Hardcode ftrace_module_init() call into load_module()
Steven Rostedt writes: > [ > Rusty, you can take this patch, or if you want, you can give me > an Acked-by, and I'll push this through my tree. > ] Assuming you want this in the current kernel, I'll just ack: Acked-by: Rusty Russell Since I've got my "make RO/NX earlier" patch queued for *next* window, and yours need to go in before that... Thanks, Rusty. -- 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] staging/lustre: Replace jobid acquiring with per node setting
Insted of meddling directly in process environment variables
(which is also not possible on certain platforms due to not exported
symbols), create jobid_name proc file to represent this info
(to be filled by job scheduler epilogue).
Signed-off-by: Oleg Drokin
CC: Andreas Dilger
---
.../staging/lustre/include/linux/libcfs/curproc.h | 1 -
.../staging/lustre/lustre/include/lprocfs_status.h | 1 +
drivers/staging/lustre/lustre/include/obd_class.h | 3 +
.../lustre/lustre/libcfs/linux/linux-curproc.c | 152 -
drivers/staging/lustre/lustre/obdclass/class_obd.c | 50 ++-
.../lustre/lustre/obdclass/linux/linux-module.c| 27
6 files changed, 44 insertions(+), 190 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/curproc.h
b/drivers/staging/lustre/include/linux/libcfs/curproc.h
index 8fd47c9..b314f34 100644
--- a/drivers/staging/lustre/include/linux/libcfs/curproc.h
+++ b/drivers/staging/lustre/include/linux/libcfs/curproc.h
@@ -56,7 +56,6 @@
/* check if task is running in compat mode.*/
#define current_pid() (current->pid)
#define current_comm() (current->comm)
-int cfs_get_environ(const char *key, char *value, int *val_len);
typedef __u32 cfs_cap_t;
diff --git a/drivers/staging/lustre/lustre/include/lprocfs_status.h
b/drivers/staging/lustre/lustre/include/lprocfs_status.h
index 9ce12c7..1b7f6a9 100644
--- a/drivers/staging/lustre/lustre/include/lprocfs_status.h
+++ b/drivers/staging/lustre/lustre/include/lprocfs_status.h
@@ -369,6 +369,7 @@ static inline void s2dhms(struct dhms *ts, time_t secs)
#define JOBSTATS_JOBID_VAR_MAX_LEN 20
#define JOBSTATS_DISABLE "disable"
#define JOBSTATS_PROCNAME_UID "procname_uid"
+#define JOBSTATS_NODELOCAL "nodelocal"
extern int lprocfs_write_frac_helper(const char *buffer, unsigned long count,
int *val, int mult);
diff --git a/drivers/staging/lustre/lustre/include/obd_class.h
b/drivers/staging/lustre/lustre/include/obd_class.h
index 61ba370..e265820 100644
--- a/drivers/staging/lustre/lustre/include/obd_class.h
+++ b/drivers/staging/lustre/lustre/include/obd_class.h
@@ -2182,6 +2182,9 @@ void class_exit_uuidlist(void);
int mea_name2idx(struct lmv_stripe_md *mea, const char *name, int namelen);
int raw_name2idx(int hashtype, int count, const char *name, int namelen);
+/* class_obd.c */
+extern char obd_jobid_node[];
+
/* prng.c */
#define ll_generate_random_uuid(uuid_out) cfs_get_random_bytes(uuid_out,
sizeof(class_uuid_t))
diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
index e74c3e2..bd301ce 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
@@ -100,158 +100,6 @@ cfs_cap_t cfs_curproc_cap_pack(void)
return cap;
}
-static int cfs_access_process_vm(struct task_struct *tsk, unsigned long addr,
-void *buf, int len, int write)
-{
- /* Just copied from kernel for the kernels which doesn't
-* have access_process_vm() exported */
- struct mm_struct *mm;
- struct vm_area_struct *vma;
- struct page *page;
- void *old_buf = buf;
-
- mm = get_task_mm(tsk);
- if (!mm)
- return 0;
-
- down_read(&mm->mmap_sem);
- /* ignore errors, just check how much was successfully transferred */
- while (len) {
- int bytes, rc, offset;
- void *maddr;
-
- rc = get_user_pages(tsk, mm, addr, 1,
-write, 1, &page, &vma);
- if (rc <= 0)
- break;
-
- bytes = len;
- offset = addr & (PAGE_SIZE-1);
- if (bytes > PAGE_SIZE-offset)
- bytes = PAGE_SIZE-offset;
-
- maddr = kmap(page);
- if (write) {
- copy_to_user_page(vma, page, addr,
- maddr + offset, buf, bytes);
- set_page_dirty_lock(page);
- } else {
- copy_from_user_page(vma, page, addr,
- buf, maddr + offset, bytes);
- }
- kunmap(page);
- page_cache_release(page);
- len -= bytes;
- buf += bytes;
- addr += bytes;
- }
- up_read(&mm->mmap_sem);
- mmput(mm);
-
- return buf - old_buf;
-}
-
-/* Read the environment variable of current process specified by @key. */
-int cfs_get_environ(const char *key, char *value, int *val_len)
-{
- struct mm_struct *mm;
- char *buffer, *tmp_buf = NULL;
- int buf_len = PAGE_CACHE_SIZE;
- int key_len = strlen(key);
- unsigned long addr;
- int rc;
-
-
[PATCH 3.2 08/94] vhost: fix total length when packets are too short
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Michael S. Tsirkin"
[ Upstream commit d8316f3991d207fe32881a9ac20241be8fa2bad0 ]
When mergeable buffers are disabled, and the
incoming packet is too large for the rx buffer,
get_rx_bufs returns success.
This was intentional in order for make recvmsg
truncate the packet and then handle_rx would
detect err != sock_len and drop it.
Unfortunately we pass the original sock_len to
recvmsg - which means we use parts of iov not fully
validated.
Fix this up by detecting this overrun and doing packet drop
immediately.
CVE-2014-0077
Signed-off-by: Michael S. Tsirkin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/vhost/net.c | 14 ++
1 file changed, 14 insertions(+)
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -346,6 +346,12 @@ static int get_rx_bufs(struct vhost_virt
*iovcount = seg;
if (unlikely(log))
*log_num = nlogs;
+
+ /* Detect overrun */
+ if (unlikely(datalen > 0)) {
+ r = UIO_MAXIOV + 1;
+ goto err;
+ }
return headcount;
err:
vhost_discard_vq_desc(vq, headcount);
@@ -400,6 +406,14 @@ static void handle_rx(struct vhost_net *
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
break;
+ /* On overrun, truncate and discard */
+ if (unlikely(headcount > UIO_MAXIOV)) {
+ msg.msg_iovlen = 1;
+ err = sock->ops->recvmsg(NULL, sock, &msg,
+1, MSG_DONTWAIT | MSG_TRUNC);
+ pr_debug("Discarded rx packet: len %zd\n", sock_len);
+ continue;
+ }
/* OK, now we need to know about added descriptors. */
if (!headcount) {
if (unlikely(vhost_enable_notify(&net->dev, vq))) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 86/94] x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: "H. Peter Anvin"
commit b3b42ac2cbae1f3cecbb6229964a4d48af31d382 upstream.
The IRET instruction, when returning to a 16-bit segment, only
restores the bottom 16 bits of the user space stack pointer. We have
a software workaround for that ("espfix") for the 32-bit kernel, but
it relies on a nonzero stack segment base which is not available in
32-bit mode.
Since 16-bit support is somewhat crippled anyway on a 64-bit kernel
(no V86 mode), and most (if not quite all) 64-bit processors support
virtualization for the users who really need it, simply reject
attempts at creating a 16-bit segment when running on top of a 64-bit
kernel.
Cc: Linus Torvalds
Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/n/tip-kicdm89kzw9lldryb1br9...@git.kernel.org
Signed-off-by: Ben Hutchings
---
arch/x86/kernel/ldt.c | 11 +++
1 file changed, 11 insertions(+)
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -230,6 +230,17 @@ static int write_ldt(void __user *ptr, u
}
}
+ /*
+* On x86-64 we do not support 16-bit segments due to
+* IRET leaking the high bits of the kernel stack address.
+*/
+#ifdef CONFIG_X86_64
+ if (!ldt_info.seg_32bit) {
+ error = -EINVAL;
+ goto out_unlock;
+ }
+#endif
+
fill_ldt(&ldt, &ldt_info);
if (oldmode)
ldt.avl = 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: [Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware
On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot wrote:
> nvc0_graph_ctor() would only let the graphics engine be enabled if its
> oclass has a proper microcode linked to it. This prevents GR from being
> enabled at all on chips that rely exclusively on external firmware, even
> though such a use-case is valid.
>
> Relax the conditions enabling the GR engine to also include the case
> where an external firmware has also been loaded.
I'm happy to take this patch as-is. I do wonder if we should do
something like this though:
if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", oclass->fecs.ucode == NULL))
Which will automatically switch to external firmware if there's no
internal implementation available.
Thoughts? This could be a separate patch even, if preferred.
Thanks,
Ben.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> index f3c7329da0a0..e5b75f189988 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> @@ -1259,10 +1259,13 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
> nouveau_object *engine,
> struct nvc0_graph_oclass *oclass = (void *)bclass;
> struct nouveau_device *device = nv_device(parent);
> struct nvc0_graph_priv *priv;
> + bool use_ext_fw, enable;
> int ret, i;
>
> - ret = nouveau_graph_create(parent, engine, bclass,
> - (oclass->fecs.ucode != NULL), &priv);
> + use_ext_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
> + enable = use_ext_fw || oclass->fecs.ucode != NULL;
> +
> + ret = nouveau_graph_create(parent, engine, bclass, enable, &priv);
> *pobject = nv_object(priv);
> if (ret)
> return ret;
> @@ -1272,7 +1275,7 @@ nvc0_graph_ctor(struct nouveau_object *parent, struct
> nouveau_object *engine,
>
> priv->base.units = nvc0_graph_units;
>
> - if (nouveau_boolopt(device->cfgopt, "NvGrUseFW", false)) {
> + if (use_ext_fw) {
> nv_info(priv, "using external firmware\n");
> if (nvc0_graph_ctor_fw(priv, "fuc409c", &priv->fuc409c) ||
> nvc0_graph_ctor_fw(priv, "fuc409d", &priv->fuc409d) ||
> --
> 1.9.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 06/94] ipv6: Avoid unnecessary temporary addresses being generated
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Heiner Kallweit
[ Upstream commit ecab67015ef6e3f3635551dcc9971cf363cc1cd5 ]
tmp_prefered_lft is an offset to ifp->tstamp, not now. Therefore
age needs to be added to the condition.
Age calculation in ipv6_create_tempaddr is different from the one
in addrconf_verify and doesn't consider ADDRCONF_TIMER_FUZZ_MINUS.
This can cause age in ipv6_create_tempaddr to be less than the one
in addrconf_verify and therefore unnecessary temporary address to
be generated.
Use age calculation as in addrconf_modify to avoid this.
Signed-off-by: Heiner Kallweit
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/addrconf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -900,8 +900,11 @@ retry:
* Lifetime is greater than REGEN_ADVANCE time units. In particular,
* an implementation must not create a temporary address with a zero
* Preferred Lifetime.
+* Use age calculation as in addrconf_verify to avoid unnecessary
+* temporary addresses being generated.
*/
- if (tmp_prefered_lft <= regen_advance) {
+ age = (now - tmp_tstamp + ADDRCONF_TIMER_FUZZ_MINUS) / HZ;
+ if (tmp_prefered_lft <= regen_advance + age) {
in6_ifa_put(ifp);
in6_dev_put(idev);
ret = -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 3.2 87/94] target/tcm_fc: Fix use-after-free of ft_tpg
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Grover
commit 2c42be2dd4f6586728dba5c4e197afd5cfaded78 upstream.
ft_del_tpg checks tpg->tport is set before unlinking the tpg from the
tport when the tpg is being removed. Set this pointer in ft_tport_create,
or the unlinking won't happen in ft_del_tpg and tport->tpg will reference
a deleted object.
This patch sets tpg->tport in ft_tport_create, because that's what
ft_del_tpg checks, and is the only way to get back to the tport to
clear tport->tpg.
The bug was occuring when:
- lport created, tport (our per-lport, per-provider context) is
allocated.
tport->tpg = NULL
- tpg created
- a PRLI is received. ft_tport_create is called, tpg is found and
tport->tpg is set
- tpg removed. ft_tpg is freed in ft_del_tpg. Since tpg->tport was not
set, tport->tpg is not cleared and points at freed memory
- Future calls to ft_tport_create return tport via first conditional,
instead of searching for new tpg by calling ft_lport_find_tpg.
tport->tpg is still invalid, and will access freed memory.
see https://bugzilla.redhat.com/show_bug.cgi?id=1071340
Signed-off-by: Andy Grover
Signed-off-by: Nicholas Bellinger
Signed-off-by: Ben Hutchings
---
drivers/target/tcm_fc/tfc_sess.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/target/tcm_fc/tfc_sess.c
+++ b/drivers/target/tcm_fc/tfc_sess.c
@@ -72,6 +72,7 @@ static struct ft_tport *ft_tport_create(
if (tport) {
tport->tpg = tpg;
+ tpg->tport = tport;
return tport;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 75/94] sh: fix format string bug in stack tracer
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Matt Fleming
commit a0c32761e73ccbf592b702f284221fea8040 upstream.
Kees reported the following error:
arch/sh/kernel/dumpstack.c: In function 'print_trace_address':
arch/sh/kernel/dumpstack.c:118:2: error: format not a string literal and no
format arguments [-Werror=format-security]
Use the "%s" format so that it's impossible to interpret 'data' as a
format string.
Signed-off-by: Matt Fleming
Reported-by: Kees Cook
Acked-by: Kees Cook
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
arch/sh/kernel/dumpstack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/sh/kernel/dumpstack.c
+++ b/arch/sh/kernel/dumpstack.c
@@ -80,7 +80,7 @@ static int print_trace_stack(void *data,
*/
static void print_trace_address(void *data, unsigned long addr, int reliable)
{
- printk(data);
+ printk("%s", (char *)data);
printk_address(addr, reliable);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 25/94] ARM: 7954/1: mm: remove remaining domain support from ARMv6
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
commit b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream.
CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is
because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do
not have hardware thread registers. The lack of these registers requires
the kernel to update the vectors page at each context switch in order to
write a new TLS pointer. This write must be done via the userspace
mapping, since aliasing caches can lead to expensive flushing when using
kmap. Finally, this requires the vectors page to be mapped r/w for
kernel and r/o for user, which has implications for things like put_user
which must trigger CoW appropriately when targetting user pages.
The upshot of all this is that a v6/v7 kernel makes use of domains to
segregate kernel and user memory accesses. This has the nasty
side-effect of making device mappings executable, which has been
observed to cause subtle bugs on recent cores (e.g. Cortex-A15
performing a speculative instruction fetch from the GIC and acking an
interrupt in the process).
This patch solves this problem by removing the remaining domain support
from ARMv6. A new memory type is added specifically for the vectors page
which allows that page (and only that page) to be mapped as user r/o,
kernel r/w. All other user r/o pages are mapped also as kernel r/o.
Patch co-developed with Russell King.
Signed-off-by: Will Deacon
Signed-off-by: Russell King
[bwh: Backported to 3.2:
- Adjust filename, context
- Drop condition on CONFIG_ARM_LPAE]
Signed-off-by: Ben Hutchings
---
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -3,11 +3,6 @@
#ifdef __KERNEL__
-#if defined(CONFIG_CPU_USE_DOMAINS) && defined(CONFIG_SMP)
-/* ARM doesn't provide unprivileged exclusive memory accessors */
-#include
-#else
-
#include
#include
#include
@@ -163,6 +158,5 @@ futex_atomic_op_inuser (int encoded_op,
return ret;
}
-#endif /* !(CPU_USE_DOMAINS && SMP) */
#endif /* __KERNEL__ */
#endif /* _ASM_ARM_FUTEX_H */
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -139,6 +139,7 @@
#define L_PTE_MT_DEV_NONSHARED (_AT(pteval_t, 0x0c) << 2) /* 1100 */
#define L_PTE_MT_DEV_WC(_AT(pteval_t, 0x09) << 2) /* 1001
*/
#define L_PTE_MT_DEV_CACHED(_AT(pteval_t, 0x0b) << 2) /* 1011 */
+#define L_PTE_MT_VECTORS (_AT(pteval_t, 0x0f) << 2) /* */
#define L_PTE_MT_MASK (_AT(pteval_t, 0x0f) << 2)
#endif /* _ASM_PGTABLE_2LEVEL_H */
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -458,7 +458,6 @@ config CPU_32v5
config CPU_32v6
bool
select TLS_REG_EMUL if !CPU_32v6K && !MMU
- select CPU_USE_DOMAINS if CPU_V6 && MMU
config CPU_32v6K
bool
@@ -652,7 +651,7 @@ config ARM_THUMBEE
config SWP_EMULATE
bool "Emulate SWP/SWPB instructions"
- depends on !CPU_USE_DOMAINS && CPU_V7
+ depends on CPU_V7
select HAVE_PROC_CPU if PROC_FS
default y if SMP
help
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -426,6 +426,14 @@ static void __init build_mem_type_table(
mem_types[MT_MEMORY_NONCACHED].prot_pte |= L_PTE_SHARED;
}
/*
+* We don't use domains on ARMv6 (since this causes problems with
+* v6/v7 kernels), so we must use a separate memory type for user
+* r/o, kernel r/w to map the vectors page.
+*/
+ if (cpu_arch == CPU_ARCH_ARMv6)
+ vecs_pgprot |= L_PTE_MT_VECTORS;
+
+ /*
* ARMv6 and above have extended page tables.
*/
if (cpu_arch >= CPU_ARCH_ARMv6 && (cr & CR_XP)) {
--- a/arch/arm/mm/proc-macros.S
+++ b/arch/arm/mm/proc-macros.S
@@ -106,13 +106,9 @@
* 100x 1 0 1 r/o no acc
* 10x0 1 0 1 r/o no acc
* 1011 0 0 1 r/w no acc
- * 110x 0 1 0 r/w r/o
- * 11x0 0 1 0 r/w r/o
- * 0 1 1 r/w r/w
- *
- * If !CONFIG_CPU_USE_DOMAINS, the following permissions are changed:
* 110x 1 1 1 r/o r/o
* 11x0 1 1 1 r/o r/o
+ * 0 1 1 r/w r/w
*/
.macro armv6_mt_table pfx
\pfx\()_mt_table:
@@ -131,7 +127,7 @@
.long PTE_EXT_TEX(2) @
L_PTE_MT_DEV_NONSHARED
.long 0x00@ unused
.long 0x00@ unused
- .long 0x00@ unused
+ .long PTE_CACHEABLE | PTE_BUFFERABLE | PTE_EXT_APX@
L_PTE_MT_VECTORS
.endm
.macro armv6_set_pte_ext pfx
@@ -152,24 +148,21 @@
tst r1, #L_PTE_USER
orrne r3, r3, #PTE_EXT_AP1
-#ifdef CONFIG_CPU_USE_DOMAINS
- @ allow kernel read/write access to read-only u
Re: [PATCH V5 12/12] ACPI: introduce .handle_children flag for acpi scan handler
On Mon, 2014-04-28 at 00:26 +0200, Rafael J. Wysocki wrote:
> On Tuesday, April 08, 2014 12:06:59 AM Zhang Rui wrote:
> > For some devices with scan handler attached, their children devices
> > are enumerated by the scan handler, indirectly.
>
> This isn't the case really. They are enumerated by bus controller drivers
> for the buses they are on.
>
that's what I mean by saying "indirectly". :)
> > In this case, we do not want to enumerate the children devices in
> > acpi scan code explicitly.
> >
> > Thus a new flag .handle_children is introduced in this patch.
> >
> > For scan handlers with this flag set, we will do default enumeration neither
> > for the attached devices nor for the children of the attached devices.
>
> I'm not sure if that is the right approach. I would prefer that to be
> handled in a more fine-graind manner, like a flag per device ID or something
> similar?
>
hmmm, how about this,
first, keep the device->flags.no_child_enumeration flag introduced in
this patch
second, set the flag explicitly, for specified devices, in the scan
handler .attach() function.
thanks,
rui
> > Signed-off-by: Zhang Rui
> > ---
> > drivers/acpi/acpi_lpss.c |2 ++
> > drivers/acpi/scan.c | 28 ++--
> > include/acpi/acpi_bus.h |4 +++-
> > 3 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
> > index 965428f..da0a3d4 100644
> > --- a/drivers/acpi/acpi_lpss.c
> > +++ b/drivers/acpi/acpi_lpss.c
> > @@ -521,6 +521,7 @@ static struct acpi_scan_handler lpss_handler = {
> > .attach = acpi_lpss_create_device,
> > .bind = acpi_lpss_bind,
> > .unbind = acpi_lpss_unbind,
> > + .handle_children = true,
> > };
> >
> > #endif /* CONFIG_X86_INTEL_LPSS */
> > @@ -534,6 +535,7 @@ static int acpi_lpss_dummy_attach(struct acpi_device
> > *adev,
> > static struct acpi_scan_handler lpss_dummy_handler = {
> > .ids = acpi_lpss_device_ids,
> > .attach = acpi_lpss_dummy_attach,
> > + .handle_children = true,
> > };
> >
> > void __init acpi_lpss_init(void)
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 44c4668..4ea867e 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> > @@ -2073,6 +2073,31 @@ static acpi_status acpi_bus_check_add(acpi_handle
> > handle, u32 lvl_not_used,
> > return AE_OK;
> > }
> >
> > +static void acpi_do_default_enumeration(struct acpi_device *device)
> > +{
> > + /*
> > +* Do not do enumeration for device object that
> > +* its parent doesn't want to
> > +*/
> > + if (device->parent && device->parent->flags.no_child_enumeration) {
> > + device->flags.no_child_enumeration = 1;
> > + return;
> > + }
> > +
> > + /* Do not do enumeration for device object with scan handler attached */
> > + if (device->handler) {
> > + if (device->handler->handle_children)
> > + device->flags.no_child_enumeration = 1;
> > + return;
> > + }
> > +
> > + /* Do not do enumeration for device object w/o platform_id */
> > + if (!device->pnp.type.platform_id)
> > + return;
> > +
> > + acpi_create_platform_device(device, NULL);
> > +}
> > +
> > static int acpi_scan_attach_handler(struct acpi_device *device)
> > {
> > struct acpi_hardware_id *hwid;
> > @@ -2095,8 +2120,7 @@ static int acpi_scan_attach_handler(struct
> > acpi_device *device)
> > }
> > }
> >
> > - if (device->pnp.type.platform_id && !device->handler)
> > - acpi_create_platform_device(device, NULL);
> > + acpi_do_default_enumeration(device);
> >
> > return ret;
> > }
> > diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> > index ec92ad3..4724fe5 100644
> > --- a/include/acpi/acpi_bus.h
> > +++ b/include/acpi/acpi_bus.h
> > @@ -137,6 +137,7 @@ struct acpi_scan_handler {
> > void (*bind)(struct device *phys_dev);
> > void (*unbind)(struct device *phys_dev);
> > struct acpi_hotplug_profile hotplug;
> > + bool handle_children;
> > };
> >
> > /*
> > @@ -207,7 +208,8 @@ struct acpi_device_flags {
> > u32 no_hotplug:1;
> > u32 hotplug_notify:1;
> > u32 is_dock_station:1;
> > - u32 reserved:22;
> > + u32 no_child_enumeration:1;
> > + u32 reserved:21;
> > };
> >
> > /* File System */
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 17/94] Revert "sparc64: Fix __copy_{to,from}_user_inatomic defines."
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Dave Kleikamp [ Upstream commit 16932237f2978a2265662f8de4af743b1f55a209 ] This reverts commit 145e1c0023585e0e8f6df22316308ec61c5066b2. This commit broke the behavior of __copy_from_user_inatomic when it is only partially successful. Instead of returning the number of bytes not copied, it now returns 1. This translates to the wrong value being returned by iov_iter_copy_from_user_atomic. xfstests generic/246 and LTP writev01 both fail on btrfs and nfs because of this. Signed-off-by: Dave Kleikamp Cc: Hugh Dickins Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- arch/sparc/include/asm/uaccess_64.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/include/asm/uaccess_64.h b/arch/sparc/include/asm/uaccess_64.h index 3e1449f..6d6c731 100644 --- a/arch/sparc/include/asm/uaccess_64.h +++ b/arch/sparc/include/asm/uaccess_64.h @@ -267,8 +267,8 @@ extern long __strnlen_user(const char __user *, long len); #define strlen_user __strlen_user #define strnlen_user __strnlen_user -#define __copy_to_user_inatomic ___copy_to_user -#define __copy_from_user_inatomic ___copy_from_user +#define __copy_to_user_inatomic __copy_to_user +#define __copy_from_user_inatomic __copy_from_user #endif /* __ASSEMBLY__ */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 33/94] [media] media: gspca: sn9c20x: add ID for Genius Look 1320 V2
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Wolfram Sang
commit 61f0319193c44adbbada920162d880b1fdb3aeb3 upstream.
Signed-off-by: Wolfram Sang
Signed-off-by: Hans de Goede
Signed-off-by: Mauro Carvalho Chehab
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings
---
Documentation/video4linux/gspca.txt | 1 +
drivers/media/video/gspca/sn9c20x.c | 1 +
2 files changed, 2 insertions(+)
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -55,6 +55,7 @@ zc3xx 0458:700f Genius VideoCam Web V2
sonixj 0458:7025 Genius Eye 311Q
sn9c20x0458:7029 Genius Look 320s
sonixj 0458:702e Genius Slim 310 NB
+sn9c20x0458:7045 Genius Look 1320 V2
sn9c20x0458:704a Genius Slim 1320
sn9c20x0458:704c Genius i-Look 1321
sn9c20x045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650)
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -2521,6 +2521,7 @@ static const struct usb_device_id device
{USB_DEVICE(0x045e, 0x00f4), SN9C20X(OV9650, 0x30, 0)},
{USB_DEVICE(0x145f, 0x013d), SN9C20X(OV7660, 0x21, 0)},
{USB_DEVICE(0x0458, 0x7029), SN9C20X(HV7131R, 0x11, 0)},
+ {USB_DEVICE(0x0458, 0x7045), SN9C20X(MT9M112, 0x5d, LED_REVERSE)},
{USB_DEVICE(0x0458, 0x704a), SN9C20X(MT9M112, 0x5d, 0)},
{USB_DEVICE(0x0458, 0x704c), SN9C20X(MT9M112, 0x5d, 0)},
{USB_DEVICE(0xa168, 0x0610), SN9C20X(HV7131R, 0x11, 0)},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 14/94] isdnloop: several buffer overflows
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dan Carpenter
[ Upstream commit 7563487cbf865284dcd35e9ef5a95380da046737 ]
There are three buffer overflows addressed in this patch.
1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
then copy it into a 60 character buffer. I have made the destination
buffer 64 characters and I'm changed the sprintf() to a snprintf().
2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
character buffer so we have 54 characters. The ->eazlist[] is 11
characters long. I have modified the code to return if the source
buffer is too long.
3) In isdnloop_command() the cbuf[] array was 60 characters long but the
max length of the string then can be up to 79 characters. I made the
cbuf array 80 characters long and changed the sprintf() to snprintf().
I also removed the temporary "dial" buffer and changed it to use "p"
directly.
Unfortunately, we pass the "cbuf" string from isdnloop_command() to
isdnloop_writecmd() which truncates anything over 60 characters to make
it fit in card->omsg[]. (It can accept values up to 255 characters so
long as there is a '\n' character every 60 characters). For now I have
just fixed the memory corruption bug and left the other problems in this
driver alone.
Signed-off-by: Dan Carpenter
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/isdn/isdnloop/isdnloop.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -518,9 +518,9 @@ static isdnloop_stat isdnloop_cmd_table[
static void
isdnloop_fake_err(isdnloop_card * card)
{
- char buf[60];
+ char buf[64];
- sprintf(buf, "E%s", card->omsg);
+ snprintf(buf, sizeof(buf), "E%s", card->omsg);
isdnloop_fake(card, buf, -1);
isdnloop_fake(card, "NAK", -1);
}
@@ -903,6 +903,8 @@ isdnloop_parse_cmd(isdnloop_card * card)
case 7:
/* 0x;EAZ */
p += 3;
+ if (strlen(p) >= sizeof(card->eazlist[0]))
+ break;
strcpy(card->eazlist[ch - 1], p);
break;
case 8:
@@ -1133,7 +1135,7 @@ isdnloop_command(isdn_ctrl * c, isdnloop
{
ulong a;
int i;
- char cbuf[60];
+ char cbuf[80];
isdn_ctrl cmd;
isdnloop_cdef cdef;
@@ -1198,7 +1200,6 @@ isdnloop_command(isdn_ctrl * c, isdnloop
break;
if ((c->arg & 255) < ISDNLOOP_BCH) {
char *p;
- char dial[50];
char dcode[4];
a = c->arg;
@@ -1210,10 +1211,10 @@ isdnloop_command(isdn_ctrl * c, isdnloop
} else
/* Normal Dial */
strcpy(dcode, "CAL");
- strcpy(dial, p);
- sprintf(cbuf, "%02d;D%s_R%s,%02d,%02d,%s\n",
(int) (a + 1),
- dcode, dial, c->parm.setup.si1,
- c->parm.setup.si2, c->parm.setup.eazmsn);
+ snprintf(cbuf, sizeof(cbuf),
+"%02d;D%s_R%s,%02d,%02d,%s\n", (int)
(a + 1),
+dcode, p, c->parm.setup.si1,
+c->parm.setup.si2,
c->parm.setup.eazmsn);
i = isdnloop_writecmd(cbuf, strlen(cbuf), 0,
card);
}
break;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 19/94] sparc64: don't treat 64-bit syscall return codes as 32-bit
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Dave Kleikamp [ Upstream commit 1535bd8adbdedd60a0ee62e28fd5225d66434371 ] When checking a system call return code for an error, linux_sparc_syscall was sign-extending the lower 32-bit value and comparing it to -ERESTART_RESTARTBLOCK. lseek can return valid return codes whose lower 32-bits alone would indicate a failure (such as 4G-1). Use the whole 64-bit value to check for errors. Only the 32-bit path should sign extend the lower 32-bit value. Signed-off-by: Dave Kleikamp Acked-by: Bob Picco Acked-by: Allen Pais Cc: David S. Miller Cc: sparcli...@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- arch/sparc/kernel/syscalls.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/sparc/kernel/syscalls.S b/arch/sparc/kernel/syscalls.S index 817187d..557212c 100644 --- a/arch/sparc/kernel/syscalls.S +++ b/arch/sparc/kernel/syscalls.S @@ -184,7 +184,8 @@ linux_sparc_syscall32: mov%i0, %l5! IEU1 5: call%l7 ! CTI Group brk forced srl%i5, 0, %o5 ! IEU1 - ba,a,pt %xcc, 3f + ba,pt %xcc, 3f +sra%o0, 0, %o0 /* Linux native system calls enter here... */ .align 32 @@ -212,7 +213,6 @@ linux_sparc_syscall: 3: stx %o0, [%sp + PTREGS_OFF + PT_V9_I0] ret_sys_call: ldx [%sp + PTREGS_OFF + PT_V9_TSTATE], %g3 - sra %o0, 0, %o0 mov %ulo(TSTATE_XCARRY | TSTATE_ICARRY), %g2 sllx%g2, 32, %g2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 15/94] rds: prevent dereference of a NULL device in rds_iw_laddr_check
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Sasha Levin
[ Upstream commit bf39b4247b8799935ea91d90db250ab608a58e50 ]
Binding might result in a NULL device which is later dereferenced
without checking.
Signed-off-by: Sasha Levin
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/rds/iw.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/rds/iw.c
+++ b/net/rds/iw.c
@@ -239,7 +239,8 @@ static int rds_iw_laddr_check(__be32 add
ret = rdma_bind_addr(cm_id, (struct sockaddr *)&sin);
/* due to this, we will claim to support IB devices unless we
check node_type. */
- if (ret || cm_id->device->node_type != RDMA_NODE_RNIC)
+ if (ret || !cm_id->device ||
+ cm_id->device->node_type != RDMA_NODE_RNIC)
ret = -EADDRNOTAVAIL;
rdsdebug("addr %pI4 ret %d node type %d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 03/94] net: unix: non blocking recvmsg() should not return -EINTR
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit de1443916791d75fdd26becb116898277bb0273f ]
Some applications didn't expect recvmsg() on a non blocking socket
could return -EINTR. This possibility was added as a side effect
of commit b3ca9b02b00704 ("net: fix multithreaded signal handling in
unix recv routines").
To hit this bug, you need to be a bit unlucky, as the u->readlock
mutex is usually held for very small periods.
Fixes: b3ca9b02b00704 ("net: fix multithreaded signal handling in unix recv
routines")
Signed-off-by: Eric Dumazet
Cc: Rainer Weikusat
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/unix/af_unix.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1771,8 +1771,11 @@ static int unix_dgram_recvmsg(struct kio
goto out;
err = mutex_lock_interruptible(&u->readlock);
- if (err) {
- err = sock_intr_errno(sock_rcvtimeo(sk, noblock));
+ if (unlikely(err)) {
+ /* recvmsg() in non blocking mode is supposed to return -EAGAIN
+* sk_rcvtimeo is not honored by mutex_lock_interruptible()
+*/
+ err = noblock ? -EAGAIN : -ERESTARTSYS;
goto out;
}
@@ -1887,6 +1890,7 @@ static int unix_stream_recvmsg(struct ki
struct unix_sock *u = unix_sk(sk);
struct sockaddr_un *sunaddr = msg->msg_name;
int copied = 0;
+ int noblock = flags & MSG_DONTWAIT;
int check_creds = 0;
int target;
int err = 0;
@@ -1901,7 +1905,7 @@ static int unix_stream_recvmsg(struct ki
goto out;
target = sock_rcvlowat(sk, flags&MSG_WAITALL, size);
- timeo = sock_rcvtimeo(sk, flags&MSG_DONTWAIT);
+ timeo = sock_rcvtimeo(sk, noblock);
/* Lock the socket to prevent queue disordering
* while sleeps in memcpy_tomsg
@@ -1913,8 +1917,11 @@ static int unix_stream_recvmsg(struct ki
}
err = mutex_lock_interruptible(&u->readlock);
- if (err) {
- err = sock_intr_errno(timeo);
+ if (unlikely(err)) {
+ /* recvmsg() in non blocking mode is supposed to return -EAGAIN
+* sk_rcvtimeo is not honored by mutex_lock_interruptible()
+*/
+ err = noblock ? -EAGAIN : -ERESTARTSYS;
goto out;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 42/94] jffs2: avoid soft-lockup in jffs2_reserve_space_gc()
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Li Zefan
commit 13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.
We triggered soft-lockup under stress test on 2.6.34 kernel.
BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
...
[] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
[] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
[] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
[] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
[] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
[] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
[] (jffs2_write_end+0x198/0x2c0 [jffs2])
[] (generic_file_buffered_write+0x158/0x200)
[] (__generic_file_aio_write+0x3a4/0x414)
[] (generic_file_aio_write+0x5c/0xbc)
[] (do_sync_write+0x98/0xd4)
[] (vfs_write+0xa8/0x150)
[] (sys_write+0x3c/0xc0)]
Fix this by adding a cond_resched() in the while loop.
[a...@linux-foundation.org: don't initialize `ret']
Signed-off-by: Li Zefan
Cc: David Woodhouse
Cc: Artem Bityutskiy
Signed-off-by: Andrew Morton
Signed-off-by: Brian Norris
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
fs/jffs2/nodemgmt.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/fs/jffs2/nodemgmt.c
+++ b/fs/jffs2/nodemgmt.c
@@ -159,19 +159,24 @@ int jffs2_reserve_space(struct jffs2_sb_
int jffs2_reserve_space_gc(struct jffs2_sb_info *c, uint32_t minsize,
uint32_t *len, uint32_t sumsize)
{
- int ret = -EAGAIN;
+ int ret;
minsize = PAD(minsize);
D1(printk(KERN_DEBUG "jffs2_reserve_space_gc(): Requested 0x%x
bytes\n", minsize));
- spin_lock(&c->erase_completion_lock);
- while(ret == -EAGAIN) {
+ while (true) {
+ spin_lock(&c->erase_completion_lock);
ret = jffs2_do_reserve_space(c, minsize, len, sumsize);
if (ret) {
D1(printk(KERN_DEBUG "jffs2_reserve_space_gc: looping,
ret is %d\n", ret));
}
+ spin_unlock(&c->erase_completion_lock);
+
+ if (ret == -EAGAIN)
+ cond_resched();
+ else
+ break;
}
- spin_unlock(&c->erase_completion_lock);
if (!ret)
ret = jffs2_prealloc_raw_node_refs(c, c->nextblock, 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 3.2 12/94] netlink: don't compare the nul-termination in nla_strcmp
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Pablo Neira
[ Upstream commit 8b7b932434f5eee495b91a2804f5b64ebb2bc835 ]
nla_strcmp compares the string length plus one, so it's implicitly
including the nul-termination in the comparison.
int nla_strcmp(const struct nlattr *nla, const char *str)
{
int len = strlen(str) + 1;
...
d = memcmp(nla_data(nla), str, len);
However, if NLA_STRING is used, userspace can send us a string without
the nul-termination. This is a problem since the string
comparison will not match as the last byte may be not the
nul-termination.
Fix this by skipping the comparison of the nul-termination if the
attribute data is nul-terminated. Suggested by Thomas Graf.
Cc: Florian Westphal
Cc: Thomas Graf
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
lib/nlattr.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/lib/nlattr.c
+++ b/lib/nlattr.c
@@ -299,9 +299,15 @@ int nla_memcmp(const struct nlattr *nla,
*/
int nla_strcmp(const struct nlattr *nla, const char *str)
{
- int len = strlen(str) + 1;
- int d = nla_len(nla) - len;
+ int len = strlen(str);
+ char *buf = nla_data(nla);
+ int attrlen = nla_len(nla);
+ int d;
+ if (attrlen > 0 && buf[attrlen - 1] == '\0')
+ attrlen--;
+
+ d = attrlen - len;
if (d == 0)
d = memcmp(nla_data(nla), str, len);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 13/94] isdnloop: Validate NUL-terminated strings from user.
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: YOSHIFUJI Hideaki / 吉藤英明
[ Upstream commit 77bc6bed7121936bb2e019a8c336075f4c8eef62 ]
Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.
Signed-off-by: YOSHIFUJI Hideaki
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/isdn/isdnloop/isdnloop.c | 6 ++
1 file changed, 6 insertions(+)
--- a/drivers/isdn/isdnloop/isdnloop.c
+++ b/drivers/isdn/isdnloop/isdnloop.c
@@ -1070,6 +1070,12 @@ isdnloop_start(isdnloop_card * card, isd
return -EBUSY;
if (copy_from_user((char *) &sdef, (char *) sdefp, sizeof(sdef)))
return -EFAULT;
+
+ for (i = 0; i < 3; i++) {
+ if (!memchr(sdef.num[i], 0, sizeof(sdef.num[i])))
+ return -EINVAL;
+ }
+
spin_lock_irqsave(&card->isdnloop_lock, flags);
switch (sdef.ptype) {
case ISDN_PTYPE_EURO:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 22/94] drm/i915: quirk invert brightness for Acer Aspire 5336
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Jani Nikula
commit 0f540c3a7cfb91c9d7a19eb0c95c24c5de1197d5 upstream.
Since
commit ee1452d7458451a7508e0663553ce88d63958157
Author: Jani Nikula
Date: Fri Sep 20 15:05:30 2013 +0300
drm/i915: assume all GM45 Acer laptops use inverted backlight PWM
failed and was later reverted in
commit be505f643925e257087247b996cd8ece787c12af
Author: Alexander van Heukelum
Date: Sat Dec 28 21:00:39 2013 +0100
Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"
fix the individual broken machine instead.
Note to backporters:
http://patchwork.freedesktop.org/patch/17837/
is the patch you want for 3.13 and older.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171
Reference: http://mid.gmane.org/dub115-w7628c7c710ea51aa110cd4a5...@phx.gbl
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
[danvet: Patch mangling for 3.14 plus adding the link to the original
for 3.13.]
Signed-off-by: Daniel Vetter
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8949,6 +8949,9 @@ struct intel_quirk intel_quirks[] = {
/* Acer Aspire 4736Z */
{ 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
+ /* Acer Aspire 5336 */
+ { 0x2a42, 0x1025, 0x048a, quirk_invert_brightness },
+
/* Dell XPS13 HD Sandy Bridge */
{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 41/94] jffs2: remove from wait queue after schedule()
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Li Zefan commit 3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream. @wait is a local variable, so if we don't remove it from the wait queue list, later wake_up() may end up accessing invalid memory. This was spotted by eyes. Signed-off-by: Li Zefan Cc: David Woodhouse Cc: Artem Bityutskiy Signed-off-by: Andrew Morton Signed-off-by: Brian Norris Signed-off-by: Ben Hutchings --- fs/jffs2/nodemgmt.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/jffs2/nodemgmt.c +++ b/fs/jffs2/nodemgmt.c @@ -128,6 +128,7 @@ int jffs2_reserve_space(struct jffs2_sb_ spin_unlock(&c->erase_completion_lock); schedule(); + remove_wait_queue(&c->erase_wait, &wait); } else spin_unlock(&c->erase_completion_lock); } else if (ret) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips
It should never be NULL because our interface list is up to date,
and even if it does, we'll just crash anyway so we are no better off.
Signed-off-by: Oleg Drokin
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 21d36ee..a391d13 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -793,8 +793,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
ip = peer->ksnp_passive_ips[i];
best_iface = ksocknal_ip2iface(peer->ksnp_ni, ip);
- /* peer passive ips are kept up to date */
- LASSERT(best_iface != NULL);
} else {
/* choose a new interface */
LASSERT (i == peer->ksnp_n_passive_ips);
@@ -835,8 +833,6 @@ ksocknal_select_ips(ksock_peer_t *peer, __u32 *peerips, int
n_peerips)
peer->ksnp_n_passive_ips = i+1;
}
- LASSERT (best_iface != NULL);
-
/* mark the best matching peer IP used */
j = ksocknal_match_peerip(best_iface, peerips, n_peerips);
peerips[j] = 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 3.2 46/94] virtio_balloon: don't softlockup on huge balloon changes.
3.2.58-rc1 review patch. If anyone has any objections, please let me know. -- From: Rusty Russell commit 1f74ef0f2d7d692fcd615621e0e734c3e7771413 upstream. When adding or removing 100G from a balloon: BUG: soft lockup - CPU#0 stuck for 22s! [vballoon:367] We have a wait_event_interruptible(), but the condition is always true (more ballooning to do) so we don't ever sleep. We also have a wait_event() for the host to ack, but that is also always true as QEMU is synchronous for balloon operations. Reported-by: Gopesh Kumar Chaudhary Signed-off-by: Rusty Russell Signed-off-by: Ben Hutchings --- drivers/virtio/virtio_balloon.c | 6 ++ 1 file changed, 6 insertions(+) --- a/drivers/virtio/virtio_balloon.c +++ b/drivers/virtio/virtio_balloon.c @@ -271,6 +271,12 @@ static int balloon(void *_vballoon) else if (diff < 0) leak_balloon(vb, -diff); update_balloon_size(vb); + + /* +* For large balloon changes, we could spend a lot of time +* and always have work to do. Be nice if preempt disabled. +*/ + cond_resched(); } return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.2 31/94] hvc: ensure hvc_init is only ever called once in hvc_console.c
3.2.58-rc1 review patch. If anyone has any objections, please let me know.
--
From: Paul Gortmaker
commit f76a1cbed18c86e2d192455f0daebb48458965f3 upstream.
Commit 3e6c6f630a5282df8f3393a59f10eb9c56536d23 ("Delay creation of
khcvd thread") moved the call of hvc_init from being a device_initcall
into hvc_alloc, and used a non-null hvc_driver as indication of whether
hvc_init had already been called.
The problem with this is that hvc_driver is only assigned a value
at the bottom of hvc_init, and so there is a window where multiple
hvc_alloc calls can be in progress at the same time and hence try
and call hvc_init multiple times. Previously the use of device_init
guaranteed that hvc_init was only called once.
This manifests itself as sporadic instances of two hvc_init calls
racing each other, and with the loser of the race getting -EBUSY
from tty_register_driver() and hence that virtual console fails:
Couldn't register hvc console driver
virtio-ports vport0p1: error -16 allocating hvc for port
Here we add an atomic_t to guarantee we'll never run hvc_init twice.
Cc: Rusty Russell
Cc: Greg Kroah-Hartman
Fixes: 3e6c6f630a52 ("Delay creation of khcvd thread")
Reported-by: Jim Somerville
Tested-by: Jim Somerville
Signed-off-by: Paul Gortmaker
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/tty/hvc/hvc_console.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -70,6 +71,9 @@ static struct task_struct *hvc_task;
/* Picks up late kicks after list walk but before schedule() */
static int hvc_kicked;
+/* hvc_init is triggered from hvc_alloc, i.e. only when actually used */
+static atomic_t hvc_needs_init __read_mostly = ATOMIC_INIT(-1);
+
static int hvc_init(void);
#ifdef CONFIG_MAGIC_SYSRQ
@@ -825,7 +829,7 @@ struct hvc_struct *hvc_alloc(uint32_t vt
int i;
/* We wait until a driver actually comes along */
- if (!hvc_driver) {
+ if (atomic_inc_not_zero(&hvc_needs_init)) {
int err = hvc_init();
if (err)
return ERR_PTR(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/
[PATCH v2 0/4] Lustre Klocwork fixes
This is just splitting big lnet fixes patch from Klocwork static analysis tool into smaller bits. Reworked according to previous comments. Dmitry Eremin (2): staging/lustre/lnet: remove unused variable in lnet_destroy_remote_nets_table staging/lustre/lnet: fix potential null pointer dereference in kiblnd_rejected Oleg Drokin (2): staging/lustre/lnet: Drop useless LASSERT in ksocknal_select_ips staging/lustre/lnet: fix potential null pointer dereference drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 8 ++-- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c| 4 drivers/staging/lustre/lnet/lnet/api-ni.c | 6 +++--- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 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 v2 4/4] staging/lustre/lnet: fix potential null pointer dereference
Pointer 'ni' checked for NULL at line 1569 may be passed to function and may be dereferenced there by passing argument 1 to function 'lnet_ni_notify_locked' at line 1621. found by Klocwork Insight tool Signed-off-by: Oleg Drokin CC: Dmitry Eremin CC: Liang Zhen --- drivers/staging/lustre/lnet/lnet/router.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/lnet/router.c b/drivers/staging/lustre/lnet/lnet/router.c index 995f509..926923a 100644 --- a/drivers/staging/lustre/lnet/lnet/router.c +++ b/drivers/staging/lustre/lnet/lnet/router.c @@ -145,7 +145,7 @@ lnet_ni_notify_locked(lnet_ni_t *ni, lnet_peer_t *lp) * NB individual events can be missed; the only guarantee is that you * always get the most recent news */ - if (lp->lp_notifying) + if (lp->lp_notifying || ni == NULL) return; lp->lp_notifying = 1; -- 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] perf tools: Remove extra '/' character in events file path
于 2014/4/28 8:14, Namhyung Kim 写道:
> Hi xiakaixu,
>
> (Adding Jiri and Boris to CC)
OK.
thanks,
>
>> The array debugfs_known_mountpoints[] will cause extra '/'
>> character output.
>> Remove it.
>>
>> pre:
>> $ perf probe -l
>> /sys/kernel/debug//tracing/uprobe_events file does not exist -
>> please rebuild kernel with CONFIG_UPROBE_EVENTS.
>>
>> post:
>> $ perf probe -l
>> /sys/kernel/debug/tracing/uprobe_events file does not exist -
>> please rebuild kernel with CONFIG_UPROBE_EVENTS.
>
> Looks like all of its callers already provide a '/' after the debugfs
> mountpoint, so
>
> Acked-by: Namhyung Kim
>
> Thanks,
> Namhyung
>
>>
>> Signed-off-by: Xia Kaixu
>> ---
>> tools/lib/api/fs/debugfs.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
>> index 7c43479..a74fba6 100644
>> --- a/tools/lib/api/fs/debugfs.c
>> +++ b/tools/lib/api/fs/debugfs.c
>> @@ -12,8 +12,8 @@
>> char debugfs_mountpoint[PATH_MAX + 1] = "/sys/kernel/debug";
>>
>> static const char * const debugfs_known_mountpoints[] = {
>> -"/sys/kernel/debug/",
>> -"/debug/",
>> +"/sys/kernel/debug",
>> +"/debug",
>> 0,
>> };
>>
>> -- 1.8.5.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/
