[no subject]
On Tue, Jun 25, 2013, Greg KH said: > On Tue, Jun 25, 2013 at 04:27:18PM +0530, navin patidar wrote: >> On Tue, Jun 25, 2013, Greg KH said: >> >> > On Fri, Jun 21, 2013 at 03:01:04PM +0530, navin patidar wrote: >> >> pr_warn() is preferred over pr_warning(). >> > >> > And dev_warn() is preferred over both of them, can you convert the code >> > to use that instead? >> > >> >> struct device is not available in usbip_start_eh() which is required >> for dev_warn(). >> >> usbip_device's containers struct stub_device and struct vhci_device >> both have member structure usb_device but inside usbip_start_eh(), it >> is difficult to determine to which container struct usbip_device >> belongs, thus container_of() can not be used here to get struct >> usb_device. > > Then the code should be reworked in order to be able to properly > determine that. How about adding a usb_device pointer in usbip_device structure ? regards, --navin-patidar -- 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/6 v5] powerpc: remove unnecessary line continuations
Signed-off-by: Bharat Bhushan --- arch/powerpc/kernel/process.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c index ceb4e7b..639a8de 100644 --- a/arch/powerpc/kernel/process.c +++ b/arch/powerpc/kernel/process.c @@ -325,7 +325,7 @@ static void set_debug_reg_defaults(struct thread_struct *thread) /* * Force User/Supervisor bits to b11 (user-only MSR[PR]=1) */ - thread->dbcr1 = DBCR1_IAC1US | DBCR1_IAC2US | \ + thread->dbcr1 = DBCR1_IAC1US | DBCR1_IAC2US | DBCR1_IAC3US | DBCR1_IAC4US; /* * Force Data Address Compare User/Supervisor bits to be User-only -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc/vfio: Add missing locks for take/release TCE table ownership
On Wed, 2013-06-26 at 15:39 +1000, Alexey Kardashevskiy wrote:
> VFIO IOMMU driver for sPAPR TCE locks the whole DMA window by setting
> ones to iommu_table.it_map. However this was not protected by the locks
> which other clients of iommu_table use.
>
> The patch fixes this.
>
> Signed-off-by: Alexey Kardashevskiy
> ---
> arch/powerpc/kernel/iommu.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index b20ff17..9f34742 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -1076,25 +1076,41 @@ EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
> int iommu_take_ownership(struct iommu_table *tbl)
> {
> unsigned long sz = (tbl->it_size + 7) >> 3;
> + int i, ret = 0;
> +
> + for (i = 0; i < tbl->nr_pools; i++)
> + spin_lock(>pools[i].lock);
> + spin_lock(>large_pool.lock);
IOMMUs can be used at interrupt time so the above will trigger lockdep
warnings unless you also bracket the whole function in
local_irq_save/restore.
Now you *shouldn't* be racing since afaik you only take the iommu
ownership after no more drivers are hooked up, but better safe than
sorry.
Cheers,
Ben.
> if (tbl->it_offset == 0)
> clear_bit(0, tbl->it_map);
>
> if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
> pr_err("iommu_tce: it_map is not empty");
> - return -EBUSY;
> + ret = -EBUSY;
> + goto unlock_exit;
> }
>
> memset(tbl->it_map, 0xff, sz);
> iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
>
> - return 0;
> +unlock_exit:
> + spin_unlock(>large_pool.lock);
> + for (i = 0; i < tbl->nr_pools; i++)
> + spin_unlock(>pools[i].lock);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(iommu_take_ownership);
>
> void iommu_release_ownership(struct iommu_table *tbl)
> {
> unsigned long sz = (tbl->it_size + 7) >> 3;
> + int i;
> +
> + for (i = 0; i < tbl->nr_pools; i++)
> + spin_lock(>pools[i].lock);
> + spin_lock(>large_pool.lock);
>
> iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
> memset(tbl->it_map, 0, sz);
> @@ -1102,6 +1118,11 @@ void iommu_release_ownership(struct iommu_table *tbl)
> /* Restore bit#0 set by iommu_init_table() */
> if (tbl->it_offset == 0)
> set_bit(0, tbl->it_map);
> +
> + spin_unlock(>large_pool.lock);
> + for (i = 0; i < tbl->nr_pools; i++)
> + spin_unlock(>pools[i].lock);
> +
> }
> EXPORT_SYMBOL_GPL(iommu_release_ownership);
>
--
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: frequent softlockups with 3.10rc6.
On Tue, Jun 25, 2013 at 12:23:34PM -0400, Steven Rostedt wrote: > On Tue, 2013-06-25 at 11:35 -0400, Dave Jones wrote: > > Took a lot longer to trigger this time. (13 hours of runtime). > > > > This trace may still not be from the first lockup, as a flood of > > them happened at the same time. > > > > > > # tracer: preemptirqsoff > > # > > # preemptirqsoff latency trace v1.1.5 on 3.10.0-rc7+ > > # > > # latency: 389877255 us, #4/4, CPU#1 | (M:preempt VP:0, KP:0, SP:0 HP:0 > > #P:4) > > #- > > #| task: trinity-main-9252 (uid:1000 nice:19 policy:0 rt_prio:0) > > #- > > # => started at: vprintk_emit > > # => ended at: vprintk_emit > > # > > # > > # _--=> CPU# > > # / _-=> irqs-off > > #| / _=> need-resched > > #|| / _---=> hardirq/softirq > > #||| / _--=> preempt-depth > > # / delay > > # cmd pid | time | caller > > # \ / | \| / > > trinity--92521dNh10us!: console_unlock <-vprintk_emit > > trinity--92521dNh1 389877255us : console_unlock <-vprintk_emit > > trinity--92521dNh1 389877255us+: stop_critical_timings <-vprintk_emit > > trinity--92521dNh1 389877261us : > > => console_unlock > > => vprintk_emit > > => printk > > This is the same as the last one, with no new info to why it started the > tracing at console_unlock :-/ > > Now, what we can try to do as well, is to add a trigger to disable > tracing, which should (I need to check the code) stop tracing on printk. > To do so: > > # echo printk:traceoff > /sys/kernel/debug/tracing/set_ftrace_filter > > This will add a trigger to the printk function that when called, will > disable tracing. If it is hit before you get your trace, you can just > re-enable tracing with: > > # echo 1 > /sys/kernel/debug/tracing/tracing_on > > Hmm, no it needs a fix to make this work. I applied a patch below that > should do this correctly (and will put this into my 3.11 queue). > > If you run the test again with this change and with the above filter, it > should stop the trace before overwriting the first dump, as it should > ignore the printk output. More puzzling. Rebooted the machine, restarted the test, and hit it pretty quickly.. Though different backtrace this time.. [ 1583.293902] BUG: soft lockup - CPU#1 stuck for 22s! [migration/1:28] [ 1583.293905] BUG: soft lockup - CPU#0 stuck for 22s! [migration/0:7] [ 1583.293932] Modules linked in: tun hidp bnep nfnetlink rfcomm scsi_transport_iscsi ipt_ULOG can_raw af_rxrpc netrom nfc can_bcm can appletalk ipx p8023 af_key psnap irda p8022 rose caif_socket caif ax25 crc_ccitt llc2 af_802154 llc rds bluetooth phonet rfkill pppoe pppox atm ppp_generic slhc x25 coretemp hwmon kvm_intel kvm snd_hda_codec_realtek crc32c_intel snd_hda_codec_hdmi ghash_clmulni_intel microcode snd_hda_intel pcspkr snd_hda_codec snd_hwdep snd_seq snd_seq_device e1000e snd_pcm ptp pps_core snd_page_alloc snd_timer snd soundcore xfs libcrc32c [ 1583.293932] irq event stamp: 108950 [ 1583.293937] hardirqs last enabled at (108949): [] restore_args+0x0/0x30 [ 1583.293940] hardirqs last disabled at (108950): [] apic_timer_interrupt+0x6a/0x80 [ 1583.293943] softirqs last enabled at (108948): [] __do_softirq+0x194/0x440 [ 1583.293945] softirqs last disabled at (108943): [] irq_exit+0xcd/0xe0 [ 1583.293947] CPU: 0 PID: 7 Comm: migration/0 Not tainted 3.10.0-rc7+ #5 [ 1583.293948] task: 88024419 ti: 88024418a000 task.ti: 88024418a000 [ 1583.293952] RIP: 0010:[] [] stop_machine_cpu_stop+0x86/0x110 [ 1583.293953] RSP: 0018:88024418bce8 EFLAGS: 0293 [ 1583.293953] RAX: 0001 RBX: 816e9320 RCX: [ 1583.293954] RDX: 88024418bf00 RSI: 81084b2c RDI: 8801ecd51b88 [ 1583.293954] RBP: 88024418bd10 R08: 0001 R09: [ 1583.293955] R10: 0001 R11: R12: 88024418bc58 [ 1583.293956] R13: 88024418bfd8 R14: 88024418a000 R15: 0046 [ 1583.293956] FS: () GS:88024560() knlGS: [ 1583.293957] CS: 0010 DS: ES: CR0: 80050033 [ 1583.293958] CR2: 06ff0158 CR3: 0001ea0df000 CR4: 001407f0 [ 1583.293958] DR0: DR1: DR2: [ 1583.293959] DR3: DR6: fffe0ff0 DR7: 0400 [ 1583.293959] Stack: [ 1583.293961] 8802457cd880 8801ecd51ac0 8801ecd51b88 810dd7d0 [ 1583.293963] 88024418bfd8 88024418bde0 810dd6ed 88024418bfd8 [ 1583.293965] 8802457cd8d0 017f 88024418bd48 0007810b463e
[PATCH] powerpc/vfio: Add missing locks for take/release TCE table ownership
VFIO IOMMU driver for sPAPR TCE locks the whole DMA window by setting
ones to iommu_table.it_map. However this was not protected by the locks
which other clients of iommu_table use.
The patch fixes this.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/iommu.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index b20ff17..9f34742 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1076,25 +1076,41 @@ EXPORT_SYMBOL_GPL(iommu_put_tce_user_mode);
int iommu_take_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl->it_size + 7) >> 3;
+ int i, ret = 0;
+
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(>pools[i].lock);
+ spin_lock(>large_pool.lock);
if (tbl->it_offset == 0)
clear_bit(0, tbl->it_map);
if (!bitmap_empty(tbl->it_map, tbl->it_size)) {
pr_err("iommu_tce: it_map is not empty");
- return -EBUSY;
+ ret = -EBUSY;
+ goto unlock_exit;
}
memset(tbl->it_map, 0xff, sz);
iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
- return 0;
+unlock_exit:
+ spin_unlock(>large_pool.lock);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(>pools[i].lock);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(iommu_take_ownership);
void iommu_release_ownership(struct iommu_table *tbl)
{
unsigned long sz = (tbl->it_size + 7) >> 3;
+ int i;
+
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_lock(>pools[i].lock);
+ spin_lock(>large_pool.lock);
iommu_clear_tces_and_put_pages(tbl, tbl->it_offset, tbl->it_size);
memset(tbl->it_map, 0, sz);
@@ -1102,6 +1118,11 @@ void iommu_release_ownership(struct iommu_table *tbl)
/* Restore bit#0 set by iommu_init_table() */
if (tbl->it_offset == 0)
set_bit(0, tbl->it_map);
+
+ spin_unlock(>large_pool.lock);
+ for (i = 0; i < tbl->nr_pools; i++)
+ spin_unlock(>pools[i].lock);
+
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] pinctrl: vt8500: wmt: remove redundant dev_err call in wmt_pinctrl_probe()
On 26/06/13 13:56, Wei Yongjun wrote:
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/pinctrl/vt8500/pinctrl-wmt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c
b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index fb30edf3..0cc4335 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -570,10 +570,8 @@ int wmt_pinctrl_probe(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(data->base)) {
- dev_err(>dev, "failed to map memory resource\n");
+ if (IS_ERR(data->base))
return PTR_ERR(data->base);
- }
wmt_desc.pins = data->pins;
wmt_desc.npins = data->npins;
Acked-by: Tony Prisk
Regards
Tony P
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] minnowboard: Add base platform driver for the MinnowBoard
On Tue, 2013-06-25 at 22:32 -0700, Darren Hart wrote: > are all board-specific. They map GPIO to their fixed functions and > provide an API for board-specific queries (minnowboard.c), they provide > example uses (minnowboard-gpio and minnowboard-keys) which aid in > experimentation and the development of new drivers. > > Which of these make sense as ACPI devices in your opinion? Does the firmware contain a corresponding ACPI device with a specific _HID that defines the programming model? If so, it should have an ACPI driver. If not, it shouldn't. -- Matthew Garrett | mj...@srcf.ucam.org
[PATCH 5/6 v5] KVM: PPC: Using "struct debug_reg"
For KVM also use the "struct debug_reg" defined in asm/processor.h
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/kvm_host.h | 13 +
arch/powerpc/kvm/booke.c| 34 --
2 files changed, 25 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index af326cd..838a577 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -381,17 +381,6 @@ struct kvmppc_slb {
#define KVMPPC_EPR_USER1 /* exit to userspace to fill EPR */
#define KVMPPC_EPR_KERNEL 2 /* in-kernel irqchip */
-struct kvmppc_booke_debug_reg {
- u32 dbcr0;
- u32 dbcr1;
- u32 dbcr2;
-#ifdef CONFIG_KVM_E500MC
- u32 dbcr4;
-#endif
- u64 iac[KVMPPC_BOOKE_MAX_IAC];
- u64 dac[KVMPPC_BOOKE_MAX_DAC];
-};
-
#define KVMPPC_IRQ_DEFAULT 0
#define KVMPPC_IRQ_MPIC1
#define KVMPPC_IRQ_XICS2
@@ -535,7 +524,7 @@ struct kvm_vcpu_arch {
u32 eptcfg;
u32 epr;
u32 crit_save;
- struct kvmppc_booke_debug_reg dbg_reg;
+ struct debug_reg dbg_reg;
#endif
gpa_t paddr_accessed;
gva_t vaddr_accessed;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 62d4ece..3e9fc1d 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1424,7 +1424,6 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
int r = 0;
union kvmppc_one_reg val;
int size;
- long int i;
size = one_reg_size(reg->id);
if (size > sizeof(val))
@@ -1432,16 +1431,24 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
switch (reg->id) {
case KVM_REG_PPC_IAC1:
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.iac1);
+ break;
case KVM_REG_PPC_IAC2:
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.iac2);
+ break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
case KVM_REG_PPC_IAC3:
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.iac3);
+ break;
case KVM_REG_PPC_IAC4:
- i = reg->id - KVM_REG_PPC_IAC1;
- val = get_reg_val(reg->id, vcpu->arch.dbg_reg.iac[i]);
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.iac4);
break;
+#endif
case KVM_REG_PPC_DAC1:
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.dac1);
+ break;
case KVM_REG_PPC_DAC2:
- i = reg->id - KVM_REG_PPC_DAC1;
- val = get_reg_val(reg->id, vcpu->arch.dbg_reg.dac[i]);
+ val = get_reg_val(reg->id, vcpu->arch.dbg_reg.dac2);
break;
case KVM_REG_PPC_EPR: {
u32 epr = get_guest_epr(vcpu);
@@ -1481,7 +1488,6 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
int r = 0;
union kvmppc_one_reg val;
int size;
- long int i;
size = one_reg_size(reg->id);
if (size > sizeof(val))
@@ -1492,16 +1498,24 @@ int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
struct kvm_one_reg *reg)
switch (reg->id) {
case KVM_REG_PPC_IAC1:
+ vcpu->arch.dbg_reg.iac1 = set_reg_val(reg->id, val);
+ break;
case KVM_REG_PPC_IAC2:
+ vcpu->arch.dbg_reg.iac2 = set_reg_val(reg->id, val);
+ break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
case KVM_REG_PPC_IAC3:
+ vcpu->arch.dbg_reg.iac3 = set_reg_val(reg->id, val);
+ break;
case KVM_REG_PPC_IAC4:
- i = reg->id - KVM_REG_PPC_IAC1;
- vcpu->arch.dbg_reg.iac[i] = set_reg_val(reg->id, val);
+ vcpu->arch.dbg_reg.iac4 = set_reg_val(reg->id, val);
break;
+#endif
case KVM_REG_PPC_DAC1:
+ vcpu->arch.dbg_reg.dac1 = set_reg_val(reg->id, val);
+ break;
case KVM_REG_PPC_DAC2:
- i = reg->id - KVM_REG_PPC_DAC1;
- vcpu->arch.dbg_reg.dac[i] = set_reg_val(reg->id, val);
+ vcpu->arch.dbg_reg.dac2 = set_reg_val(reg->id, val);
break;
case KVM_REG_PPC_EPR: {
u32 new_epr = set_reg_val(reg->id, val);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6 v5] KVM: PPC: exit to user space on "ehpriv" instruction
"ehpriv" instruction is used for setting software breakpoints
by user space. This patch adds support to exit to user space
with "run->debug" have relevant information.
As this is the first point we are using run->debug, also defined
the run->debug structure.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/disassemble.h |4
arch/powerpc/include/uapi/asm/kvm.h| 21 +
arch/powerpc/kvm/e500_emulate.c| 27 +++
3 files changed, 48 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/disassemble.h
b/arch/powerpc/include/asm/disassemble.h
index 9b198d1..856f8de 100644
--- a/arch/powerpc/include/asm/disassemble.h
+++ b/arch/powerpc/include/asm/disassemble.h
@@ -77,4 +77,8 @@ static inline unsigned int get_d(u32 inst)
return inst & 0x;
}
+static inline unsigned int get_oc(u32 inst)
+{
+ return (inst >> 11) & 0x7fff;
+}
#endif /* __ASM_PPC_DISASSEMBLE_H__ */
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index 0fb1a6e..ded0607 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -269,7 +269,24 @@ struct kvm_fpu {
__u64 fpr[32];
};
+/*
+ * Defines for h/w breakpoint, watchpoint (read, write or both) and
+ * software breakpoint.
+ * These are used as "type" in KVM_SET_GUEST_DEBUG ioctl and "status"
+ * for KVM_DEBUG_EXIT.
+ */
+#define KVMPPC_DEBUG_NONE 0x0
+#define KVMPPC_DEBUG_BREAKPOINT(1UL << 1)
+#define KVMPPC_DEBUG_WATCH_WRITE (1UL << 2)
+#define KVMPPC_DEBUG_WATCH_READ(1UL << 3)
struct kvm_debug_exit_arch {
+ __u64 address;
+ /*
+* exiting to userspace because of h/w breakpoint, watchpoint
+* (read, write or both) and software breakpoint.
+*/
+ __u32 status;
+ __u32 reserved;
};
/* for KVM_SET_GUEST_DEBUG */
@@ -281,10 +298,6 @@ struct kvm_guest_debug_arch {
* Type denotes h/w breakpoint, read watchpoint, write
* watchpoint or watchpoint (both read and write).
*/
-#define KVMPPC_DEBUG_NONE 0x0
-#define KVMPPC_DEBUG_BREAKPOINT(1UL << 1)
-#define KVMPPC_DEBUG_WATCH_WRITE (1UL << 2)
-#define KVMPPC_DEBUG_WATCH_READ(1UL << 3)
__u32 type;
__u32 reserved;
} bp[16];
diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
index b10a012..dab9d07 100644
--- a/arch/powerpc/kvm/e500_emulate.c
+++ b/arch/powerpc/kvm/e500_emulate.c
@@ -26,6 +26,8 @@
#define XOP_TLBRE 946
#define XOP_TLBWE 978
#define XOP_TLBILX 18
+#define XOP_EHPRIV 270
+#define EHPRIV_OC_DEBUG 0
#ifdef CONFIG_KVM_E500MC
static int dbell2prio(ulong param)
@@ -82,6 +84,26 @@ static int kvmppc_e500_emul_msgsnd(struct kvm_vcpu *vcpu,
int rb)
}
#endif
+static int kvmppc_e500_emul_ehpriv(struct kvm_run *run, struct kvm_vcpu *vcpu,
+ unsigned int inst, int *advance)
+{
+ int emulated = EMULATE_DONE;
+
+ switch (get_oc(inst)) {
+ case EHPRIV_OC_DEBUG:
+ run->exit_reason = KVM_EXIT_DEBUG;
+ run->debug.arch.address = vcpu->arch.pc;
+ run->debug.arch.status = 0;
+ kvmppc_account_exit(vcpu, DEBUG_EXITS);
+ emulated = EMULATE_EXIT_USER;
+ *advance = 0;
+ break;
+ default:
+ emulated = EMULATE_FAIL;
+ }
+ return emulated;
+}
+
int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
unsigned int inst, int *advance)
{
@@ -130,6 +152,11 @@ int kvmppc_core_emulate_op(struct kvm_run *run, struct
kvm_vcpu *vcpu,
emulated = kvmppc_e500_emul_tlbivax(vcpu, ea);
break;
+ case XOP_EHPRIV:
+ emulated = kvmppc_e500_emul_ehpriv(run, vcpu, inst,
+ advance);
+ break;
+
default:
emulated = EMULATE_FAIL;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6 v5] KVM: PPC: Add userspace debug stub support
This patch adds the debug stub support on booke/bookehv.
Now QEMU debug stub can use hw breakpoint, watchpoint and
software breakpoint to debug guest.
This is how we save/restore debug register context when switching
between guest, userspace and kernel user-process:
When QEMU is running
-> thread->debug_reg == QEMU debug register context.
-> Kernel will handle switching the debug register on context switch.
-> no vcpu_load() called
QEMU makes ioctls (except RUN)
-> This will call vcpu_load()
-> should not change context.
-> Some ioctls can change vcpu debug register, context saved in
vcpu->debug_regs
QEMU Makes RUN ioctl
-> Save thread->debug_reg on STACK
-> Store thread->debug_reg == vcpu->debug_reg
-> load thread->debug_reg
-> RUN VCPU ( So thread points to vcpu context )
Context switch happens When VCPU running
-> makes vcpu_load() should not load any context
-> kernel loads the vcpu context as thread->debug_regs points to vcpu context.
On heavyweight_exit
-> Load the context saved on stack in thread->debug_reg
Currently we do not support debug resource emulation to guest,
On debug exception, always exit to user space irrespective of
user space is expecting the debug exception or not. If this is
unexpected exception (breakpoint/watchpoint event not set by
userspace) then let us leave the action on user space. This
is similar to what it was before, only thing is that now we
have proper exit state available to user space.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/kvm_host.h |3 +
arch/powerpc/include/uapi/asm/kvm.h |1 +
arch/powerpc/kvm/booke.c| 239 ---
arch/powerpc/kvm/booke.h|5 +
4 files changed, 230 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 838a577..aeb490d 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -524,7 +524,10 @@ struct kvm_vcpu_arch {
u32 eptcfg;
u32 epr;
u32 crit_save;
+ /* guest debug registers*/
struct debug_reg dbg_reg;
+ /* hardware visible debug registers when in guest state */
+ struct debug_reg shadow_dbg_reg;
#endif
gpa_t paddr_accessed;
gva_t vaddr_accessed;
diff --git a/arch/powerpc/include/uapi/asm/kvm.h
b/arch/powerpc/include/uapi/asm/kvm.h
index ded0607..f5077c2 100644
--- a/arch/powerpc/include/uapi/asm/kvm.h
+++ b/arch/powerpc/include/uapi/asm/kvm.h
@@ -27,6 +27,7 @@
#define __KVM_HAVE_PPC_SMT
#define __KVM_HAVE_IRQCHIP
#define __KVM_HAVE_IRQ_LINE
+#define __KVM_HAVE_GUEST_DEBUG
struct kvm_regs {
__u64 pc;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 3e9fc1d..8cd8d41 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -133,6 +133,29 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
#endif
}
+static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
+{
+ /* Synchronize guest's desire to get debug interrupts into shadow MSR */
+#ifndef CONFIG_KVM_BOOKE_HV
+ vcpu->arch.shadow_msr &= ~MSR_DE;
+ vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;
+#endif
+
+ /* Force enable debug interrupts when user space wants to debug */
+ if (vcpu->guest_debug) {
+#ifdef CONFIG_KVM_BOOKE_HV
+ /*
+* Since there is no shadow MSR, sync MSR_DE into the guest
+* visible MSR.
+*/
+ vcpu->arch.shared->msr |= MSR_DE;
+#else
+ vcpu->arch.shadow_msr |= MSR_DE;
+ vcpu->arch.shared->msr &= ~MSR_DE;
+#endif
+ }
+}
+
/*
* Helper function for "full" MSR writes. No need to call this if only
* EE/CE/ME/DE/RI are changing.
@@ -150,6 +173,7 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u32 new_msr)
kvmppc_mmu_msr_notify(vcpu, old_msr);
kvmppc_vcpu_sync_spe(vcpu);
kvmppc_vcpu_sync_fpu(vcpu);
+ kvmppc_vcpu_sync_debug(vcpu);
}
static void kvmppc_booke_queue_irqprio(struct kvm_vcpu *vcpu,
@@ -655,6 +679,7 @@ int kvmppc_core_check_requests(struct kvm_vcpu *vcpu)
int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
{
int ret, s;
+ struct thread_struct thread;
#ifdef CONFIG_PPC_FPU
unsigned int fpscr;
int fpexc_mode;
@@ -698,12 +723,21 @@ int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct
kvm_vcpu *vcpu)
kvmppc_load_guest_fp(vcpu);
#endif
+ /* Switch to guest debug context */
+ thread.debug = vcpu->arch.shadow_dbg_reg;
+ switch_booke_debug_regs();
+ thread.debug = current->thread.debug;
+ current->thread.debug = vcpu->arch.shadow_dbg_reg;
ret = __kvmppc_vcpu_run(kvm_run, vcpu);
/* No need for kvm_guest_exit. It's done in handle_exit.
We also get here with interrupts enabled. */
+ /* Switch back to user space debug context */
+
[PATCH 3/6 v5] powerpc: export debug registers save function for KVM
KVM need this function when switching from vcpu to user-space
thread. My subsequent patch will use this function.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/switch_to.h |4
arch/powerpc/kernel/process.c|3 ++-
2 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
index 200d763..50b357f 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -30,6 +30,10 @@ extern void enable_kernel_spe(void);
extern void giveup_spe(struct task_struct *);
extern void load_up_spe(struct task_struct *);
+#ifdef CONFIG_PPC_ADV_DEBUG_REGS
+extern void switch_booke_debug_regs(struct thread_struct *new_thread);
+#endif
+
#ifndef CONFIG_SMP
extern void discard_lazy_cpu_state(void);
#else
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 01ff496..da586aa 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -362,12 +362,13 @@ static void prime_debug_regs(struct thread_struct *thread)
* debug registers, set the debug registers from the values
* stored in the new thread.
*/
-static void switch_booke_debug_regs(struct thread_struct *new_thread)
+void switch_booke_debug_regs(struct thread_struct *new_thread)
{
if ((current->thread.debug.dbcr0 & DBCR0_IDM)
|| (new_thread->debug.dbcr0 & DBCR0_IDM))
prime_debug_regs(new_thread);
}
+EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
#ifndef CONFIG_HAVE_HW_BREAKPOINT
static void set_debug_reg_defaults(struct thread_struct *thread)
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6 v5] KVM :PPC: Userspace Debug support
From: Bharat Bhushan Note: These patches are based on http://github.com/agraf/linux-2.6.git queue This patchset adds the userspace debug support for booke/bookehv. this is tested on powerpc e500v2/e500mc devices. We are now assuming that debug resource will not be used by kernel for its own debugging. It will be used for only kernel user process debugging. So the kernel debug load interface during context_to is used to load debug conext for that selected process. v4->v5 - Some comments reworded and other cleanup (like change of function name etc) - Added a function for setting MSRP rather than inline v3->v4 - 4 out of 7 patches of initial patchset were applied. This patchset is on and above those 4 patches - KVM local "struct kvmppc_booke_debug_reg" is replaced by powerpc global "struct debug_reg" - use switch_booke_debug_regs() for debug register context switch. - Save DBSR before kernel pre-emption is enabled. - Some more cleanup v2->v3 - We are now assuming that debug resource will not be used by kernel for its own debugging. It will be used for only kernel user process debugging. So the kernel debug load interface during context_to is used to load debug conext for that selected process. v1->v2 - Debug registers are save/restore in vcpu_put/vcpu_get. Earlier the debug registers are saved/restored in guest entry/exit Bharat Bhushan (6): powerpc: remove unnecessary line continuations powerpc: move debug registers in a structure powerpc: export debug registers save function for KVM KVM: PPC: exit to user space on "ehpriv" instruction KVM: PPC: Using "struct debug_reg" KVM: PPC: Add userspace debug stub support arch/powerpc/include/asm/disassemble.h |4 + arch/powerpc/include/asm/kvm_host.h| 16 +-- arch/powerpc/include/asm/processor.h | 38 +++-- arch/powerpc/include/asm/reg_booke.h |8 +- arch/powerpc/include/asm/switch_to.h |4 + arch/powerpc/include/uapi/asm/kvm.h| 22 ++- arch/powerpc/kernel/asm-offsets.c |2 +- arch/powerpc/kernel/process.c | 45 +++--- arch/powerpc/kernel/ptrace.c | 154 +- arch/powerpc/kernel/signal_32.c|6 +- arch/powerpc/kernel/traps.c| 35 ++-- arch/powerpc/kvm/booke.c | 273 arch/powerpc/kvm/booke.h |5 + arch/powerpc/kvm/e500_emulate.c| 27 +++ 14 files changed, 455 insertions(+), 184 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/
[PATCH 2/6 v5] powerpc: move debug registers in a structure
This way we can use same data type struct with KVM and
also help in using other debug related function.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/processor.h | 38 +
arch/powerpc/include/asm/reg_booke.h |8 +-
arch/powerpc/kernel/asm-offsets.c|2 +-
arch/powerpc/kernel/process.c| 42 +-
arch/powerpc/kernel/ptrace.c | 154 +-
arch/powerpc/kernel/signal_32.c |6 +-
arch/powerpc/kernel/traps.c | 35
7 files changed, 146 insertions(+), 139 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index d7e67ca..5b8a7f1 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -147,22 +147,7 @@ typedef struct {
#define TS_FPR(i) fpr[i][TS_FPROFFSET]
#define TS_TRANS_FPR(i) transact_fpr[i][TS_FPROFFSET]
-struct thread_struct {
- unsigned long ksp;/* Kernel stack pointer */
- unsigned long ksp_limit; /* if ksp <= ksp_limit stack overflow */
-
-#ifdef CONFIG_PPC64
- unsigned long ksp_vsid;
-#endif
- struct pt_regs *regs; /* Pointer to saved register state */
- mm_segment_tfs; /* for get_fs() validation */
-#ifdef CONFIG_BOOKE
- /* BookE base exception scratch space; align on cacheline */
- unsigned long normsave[8] cacheline_aligned;
-#endif
-#ifdef CONFIG_PPC32
- void*pgdir; /* root of page-table tree */
-#endif
+struct debug_reg {
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
/*
* The following help to manage the use of Debug Control Registers
@@ -199,6 +184,27 @@ struct thread_struct {
unsigned long dvc2;
#endif
#endif
+};
+
+struct thread_struct {
+ unsigned long ksp;/* Kernel stack pointer */
+ unsigned long ksp_limit; /* if ksp <= ksp_limit stack overflow */
+
+#ifdef CONFIG_PPC64
+ unsigned long ksp_vsid;
+#endif
+ struct pt_regs *regs; /* Pointer to saved register state */
+ mm_segment_tfs; /* for get_fs() validation */
+#ifdef CONFIG_BOOKE
+ /* BookE base exception scratch space; align on cacheline */
+ unsigned long normsave[8] cacheline_aligned;
+#endif
+#ifdef CONFIG_PPC32
+ void*pgdir; /* root of page-table tree */
+#endif
+ /* Debug Registers */
+ struct debug_reg debug;
+
/* FP and VSX 0-31 register set */
double fpr[32][TS_FPRWIDTH];
struct {
diff --git a/arch/powerpc/include/asm/reg_booke.h
b/arch/powerpc/include/asm/reg_booke.h
index b417de3..455dc89 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -381,7 +381,7 @@
#define DBCR0_IA34T0x4000 /* Instr Addr 3-4 range Toggle */
#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */
-#define dbcr_iac_range(task) ((task)->thread.dbcr0)
+#define dbcr_iac_range(task) ((task)->thread.debug.dbcr0)
#define DBCR_IAC12IDBCR0_IA12 /* Range Inclusive */
#define DBCR_IAC12X(DBCR0_IA12 | DBCR0_IA12X) /* Range Exclusive */
#define DBCR_IAC12MODE (DBCR0_IA12 | DBCR0_IA12X) /* IAC 1-2 Mode Bits */
@@ -395,7 +395,7 @@
#define DBCR1_DAC1W0x2000 /* DAC1 Write Debug Event */
#define DBCR1_DAC2W0x1000 /* DAC2 Write Debug Event */
-#define dbcr_dac(task) ((task)->thread.dbcr1)
+#define dbcr_dac(task) ((task)->thread.debug.dbcr1)
#define DBCR_DAC1R DBCR1_DAC1R
#define DBCR_DAC1W DBCR1_DAC1W
#define DBCR_DAC2R DBCR1_DAC2R
@@ -441,7 +441,7 @@
#define DBCR0_CRET 0x0020 /* Critical Return Debug Event */
#define DBCR0_FT 0x0001 /* Freeze Timers on debug event */
-#define dbcr_dac(task) ((task)->thread.dbcr0)
+#define dbcr_dac(task) ((task)->thread.debug.dbcr0)
#define DBCR_DAC1R DBCR0_DAC1R
#define DBCR_DAC1W DBCR0_DAC1W
#define DBCR_DAC2R DBCR0_DAC2R
@@ -475,7 +475,7 @@
#define DBCR1_IAC34MX 0x00C0 /* Instr Addr 3-4 range eXclusive */
#define DBCR1_IAC34AT 0x0001 /* Instr Addr 3-4 range Toggle */
-#define dbcr_iac_range(task) ((task)->thread.dbcr1)
+#define dbcr_iac_range(task) ((task)->thread.debug.dbcr1)
#define DBCR_IAC12IDBCR1_IAC12M/* Range Inclusive */
#define DBCR_IAC12XDBCR1_IAC12MX /* Range Exclusive */
#define DBCR_IAC12MODE DBCR1_IAC12MX /* IAC 1-2 Mode Bits */
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index b51a97c..c241c60 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -106,7 +106,7 @@ int main(void)
#else /* CONFIG_PPC64 */
DEFINE(PGDIR, offsetof(struct thread_struct, pgdir));
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
- DEFINE(THREAD_DBCR0, offsetof(struct thread_struct,
[PATCH] arch: arm64: include: asm: add pci.h to pass compiling
Need add pci.h for compiling, the related error (with allmodconfig): drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_exit’: drivers/media/usb/b2c2/flexcop-usb.c:393:3: error: implicit declaration of function ‘pci_free_consistent’ [-Werror=implicit-function-declaration] drivers/media/usb/b2c2/flexcop-usb.c: In function ‘flexcop_usb_transfer_init’: drivers/media/usb/b2c2/flexcop-usb.c:410:2: error: implicit declaration of function ‘pci_alloc_consistent’ [-Werror=implicit-function-declaration] drivers/media/usb/b2c2/flexcop-usb.c:410:21: warning: assignment makes pointer from integer without a cast [enabled by default] cc1: some warnings being treated as errors Signed-off-by: Chen Gang --- arch/arm64/include/asm/pci.h | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) create mode 100644 arch/arm64/include/asm/pci.h diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h new file mode 100644 index 000..2ed467f --- /dev/null +++ b/arch/arm64/include/asm/pci.h @@ -0,0 +1,11 @@ +#ifndef ASMARM64_PCI_H +#define ASMARM64_PCI_H + +#ifdef __KERNEL__ + +#include +#include + +#endif /* __KERNEL__ */ + +#endif -- 1.7.7.6 -- 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] arch: asm-generic: for atomic_set_mask() 1st param, use 'unsigned int' instead of 'unsigned long'
Hello Maintainers: Firstly thank the s390 maintainers again for their 'Acked-by' (in my memory, s390 is the most important business mainframe machine) Could another related maintainers give a glance for it, when you have time. Thanks. On 06/13/2013 09:19 AM, Chen Gang wrote: > On 06/10/2013 05:21 PM, Heiko Carstens wrote: >> On Sun, Jun 09, 2013 at 02:31:42PM +0800, Chen Gang wrote: atomic_set_mask() and atomic_clear_mask() are the pairs, so the related parameters' type need match with each other. The type of 'addr->counter' is 'int', so use 'unsigned int' instead of 'unsigned long', and let atomic_set_mask() match atomic_clear_mask(). For arch sub-system, currently, have 3 types of definition for them: 1st for 'int', 2nd for 'long', 3rd is conflict to use 'int' and 'long'. At least, better to fix 3rd (conflict using 'int' and 'long'). Signed-off-by: Chen Gang --- arch/blackfin/include/asm/atomic.h |4 ++-- arch/m32r/include/asm/atomic.h |8 arch/s390/include/asm/atomic.h |4 ++-- include/asm-generic/atomic.h |2 +- 4 files changed, 9 insertions(+), 9 deletions(-) >> For the s390 part: >> >> Acked-by: Heiko Carstens >> > > Thank you very much !! > > -- Chen Gang Asianux Corporation -- 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 2/4] SUNRPC: fix races on PipeFS UMOUNT notifications
25.06.2013 20:13, Myklebust, Trond пишет:
On Mon, 2013-06-24 at 11:52 +0400, Stanislav Kinsbursky wrote:
CPU#0 CPU#1
- -
rpc_kill_sb
sn->pipefs_sb = NULLrpc_release_client
(UMOUNT_EVENT) rpc_free_auth
rpc_pipefs_event
rpc_get_client_for_event
!atomic_inc_not_zero(cl_count)
atomic_inc(cl_count)
rpc_free_client
rpc_clnt_remove_pipedir
To fix this, this patch does the following:
1) Calls RPC_PIPEFS_UMOUNT notification with sn->pipefs_sb_lock being held.
2) Removes SUNRPC client from the list AFTER pipes destroying.
3) Doesn't hold RPC client on notification: if client in the list, then it
can't be destroyed while sn->pipefs_sb_lock in hold by notification caller.
Signed-off-by: Stanislav Kinsbursky
Cc: sta...@vger.kernel.org
---
net/sunrpc/clnt.c |5 +
net/sunrpc/rpc_pipe.c |2 +-
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index c512448..efca2f7 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -1165,7 +1165,6 @@ static void rpc_kill_sb(struct super_block *sb)
goto out;
}
sn->pipefs_sb = NULL;
- mutex_unlock(>pipefs_sb_lock);
dprintk("RPC: sending pipefs UMOUNT notification for net %p%s\n",
net, NET_NAME(net));
blocking_notifier_call_chain(_pipefs_notifier_list,
@@ -1173,6 +1172,7 @@ static void rpc_kill_sb(struct super_block *sb)
sb);
put_net(net);
out:
+ mutex_unlock(>pipefs_sb_lock);
Is this safe to do after the put_net()?
Sure it's not. Sorry.
Will send the patch once more.
kill_litter_super(sb);
}
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] minnowboard: Add base platform driver for the MinnowBoard
On Wed, 2013-06-26 at 04:52 +, Matthew Garrett wrote: > On Tue, 2013-06-25 at 21:43 -0700, Darren Hart wrote: > > > 1) I need time, possibly a couple of months, to get proper ACPI support > > for these drivers into the firmware. Then I can rewrite these as ACPI > > drivers as is proper for an x86 board. I've already started down this > > path. > > A couple of months pushes you back one kernel release. It's not a huge > deal. I think I side with Olof here - the kernel developers have pushed > back against hardcoded and NIHed ARM device descriptors, and given that > we have a perfectly reasonable standard in the X86 world (ie, ACPI), I'm > not enthusiastic about merging something that's (a) going to be > superseded in the near future and (b) may end up serving as an example > to others who think this is ok. My biggest concern is fragmentation after the boards start to ship. I recognize this comes under the "lack of planning on your part doesn't constitute an emergency on my part" heading (although it really wasn't a lack of planning). Now that this is out here and people can see where it's going, if we choose to nack these and wait for a better implementation, that alone may accomplish the same goal. > Do these boards currently boot any other OSes? Currently the linux-yocto_3.8 standard/minnow Linux kernel is the only thing known to boot on it. This is what will ship with the device. > > See what happens when core kernel people are allowed to write driver > > code? How does this relate to converting this over to an ACPI device > > driver? I guess I would replace the above with > > MODULE_DEVICE_TABLE(acpi, ...) ? If I do the above is this still an > > evil board-file? What makes the acpi method of discover superior to > > setting up linux-hotplug via dmi? > > MODULE_DEVICE_TABLE is invisible to the running driver, it just exports > metadata that udev will use to decide whether to load the driver. If a > driver is intended to deal with a specific board, DMI makes sense. If > it's intended to deal with a specific ACPI device (ie, something with a > _HID that defines the programming model), ACPI makes sense. What are you referring to with "programming model" here? The three drivers in question: minnowboard.c minnowboard-gpio.c minnowboard-keys.c are all board-specific. They map GPIO to their fixed functions and provide an API for board-specific queries (minnowboard.c), they provide example uses (minnowboard-gpio and minnowboard-keys) which aid in experimentation and the development of new drivers. Which of these make sense as ACPI devices in your opinion? -- Darren Hart Intel Open Source Technology Center Yocto Project - Technical Lead - Linux Kernel -- 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/
Workaround: kernel Docbook documentation - fsfunc prefix issue
Hi, We're maintaining an online copy of kernel documentation at http://free-electrons.com/kerneldoc/, where Docbook .tmpl files have been converted to html, using the "make htmldocs" command. The goal is to make such automatically generated documentation available to search engines. I noticed that in the generated .html files, all function names where prefixed by "fsfunc", which was quite ugly. At least in Debian based distros, this is actually a known bug in the "docbook-xls" package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654338 Fortunately, a fix is now available. You can either upgrade to the latest Debian versions, or just install the new package manually. That's what I did on my Ubuntu 13.04 system: > wget http://ftp.us.debian.org/debian/pool/main/d/docbook-xsl/docbook-xsl_1.78.1+dfsg-1_all.deb > sudo dpkg -i docbook-xsl_1.78.1+dfsg-1_all.deb Now, my generated kernel documentation looks great again. Cheers, Michael. -- Michael Opdenacker, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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: amba-pl08x and 'get_signal' namespace collision/build error
On Tue, Jun 25, 2013 at 07:45:39PM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 25, 2013 at 12:30:08PM +0100, Jonathan Austin wrote: > > There's a patch making its way to mainline via Russell's tree > > (8d96250700: ARM: mm: Transparent huge page support for LPAE systems) > > that breaks the build of the amba-pl08x driver (drivers/dma/amba-pl08x.c) > > because the 'get_signal' macro from include/linux/signal.h is now in the > > driver's scope and it clobbers a (previously) valid function call. > > Well, here's the change to asm/pgtable.h in that patch: > > diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h > index 9bcd262..eaedce7 100644 > --- a/arch/arm/include/asm/pgtable.h > +++ b/arch/arm/include/asm/pgtable.h > @@ -24,6 +24,9 @@ > #include > #include > > + > +#include > + > #ifdef CONFIG_ARM_LPAE > #include > #else > > And the question is - if that's all that is going on in that file, why > is asm/tlbflush.h being added to it? What in _that_ file uses anything > from asm/tlbflush.h (nothing apparantly from what I can see)? > > So, I'm tempted to kill this change off unless someone can justify why > that addition happened - it looks completely inappropriate to me. Yup. This is fixed in slave-dma tree by a patch from mark by renaming it. This should not show in the -next tree -- ~Vinod -- 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: frequent softlockups with 3.10rc6.
On Tue, Jun 25, 2013 at 12:23:34PM -0400, Steven Rostedt wrote: > Now, what we can try to do as well, is to add a trigger to disable > tracing, which should (I need to check the code) stop tracing on printk. > To do so: > > # echo printk:traceoff > /sys/kernel/debug/tracing/set_ftrace_filter > > This will add a trigger to the printk function that when called, will > disable tracing. If it is hit before you get your trace, you can just > re-enable tracing with: > > # echo 1 > /sys/kernel/debug/tracing/tracing_on > > Hmm, no it needs a fix to make this work. I applied a patch below that > should do this correctly (and will put this into my 3.11 queue). > > If you run the test again with this change and with the above filter, it > should stop the trace before overwriting the first dump, as it should > ignore the printk output. I think something isn't right with this patch. After 10 hours, I hit the bug again, but... (01:21:28:root@binary:tracing)# cat trace # tracer: preemptirqsoff # (01:21:30:root@binary:tracing)# Dave -- 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] arch: s390: kernel: reset 'c->hotpluggable' when failure occurs
On 06/25/2013 05:31 PM, Chen Gang wrote:
> On 06/25/2013 05:09 PM, Heiko Carstens wrote:
>> On Tue, Jun 25, 2013 at 03:24:09PM +0800, Chen Gang wrote:
>>> On 06/25/2013 02:48 PM, Heiko Carstens wrote:
On Tue, Jun 25, 2013 at 09:46:45AM +0800, Chen Gang wrote:
>> When smp_add_present_cpu() fails, it has reset all things excluding
>> 'c->hotpluggable', so need reset it as original state completely.
>>
>> +c->hotpluggable = 0;
>> return rc;
No, that doesn't make sense. All cpus on s390 are always hotplugable.
It really doesn't matter if the value of this field is 0 or 1 after
an error.
>>>
>>> If so, is it better to set 'c->hotpluggable' for all cpus on s390 during
>>> initializing ?
>>
> No, just leave the code as it is.
>>
>
Please help check the diff below whether is valuable, thanks.
For architectures which may support 'hotpluggable', can loop all cpus
during subsys_initcall().
The caller will skip the return value of subsys_initcall(), so can only
return 0.
diff begin--
diff --git a/arch/s390/kernel/smp.c b/arch/s390/kernel/smp.c
index 15a016c..147cc18 100644
--- a/arch/s390/kernel/smp.c
+++ b/arch/s390/kernel/smp.c
@@ -1065,8 +1065,9 @@ static int __init s390_smp_init(void)
#endif
for_each_present_cpu(cpu) {
rc = smp_add_present_cpu(cpu);
- if (rc)
- return rc;
+ if (unlikely(rc))
+ printk(KERN_WARNING "%s: register_cpu %d failed (%d)\n",
+ __func__, cpu, rc);
}
return 0;
}
diff end
> Currently we have 3 possible states for 'struct cpu':
> initialized, and set hotplugable.
> unitialized, and set hotplugable.
> unitialized, and unset hotplugable.
>
> Either 2nd or 3rd is inconsistent.
>
> The cpu_is_hotplugable() will be used in kernel/rcutorture.c. I do not
> know whether it will cause issue or not, but it seems dangerous when
> __smp_rescan_cpus() has already called, and has some unsucessfull call
> of smp_add_present_cpu().
>
> Please help check.
>
> Thanks.
>
--
Chen Gang
Asianux Corporation
--
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] f2fs: add sysfs support for controlling the gc_thread
2013/6/25, Jaegeuk Kim : > Hi Namjae, > > Sorry for the late reply. > > 2013-05-29 (수), 09:01 +0900, Namjae Jeon: >> >> I have thought more after getting your reply. >> >> f2fs_cleaner(a tentative name) is that provide the following several >> >> options to control gc thread. >> >> 1. start forground gc thread to clean all invalid blocks. >> >> 2. stop number 1(fg) working. >> >> 3. set new tunning parameter (min/max/no_gc). >> >> 4. get status of current f2fs. >> >> We will provide user level util in f2fs tools and sysfs at the same >> >> time. >> >> It is useful if the console level user/App user can change them >> >> easily. > > I think we'd better support configurable min/max/no_gc times only. > And I don't think users need to do foreground GCs explicitly, since > foreground GCs should be done only when the file system suffers from the > shortage of free space. The foreground GC is the most costly operation > so that I'd like to avoid triggering it as much as possible even if > users want to do. > > Otherwise, if users would like to move data, they can just adjust > background GC times appropriately and then do sync if they really move > data synchronously. Hi Jaegeuk. Agreed, we can provide only time update values to the user and leave the user to work out the setting as per the environment. > >> >> >> >> > >> >> > Afterwards, it is worth to add some information to >> >> > Document/filesystems/f2fs.txt. >> >> Yes, It will be included in next series patches. >> >> How do you think ? If you agree my suggestion, I will start to work >> >> the above jobs. >> Hi. Jaegeuk. >> > >> > As I described, basically I agreed that this kind of interfaces and >> > user >> > apps are definitely beneficial to the f2fs users. >> > >> > But wrt design and implementation of new interfaces, we'd better >> > discuss >> > how to use them in more detail and what information should be needed >> > for >> > user-made cleaner. >> > After then, we'd better start to design the interfaces as well as user >> > scenarios clearly. >> Okay. I agree. >> >> > >> > IMO, the following issues should be addressed. >> > - how to know system idle time by users? >> e.g. When playing PVR function, In case of DTV, App try to read data >> from filesystem of usb device. >> now that, user app will never access flash rw partition and don't need >> to access there. >> I think that we can cleverly use such time to avoid or make slowly >> come in the possible performance regression later. > > Okay. > >> >> > - any priority scheme for cleaning? >> Could you plz tell me a little more detail ? > > I meant, as well as the GC times, user also gives a kind of status like: > LONG_IDLE, SHORT_IDLE, something like that. > Therefore, how about using this information to select a victim selection > policy between cost-benefit and greedy algorithms? currently we will provide the option of updating the time values from the ‘sysfs’ interface, and the GC policy is selected by default from GC thread based upon the gc type, BG or FG. So, do you mean we should provide an option to select the default GC policy for the user using ‘sysfs’ interface? Like, if the user sets “LONG_IDLE” – we choose Cost Benefit and in case of SHORT_IDLE “Greedy” ? Please elaborate more on this. 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: [Resend patch v8 01/13] Revert "sched: Introduce temporary FAIR_GROUP_SCHED dependency for load-tracking"
On 06/20/2013 10:18 AM, Alex Shi wrote:
> Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
> we can use runnable load variables.
>
> Signed-off-by: Alex Shi
There are 2 more place need to be reverted too, and merged them into the
updated patch.
BTW, this patchset was tested by Fengguang's 0day kbuild system.
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f404468..1a14209 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5858,7 +5858,7 @@ static void switched_from_fair(struct rq *rq, struct
task_struct *p)
se->vruntime -= cfs_rq->min_vruntime;
}
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
+#ifdef CONFIG_SMP
/*
* Remove our load from contribution when we leave sched_fair
* and ensure we don't carry in an old decay_count if we
@@ -5917,7 +5917,7 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#ifndef CONFIG_64BIT
cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
#endif
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
+#ifdef CONFIG_SMP
atomic64_set(_rq->decay_counter, 1);
atomic64_set(_rq->removed_load, 0);
#endif
--
---
>From 190a4d0c8fd6325c6141a9d1ae14518e521e4289 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Sun, 3 Mar 2013 16:04:36 +0800
Subject: Revert "sched: Introduce temporary FAIR_GROUP_SCHED
dependency for load-tracking"
Remove CONFIG_FAIR_GROUP_SCHED that covers the runnable info, then
we can use runnable load variables.
Also remove 2 CONFIG_FAIR_GROUP_SCHED setting which is not in reverted
patch(introduced in 9ee474f), but also need to revert.
Signed-off-by: Alex Shi
---
include/linux/sched.h | 7 +--
kernel/sched/core.c | 7 +--
kernel/sched/fair.c | 17 -
kernel/sched/sched.h | 10 ++
4 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 178a8d9..0019bef 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -994,12 +994,7 @@ struct sched_entity {
struct cfs_rq *my_q;
#endif
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
/* Per-entity load-tracking */
struct sched_avgavg;
#endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 36f85be..b9e7036 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1598,12 +1598,7 @@ static void __sched_fork(struct task_struct *p)
p->se.vruntime = 0;
INIT_LIST_HEAD(>se.group_node);
-/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
#endif
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3ee1c2e..1a14209 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1128,8 +1128,7 @@ static inline void update_cfs_shares(struct cfs_rq
*cfs_rq)
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
-/* Only depends on SMP, FAIR_GROUP_SCHED may be removed when useful in lb */
-#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
+#ifdef CONFIG_SMP
/*
* We choose a half-life close to 1 scheduling period.
* Note: The tables below are dependent on this value.
@@ -3436,12 +3435,6 @@ unlock:
}
/*
- * Load-tracking only depends on SMP, FAIR_GROUP_SCHED dependency below may be
- * removed when useful for applications beyond shares distribution (e.g.
- * load-balance).
- */
-#ifdef CONFIG_FAIR_GROUP_SCHED
-/*
* Called immediately before a task is migrated to a new cpu; task_cpu(p) and
* cfs_rq_of(p) references at time of call are still valid and identify the
* previous cpu. However, the caller only guarantees p->pi_lock is held; no
@@ -3464,7 +3457,6 @@ migrate_task_rq_fair(struct task_struct *p, int next_cpu)
atomic64_add(se->avg.load_avg_contrib, _rq->removed_load);
}
}
-#endif
#endif /* CONFIG_SMP */
static unsigned long
@@ -5866,7 +5858,7 @@ static void switched_from_fair(struct rq *rq, struct
task_struct *p)
se->vruntime -= cfs_rq->min_vruntime;
}
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
+#ifdef CONFIG_SMP
/*
* Remove our load from contribution when we leave sched_fair
* and ensure we don't carry in an old decay_count if we
@@ -5925,7 +5917,7 @@ void init_cfs_rq(struct cfs_rq *cfs_rq)
#ifndef CONFIG_64BIT
cfs_rq->min_vruntime_copy = cfs_rq->min_vruntime;
#endif
-#if defined(CONFIG_FAIR_GROUP_SCHED) && defined(CONFIG_SMP)
+#ifdef CONFIG_SMP
[Suggestion] tile: include: asm: missing "feedback.h" file.
Hello Maintainers: The compilation failed by "make ARCH=tile tilegx_defconfig", and "make ARCH=tile CROSS_COMPILE=tile-linux-gnu-" for upstream next-20130625. The related error: CC kernel/bounds.s In file included from include/linux/linkage.h:7:0, from include/linux/kernel.h:6, from include/asm-generic/bug.h:13, from arch/tile/include/generated/asm/bug.h:1, from include/linux/bug.h:4, from include/linux/page-flags.h:9, from kernel/bounds.c:9: /root/linux-next/arch/tile/include/asm/linkage.h:18:22: fatal error: feedback.h: No such file or directory We really need "feedback.h" arch/tile/kernel/entry.S: Assembler messages: arch/tile/kernel/entry.S:26: Error: Unknown opcode `feedback_enter(current_text_addr)'. arch/tile/kernel/entry.S:46: Error: Unknown opcode `feedback_enter(dump_stack)'. arch/tile/kernel/entry.S:53: Error: Unknown opcode `feedback_enter(KBacktraceIterator_init_current)'. arch/tile/kernel/entry.S:61: Error: Unknown opcode `feedback_enter(smp_nap)'. arch/tile/kernel/entry.S:76: Error: Unknown opcode `feedback_enter(_cpu_idle)'. Welcome any suggestions and completions. Thanks. -- Chen Gang Asianux Corporation -- 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] arch: frv: mb93090-mb00: remove '__init' for pci_fixup_umc_ide() which used by 'DECLARE_PCI_FIXUP_HEADER'
pci_fixup_umc_ide() is for 'DECLARE_PCI_FIXUP_HEADER', so need remove
it from init section to normal section.
The related warning (with allmodconfig):
LD arch/frv/mb93090-mb00/built-in.o
WARNING: arch/frv/mb93090-mb00/built-in.o(.pci_fixup_header+0x4c): Section
mismatch in reference from the variable
__pci_fixup_PCI_VENDOR_ID_UMCPCI_DEVICE_ID_UMC_UM8886BFpci_fixup_umc_ide to the
function .init.text:pci_fixup_umc_ide()
The variable
__pci_fixup_PCI_VENDOR_ID_UMCPCI_DEVICE_ID_UMC_UM8886BFpci_fixup_umc_ide
references
a function __init pci_fixup_umc_ide().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __init annotation of
pci_fixup_umc_ide() so it may be used outside an exit section.
Signed-off-by: Chen Gang
---
arch/frv/mb93090-mb00/pci-vdk.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/frv/mb93090-mb00/pci-vdk.c b/arch/frv/mb93090-mb00/pci-vdk.c
index 0aa35f0..56a3abf 100644
--- a/arch/frv/mb93090-mb00/pci-vdk.c
+++ b/arch/frv/mb93090-mb00/pci-vdk.c
@@ -254,7 +254,7 @@ static void __init pcibios_fixup_peer_bridges(void)
* Exceptions for specific devices. Usually work-arounds for fatal design
flaws.
*/
-static void __init pci_fixup_umc_ide(struct pci_dev *d)
+static void pci_fixup_umc_ide(struct pci_dev *d)
{
/*
* UM8886BF IDE controller sets region type bits incorrectly,
--
1.7.7.6
--
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] arch: m32r: kernel: use 'COPY_UNALIGNED_HWORD' instead of 'COPY_UNALIGNED_WORD'
For 'hvalue' and 'hlocation', need use 'COPY_UNALIGNED_HWORD' instead The related warnings (with allmodconfig) CC arch/m32r/kernel/module.o arch/m32r/kernel/module.c: In function ‘apply_relocate_add’: arch/m32r/kernel/module.c:127:8: warning: ‘*((void *)+2)’ is used uninitialized in this function [-Wuninitialized] arch/m32r/kernel/module.c:127:8: warning: ‘*((void *)+2)’ is used uninitialized in this function [-Wuninitialized] arch/m32r/kernel/module.c:127:8: warning: ‘*((void *)+3)’ is used uninitialized in this function [-Wuninitialized] Signed-off-by: Chen Gang --- arch/m32r/kernel/module.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/m32r/kernel/module.c b/arch/m32r/kernel/module.c index 38233b6..bcad14c 100644 --- a/arch/m32r/kernel/module.c +++ b/arch/m32r/kernel/module.c @@ -124,7 +124,7 @@ int apply_relocate_add(Elf32_Shdr *sechdrs, relocation = relocation & 0x; /* RELA must has 0 at relocation field. */ hvalue = relocation; - COPY_UNALIGNED_WORD (hvalue, *hlocation, align); + COPY_UNALIGNED_HWORD(hvalue, *hlocation, align); break; case R_M32R_SDA16_RELA: case R_M32R_LO16_RELA: -- 1.7.7.6 -- 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] regulator: ab8500-ext: Staticize local symbols
Local symbols used only in this file are made static.
Signed-off-by: Sachin Kamat
Cc: Bengt Jonsson
---
drivers/regulator/ab8500-ext.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/ab8500-ext.c b/drivers/regulator/ab8500-ext.c
index 4137a2f..02ff691 100644
--- a/drivers/regulator/ab8500-ext.c
+++ b/drivers/regulator/ab8500-ext.c
@@ -341,7 +341,7 @@ static struct of_regulator_match
ab8500_ext_regulator_match[] = {
{ .name = "ab8500_ext3", .driver_data = (void *) AB8500_EXT_SUPPLY3, },
};
-int ab8500_ext_regulator_probe(struct platform_device *pdev)
+static int ab8500_ext_regulator_probe(struct platform_device *pdev)
{
struct ab8500 *ab8500 = dev_get_drvdata(pdev->dev.parent);
struct ab8500_platform_data *ppdata;
@@ -433,7 +433,7 @@ int ab8500_ext_regulator_probe(struct platform_device *pdev)
return 0;
}
-int ab8500_ext_regulator_remove(struct platform_device *pdev)
+static int ab8500_ext_regulator_remove(struct platform_device *pdev)
{
int i;
--
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 4/8] minnowboard: Add base platform driver for the MinnowBoard
On Tue, 2013-06-25 at 21:43 -0700, Darren Hart wrote:
> 1) I need time, possibly a couple of months, to get proper ACPI support
> for these drivers into the firmware. Then I can rewrite these as ACPI
> drivers as is proper for an x86 board. I've already started down this
> path.
A couple of months pushes you back one kernel release. It's not a huge
deal. I think I side with Olof here - the kernel developers have pushed
back against hardcoded and NIHed ARM device descriptors, and given that
we have a perfectly reasonable standard in the X86 world (ie, ACPI), I'm
not enthusiastic about merging something that's (a) going to be
superseded in the near future and (b) may end up serving as an example
to others who think this is ok.
Do these boards currently boot any other OSes?
> See what happens when core kernel people are allowed to write driver
> code? How does this relate to converting this over to an ACPI device
> driver? I guess I would replace the above with
> MODULE_DEVICE_TABLE(acpi, ...) ? If I do the above is this still an
> evil board-file? What makes the acpi method of discover superior to
> setting up linux-hotplug via dmi?
MODULE_DEVICE_TABLE is invisible to the running driver, it just exports
metadata that udev will use to decide whether to load the driver. If a
driver is intended to deal with a specific board, DMI makes sense. If
it's intended to deal with a specific ACPI device (ie, something with a
_HID that defines the programming model), ACPI makes sense.
--
Matthew Garrett | mj...@srcf.ucam.org
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 4/8] minnowboard: Add base platform driver for the MinnowBoard
On Tue, 2013-06-25 at 21:00 -0700, Olof Johansson wrote:
> Hi,
Hey Olof, thanks for the review!
David M, search for "minnow_phy_reset" for your bit :-)
>
> On Tue, Jun 25, 2013 at 06:53:24PM -0700, Darren Hart wrote:
> > The MinnowBoard (http://www.minnowboard.org) is an Intel Atom (E6xx) plus
> > EG20T
> > PCH development board. It uses a few GPIO lines for specific purposes and
> > exposes the rest to the user.
> >
> > Request the dedicated GPIO lines:
> > HWID
> > LVDS_DETECT
> > PHY_RESET
> > LED0
> > LED1
> >
> > Setup platform drivers for the MinnowBoard LEDs using the leds-gpio
> > driver. Setup led0 and led1 with heartbeat and mmc0 default triggers
> > respectively.
> >
> > GPIO lines SUS[0-4] are dual purpose, either for LVDS signaling or as
> > user GPIO. Determine which via the LVDS_DETECT signal and enable or
> > disable them accordingly.
> >
> > Provide a minimal public interface:
> > minnow_detect()
> > minnow_lvds_detect()
> > minnow_hwid()
> > minnow_phy_reset()
> >
> > Signed-off-by: Darren Hart
> > Cc: Matthew Garrett
> > Cc: Grant Likely
> > Cc: Linus Walleij
> > Cc: Richard Purdie
> > Cc: "H. Peter Anvin"
> > Cc: Peter Waskiewicz
> > Cc: Andy Shevchenko
> > Cc: platform-driver-...@vger.kernel.org
> > ---
> > drivers/platform/x86/Kconfig| 20
> > drivers/platform/x86/Makefile | 1 +
> > drivers/platform/x86/minnowboard-gpio.h | 60 ++
> > drivers/platform/x86/minnowboard.c | 193
> >
> > include/linux/minnowboard.h | 37 ++
> > 5 files changed, 311 insertions(+)
> > create mode 100644 drivers/platform/x86/minnowboard-gpio.h
> > create mode 100644 drivers/platform/x86/minnowboard.c
> > create mode 100644 include/linux/minnowboard.h
>
> H. x86 boardfiles arriving under drivers/platform.
Indeed, I hate myself for this :-)
Here was my rationale, feel free to pick it apart:
1) I need time, possibly a couple of months, to get proper ACPI support
for these drivers into the firmware. Then I can rewrite these as ACPI
drivers as is proper for an x86 board. I've already started down this
path.
2) I felt the value of getting something upstream, even if it isn't
perfect, before the board ships was preferable to only having it in
what is effectively a vendor tree (linux-yocto_3.8 standard/minnow) and
risking various other implementations popping up and confusing the
situation.
3) I at least wanted to fix the pch_gbe support which is currently tied
up with these platform drivers. I considered pushing the
minnow_phy_reset into pch_gbe, but I previously was scolded for putting
too much board-specific knowledge into that driver.
> The main concern is that this won't really scale if more vendors add
> variations of this board -- needing code changes for each and every one
> of them. Given that it's an open platform encouraging derivatives, that seems
> like a slippery slope.
+10
> It's really unfortunate that this information couldn't be passed in from
> firmware. We've been working so hard for so long on ARM now to move away
> from board files, it's such a pity to add them on another major platform.
Nod, see above. If this trumps the rationale above, it might just make
sense to push the phy reset into the pch_gbe driver and hold off on
these. Alternatively, we can choose to accept that this is transitional
with the understanding that drivers/platform/x86/minnow* *will* go
away.
> > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> > index 8577261..154dbf6 100644
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -15,6 +15,26 @@ menuconfig X86_PLATFORM_DEVICES
> >
> > if X86_PLATFORM_DEVICES
> >
> > +config MINNOWBOARD
> > + tristate "MinnowBoard GPIO and LVDS support"
> > + depends on LPC_SCH
> > + depends on GPIO_SCH
> > + depends on GPIO_PCH
> > + depends on LEDS_GPIO
> > + default n
>
> No need to default n. 'n' is the default default. :)
Check. Thanks.
...
> > +#define GPIO_PCH0 244
> > +#define GPIO_PCH1 245
> > +#define GPIO_PCH2 246
> > +#define GPIO_PCH3 247
> > +#define GPIO_PCH4 248
> > +#define GPIO_PCH5 249
> > +#define GPIO_PCH6 250
> > +#define GPIO_PCH7 251
> > +
> > +#define GPIO_HWID0 252
> > +#define GPIO_HWID1 253
> > +#define GPIO_HWID2 254
> > +
> > +#define GPIO_LVDS_DETECT 255
>
> It looks like at least gpio-pch.c uses dynamic gpio numbers, which makes it
> hard to define these as static numbers since they might move around depending
> on module load order, etc.
Oh dear, not something I've experienced. OK, I'll go look into how to
properly handle that case. Any pointers?
...
> > +int minnow_hwid(void)
> > +{
> > + /* This should never be called prior to minnow_init_module() */
> > + WARN_ON_ONCE(minnow_hwid_val == -1);
> > + return minnow_hwid_val;
> > +}
> > +EXPORT_SYMBOL_GPL(minnow_hwid);
>
> I don't see this
__perf_event_overflow suspicious RCU usage.
[40924.102878] ===
[40924.102898] [ INFO: suspicious RCU usage. ]
[40924.102918] 3.10.0-rc7+ #4 Not tainted
[40924.102936] ---
[40924.102957] include/linux/rcupdate.h:780 rcu_read_lock() used illegally
while idle!
[40924.102987]
other info that might help us debug this:
[40924.103019]
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
[40924.103059] RCU used illegally from extended quiescent state!
[40924.103084] 1 lock held by trinity-child2/7828:
[40924.103104] #0: (rcu_read_lock){.+.+..}, at: []
__perf_event_overflow+0x108/0x310
[40924.103960]
stack backtrace:
[40924.105608] CPU: 2 PID: 7828 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #4
[40924.107348] 0001 8801df29ba90 816dfc58
8801df29bac0
[40924.108251] 810b5c47 880231947000
8801df29bbc0
[40924.109152] 8801df29bb40 8113e474
8113e2e8
[40924.110059] Call Trace:
[40924.110949] [] dump_stack+0x19/0x1b
[40924.111848] [] lockdep_rcu_suspicious+0xe7/0x120
[40924.112752] [] __perf_event_overflow+0x294/0x310
[40924.113654] [] ? __perf_event_overflow+0x108/0x310
[40924.114556] [] ? ftrace_call+0x5/0x2f
[40924.115450] [] perf_swevent_overflow+0x51/0xe0
[40924.116352] [] perf_swevent_event+0x5f/0x90
[40924.117251] [] perf_tp_event+0x109/0x4f0
[40924.118149] [] ? perf_tp_event+0x2af/0x4f0
[40924.119049] [] ? __rcu_read_lock+0x20/0x20
[40924.119944] [] perf_ftrace_function_call+0xbf/0xd0
[40924.120841] [] ? ftrace_ops_control_func+0x105/0x140
[40924.121743] [] ? __rcu_read_lock+0x20/0x20
[40924.122645] [] ? rcu_eqs_enter_common+0x5e/0x470
[40924.123544] [] ftrace_ops_control_func+0x105/0x140
[40924.12] [] ? __rcu_read_lock+0x20/0x20
[40924.125344] [] ? rcu_eqs_enter_common+0x5e/0x470
[40924.126242] [] ftrace_ops_list_func+0x156/0x180
[40924.127139] [] ftrace_call+0x5/0x2f
[40924.128031] [] ? ftrace_ops_list_func+0xb2/0x180
[40924.128932] [] ? ftrace_call+0x5/0x2f
[40924.129825] [] ? debug_lockdep_rcu_enabled+0x5/0x40
[40924.130723] [] ? debug_lockdep_rcu_enabled+0x5/0x40
[40924.131611] [] ? rcu_eqs_enter_common+0x5e/0x470
[40924.132492] [] rcu_eqs_enter+0x6a/0xb0
[40924.133367] [] rcu_user_enter+0x13/0x20
[40924.134244] [] user_enter+0x6a/0xd0
[40924.135113] [] syscall_trace_leave+0x78/0x140
[40924.135975] [] int_check_syscall_exit_work+0x34/0x3d
--
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] irqchip: Add TB10x interrupt controller driver
On 06/25/2013 07:41 PM, Christian Ruppert wrote: >>> > > Signed-off-by: Christian Ruppert >>> > > Signed-off-by: Pierrick Hascoet >> > >> > Why is Pierrick in the SOB chain? > We work on the platform port together and review and test each others' > patches. It is planned submitting several of his patches as soon as > basic platform is in. Which is fine, however the rule is, person sending the patch needs to do the last SOB. -- 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 v9] i2c-designware: make SDA hold time configurable
On 06/25/2013 10:09 PM, Wolfram Sang wrote: > Hi, > > On Fri, Jun 21, 2013 at 11:53:42AM +0200, Christian Ruppert wrote: >> > This patch makes the SDA hold time configurable through device tree. >> > >> > Signed-off-by: Christian Ruppert >> > Signed-off-by: Pierrick Hascoet >> > --- >> > .../devicetree/bindings/i2c/i2c-designware.txt | 14 ++ >> > arch/arc/boot/dts/abilis_tb100_dvk.dts | 10 +- >> > arch/arc/boot/dts/abilis_tb101_dvk.dts | 10 +- > Vineet, an ack for those would be nice since I think it is better if I > take all this via I2C. > Certainly, I was waiting for you guys to converge :-) Acked-by: Vineet Gupta# for arch/arc/boot/dts/* -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] pci: ACS quirk for AMD southbridge
[fix Joerg's email address]
On Tue, Jun 25, 2013 at 10:15 PM, Bjorn Helgaas wrote:
> On Wed, Jul 11, 2012 at 11:18 PM, Alex Williamson
> wrote:
>> We've confirmed that peer-to-peer between these devices is
>> not possible. We can therefore claim that they support a
>> subset of ACS.
>>
>> Signed-off-by: Alex Williamson
>> Cc: Joerg Roedel
>> ---
>>
>> Two things about this patch make me a little nervous. The
>> first is that I'd really like to have a pci_is_pcie() test
>> in pci_mf_no_p2p_acs_enabled(), but these devices don't
>> have a PCIe capability. That means that if there was a
>> topology where these devices sit on a legacy PCI bus,
>> we incorrectly return that we're ACS safe here. That leads
>> to my second problem, pciids seems to suggest that some of
>> these functions have been around for a while. Is it just
>> this package that's peer-to-peer safe, or is it safe to
>> assume that any previous assembly of these functions is
>> also p2p safe. Maybe we need to factor in device revs if
>> that uniquely identifies this package?
>>
>> Looks like another useful device to potentially quirk
>> would be:
>>
>> 00:15.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900
>> PCI to PCI bridge (PCIE port 0)
>> 00:15.1 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900
>> PCI to PCI bridge (PCIE port 1)
>> 00:15.2 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB900 PCI to PCI
>> bridge (PCIE port 2)
>> 00:15.3 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB900 PCI to PCI
>> bridge (PCIE port 3)
>>
>> 00:15.0 0604: 1002:43a0
>> 00:15.1 0604: 1002:43a1
>> 00:15.2 0604: 1002:43a2
>> 00:15.3 0604: 1002:43a3
>>
>> drivers/pci/quirks.c | 29 +
>> 1 file changed, 29 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 4ebc865..2c84961 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3271,11 +3271,40 @@ struct pci_dev *pci_get_dma_source(struct pci_dev
>> *dev)
>> return pci_dev_get(dev);
>> }
>>
>> +/*
>> + * Multifunction devices that do not support peer-to-peer between
>> + * functions can claim to support a subset of ACS. Such devices
>> + * effectively enable request redirect (RR) and completion redirect (CR)
>> + * since all transactions are redirected to the upstream root complex.
>> + */
>> +static int pci_mf_no_p2p_acs_enabled(struct pci_dev *dev, u16 acs_flags)
>> +{
>> + if (!dev->multifunction)
>> + return -ENODEV;
>> +
>> + /* Filter out flags not applicable to multifunction */
>> + acs_flags &= (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_EC | PCI_ACS_DT);
>> +
>> + return acs_flags & ~(PCI_ACS_RR | PCI_ACS_CR) ? 0 : 1;
>> +}
>> +
>> static const struct pci_dev_acs_enabled {
>> u16 vendor;
>> u16 device;
>> int (*acs_enabled)(struct pci_dev *dev, u16 acs_flags);
>> } pci_dev_acs_enabled[] = {
>> + /*
>> +* AMD/ATI multifunction southbridge devices. AMD has confirmed
>> +* that peer-to-peer between these devices is not possible, so
>> +* they do support a subset of ACS even though the capability is
>> +* not exposed in config space.
>> +*/
>> + { PCI_VENDOR_ID_ATI, 0x4385, pci_mf_no_p2p_acs_enabled },
>> + { PCI_VENDOR_ID_ATI, 0x439c, pci_mf_no_p2p_acs_enabled },
>> + { PCI_VENDOR_ID_ATI, 0x4383, pci_mf_no_p2p_acs_enabled },
>> + { PCI_VENDOR_ID_ATI, 0x439d, pci_mf_no_p2p_acs_enabled },
>> + { PCI_VENDOR_ID_ATI, 0x4384, pci_mf_no_p2p_acs_enabled },
>> + { PCI_VENDOR_ID_ATI, 0x4399, pci_mf_no_p2p_acs_enabled },
>> { 0 }
>> };
>>
>>
>
> I was looking for something else and found this old email. This patch
> hasn't been applied and I haven't seen any discussion about it. Is it
> still of interest? It seems relevant to the current ACS discussion
> [1].
>
> If it's relevant, what's the topology? Apparently they don't have a
> PCIe capability. Is the upstream device a PCIe device (a downstream
> port or a root port)? I assume anything downstream from these AMD
> devices (0x4385, 0x439c, etc.) is plain PCI (not PCIe)?
>
> Bjorn
>
> [1] https://lkml.kernel.org/r/20130607163441.7733.23221.st...@bling.home
--
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] irqchip: Add TB10x interrupt controller driver
Hi Thomas, On 06/25/2013 08:07 PM, Thomas Gleixner wrote: > >>> I can pick it up, but I'm not so fond of carrying arch/arc patches >>> which might conflict with other stuff in the arc tree. Veenet, if I >>> should pick the whole thing up, I'd like to have an acked-by at least. >> Would you prefer if we separated everything in arch/arc from this patch >> and push it through Vineet's channel? > If it can be split w/o breaking the world, this would be the most > elegant solution. I would have preferred it to be part of same patch, for bisectability if nothing else. However your tree gets merged in pretty early in the cycle so I'll make sure my pull request goes in after yours. Anyways, thanks for merging the driver. Chrisitian, please send over the forked out arch/arc bits for this to me separately. The i2c DT changes seem to touch different files though so I don't see merge issues as of now. -Vineet -- 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: [ 00/17] 3.0.84-stable review
On Tue, Jun 25, 2013 at 12:23:00PM -0700, Guenter Roeck wrote: > On Tue, Jun 25, 2013 at 11:39:15AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.0.84 release. > > There are 17 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 27 18:35:59 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.0.84-rc1.gz > > and the diffstat can be found below. > > > Build results are as follows. I did not check every failure, but as far as I > recall there are no new failures. Thanks for testing and letting us know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] pci: ACS quirk for AMD southbridge
On Wed, Jul 11, 2012 at 11:18 PM, Alex Williamson
wrote:
> We've confirmed that peer-to-peer between these devices is
> not possible. We can therefore claim that they support a
> subset of ACS.
>
> Signed-off-by: Alex Williamson
> Cc: Joerg Roedel
> ---
>
> Two things about this patch make me a little nervous. The
> first is that I'd really like to have a pci_is_pcie() test
> in pci_mf_no_p2p_acs_enabled(), but these devices don't
> have a PCIe capability. That means that if there was a
> topology where these devices sit on a legacy PCI bus,
> we incorrectly return that we're ACS safe here. That leads
> to my second problem, pciids seems to suggest that some of
> these functions have been around for a while. Is it just
> this package that's peer-to-peer safe, or is it safe to
> assume that any previous assembly of these functions is
> also p2p safe. Maybe we need to factor in device revs if
> that uniquely identifies this package?
>
> Looks like another useful device to potentially quirk
> would be:
>
> 00:15.0 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900
> PCI to PCI bridge (PCIE port 0)
> 00:15.1 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB700/SB800/SB900
> PCI to PCI bridge (PCIE port 1)
> 00:15.2 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB900 PCI to PCI
> bridge (PCIE port 2)
> 00:15.3 PCI bridge: Advanced Micro Devices [AMD] nee ATI SB900 PCI to PCI
> bridge (PCIE port 3)
>
> 00:15.0 0604: 1002:43a0
> 00:15.1 0604: 1002:43a1
> 00:15.2 0604: 1002:43a2
> 00:15.3 0604: 1002:43a3
>
> drivers/pci/quirks.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 4ebc865..2c84961 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3271,11 +3271,40 @@ struct pci_dev *pci_get_dma_source(struct pci_dev
> *dev)
> return pci_dev_get(dev);
> }
>
> +/*
> + * Multifunction devices that do not support peer-to-peer between
> + * functions can claim to support a subset of ACS. Such devices
> + * effectively enable request redirect (RR) and completion redirect (CR)
> + * since all transactions are redirected to the upstream root complex.
> + */
> +static int pci_mf_no_p2p_acs_enabled(struct pci_dev *dev, u16 acs_flags)
> +{
> + if (!dev->multifunction)
> + return -ENODEV;
> +
> + /* Filter out flags not applicable to multifunction */
> + acs_flags &= (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_EC | PCI_ACS_DT);
> +
> + return acs_flags & ~(PCI_ACS_RR | PCI_ACS_CR) ? 0 : 1;
> +}
> +
> static const struct pci_dev_acs_enabled {
> u16 vendor;
> u16 device;
> int (*acs_enabled)(struct pci_dev *dev, u16 acs_flags);
> } pci_dev_acs_enabled[] = {
> + /*
> +* AMD/ATI multifunction southbridge devices. AMD has confirmed
> +* that peer-to-peer between these devices is not possible, so
> +* they do support a subset of ACS even though the capability is
> +* not exposed in config space.
> +*/
> + { PCI_VENDOR_ID_ATI, 0x4385, pci_mf_no_p2p_acs_enabled },
> + { PCI_VENDOR_ID_ATI, 0x439c, pci_mf_no_p2p_acs_enabled },
> + { PCI_VENDOR_ID_ATI, 0x4383, pci_mf_no_p2p_acs_enabled },
> + { PCI_VENDOR_ID_ATI, 0x439d, pci_mf_no_p2p_acs_enabled },
> + { PCI_VENDOR_ID_ATI, 0x4384, pci_mf_no_p2p_acs_enabled },
> + { PCI_VENDOR_ID_ATI, 0x4399, pci_mf_no_p2p_acs_enabled },
> { 0 }
> };
>
>
I was looking for something else and found this old email. This patch
hasn't been applied and I haven't seen any discussion about it. Is it
still of interest? It seems relevant to the current ACS discussion
[1].
If it's relevant, what's the topology? Apparently they don't have a
PCIe capability. Is the upstream device a PCIe device (a downstream
port or a root port)? I assume anything downstream from these AMD
devices (0x4385, 0x439c, etc.) is plain PCI (not PCIe)?
Bjorn
[1] https://lkml.kernel.org/r/20130607163441.7733.23221.st...@bling.home
--
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/8] pch_uart: Add uart_clk selection for the MinnowBoard
On Tue, Jun 25, 2013 at 08:58:45PM -0700, Darren Hart wrote: > > How about this, which makes it easy to backport, then you fix it up > > properly for 3.12? This comes after my tree is pretty much closed for > > 3.11, but a simple device id addition like this is acceptable, but I'll > > not get to it until after 3.11-rc1 is out... > > Sure. So something like this is what you have in mind? Build tested > only, I'll include it in V2 with proper testing, but just wanted to > make sure we're on the same page while I have your attention: Yes, that patch looks good to me, and it makes it easier to add new devices later as well. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
On Wed, Jun 26, 2013 at 07:02:00, Fernandes, Joel wrote: > From: Joel A Fernandes > > Build EDMA in my default to avoid fewer people stepping on their toes "my default" --> which default. I believe it should be omap2plus defconfig > with broken DMA on drivers needing EDMA. > > Signed-off-by: Joel A Fernandes > --- > arch/arm/configs/omap2plus_defconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/configs/omap2plus_defconfig > b/arch/arm/configs/omap2plus_defconfig > index abbe319..7e00deb 100644 > --- a/arch/arm/configs/omap2plus_defconfig > +++ b/arch/arm/configs/omap2plus_defconfig > @@ -236,6 +236,7 @@ CONFIG_RTC_DRV_TWL92330=y > CONFIG_RTC_DRV_TWL4030=y > CONFIG_RTC_DRV_OMAP=y > CONFIG_DMADEVICES=y > +CONFIG_TI_EDMA=y > CONFIG_DMA_OMAP=y > CONFIG_EXT2_FS=y > CONFIG_EXT3_FS=y > -- > 1.7.9.5 > > ___ > Davinci-linux-open-source mailing list > davinci-linux-open-sou...@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > Regards, Gururaja -- 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/5] ARM: dts: add AM33XX MMC support
On Wed, Jun 26, 2013 at 06:54:41, Fernandes, Joel wrote:
> From: Matt Porter
>
> Adds AM33XX MMC support for am335x-bone, am335x-evm, and
> am335x-evmsk.
>
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> ---
> arch/arm/boot/dts/am335x-bone.dts |7 +++
> arch/arm/boot/dts/am335x-evm.dts |7 +++
> arch/arm/boot/dts/am335x-evmsk.dts |7 +++
> arch/arm/boot/dts/am33xx.dtsi | 28
> 4 files changed, 49 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am335x-bone.dts
> b/arch/arm/boot/dts/am335x-bone.dts
> index 5302f79..80bff9c 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -120,6 +120,8 @@
> };
>
> ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
>
> @@ -136,3 +138,8 @@
> _emac1 {
> phy_id = <_mdio>, <1>;
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 0423298..62af561 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -232,6 +232,8 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> @@ -244,3 +246,8 @@
> _emac1 {
> phy_id = <_mdio>, <1>;
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index f67c360..8904b88 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -244,7 +244,14 @@
> };
>
> vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> regulator-always-on;
> };
> };
> };
> +
> + {
> + status = "okay";
> + vmmc-supply = <_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index b4fda12..119f8a9 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -229,6 +229,34 @@
> status = "disabled";
> };
>
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = < 24
> + 25>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
MMC1 also needs "ti,needs-special-hs-handling" dt property to indicate support
for properly supporting SD HS cards.
>From commit
commit cd587096c0e2b85a67e77721a753679bac89b394
mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = < 2
> + 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;
> + status = "disabled";
> + };
> +
> wdt2: wdt@44e35000 {
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> --
> 1.7.9.5
>
> ___
> Davinci-linux-open-source mailing list
> davinci-linux-open-sou...@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
Regards,
Gururaja
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5] mmc: omap_hsmmc: Add reg-offset to bindings documentation
On Wed, Jun 26, 2013 at 06:55:01, Fernandes, Joel wrote: > From: Joel A Fernandes > > A new reg-offset property was added to account for register offsets > in some omap-hsmmc's. Document the new property. > Small nitpick I usually get feedback that any driver DT changes and the associated Binding doc update should come in one single patch for better readability. In this case, I believe it would be patch 1/5 & 5/5 Regards, Gururaja > Signed-off-by: Joel A Fernandes > --- > .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > index 8c8908a..33f4b1e 100644 > --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > @@ -20,6 +20,9 @@ ti,dual-volt: boolean, supports dual voltage cards > ti,non-removable: non-removable slot (like eMMC) > ti,needs-special-reset: Requires a special softreset sequence > ti,needs-special-hs-handling: HSMMC IP needs special setting for handling > High Speed > +reg-offset: Supplementing the common reg property (described in > bindings/mmc/mmc.txt), > +some omap-hsmmc's can start an offset from reg but are otherwise identical > to others. > +The registers between start to offset are considered reserved. > dmas: List of DMA specifiers with the controller specific format > as described in the generic DMA client binding. A tx and rx > specifier is required. > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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] vmpressure: implement strict mode
On Tue, Jun 25, 2013 at 05:51:29PM -0400, Luiz Capitulino wrote: > Currently, applications are notified for the level they registered for > _plus_ higher levels. > > This is a problem if the application wants to implement different > actions for different levels. For example, an application might want > to release 10% of its cache on level low, 50% on medium and 100% on > critical. To do this, the application has to register a different fd > for each event. However, fd low is always going to be notified and > and all fds are going to be notified on level critical. > > Strict mode solves this problem by strictly notifiying the event > an fd has registered for. It's optional. By default we still notify > on higher levels. > > Signed-off-by: Luiz Capitulino In the documentation I would add more information about why exactly the strict mode makes sense. For example, the non-strict fd listener hooked onto the low level makes sense for apps that just monitor reclaiming activity (like current Android Activity Manager), hooking onto 'medium' non-strict mode makes sense for simple load-balancing logic, and the new strict mode is for the cases when an application wants to implement some fancy logic as it makes a decision based on a concrete level. Otherwise, it looks good. Acked-by: Anton Vorontsov Thanks! Anton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/8] minnowboard: Add base platform driver for the MinnowBoard
Hi, On Tue, Jun 25, 2013 at 06:53:24PM -0700, Darren Hart wrote: > The MinnowBoard (http://www.minnowboard.org) is an Intel Atom (E6xx) plus > EG20T > PCH development board. It uses a few GPIO lines for specific purposes and > exposes the rest to the user. > > Request the dedicated GPIO lines: > HWID > LVDS_DETECT > PHY_RESET > LED0 > LED1 > > Setup platform drivers for the MinnowBoard LEDs using the leds-gpio > driver. Setup led0 and led1 with heartbeat and mmc0 default triggers > respectively. > > GPIO lines SUS[0-4] are dual purpose, either for LVDS signaling or as > user GPIO. Determine which via the LVDS_DETECT signal and enable or > disable them accordingly. > > Provide a minimal public interface: > minnow_detect() > minnow_lvds_detect() > minnow_hwid() > minnow_phy_reset() > > Signed-off-by: Darren Hart > Cc: Matthew Garrett > Cc: Grant Likely > Cc: Linus Walleij > Cc: Richard Purdie > Cc: "H. Peter Anvin" > Cc: Peter Waskiewicz > Cc: Andy Shevchenko > Cc: platform-driver-...@vger.kernel.org > --- > drivers/platform/x86/Kconfig| 20 > drivers/platform/x86/Makefile | 1 + > drivers/platform/x86/minnowboard-gpio.h | 60 ++ > drivers/platform/x86/minnowboard.c | 193 > > include/linux/minnowboard.h | 37 ++ > 5 files changed, 311 insertions(+) > create mode 100644 drivers/platform/x86/minnowboard-gpio.h > create mode 100644 drivers/platform/x86/minnowboard.c > create mode 100644 include/linux/minnowboard.h H. x86 boardfiles arriving under drivers/platform. The main concern is that this won't really scale if more vendors add variations of this board -- needing code changes for each and every one of them. Given that it's an open platform encouraging derivatives, that seems like a slippery slope. It's really unfortunate that this information couldn't be passed in from firmware. We've been working so hard for so long on ARM now to move away from board files, it's such a pity to add them on another major platform. > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 8577261..154dbf6 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -15,6 +15,26 @@ menuconfig X86_PLATFORM_DEVICES > > if X86_PLATFORM_DEVICES > > +config MINNOWBOARD > + tristate "MinnowBoard GPIO and LVDS support" > + depends on LPC_SCH > + depends on GPIO_SCH > + depends on GPIO_PCH > + depends on LEDS_GPIO > + default n No need to default n. 'n' is the default default. :) > + ---help--- > + This driver configures the MinnowBoard fixed functionality GPIO lines. > + > + It ensures that the E6XX SUS GPIOs muxed with LVDS signals (SUS[0:2]) > + are disabled if the LVDS_DETECT signal is asserted. > + > + If LED_TRIGGER* are enabled, LED0 will use the heartbeat trigger and > + LED1 will use the mmc0 trigger. > + > + The Minnow Hardware ID is read from the GPIO HWID lines and logged. > + > + If you have a MinnowBoard, say Y or M here. > + > config ACER_WMI > tristate "Acer WMI Laptop Extras" > depends on ACPI > diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile > index ef0ec74..45ede1c 100644 > --- a/drivers/platform/x86/Makefile > +++ b/drivers/platform/x86/Makefile > @@ -2,6 +2,7 @@ > # Makefile for linux/drivers/platform/x86 > # x86 Platform-Specific Drivers > # > +obj-$(CONFIG_MINNOWBOARD)+= minnowboard.o > obj-$(CONFIG_ASUS_LAPTOP)+= asus-laptop.o > obj-$(CONFIG_ASUS_WMI) += asus-wmi.o > obj-$(CONFIG_ASUS_NB_WMI)+= asus-nb-wmi.o > diff --git a/drivers/platform/x86/minnowboard-gpio.h > b/drivers/platform/x86/minnowboard-gpio.h > new file mode 100644 > index 000..ccc8361 > --- /dev/null > +++ b/drivers/platform/x86/minnowboard-gpio.h > @@ -0,0 +1,60 @@ > +/* > + * MinnowBoard Linux platform driver > + * Copyright (c) 2013, Intel Corporation. > + * All rights reserved. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms and conditions of the GNU General Public License, > + * version 2, as published by the Free Software Foundation. > + * > + * This program is distributed in the hope 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. > + * > + * You should have received a copy of the GNU General Public License along > with > + * this program; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Author: Darren Hart > + */ > + > +/* MinnowBoard GPIO definitions */ > +#define GPIO_BTN0 0 > +#define GPIO_BTN1 1 > +#define GPIO_BTN2 2 > +#define GPIO_BTN3 3 > + > +#define
Re: [PATCH] ceph: Reconstruct the func ceph_reserve_caps.
looks good, applied to the testing branch.
thanks!
sage
On Wed, 26 Jun 2013, majianpeng wrote:
> Signed-off-by: Jianpeng Ma
> ---
> fs/ceph/caps.c | 21 +++--
> fs/ceph/super.h | 2 +-
> 2 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
> index da0f9b8..6d2655c 100644
> --- a/fs/ceph/caps.c
> +++ b/fs/ceph/caps.c
> @@ -147,7 +147,7 @@ void ceph_adjust_min_caps(struct ceph_mds_client *mdsc,
> int delta)
> spin_unlock(>caps_list_lock);
> }
>
> -int ceph_reserve_caps(struct ceph_mds_client *mdsc,
> +void ceph_reserve_caps(struct ceph_mds_client *mdsc,
> struct ceph_cap_reservation *ctx, int need)
> {
> int i;
> @@ -155,7 +155,6 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
> int have;
> int alloc = 0;
> LIST_HEAD(newcaps);
> - int ret = 0;
>
> dout("reserve caps ctx=%p need=%d\n", ctx, need);
>
> @@ -174,14 +173,15 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
>
> for (i = have; i < need; i++) {
> cap = kmem_cache_alloc(ceph_cap_cachep, GFP_NOFS);
> - if (!cap) {
> - ret = -ENOMEM;
> - goto out_alloc_count;
> - }
> + if (!cap)
> + break;
> list_add(>caps_item, );
> alloc++;
> }
> - BUG_ON(have + alloc != need);
> + /* we didn't manage to reserve as much as we needed */
> + if (have + alloc != need)
> + pr_warn("reserve caps ctx=%p ENOMEM need=%d got=%d\n",
> + ctx, need, have + alloc);
>
> spin_lock(>caps_list_lock);
> mdsc->caps_total_count += alloc;
> @@ -197,13 +197,6 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
> dout("reserve caps ctx=%p %d = %d used + %d resv + %d avail\n",
>ctx, mdsc->caps_total_count, mdsc->caps_use_count,
>mdsc->caps_reserve_count, mdsc->caps_avail_count);
> - return 0;
> -
> -out_alloc_count:
> - /* we didn't manage to reserve as much as we needed */
> - pr_warning("reserve caps ctx=%p ENOMEM need=%d got=%d\n",
> -ctx, need, have);
> - return ret;
> }
>
> int ceph_unreserve_caps(struct ceph_mds_client *mdsc,
> diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> index 7ccfdb4..dfbb729 100644
> --- a/fs/ceph/super.h
> +++ b/fs/ceph/super.h
> @@ -534,7 +534,7 @@ extern int __ceph_caps_mds_wanted(struct ceph_inode_info
> *ci);
> extern void ceph_caps_init(struct ceph_mds_client *mdsc);
> extern void ceph_caps_finalize(struct ceph_mds_client *mdsc);
> extern void ceph_adjust_min_caps(struct ceph_mds_client *mdsc, int delta);
> -extern int ceph_reserve_caps(struct ceph_mds_client *mdsc,
> +extern void ceph_reserve_caps(struct ceph_mds_client *mdsc,
>struct ceph_cap_reservation *ctx, int need);
> extern int ceph_unreserve_caps(struct ceph_mds_client *mdsc,
> struct ceph_cap_reservation *ctx);
> --
> 1.8.1.2
> Nyb?v?{.n??z??ayj???f:+v??zZ+??"?!?
--
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: [Xen-devel] [PATCH] xen: reuse the same pirq allocated when driver load first time
On 2013-06-26 01:51, Stefano Stabellini wrote:
On Tue, 25 Jun 2013, DuanZhenzhong wrote:
Stefano Stabellini wrote:
Trimming some of the people in CC
On Mon, 24 Jun 2013, Zhenzhong Duan wrote:
On 2013-06-20 22:21, Stefano Stabellini wrote:
On Thu, 20 Jun 2013, Zhenzhong Duan wrote:
On 2013-06-05 20:50, Stefano Stabellini wrote:
On Wed, 5 Jun 2013, Zhenzhong Duan wrote:
Stefano Stabellini wrote:
On Tue, 21 May 2013, Stefano Stabellini wrote:
On Tue, 21 May 2013, Konrad Rzeszutek Wilk wrote:
Looking at the hypervisor code I couldn't see anything
obviously
wrong.
I think the culprit is "physdev_unmap_pirq":
if ( is_hvm_domain(d) )
{
spin_lock(>event_lock);
gdprintk(XENLOG_WARNING,"d%d, pirq: %d is %x %s, irq:
%d\n",
d->domain_id, pirq, domain_pirq_to_emuirq(d, pirq),
domain_pirq_to_emuirq(d, pirq) == IRQ_UNBOUND ?
"unbound" :
"",
domain_pirq_to_irq(d, pirq));
if
( domain_pirq_to_emuirq(d, pirq) != IRQ_UNBOUND )
ret = unmap_domain_pirq_emuirq(d, pirq);
spin_unlock(>event_lock);
if ( domid == DOMID_SELF || ret )
goto free_domain;
It always tells me unbound:
(XEN) physdev.c:237:d14 14, pirq: 54 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 53 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 52 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 51 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(XEN) physdev.c:237:d14 14, pirq: 50 is
(XEN) irq.c:1873:d14 14, nr_pirqs: 56
(a bit older debug code, so the 'unbound' does not show up here).
Which means that the call to unmap_domain_pirq_emuirq does not
happen.
The checks in unmap_domain_pirq_emuirq also look to be depend
on the code being IRQ_UNBOUND.
In other words, all of that code looks to only clear things when
they are !IRQ_UNBOUND.
But the other logic (IRQ_UNBOUND) looks to be missing a removal
in the radix tree:
if ( emuirq != IRQ_PT )
radix_tree_delete(>arch.hvm_domain.emuirq_pirq,
emuirq);
And
I think that is what is causing the leak - the radix tree
needs to be pruned? Or perhaps the allocate_pirq should check
the radix tree for IRQ_UNBOUND ones and re-use them?
I think that you are looking in the wrong place.
The issue is that QEMU doesn't call pt_msi_disable in
pt_msgctrl_reg_write if (!val & PCI_MSI_FLAGS_ENABLE).
The code above is correct as is because it is trying to handle
emulated
IRQs and MSIs, not real passthrough MSIs. They latter are not
added to
that radix tree, see physdev_hvm_map_pirq and physdev_map_pirq.
This patch fixes the issue, I have only tested MSI (MSI-X
completely
untested).
diff --git a/hw/pass-through.c b/hw/pass-through.c
index 304c438..079e465 100644
--- a/hw/pass-through.c
+++ b/hw/pass-through.c
@@ -3866,7 +3866,11 @@ static int pt_msgctrl_reg_write(struct
pt_dev
*ptdev,
ptdev->msi->flags |= PCI_MSI_FLAGS_ENABLE;
}
else
-ptdev->msi->flags &= ~PCI_MSI_FLAGS_ENABLE;
+{
+if (ptdev->msi->flags & PT_MSI_MAPPED) {
+pt_msi_disable(ptdev);
+}
+}
/* pass through MSI_ENABLE bit when no MSI-INTx
translation
*/
if (!ptdev->msi_trans_en) {
@@ -4013,6 +4017,8 @@ static int pt_msixctrl_reg_write(struct
pt_dev
*ptdev,
pt_disable_msi_translate(ptdev);
}
pt_msix_update(ptdev);
+} else if (!(*value & PCI_MSIX_ENABLE) &&
ptdev->msix->enabled) {
+pt_msix_delete(ptdev);
Hi Stefano,
I made a test with this patch, os reboot when driver reload. If
use
pt_msix_disable
instead of pt_msix_delete, driver could be reloaded.
But I still see some error in qemu.log and xen console. Seems four
IRQs
are not freed
when unmap.
--first load---
pt_msix_update_one: pt_msix_update_one requested pirq = 103
pt_msix_update_one: Update msix entry 0 with pirq 67 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 102
pt_msix_update_one: Update msix entry 1 with pirq 66 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 101
pt_msix_update_one: Update msix entry 2 with pirq 65 gvec 0
pt_msix_update_one: pt_msix_update_one requested pirq = 100
pt_msix_update_one: Update msix entry 3 with pirq 64 gvec 0
- first unload---
pt_msix_disable: Unbind msix with pirq 67, gvec 0
pt_msix_disable: Unmap msix with pirq 67
pt_msix_disable: Error: Unmapping of MSI-X failed. [00:04.0]
pt_msix_disable: Unbind msix with pirq 66, gvec 0
pt_msix_disable: Unmap msix with pirq 66
pt_msix_disable: Error: Unmapping of MSI-X failed.
Re: [PATCH 2/8] pch_uart: Add uart_clk selection for the MinnowBoard
On Tue, 2013-06-25 at 20:39 -0700, Greg Kroah-Hartman wrote:
> On Tue, Jun 25, 2013 at 08:16:18PM -0700, Darren Hart wrote:
> > On Tue, 2013-06-25 at 19:31 -0700, Greg Kroah-Hartman wrote:
> > > On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
> > >
> > > > struct pch_uart_buffer {
> > > > unsigned char *buf;
> > > > @@ -398,6 +399,10 @@ static int pch_uart_get_uartclk(void)
> > > > strstr(cmp, "nanoETXexpress-TT")))
> > > > return NTC1_UARTCLK;
> > > >
> > > > + cmp = dmi_get_system_info(DMI_BOARD_NAME);
> > > > + if (cmp && strstr(cmp, "MinnowBoard"))
> > > > + return MINNOW_UARTCLK;
> > > > +
> > >
> > > You know, we do have the DMI interface to handle this in a much nicer
> > > way instead of just randomly trying different strings over and over
> > > until we find one that matches...
> >
> > I was aiming for minimal change. Partly because I'm lazy. Partly
> > because I don't have all of the impacted hardware to test. Partly
> > because I wanted to keep it simple so I could push this to 3.8 stable.
>
> Then you should have marked it for the stable tree by putting the proper
> Cc: in the body of the patch...
I had expected there to be some discussion on this series as a whole
and didn't want to confuse things... I suppose that was silly as the
patch will just whither and die if it never makes it into mainline.
Apologies.
>
> > I can rewrite this detection to use the DMI interface. Would you allow
> > it as a follow-on, to keep the changes to stable minimal?
> >
> > Also, I do have a PCI subsystem ID for this particular board which I
> > could trigger on, but since that mechanism didn't exist in the driver
> > already and the other boards don't do it, I just followed what was
> > already there (yeah, so I wrote most of what was already there...
> > but anyway) :-)
> >
> > What do you prefer? Rewrite, then add Minnow, or use this, then
> > rewrite?
>
> How about this, which makes it easy to backport, then you fix it up
> properly for 3.12? This comes after my tree is pretty much closed for
> 3.11, but a simple device id addition like this is acceptable, but I'll
> not get to it until after 3.11-rc1 is out...
Sure. So something like this is what you have in mind? Build tested
only, I'll include it in V2 with proper testing, but just wanted to
make sure we're on the same page while I have your attention:
>From 22cb21e2421ffcd439f58843422cff0e2579902f Mon Sep 17 00:00:00 2001
Message-Id:
<22cb21e2421ffcd439f58843422cff0e2579902f.1372219079.git.dvh...@linux.intel.com>
From: Darren Hart
Date: Tue, 25 Jun 2013 20:54:29 -0700
Subject: [PATCH] pch_uart: Use DMI interface for board detection
Use the DMI interface rather than manually matching DMI strings.
Signed-off-by: Darren Hart
---
drivers/tty/serial/pch_uart.c | 71
+--
1 file changed, 49 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c
b/drivers/tty/serial/pch_uart.c
index 572d481..271cc73 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -373,35 +373,62 @@ static const struct file_operations port_regs_ops
= {
};
#endif /* CONFIG_DEBUG_FS */
+static struct dmi_system_id __initdata pch_uart_dmi_table[] = {
+ {
+ .ident = "CM-iTC",
+ {
+ DMI_MATCH(DMI_BOARD_NAME, "CM-iTC"),
+ },
+ (void *)CMITC_UARTCLK,
+ },
+ {
+ .ident = "FRI2",
+ {
+ DMI_MATCH(DMI_BIOS_VERSION, "FRI2"),
+ },
+ (void *)FRI2_64_UARTCLK,
+ },
+ {
+ .ident = "Fish River Island II",
+ {
+ DMI_MATCH(DMI_PRODUCT_NAME, "Fish River Island II"),
+ },
+ (void *)FRI2_48_UARTCLK,
+ },
+ {
+ .ident = "COMe-mTT",
+ {
+ DMI_MATCH(DMI_BOARD_NAME, "COMe-mTT"),
+ },
+ (void *)NTC1_UARTCLK,
+ },
+ {
+ .ident = "nanoETXexpress-TT",
+ {
+ DMI_MATCH(DMI_BOARD_NAME, "nanoETXexpress-TT"),
+ },
+ (void *)NTC1_UARTCLK,
+ },
+ {
+ .ident = "MinnowBoard",
+ {
+ DMI_MATCH(DMI_BOARD_NAME, "MinnowBoard"),
+ },
+ (void *)MINNOW_UARTCLK,
+ },
+};
+
/* Return UART clock, checking for board specific clocks. */
static int pch_uart_get_uartclk(void)
{
- const char *cmp;
+ const struct dmi_system_id *d;
if (user_uartclk)
return user_uartclk;
- cmp = dmi_get_system_info(DMI_BOARD_NAME);
- if (cmp && strstr(cmp, "CM-iTC"))
- return CMITC_UARTCLK;
-
- cmp = dmi_get_system_info(DMI_BIOS_VERSION);
- if (cmp &&
[PATCH] driver core: device.h: fix doc compilation warnings
This patch fixes the below 3 warnings running "make htmldocs",
by adding descriptions for recently added structure members:
DOCPROC Documentation/DocBook/device-drivers.xml
Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:116):
No description found for parameter 'lock_key'
Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723):
No description found for parameter 'cma_area'
Warning(/work/git.free-electrons.com/users/michael-opdenacker/linux//include/linux/device.h:723):
No description found for parameter 'iommu_group'
Don't hesitate to propose better descriptions!
Signed-off-by: Michael Opdenacker
---
include/linux/device.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index c0a1261..9d4835a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -80,6 +80,7 @@ extern void bus_remove_file(struct bus_type *, struct
bus_attribute *);
* bus-specific setup
* @p: The private data of the driver core, only the driver core can
* touch this.
+ * @lock_key: Lock class key for use by the lock validator
*
* A bus is a channel between the processor and one or more devices. For the
* purposes of the device model, all devices are connected via a bus, even if
@@ -635,6 +636,7 @@ struct acpi_dev_node {
* segment limitations.
* @dma_pools: Dma pools (if dma'ble device).
* @dma_mem: Internal for coherent mem override.
+ * @cma_area: Contiguous memory area for dma allocations
* @archdata: For arch-specific additions.
* @of_node: Associated device tree node.
* @acpi_node: Associated ACPI device node.
@@ -648,6 +650,7 @@ struct acpi_dev_node {
* @release: Callback to free the device after all references have
* gone away. This should be set by the allocator of the
* device (i.e. the bus driver that discovered the device).
+ * @iommu_group: IOMMU group the device belongs to.
*
* At the lowest level, every device in a Linux system is represented by an
* instance of struct device. The device structure contains the information
--
1.8.1.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/
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commits 2d05eae1c92f
("drm/i915: Propagate errors back from fb set-base") and d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and commits 6c49f24180c3 ("drm/i915: hw state readout support
for pixel_multiplier") and 9222be993921 ("drm/i915: don't scream into
dmesg when a modeset fails") from the drm-intel tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 6eb99e1,8f746d9..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -8177,11 -8264,14 +8264,19 @@@ check_crtc_state(struct drm_device *dev
active = dev_priv->display.get_pipe_config(crtc,
_config);
+
+ /* hw state is inconsistent with the pipe A quirk */
+ if (crtc->pipe == PIPE_A && dev_priv->quirks &
QUIRK_PIPEA_FORCE)
+ active = crtc->active;
+
+ list_for_each_entry(encoder, >mode_config.encoder_list,
+ base.head) {
+ if (encoder->base.crtc != >base)
+ continue;
+ if (encoder->get_config)
+ encoder->get_config(encoder, _config);
+ }
+
WARN(crtc->active != active,
"crtc active state doesn't match with hw state "
"(expected %i, found %i)\n", crtc->active, active);
pgp6fSGpwPm1z.pgp
Description: PGP signature
Re: [PATCH 2/8] pch_uart: Add uart_clk selection for the MinnowBoard
On Tue, Jun 25, 2013 at 08:16:18PM -0700, Darren Hart wrote:
> On Tue, 2013-06-25 at 19:31 -0700, Greg Kroah-Hartman wrote:
> > On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
> >
> > > struct pch_uart_buffer {
> > > unsigned char *buf;
> > > @@ -398,6 +399,10 @@ static int pch_uart_get_uartclk(void)
> > > strstr(cmp, "nanoETXexpress-TT")))
> > > return NTC1_UARTCLK;
> > >
> > > + cmp = dmi_get_system_info(DMI_BOARD_NAME);
> > > + if (cmp && strstr(cmp, "MinnowBoard"))
> > > + return MINNOW_UARTCLK;
> > > +
> >
> > You know, we do have the DMI interface to handle this in a much nicer
> > way instead of just randomly trying different strings over and over
> > until we find one that matches...
>
> I was aiming for minimal change. Partly because I'm lazy. Partly
> because I don't have all of the impacted hardware to test. Partly
> because I wanted to keep it simple so I could push this to 3.8 stable.
Then you should have marked it for the stable tree by putting the proper
Cc: in the body of the patch...
> I can rewrite this detection to use the DMI interface. Would you allow
> it as a follow-on, to keep the changes to stable minimal?
>
> Also, I do have a PCI subsystem ID for this particular board which I
> could trigger on, but since that mechanism didn't exist in the driver
> already and the other boards don't do it, I just followed what was
> already there (yeah, so I wrote most of what was already there...
> but anyway) :-)
>
> What do you prefer? Rewrite, then add Minnow, or use this, then
> rewrite?
How about this, which makes it easy to backport, then you fix it up
properly for 3.12? This comes after my tree is pretty much closed for
3.11, but a simple device id addition like this is acceptable, but I'll
not get to it until after 3.11-rc1 is out...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/27] 3.4.51-stable review
On Tue, Jun 25, 2013 at 12:39:25PM -0700, Guenter Roeck wrote: > On Tue, Jun 25, 2013 at 11:35:19AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.4.51 release. > > There are 27 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 27 18:33:29 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.51-rc1.gz > > and the diffstat can be found below. > > > Build results are as follows. Most failures are due to > > bonding: rlb mode of bond should not alter ARP originating via bridge Thanks for testing, hopefully we get that straightened out soon... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/95] 3.9.8-stable review
On Tue, Jun 25, 2013 at 07:58:38PM -0700, Guenter Roeck wrote: > On Tue, Jun 25, 2013 at 11:31:47AM -0700, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.9.8 release. > > There are 95 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Jun 27 18:18:29 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.8-rc1.gz > > and the diffstat can be found below. > > > Build results are as follows. Same as with 3.9.7. Thanks for testing and letting us know. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] pch_gbe: Add MinnowBoard support
The same subsystem (not subdevice!) ID is used for all devices on the
Minnowboard itself.
Bjorn Helgaas wrote:
>On Tue, Jun 25, 2013 at 7:53 PM, Darren Hart
>wrote:
>> The MinnowBoard uses an AR803x PHY with the PCH GBE.
>>
>> It does not implement the RGMII 2ns TX clock delay in the trace
>routing
>> nor via strapping. Add a detection method for the board and the PHY
>and
>> enable the tx clock delay via the registers.
>>
>> This PHY will hibernate without link for 10 seconds. Ensure the PHY
>is
>> awake for probe and then disable hibernation. A future improvement
>would
>> be to convert pch_gbe to using PHYLIB and making sure we can wake the
>> PHY at the necessary times rather than permanently disabling it.
>>
>> Use the MinnowBoard PCI subsystem ID to identify the board and setup
>the
>> appropriate callbacks in a new pci_id driver_data structure.
>>
>> Signed-off-by: Darren Hart
>> Cc: "David S. Miller"
>> Cc: "H. Peter Anvin"
>> Cc: Peter Waskiewicz
>> Cc: Andy Shevchenko
>> Cc: net...@vger.kernel.org
>> ---
>> drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 1 +
>> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h| 2 +
>> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 32
>> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.c| 89
>++
>> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.h| 2 +
>> 5 files changed, 126 insertions(+)
>> ...
>
>> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
>b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
>> index 6667a6b..6f0b9e3 100644
>> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
>> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
>>...
>> +static struct pch_gbe_privdata pch_gbe_minnowboard_privdata = {
>> + .phy_reset = minnow_phy_reset,
>> + .phy_tx_clk_delay = pch_gbe_phy_tx_clk_delay,
>> +};
>> +
>> static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
>> {.vendor = PCI_VENDOR_ID_INTEL,
>> .device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
>> +.subvendor = PCI_VENDOR_ID_CIRCUITCO,
>> +.subdevice = PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD,
>
>"MINNOWBOARD" seems like a pretty generic name for something that
>probably refers only to the gigabit ethernet device in the EG20T. If
>you expect to use that same subdevice ID on other devices, I guess we
>can add PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD to pci_ids.h. If it will
>only be used for the gigabit ethernet device, we would normally not
>add a #define for it and would just use the hex constant here (see the
>comment at the top of pci_ids.h).
>
>> +.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
>> +.class_mask = (0x00),
>> +.driver_data = (unsigned long) _gbe_minnowboard_privdata
>> +},
>> + {.vendor = PCI_VENDOR_ID_INTEL,
>> +.device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
>> .subvendor = PCI_ANY_ID,
>> .subdevice = PCI_ANY_ID,
>> .class = (PCI_CLASS_NETWORK_ETHERNET << 8),
--
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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] vmpressure: implement strict mode
On Wed, 26 Jun 2013 10:12:15 +0900 Hyunhee Kim wrote: > Please see "[PATCH v3] memcg: event control at vmpressure". mail > thread. (and also the thread I sent last Saturday.) > There was discussion on this mode not sending lower events when "level > != ev->level". The new argument this patch adds should be orthogonal to what has been discussed and suggested in that thread. The patches conflict though, but it's just a matter of rebasing if both are ACKed. -- 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/8] pch_uart: Add uart_clk selection for the MinnowBoard
On Tue, 2013-06-25 at 19:31 -0700, Greg Kroah-Hartman wrote:
> On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
>
> > struct pch_uart_buffer {
> > unsigned char *buf;
> > @@ -398,6 +399,10 @@ static int pch_uart_get_uartclk(void)
> > strstr(cmp, "nanoETXexpress-TT")))
> > return NTC1_UARTCLK;
> >
> > + cmp = dmi_get_system_info(DMI_BOARD_NAME);
> > + if (cmp && strstr(cmp, "MinnowBoard"))
> > + return MINNOW_UARTCLK;
> > +
>
> You know, we do have the DMI interface to handle this in a much nicer
> way instead of just randomly trying different strings over and over
> until we find one that matches...
I was aiming for minimal change. Partly because I'm lazy. Partly
because I don't have all of the impacted hardware to test. Partly
because I wanted to keep it simple so I could push this to 3.8 stable.
I can rewrite this detection to use the DMI interface. Would you allow
it as a follow-on, to keep the changes to stable minimal?
Also, I do have a PCI subsystem ID for this particular board which I
could trigger on, but since that mechanism didn't exist in the driver
already and the other boards don't do it, I just followed what was
already there (yeah, so I wrote most of what was already there...
but anyway) :-)
What do you prefer? Rewrite, then add Minnow, or use this, then
rewrite?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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] ceph: Reconstruct the func ceph_reserve_caps.
Signed-off-by: Jianpeng Ma
---
fs/ceph/caps.c | 21 +++--
fs/ceph/super.h | 2 +-
2 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index da0f9b8..6d2655c 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -147,7 +147,7 @@ void ceph_adjust_min_caps(struct ceph_mds_client *mdsc, int
delta)
spin_unlock(>caps_list_lock);
}
-int ceph_reserve_caps(struct ceph_mds_client *mdsc,
+void ceph_reserve_caps(struct ceph_mds_client *mdsc,
struct ceph_cap_reservation *ctx, int need)
{
int i;
@@ -155,7 +155,6 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
int have;
int alloc = 0;
LIST_HEAD(newcaps);
- int ret = 0;
dout("reserve caps ctx=%p need=%d\n", ctx, need);
@@ -174,14 +173,15 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
for (i = have; i < need; i++) {
cap = kmem_cache_alloc(ceph_cap_cachep, GFP_NOFS);
- if (!cap) {
- ret = -ENOMEM;
- goto out_alloc_count;
- }
+ if (!cap)
+ break;
list_add(>caps_item, );
alloc++;
}
- BUG_ON(have + alloc != need);
+ /* we didn't manage to reserve as much as we needed */
+ if (have + alloc != need)
+ pr_warn("reserve caps ctx=%p ENOMEM need=%d got=%d\n",
+ ctx, need, have + alloc);
spin_lock(>caps_list_lock);
mdsc->caps_total_count += alloc;
@@ -197,13 +197,6 @@ int ceph_reserve_caps(struct ceph_mds_client *mdsc,
dout("reserve caps ctx=%p %d = %d used + %d resv + %d avail\n",
ctx, mdsc->caps_total_count, mdsc->caps_use_count,
mdsc->caps_reserve_count, mdsc->caps_avail_count);
- return 0;
-
-out_alloc_count:
- /* we didn't manage to reserve as much as we needed */
- pr_warning("reserve caps ctx=%p ENOMEM need=%d got=%d\n",
- ctx, need, have);
- return ret;
}
int ceph_unreserve_caps(struct ceph_mds_client *mdsc,
diff --git a/fs/ceph/super.h b/fs/ceph/super.h
index 7ccfdb4..dfbb729 100644
--- a/fs/ceph/super.h
+++ b/fs/ceph/super.h
@@ -534,7 +534,7 @@ extern int __ceph_caps_mds_wanted(struct ceph_inode_info
*ci);
extern void ceph_caps_init(struct ceph_mds_client *mdsc);
extern void ceph_caps_finalize(struct ceph_mds_client *mdsc);
extern void ceph_adjust_min_caps(struct ceph_mds_client *mdsc, int delta);
-extern int ceph_reserve_caps(struct ceph_mds_client *mdsc,
+extern void ceph_reserve_caps(struct ceph_mds_client *mdsc,
struct ceph_cap_reservation *ctx, int need);
extern int ceph_unreserve_caps(struct ceph_mds_client *mdsc,
struct ceph_cap_reservation *ctx);
--
1.8.1.2
Re: [PATCH 8/8] pch_gbe: Add MinnowBoard support
On Tue, 2013-06-25 at 20:35 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 25, 2013 at 7:53 PM, Darren Hart wrote:
> > static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
> > {.vendor = PCI_VENDOR_ID_INTEL,
> > .device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
> > +.subvendor = PCI_VENDOR_ID_CIRCUITCO,
> > +.subdevice = PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD,
>
> "MINNOWBOARD" seems like a pretty generic name for something that
> probably refers only to the gigabit ethernet device in the EG20T. If
> you expect to use that same subdevice ID on other devices, I guess we
> can add PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD to pci_ids.h. If it will
> only be used for the gigabit ethernet device, we would normally not
> add a #define for it and would just use the hex constant here (see the
> comment at the top of pci_ids.h).
The firmware populates the subsystem vendor and device ID for every
device on the PCH with PCI_VENDOR_ID_CIRCUITCO and
PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD, respectively. Currently I have
only made changes to pch_gbe to make use of it, but there is the
possibility of using this ID elsewhere. I don't currently have plans to
do so however. So if it is preferable, I can leave
PCI_VENDOR_ID_CIRCUITCO in pci_ids.h and use 0x0001 here for the
subsystem device ID.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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 pm tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
fs/select.c between commit 9745cdb36da8 ("select: use freezable blocking
call") from the pm tree and commit 2d48d67fa8cd ("net: poll/select low
latency socket support") 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 fs/select.c
index 6b14dc7,79b876e..000
--- a/fs/select.c
+++ b/fs/select.c
@@@ -27,7 -27,7 +27,8 @@@
#include
#include
#include
+#include
+ #include
#include
pgp8NSddAQ7CX.pgp
Description: PGP signature
Re: SATA hdd refuses to reallocate a sector?
On Mon, 2013-06-24 at 08:18 -0400, Mark Lord wrote: > And the SCSI stack in Linux has rather atrocious error handling. > It lumps multiple requests together, and can fail the entire lot even > if only a single sector is bad. That's rather misleading. SCSI doesn't lump anything together; it handles the requests it was passed. For reads and writes through the page cache, block will aggregate in the elevators, but you avoid that by not using the page cache (O_DIRECT or SG_IO). For devices which report failing sectors correctly data up to the failed sector is returned and the request is shortened and retried from the failed sector on. If we get a second failure at the beginning (where the previous bad sector was), then we give up. James -- 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, part2 15/20] PCI, EDAC: use hotplug-safe PCI bus iterators to walk PCI buses
On Tue, Jun 18, 2013 at 10:33 AM, Jiang Liu wrote:
> On 06/18/2013 04:18 AM, Bjorn Helgaas wrote:
>> On Sun, May 26, 2013 at 11:53:12PM +0800, Jiang Liu wrote:
>>> Enhance EDAC drviers to use hotplug-safe iterators to walk PCI buses.
>>>
>>> Signed-off-by: Jiang Liu
>>> Cc: Mauro Carvalho Chehab
>>> Cc: Doug Thompson r
>>> Cc: linux-e...@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> ---
>>> drivers/edac/i7core_edac.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/edac/i7core_edac.c b/drivers/edac/i7core_edac.c
>>> index 0ec3e95..7146e10 100644
>>> --- a/drivers/edac/i7core_edac.c
>>> +++ b/drivers/edac/i7core_edac.c
>>> @@ -1296,7 +1296,7 @@ static unsigned i7core_pci_lastbus(void)
>>> int last_bus = 0, bus;
>>> struct pci_bus *b = NULL;
>>>
>>> -while ((b = pci_find_next_bus(b)) != NULL) {
>>> +for_each_pci_root_bus(b) {
>>
>> This doesn't look equivalent. Previously, we iterated over all PCI
>> buses, so we returned the highest bus number seen anywhere. Now we
>> only look at root buses, so we return the highest bus number of any
>> root bus. But if that root bus has a bridge on it, obviously the
>> bus on the other side has a higher number.
> Hi Bjorn,
> I think the name pci_find_next_bus() is misleading, it should be named
> pci_find_next_root_bus() actually because it returns next root bus indeed.
Oh, you forgot to mention that critical bit of information! That
should be in the changelog of every patch that changes a call to
pci_find_next_bus().
Bjorn
--
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, part2 01/20] PCI: introduce hotplug-safe PCI bus iterators
On Thu, Jun 20, 2013 at 10:18 AM, Jiang Liu wrote: > On 06/18/2013 04:06 AM, Bjorn Helgaas wrote: >> On Sun, May 26, 2013 at 11:52:58PM +0800, Jiang Liu wrote: >>> Introduce hotplug-safe PCI bus iterators as below, which hold a >>> reference on the returned PCI bus object. >>> bool pci_bus_exists(int domain, int busnr); >>> struct pci_bus *pci_get_bus(int domain, int busnr); >>> struct pci_bus *pci_get_next_bus(struct pci_bus *from); >>> struct pci_bus *pci_get_next_root_bus(struct pci_bus *from); >>> #define for_each_pci_bus(b) for (b = NULL; (b = pci_get_next_bus(b)); ) >>> #define for_each_pci_root_bus(b) \ >>> for (b = NULL; (b = pci_get_next_root_bus(b)); ) >>> >>> The long-term goal is to remove hotplug-unsafe pci_find_bus(), >>> pci_find_next_bus() and the global pci_root_buses list. >> >> I think you should mark the unsafe interfaces as __deprecated so >> users will get compile-time warnings. >> >> I don't think pci_bus_exists() is a safe interface, because the value >> it returns may be incorrect before the caller can look at it. The >> only safe thing would be to make it so we try to create the bus >> and return failure if it already exists. Then the mutex can be in >> the code that creates the bus. >> >> I don't see any uses of for_each_pci_bus(), so please remove that. >> >> It sounds like we don't have a consensus on how to iterate over >> PCI root buses. If you separate that from the pci_get_bus() >> changes, maybe we can at least move forward on the pci_get_bus() >> stuff. > Hi Bjorn and Yinghai, > I have thought about the way to implement pci_for_each_root_bus() > again. And there are several possible ways here: > 1) Yinghai has a patch set implementing an iterator for PCI host > bridges, but we can't safely refer the PCI root bus associated with a > host bridge device because the host bridge doesn't hold a reference to > associated PCI root bus. So we need to find a safe way to refer the PCI > root bus associated with a PCI host bridge. > 2) Unexport pci_root_buses and convert it to klist, then we could walk > all root buses effectively. This solution is straight-forward, but it > may break out of tree drivers. > 3) Keep current implementation, which does waste some computation cycles:( > > So what's your thoughts about above solutions? Or any other suggestions? > Regards! > Gerry Iteration is generally the wrong approach because it doesn't fit well with hot plug. I recognize that it may be impossible to fix all the places that currently iterate over root buses, so we may have to accept iteration at least in the short term. Sometimes when we fix the things we *know* how to fix, it makes it easier to see how to fix the hard problem. Your pci_bus ref counting fixes seem like a clear step forward, and I'd like to get them in ASAP, even if the root bus iteration isn't figured out yet. So my advice is, let's do the simple stuff we know how to do now, then worry about the harder stuff later. Bjorn -- 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: [ 00/95] 3.9.8-stable review
On Tue, Jun 25, 2013 at 11:31:47AM -0700, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.9.8 release. > There are 95 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Thu Jun 27 18:18:29 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.9.8-rc1.gz > and the diffstat can be found below. > Build results are as follows. Same as with 3.9.7. Guenter --- Build reference: v3.9.7-95-g6a2f14b Build x86_64:defconfig passed Build x86_64:allyesconfig passed Build x86_64:allmodconfig passed Build x86_64:allnoconfig passed Build x86_64:alldefconfig passed Build i386:defconfig passed Build i386:allyesconfig passed Build i386:allmodconfig passed Build i386:allnoconfig passed Build i386:alldefconfig passed Build mips:defconfig passed Build mips:bcm47xx_defconfig passed Build mips:bcm63xx_defconfig passed Build mips:nlm_xlp_defconfig passed Build mips:ath79_defconfig passed Build mips:ar7_defconfig passed Build mips:fuloong2e_defconfig passed Build mips:e55_defconfig passed Build mips:cavium_octeon_defconfig passed Build mips:powertv_defconfig passed Build mips:malta_defconfig passed Build powerpc:defconfig passed Build powerpc:allyesconfig failed Build powerpc:allmodconfig passed Build powerpc:chroma_defconfig passed Build powerpc:maple_defconfig passed Build powerpc:ppc6xx_defconfig passed Build powerpc:mpc83xx_defconfig passed Build powerpc:mpc85xx_defconfig passed Build powerpc:mpc85xx_smp_defconfig passed Build powerpc:tqm8xx_defconfig passed Build powerpc:85xx/sbc8548_defconfig passed Build powerpc:83xx/mpc834x_mds_defconfig passed Build powerpc:86xx/sbc8641d_defconfig passed Build arm:defconfig passed Build arm:allyesconfig failed Build arm:allmodconfig failed Build arm:exynos4_defconfig passed Build arm:multi_v7_defconfig passed Build arm:kirkwood_defconfig passed Build arm:omap2plus_defconfig passed Build arm:tegra_defconfig passed Build arm:u8500_defconfig passed Build arm:at91sam9rl_defconfig passed Build arm:ap4evb_defconfig passed Build arm:bcm_defconfig passed Build arm:bonito_defconfig passed Build arm:pxa910_defconfig passed Build arm:mvebu_defconfig passed Build m68k:defconfig passed Build m68k:m5272c3_defconfig failed Build m68k:m5307c3_defconfig passed Build m68k:m5249evb_defconfig passed Build m68k:m5407c3_defconfig passed Build m68k:sun3_defconfig passed Build m68k:mvme16x_defconfig passed Build sparc:defconfig passed Build sparc:sparc64_defconfig passed Build xtensa:defconfig passed Build xtensa:iss_defconfig passed Build microblaze:mmu_defconfig passed Build microblaze:nommu_defconfig passed Build blackfin:defconfig passed Build parisc:defconfig passed --- Total builds: 64 Total build errors: 4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] perf tools: Introduce new -P/--parent-deep report option
Hi Jiri, On Tue, 25 Jun 2013 13:54:12 +0200, Jiri Olsa wrote: > Introducing new -P/--parent-deep report option. It does the > same as '-p' but it force the deep search of the callchain > and looks for the deepest possible match. > > The -p option searches for the first match of the parent > pattern in the callchain. > > $ perf report -i perf.data.delete -p perf_session__delete -s parent > > + 99.51% [other] > + 0.46% perf_session__delete_dead_threads > + 0.03% perf_session__delete > + 0.00% perf_session__delete_threads > > so we got multiple 'different' matches instancies, while > they all belong under perf_session__delete function: > > $ perf report -i perf.data.delete -P perf_session__delete -s parent > > + 99.51% [other] > + 0.49% perf_session__delete > > NOTE the 'p' vs 'P' difference in above commands above. I guess using --inverted (-G) option with -p does the job. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[05/26] KVM: x86: remove vcpu's CPL check in host-invoked XCR set
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: "Zhanghaoyu (A)"
commit 764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346 upstream.
__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is
called in two flows, one is invoked by guest, call stack shown as below,
handle_xsetbv(or xsetbv_interception)
kvm_set_xcr
__kvm_set_xcr
the other one is invoked by host, for example during system reset:
kvm_arch_vcpu_ioctl
kvm_vcpu_ioctl_x86_set_xcrs
__kvm_set_xcr
The former does need the CPL check, but the latter does not.
Signed-off-by: Zhang Haoyu
[Tweaks to commit message. - Paolo]
Signed-off-by: Paolo Bonzini
Signed-off-by: Ben Hutchings
---
arch/x86/kvm/x86.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -551,8 +551,6 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
if (index != XCR_XFEATURE_ENABLED_MASK)
return 1;
xcr0 = xcr;
- if (kvm_x86_ops->get_cpl(vcpu) != 0)
- return 1;
if (!(xcr0 & XSTATE_FP))
return 1;
if ((xcr0 & XSTATE_YMM) && !(xcr0 & XSTATE_SSE))
@@ -566,7 +564,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu,
int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
{
- if (__kvm_set_xcr(vcpu, index, xcr)) {
+ if (kvm_x86_ops->get_cpl(vcpu) != 0 ||
+ __kvm_set_xcr(vcpu, index, xcr)) {
kvm_inject_gp(vcpu, 0);
return 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/
[23/26] packet: packet_getname_spkt: make sure string is always 0-terminated
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Daniel Borkmann [ Upstream commit 2dc85bf323515e59e15dfa858d1472bb25cad0fe ] uaddr->sa_data is exactly of size 14, which is hard-coded here and passed as a size argument to strncpy(). A device name can be of size IFNAMSIZ (== 16), meaning we might leave the destination string unterminated. Thus, use strlcpy() and also sizeof() while we're at it. We need to memset the data area beforehand, since strlcpy does not padd the remaining buffer with zeroes for user space, so that we do not possibly leak anything. Signed-off-by: Daniel Borkmann Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/packet/af_packet.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index 5a70215..a2ac2c3 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2820,12 +2820,11 @@ static int packet_getname_spkt(struct socket *sock, struct sockaddr *uaddr, return -EOPNOTSUPP; uaddr->sa_family = AF_PACKET; + memset(uaddr->sa_data, 0, sizeof(uaddr->sa_data)); rcu_read_lock(); dev = dev_get_by_index_rcu(sock_net(sk), pkt_sk(sk)->ifindex); if (dev) - strncpy(uaddr->sa_data, dev->name, 14); - else - memset(uaddr->sa_data, 0, 14); + strlcpy(uaddr->sa_data, dev->name, sizeof(uaddr->sa_data)); rcu_read_unlock(); *uaddr_len = sizeof(*uaddr); -- 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/
[03/26] ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 36691e1be6ec551eef4a5225f126a281f8c051c2 upstream. Just like the previous fix for LogitechHD Webcam c270 in commit 11e7064f35bb87da8f427d1aa4bbd8b7473a3993, c310 model also requires the same workaround for avoiding the kernel warning. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59741 Signed-off-by: Takashi Iwai Signed-off-by: Ben Hutchings --- sound/usb/mixer.c |1 + 1 file changed, 1 insertion(+) --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -821,6 +821,7 @@ static void volume_control_quirks(struct case USB_ID(0x046d, 0x0808): case USB_ID(0x046d, 0x0809): + case USB_ID(0x046d, 0x081b): /* HD Webcam c310 */ case USB_ID(0x046d, 0x081d): /* HD Webcam c510 */ case USB_ID(0x046d, 0x0825): /* HD Webcam c270 */ case USB_ID(0x046d, 0x0991): -- 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/
[12/26] tcp: fix tcp_md5_hash_skb_data()
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e ]
TCP md5 communications fail [1] for some devices, because sg/crypto code
assume page offsets are below PAGE_SIZE.
This was discovered using mlx4 driver [2], but I suspect loopback
might trigger the same bug now we use order-3 pages in tcp_sendmsg()
[1] Failure is giving following messages.
huh, entered softirq 3 NET_RX 806ad230 preempt_count 0100,
exited with 0101?
[2] mlx4 driver uses order-2 pages to allocate RX frags
Reported-by: Matt Schnall
Signed-off-by: Eric Dumazet
Cc: Bernhard Beck
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/tcp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index fe381c2..ec8b4b7e 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3037,8 +3037,11 @@ int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *hp,
for (i = 0; i < shi->nr_frags; ++i) {
const struct skb_frag_struct *f = >frags[i];
- struct page *page = skb_frag_page(f);
- sg_set_page(, page, skb_frag_size(f), f->page_offset);
+ unsigned int offset = f->page_offset;
+ struct page *page = skb_frag_page(f) + (offset >> PAGE_SHIFT);
+
+ sg_set_page(, page, skb_frag_size(f),
+ offset_in_page(offset));
if (crypto_hash_update(desc, , skb_frag_size(f)))
return 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/
[15/26] netlabel: improve domain mapping validation
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Paul Moore
[ Upstream commit 6b21e1b77d1a3d58ebfd513264c885695e8a0ba5 ]
The net/netlabel/netlabel_domainhash.c:netlbl_domhsh_add() function
does not properly validate new domain hash entries resulting in
potential problems when an administrator attempts to add an invalid
entry. One such problem, as reported by Vlad Halilov, is a kernel
BUG (found in netlabel_domainhash.c:netlbl_domhsh_audit_add()) when
adding an IPv6 outbound mapping with a CIPSO configuration.
This patch corrects this problem by adding the necessary validation
code to netlbl_domhsh_add() via the newly created
netlbl_domhsh_validate() function.
Ideally this patch should also be pushed to the currently active
-stable trees.
Reported-by: Vlad Halilov
Signed-off-by: Paul Moore
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/netlabel/netlabel_domainhash.c | 69 ++
1 file changed, 69 insertions(+)
diff --git a/net/netlabel/netlabel_domainhash.c
b/net/netlabel/netlabel_domainhash.c
index e5330ed..bf99567 100644
--- a/net/netlabel/netlabel_domainhash.c
+++ b/net/netlabel/netlabel_domainhash.c
@@ -245,6 +245,71 @@ static void netlbl_domhsh_audit_add(struct netlbl_dom_map
*entry,
}
}
+/**
+ * netlbl_domhsh_validate - Validate a new domain mapping entry
+ * @entry: the entry to validate
+ *
+ * This function validates the new domain mapping entry to ensure that it is
+ * a valid entry. Returns zero on success, negative values on failure.
+ *
+ */
+static int netlbl_domhsh_validate(const struct netlbl_dom_map *entry)
+{
+ struct netlbl_af4list *iter4;
+ struct netlbl_domaddr4_map *map4;
+#if IS_ENABLED(CONFIG_IPV6)
+ struct netlbl_af6list *iter6;
+ struct netlbl_domaddr6_map *map6;
+#endif /* IPv6 */
+
+ if (entry == NULL)
+ return -EINVAL;
+
+ switch (entry->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ if (entry->type_def.cipsov4 != NULL ||
+ entry->type_def.addrsel != NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_CIPSOV4:
+ if (entry->type_def.cipsov4 == NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_ADDRSELECT:
+ netlbl_af4list_foreach(iter4, >type_def.addrsel->list4) {
+ map4 = netlbl_domhsh_addr4_entry(iter4);
+ switch (map4->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ if (map4->type_def.cipsov4 != NULL)
+ return -EINVAL;
+ break;
+ case NETLBL_NLTYPE_CIPSOV4:
+ if (map4->type_def.cipsov4 == NULL)
+ return -EINVAL;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+#if IS_ENABLED(CONFIG_IPV6)
+ netlbl_af6list_foreach(iter6, >type_def.addrsel->list6) {
+ map6 = netlbl_domhsh_addr6_entry(iter6);
+ switch (map6->type) {
+ case NETLBL_NLTYPE_UNLABELED:
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+#endif /* IPv6 */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/*
* Domain Hash Table Functions
*/
@@ -311,6 +376,10 @@ int netlbl_domhsh_add(struct netlbl_dom_map *entry,
struct netlbl_af6list *tmp6;
#endif /* IPv6 */
+ ret_val = netlbl_domhsh_validate(entry);
+ if (ret_val != 0)
+ return ret_val;
+
/* XXX - we can remove this RCU read lock as the spinlock protects the
* entire function, but before we do we need to fixup the
* netlbl_af[4,6]list RCU functions to do "the right thing" with
--
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/
[24/26] l2tp: Fix PPP header erasure and memory leak
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Guillaume Nault
[ Upstream commit 55b92b7a11690bc377b5d373872a6b650ae88e64 ]
Copy user data after PPP framing header. This prevents erasure of the
added PPP header and avoids leaking two bytes of uninitialised memory
at the end of skb's data buffer.
Signed-off-by: Guillaume Nault
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/l2tp/l2tp_ppp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 6f60175..8ab041b 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -350,12 +350,12 @@ static int pppol2tp_sendmsg(struct kiocb *iocb, struct
socket *sock, struct msgh
skb_put(skb, 2);
/* Copy user data into skb */
- error = memcpy_fromiovec(skb->data, m->msg_iov, total_len);
+ error = memcpy_fromiovec(skb_put(skb, total_len), m->msg_iov,
+total_len);
if (error < 0) {
kfree_skb(skb);
goto error_put_sess_tun;
}
- skb_put(skb, total_len);
l2tp_xmit_skb(session, skb, session->hdr_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/
[10/26] Revert "drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits"
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings This reverts commit 393143615d9f2f581d87387268dc11b95adc339c, which was commit f05bb0c7b624252a5e768287e340e8e45df96e42 upstream. This has been found to cause GPU hangs when backported to 3.2, though not in mainline. References: http://bugs.launchpad.net/bugs/1140716 Cc: Steve Conklin Cc: Stefan Bader Cc: Bradd Figg Cc: Luis Henriques Signed-off-by: Ben Hutchings --- drivers/gpu/drm/i915/intel_ringbuffer.c |5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 4fddd21..38a7793 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -408,11 +408,6 @@ static int init_render_ring(struct intel_ring_buffer *ring) if (INTEL_INFO(dev)->gen >= 6) I915_WRITE(MI_MODE, GFX_MODE_ENABLE(ASYNC_FLIP_PERF_DISABLE)); - /* Required for the hardware to program scanline values for waiting */ - if (INTEL_INFO(dev)->gen == 6) - I915_WRITE(GFX_MODE, - GFX_MODE_ENABLE(GFX_TLB_INVALIDATE_ALWAYS)); - if (IS_GEN7(dev)) I915_WRITE(GFX_MODE_GEN7, GFX_MODE_DISABLE(GFX_TLB_INVALIDATE_ALWAYS) | -- 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/
[17/26] tcp: xps: fix reordering issues
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 547669d483e5783d722772af1483fa474da7caf9 ]
commit 3853b5841c01a ("xps: Improvements in TX queue selection")
introduced ooo_okay flag, but the condition to set it is slightly wrong.
In our traces, we have seen ACK packets being received out of order,
and RST packets sent in response.
We should test if we have any packets still in host queue.
Signed-off-by: Eric Dumazet
Cc: Tom Herbert
Cc: Yuchung Cheng
Cc: Neal Cardwell
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/tcp_output.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5c1807c..3add486 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -835,11 +835,13 @@ static int tcp_transmit_skb(struct sock *sk, struct
sk_buff *skb, int clone_it,
);
tcp_header_size = tcp_options_size + sizeof(struct tcphdr);
- if (tcp_packets_in_flight(tp) == 0) {
+ if (tcp_packets_in_flight(tp) == 0)
tcp_ca_event(sk, CA_EVENT_TX_START);
- skb->ooo_okay = 1;
- } else
- skb->ooo_okay = 0;
+
+ /* if no packet is in qdisc/device queue, then allow XPS to select
+* another queue.
+*/
+ skb->ooo_okay = sk_wmem_alloc_get(sk) == 0;
skb_push(skb, tcp_header_size);
skb_reset_transport_header(skb);
--
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/
[13/26] gianfar: add missing iounmap() on error in gianfar_ptp_probe()
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Wei Yongjun [ Upstream commit e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e ] Add the missing iounmap() before return from gianfar_ptp_probe() in the error handling case. Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- drivers/net/ethernet/freescale/gianfar_ptp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c b/drivers/net/ethernet/freescale/gianfar_ptp.c index 69c3adf..c2ab21c 100644 --- a/drivers/net/ethernet/freescale/gianfar_ptp.c +++ b/drivers/net/ethernet/freescale/gianfar_ptp.c @@ -520,6 +520,7 @@ static int gianfar_ptp_probe(struct platform_device *dev) return 0; no_clock: + iounmap(etsects->regs); no_ioremap: release_resource(etsects->rsrc); no_resource: -- 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/
[04/26] ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Simon Baatz
commit 1bc39742aab09248169ef9d3727c9def3528b3f3 upstream.
Commit f8b63c1 made flush_kernel_dcache_page a no-op assuming that
the pages it needs to handle are kernel mapped only. However, for
example when doing direct I/O, pages with user space mappings may
occur.
Thus, continue to do lazy flushing if there are no user space
mappings. Otherwise, flush the kernel cache lines directly.
Signed-off-by: Simon Baatz
Reviewed-by: Catalin Marinas
Signed-off-by: Russell King
Signed-off-by: Ben Hutchings
---
arch/arm/include/asm/cacheflush.h |4 +---
arch/arm/mm/flush.c | 33 +
2 files changed, 34 insertions(+), 3 deletions(-)
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -301,9 +301,7 @@ static inline void flush_anon_page(struc
}
#define ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE
-static inline void flush_kernel_dcache_page(struct page *page)
-{
-}
+extern void flush_kernel_dcache_page(struct page *);
#define flush_dcache_mmap_lock(mapping) \
spin_lock_irq(&(mapping)->tree_lock)
--- a/arch/arm/mm/flush.c
+++ b/arch/arm/mm/flush.c
@@ -304,6 +304,39 @@ void flush_dcache_page(struct page *page
EXPORT_SYMBOL(flush_dcache_page);
/*
+ * Ensure cache coherency for the kernel mapping of this page. We can
+ * assume that the page is pinned via kmap.
+ *
+ * If the page only exists in the page cache and there are no user
+ * space mappings, this is a no-op since the page was already marked
+ * dirty at creation. Otherwise, we need to flush the dirty kernel
+ * cache lines directly.
+ */
+void flush_kernel_dcache_page(struct page *page)
+{
+ if (cache_is_vivt() || cache_is_vipt_aliasing()) {
+ struct address_space *mapping;
+
+ mapping = page_mapping(page);
+
+ if (!mapping || mapping_mapped(mapping)) {
+ void *addr;
+
+ addr = page_address(page);
+ /*
+* kmap_atomic() doesn't set the page virtual
+* address for highmem pages, and
+* kunmap_atomic() takes care of cache
+* flushing already.
+*/
+ if (!IS_ENABLED(CONFIG_HIGHMEM) || addr)
+ __cpuc_flush_dcache_area(addr, PAGE_SIZE);
+ }
+ }
+}
+EXPORT_SYMBOL(flush_kernel_dcache_page);
+
+/*
* Flush an anonymous page so that users of get_user_pages()
* can safely access the data. The expected sequence is:
*
--
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/
[02/26] ALSA: usb-audio: work around Android accessory firmware bug
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Clemens Ladisch
commit 342cda29343a6272c630f94ed56810a76740251b upstream.
When the Android firmware enables the audio interfaces in accessory
mode, it always declares in the control interface's baInterfaceNr array
that interfaces 0 and 1 belong to the audio function. However, the
accessory interface itself, if also enabled, already is at index 0 and
shifts the actual audio interface numbers to 1 and 2, which prevents the
PCM streaming interface from being seen by the host driver.
To get the PCM interface interface to work, detect when the descriptors
point to the (for this driver useless) accessory interface, and redirect
to the correct one.
Reported-by: Jeremy Rosen
Tested-by: Jeremy Rosen
Signed-off-by: Clemens Ladisch
Signed-off-by: Takashi Iwai
Signed-off-by: Ben Hutchings
---
sound/usb/card.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -149,14 +149,32 @@ static int snd_usb_create_stream(struct
return -EINVAL;
}
+ alts = >altsetting[0];
+ altsd = get_iface_desc(alts);
+
+ /*
+* Android with both accessory and audio interfaces enabled gets the
+* interface numbers wrong.
+*/
+ if ((chip->usb_id == USB_ID(0x18d1, 0x2d04) ||
+chip->usb_id == USB_ID(0x18d1, 0x2d05)) &&
+ interface == 0 &&
+ altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC &&
+ altsd->bInterfaceSubClass == USB_SUBCLASS_VENDOR_SPEC) {
+ interface = 2;
+ iface = usb_ifnum_to_if(dev, interface);
+ if (!iface)
+ return -EINVAL;
+ alts = >altsetting[0];
+ altsd = get_iface_desc(alts);
+ }
+
if (usb_interface_claimed(iface)) {
snd_printdd(KERN_INFO "%d:%d:%d: skipping, already claimed\n",
dev->devnum, ctrlif, interface);
return -EINVAL;
}
- alts = >altsetting[0];
- altsd = get_iface_desc(alts);
if ((altsd->bInterfaceClass == USB_CLASS_AUDIO ||
altsd->bInterfaceClass == USB_CLASS_VENDOR_SPEC) &&
altsd->bInterfaceSubClass == USB_SUBCLASS_MIDISTREAMING) {
--
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/
[09/26] x86/efi: Fix dummy variable buffer allocation
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Ben Hutchings commit b8cb62f82103083a6e8fa5470bfe634a2c06514d upstream. 1. Check for allocation failure 2. Clear the buffer contents, as they may actually be written to flash 3. Don't leak the buffer Compile-tested only. [ Tested successfully on my buggy ASUS machine - Matt ] Signed-off-by: Ben Hutchings Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -875,7 +875,10 @@ efi_status_t efi_query_variable_store(u3 * that by attempting to use more space than is available. */ unsigned long dummy_size = remaining_size + 1024; - void *dummy = kmalloc(dummy_size, GFP_ATOMIC); + void *dummy = kzalloc(dummy_size, GFP_ATOMIC); + + if (!dummy) + return EFI_OUT_OF_RESOURCES; status = efi.set_variable(efi_dummy_name, _DUMMY_GUID, EFI_VARIABLE_NON_VOLATILE | @@ -895,6 +898,8 @@ efi_status_t efi_query_variable_store(u3 0, dummy); } + kfree(dummy); + /* * The runtime code may now have triggered a garbage collection * run, so check the variable info again -- 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/
[07/26] USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Anders Hammarquist
commit 35a2fbc941accd0e9f1bfadd669311786118d874 upstream.
Add product id for Abbott strip port cable for Precision meter which
uses the TI 3410 chip.
Signed-off-by: Anders Hammarquist
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/usb/serial/ti_usb_3410_5052.c |3 ++-
drivers/usb/serial/ti_usb_3410_5052.h |4 +++-
2 files changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -178,7 +178,8 @@ static struct usb_device_id ti_id_table_
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,7 +52,9 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_PRODUCT_ID 0x3410
+#define ABBOTT_STEREO_PLUG_ID 0x3410
+#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
+#define ABBOTT_STRIP_PORT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
--
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/
[26/26] ncpfs: fix rmdir returns Device or resource busy
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Dave Chiluk
commit 698b8223631472bf982ed570b0812faa61955683 upstream.
1d2ef5901483004d74947bbf78d5146c24038fe7 caused a regression in ncpfs such that
directories could no longer be removed. This was because ncp_rmdir checked
to see if a dentry could be unhashed before allowing it to be removed. Since
1d2ef5901483004d74947bbf78d5146c24038fe7 introduced a change that incremented
dentry->d_count causing it to always be greater than 1 unhash would always
fail. Thus causing the error path in ncp_rmdir to always be taken. Removing
this error path is safe as unhashing is still accomplished by calls to dput
from vfs_rmdir.
Signed-off-by: Dave Chiluk
Signed-off-by: Petr Vandrovec
Signed-off-by: Al Viro
Signed-off-by: Ben Hutchings
---
fs/ncpfs/dir.c |9 -
1 file changed, 9 deletions(-)
--- a/fs/ncpfs/dir.c
+++ b/fs/ncpfs/dir.c
@@ -1033,15 +1033,6 @@ static int ncp_rmdir(struct inode *dir,
DPRINTK("ncp_rmdir: removing %s/%s\n",
dentry->d_parent->d_name.name, dentry->d_name.name);
- /*
-* fail with EBUSY if there are still references to this
-* directory.
-*/
- dentry_unhash(dentry);
- error = -EBUSY;
- if (!d_unhashed(dentry))
- goto out;
-
len = sizeof(__name);
error = ncp_io2vol(server, __name, , dentry->d_name.name,
dentry->d_name.len, !ncp_preserve_case(dir));
--
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/
[11/26] virtio-blk: Call revalidate_disk() upon online disk resize
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Vivek Goyal commit e9986f303dc0f285401de28cf96f42f4dd23a4a1 upstream. If a virtio disk is open in guest and a disk resize operation is done, (virsh blockresize), new size is not visible to tools like "fdisk -l". This seems to be happening as we update only part->nr_sects and not bdev->bd_inode size. Call revalidate_disk() which should take care of it. I tested growing disk size of already open disk and it works for me. Signed-off-by: Vivek Goyal Signed-off-by: Jens Axboe Signed-off-by: Ben Hutchings --- drivers/block/virtio_blk.c |1 + 1 file changed, 1 insertion(+) --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -343,6 +343,7 @@ static void virtblk_config_changed_work( cap_str_10, cap_str_2); set_capacity(vblk->disk, capacity); + revalidate_disk(vblk->disk); done: mutex_unlock(>config_lock); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[21/26] ipv6: assign rt6_info to inet6_ifaddr in init_loopback
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Gao feng
[ Upstream commit 534c877928a16ae5f9776436a497109639bf67dc ]
Commit 25fb6ca4ed9cad72f14f61629b68dc03c0d9713f
"net IPv6 : Fix broken IPv6 routing table after loopback down-up"
forgot to assign rt6_info to the inet6_ifaddr.
When disable the net device, the rt6_info which allocated
in init_loopback will not be destroied in __ipv6_ifa_notify.
This will trigger the waring message below
[23527.916091] unregister_netdevice: waiting for tap0 to become free. Usage
count = 1
Reported-by: Arkadiusz Miskiewicz
Signed-off-by: Gao feng
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv6/addrconf.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index d84033b..d603caa 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2437,8 +2437,10 @@ static void init_loopback(struct net_device *dev)
sp_rt = addrconf_dst_alloc(idev, _ifa->addr, 0);
/* Failure cases are ignored */
- if (!IS_ERR(sp_rt))
+ if (!IS_ERR(sp_rt)) {
+ sp_ifa->rt = sp_rt;
ip6_ins_rt(sp_rt);
+ }
}
read_unlock_bh(>lock);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[22/26] net: sctp: fix NULL pointer dereference in socket destruction
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Daniel Borkmann
[ Upstream commit 1abd165ed757db1afdefaac0a4bc8a70f97d258c ]
While stress testing sctp sockets, I hit the following panic:
BUG: unable to handle kernel NULL pointer dereference at 0020
IP: [] sctp_endpoint_free+0xe/0x40 [sctp]
PGD 7cead067 PUD 7ce76067 PMD 0
Oops: [#1] SMP
Modules linked in: sctp(F) libcrc32c(F) [...]
CPU: 7 PID: 2950 Comm: acc Tainted: GF3.10.0-rc2+ #1
Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
task: 88007ce0e0c0 ti: 88007b568000 task.ti: 88007b568000
RIP: 0010:[] []
sctp_endpoint_free+0xe/0x40 [sctp]
RSP: 0018:88007b569e08 EFLAGS: 00010292
RAX: RBX: 88007db78a00 RCX: dead00200200
RDX: a049fdb0 RSI: 8800379baf38 RDI:
RBP: 88007b569e18 R08: 88007c230da0 R09: 0001
R10: R11: R12:
R13: 880077990d00 R14: 0084 R15: 88007db78a00
FS: 7fc18ab61700() GS:88007fc6() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 0020 CR3: 7cf9d000 CR4: 07e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Stack:
88007b569e38 88007db78a00 88007b569e38 a049fded
81abf0c0 88007db78a00 88007b569e58 8145b60e
88007b569eb8 814df36e
Call Trace:
[] sctp_destroy_sock+0x3d/0x80 [sctp]
[] sk_common_release+0x1e/0xf0
[] inet_create+0x2ae/0x350
[] __sock_create+0x11f/0x240
[] sock_create+0x30/0x40
[] SyS_socket+0x4c/0xc0
[] ? do_page_fault+0xe/0x10
[] ? page_fault+0x22/0x30
[] system_call_fastpath+0x16/0x1b
Code: 0c c9 c3 66 2e 0f 1f 84 00 00 00 00 00 e8 fb fe ff ff c9 c3 66 0f
1f 84 00 00 00 00 00 55 48 89 e5 53 48 83 ec 08 66 66 66 66 90 <48>
8b 47 20 48 89 fb c6 47 1c 01 c6 40 12 07 e8 9e 68 01 00 48
RIP [] sctp_endpoint_free+0xe/0x40 [sctp]
RSP
CR2: 0020
---[ end trace e0d71ec1108c1dd9 ]---
I did not hit this with the lksctp-tools functional tests, but with a
small, multi-threaded test program, that heavily allocates, binds,
listens and waits in accept on sctp sockets, and then randomly kills
some of them (no need for an actual client in this case to hit this).
Then, again, allocating, binding, etc, and then killing child processes.
This panic then only occurs when ``echo 1 > /proc/sys/net/sctp/auth_enable''
is set. The cause for that is actually very simple: in sctp_endpoint_init()
we enter the path of sctp_auth_init_hmacs(). There, we try to allocate
our crypto transforms through crypto_alloc_hash(). In our scenario,
it then can happen that crypto_alloc_hash() fails with -EINTR from
crypto_larval_wait(), thus we bail out and release the socket via
sk_common_release(), sctp_destroy_sock() and hit the NULL pointer
dereference as soon as we try to access members in the endpoint during
sctp_endpoint_free(), since endpoint at that time is still NULL. Now,
if we have that case, we do not need to do any cleanup work and just
leave the destruction handler.
Signed-off-by: Daniel Borkmann
Acked-by: Neil Horman
Acked-by: Vlad Yasevich
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/sctp/socket.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 5e0d86e..ba0108f 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3929,6 +3929,12 @@ SCTP_STATIC void sctp_destroy_sock(struct sock *sk)
/* Release our hold on the endpoint. */
sp = sctp_sk(sk);
+ /* This could happen during socket init, thus we bail out
+* early, since the rest of the below is not setup either.
+*/
+ if (sp->ep == NULL)
+ return;
+
if (sp->do_auto_asconf) {
sp->do_auto_asconf = 0;
list_del(>auto_asconf_list);
--
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/
[20/26] net: force a reload of first item in hlist_nulls_for_each_entry_rcu
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit c87a124a5d5e8cf8e21c4363c3372bcaf53ea190 ]
Roman Gushchin discovered that udp4_lib_lookup2() was not reloading
first item in the rcu protected list, in case the loop was restarted.
This produced soft lockups as in https://lkml.org/lkml/2013/4/16/37
rcu_dereference(X)/ACCESS_ONCE(X) seem to not work as intended if X is
ptr->field :
In some cases, gcc caches the value or ptr->field in a register.
Use a barrier() to disallow such caching, as documented in
Documentation/atomic_ops.txt line 114
Thanks a lot to Roman for providing analysis and numerous patches.
Diagnosed-by: Roman Gushchin
Signed-off-by: Eric Dumazet
Reported-by: Boris Zhmurov
Signed-off-by: Roman Gushchin
Acked-by: Paul E. McKenney
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
include/linux/rculist_nulls.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
index 2ae1371..1c33dd7 100644
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -105,9 +105,14 @@ static inline void hlist_nulls_add_head_rcu(struct
hlist_nulls_node *n,
* @head: the head for your list.
* @member:the name of the hlist_nulls_node within the struct.
*
+ * The barrier() is needed to make sure compiler doesn't cache first element
[1],
+ * as this loop can be restarted [2]
+ * [1] Documentation/atomic_ops.txt around line 114
+ * [2] Documentation/RCU/rculist_nulls.txt around line 146
*/
#define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
\
- for (pos = rcu_dereference_raw(hlist_nulls_first_rcu(head));
\
+ for (({barrier();}),
\
+pos = rcu_dereference_raw(hlist_nulls_first_rcu(head));
\
(!is_a_nulls(pos)) &&
\
({ tpos = hlist_nulls_entry(pos, typeof(*tpos), member); 1; });
\
pos = rcu_dereference_raw(hlist_nulls_next_rcu(pos)))
--
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/
[00/26] 3.2.48-rc1 review
This is the start of the stable review cycle for the 3.2.48 release. There are 26 patches in this series, which will be posted as responses to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Jun 28 12:00:00 UTC 2013. Anything received after that time might be too late. A combined patch relative to 3.2.47 will be posted as an additional response to this. A shortlog and diffstat can be found below. Ben. - Anders Hammarquist (1): USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable [35a2fbc941accd0e9f1bfadd669311786118d874] Andy Lutomirski (1): net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg [1be374a0518a288147c6a7398792583200a67261, a7526eb5d06b0084ef12d7b168d008fcf516caab] Ben Hutchings (2): Revert "drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits" [not upstream; reverts a change that regressed 3.2 only] x86/efi: Fix dummy variable buffer allocation [b8cb62f82103083a6e8fa5470bfe634a2c06514d] Chris Metcalf (1): tilepro: work around module link error with gcc 4.7 [3cb3f839d306443f3d1e79b0bde1a2ad2c12b555] Clemens Ladisch (1): ALSA: usb-audio: work around Android accessory firmware bug [342cda29343a6272c630f94ed56810a76740251b] Daniel Borkmann (2): net: sctp: fix NULL pointer dereference in socket destruction [1abd165ed757db1afdefaac0a4bc8a70f97d258c] packet: packet_getname_spkt: make sure string is always 0-terminated [2dc85bf323515e59e15dfa858d1472bb25cad0fe] Dave Chiluk (1): ncpfs: fix rmdir returns Device or resource busy [698b8223631472bf982ed570b0812faa61955683] Eric Dumazet (5): ip_tunnel: fix kernel panic with icmp_dest_unreach [a622260254ee481747cceaaa8609985b29a31565] ipv6: fix possible crashes in ip6_cork_release() [284041ef21fdf2e0d216ab6b787bc9072b4eb58a] net: force a reload of first item in hlist_nulls_for_each_entry_rcu [c87a124a5d5e8cf8e21c4363c3372bcaf53ea190] tcp: fix tcp_md5_hash_skb_data() [54d27fcb338bd9c42d1dfc5a39e18f6f9d373c2e] tcp: xps: fix reordering issues [547669d483e5783d722772af1483fa474da7caf9] Gao feng (1): ipv6: assign rt6_info to inet6_ifaddr in init_loopback [534c877928a16ae5f9776436a497109639bf67dc] Guillaume Nault (2): l2tp: Fix PPP header erasure and memory leak [55b92b7a11690bc377b5d373872a6b650ae88e64] l2tp: Fix sendmsg() return value [a6f79d0f26704214b5b702bbac525cb72997f984] Matthew Garrett (1): Modify UEFI anti-bricking code [f8b8404337de4e2466e2e1139ea68b1f8295974f] Paul Moore (1): netlabel: improve domain mapping validation [6b21e1b77d1a3d58ebfd513264c885695e8a0ba5] Randy Dunlap (1): x86: fix build error and kconfig for ia32_emulation and binfmt [d1603990ea626668c78527376d9ec084d634202d] Simon Baatz (1): ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page [1bc39742aab09248169ef9d3727c9def3528b3f3] Stefan Bader, françois romieu (1): r8169: fix 8168evl frame padding. [e5195c1f31f399289347e043d6abf3ffa80f0005, b423e9ae49d78ea3f53b131c8d5a6087aed16fd6] Takashi Iwai (1): ALSA: usb-audio: Fix invalid volume resolution for Logitech HD Webcam c310 [36691e1be6ec551eef4a5225f126a281f8c051c2] Vivek Goyal (1): virtio-blk: Call revalidate_disk() upon online disk resize [e9986f303dc0f285401de28cf96f42f4dd23a4a1] Wei Yongjun (1): gianfar: add missing iounmap() on error in gianfar_ptp_probe() [e5f5e380e0f3bb11f04ca5bc66a551e58e0ad26e] Zhanghaoyu (1): KVM: x86: remove vcpu's CPL check in host-invoked XCR set [764bcbc5a6d7a2f3e75c9f0e4caa984e2926e346] Makefile |4 +- arch/arm/include/asm/cacheflush.h|4 +- arch/arm/mm/flush.c | 33 +++ arch/tile/lib/exports.c |2 + arch/x86/Kconfig |1 + arch/x86/kvm/x86.c |5 +- arch/x86/platform/efi/efi.c | 80 +++--- drivers/block/virtio_blk.c |1 + drivers/gpu/drm/i915/intel_ringbuffer.c |5 -- drivers/net/ethernet/freescale/gianfar_ptp.c |1 + drivers/net/ethernet/realtek/r8169.c | 33 +-- drivers/usb/serial/ti_usb_3410_5052.c|3 +- drivers/usb/serial/ti_usb_3410_5052.h|4 +- fs/ncpfs/dir.c |9 --- include/linux/rculist_nulls.h|7 ++- include/linux/socket.h |3 + net/compat.c | 13 - net/ipv4/ip_gre.c|2 +- net/ipv4/ipip.c
[18/26] ip_tunnel: fix kernel panic with icmp_dest_unreach
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit a622260254ee481747cceaaa8609985b29a31565 ]
Daniel Petre reported crashes in icmp_dst_unreach() with following call
graph:
Daniel found a similar problem mentioned in
http://lkml.indiana.edu/hypermail/linux/kernel/1007.0/00961.html
And indeed this is the root cause : skb->cb[] contains data fooling IP
stack.
We must clear IPCB in ip_tunnel_xmit() sooner in case dst_link_failure()
is called. Or else skb->cb[] might contain garbage from GSO segmentation
layer.
A similar fix was tested on linux-3.9, but gre code was refactored in
linux-3.10. I'll send patches for stable kernels as well.
Many thanks to Daniel for providing reports, patches and testing !
Reported-by: Daniel Petre
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/ip_gre.c | 2 +-
net/ipv4/ipip.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index d55110e..5f28fab 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -716,6 +716,7 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev
tiph = >parms.iph;
}
+ memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
if ((dst = tiph->daddr) == 0) {
/* NBMA tunnel */
@@ -851,7 +852,6 @@ static netdev_tx_t ipgre_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev
skb_reset_transport_header(skb);
skb_push(skb, gre_hlen);
skb_reset_network_header(skb);
- memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED |
IPSKB_REROUTED);
skb_dst_drop(skb);
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index 17ad951..5dc5137 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -448,6 +448,7 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev)
if (tos & 1)
tos = old_iph->tos;
+ memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
if (!dst) {
/* NBMA tunnel */
if ((rt = skb_rtable(skb)) == NULL) {
@@ -531,7 +532,6 @@ static netdev_tx_t ipip_tunnel_xmit(struct sk_buff *skb,
struct net_device *dev)
skb->transport_header = skb->network_header;
skb_push(skb, sizeof(struct iphdr));
skb_reset_network_header(skb);
- memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt));
IPCB(skb)->flags &= ~(IPSKB_XFRM_TUNNEL_SIZE | IPSKB_XFRM_TRANSFORMED |
IPSKB_REROUTED);
skb_dst_drop(skb);
--
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/
[14/26] ipv6: fix possible crashes in ip6_cork_release()
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 284041ef21fdf2e0d216ab6b787bc9072b4eb58a ]
commit 0178b695fd6b4 ("ipv6: Copy cork options in ip6_append_data")
added some code duplication and bad error recovery, leading to potential
crash in ip6_cork_release() as kfree() could be called with garbage.
use kzalloc() to make sure this wont happen.
Signed-off-by: Eric Dumazet
Signed-off-by: David S. Miller
Cc: Herbert Xu
Cc: Hideaki YOSHIFUJI
Cc: Neal Cardwell
Signed-off-by: Ben Hutchings
---
net/ipv6/ip6_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 3ccd9b2..6aadaa8 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1233,7 +1233,7 @@ int ip6_append_data(struct sock *sk, int getfrag(void
*from, char *to,
if (WARN_ON(np->cork.opt))
return -EINVAL;
- np->cork.opt = kmalloc(opt->tot_len, sk->sk_allocation);
+ np->cork.opt = kzalloc(opt->tot_len, sk->sk_allocation);
if (unlikely(np->cork.opt == NULL))
return -ENOBUFS;
--
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/
[25/26] l2tp: Fix sendmsg() return value
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Guillaume Nault [ Upstream commit a6f79d0f26704214b5b702bbac525cb72997f984 ] PPPoL2TP sockets should comply with the standard send*() return values (i.e. return number of bytes sent instead of 0 upon success). Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- net/l2tp/l2tp_ppp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c index 8ab041b..74410e6 100644 --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -362,7 +362,7 @@ static int pppol2tp_sendmsg(struct kiocb *iocb, struct socket *sock, struct msgh sock_put(ps->tunnel_sock); sock_put(sk); - return error; + return total_len; error_put_sess_tun: sock_put(ps->tunnel_sock); -- 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/
[19/26] net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Andy Lutomirski
[ Upstream commits 1be374a0518a288147c6a7398792583200a67261 and
a7526eb5d06b0084ef12d7b168d008fcf516caab ]
MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API --
it's a hack that steals a bit to indicate to other networking code
that a compat entry was used. So don't allow it from a non-compat
syscall.
This prevents an oops when running this code:
int main()
{
int s;
struct sockaddr_in addr;
struct msghdr *hdr;
char *highpage = mmap((void*)(TASK_SIZE_MAX - 4096), 4096,
PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0);
if (highpage == MAP_FAILED)
err(1, "mmap");
s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
if (s == -1)
err(1, "socket");
addr.sin_family = AF_INET;
addr.sin_port = htons(1);
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(s, (struct sockaddr*), sizeof(addr)) != 0)
err(1, "connect");
void *evil = highpage + 4096 - COMPAT_MSGHDR_SIZE;
printf("Evil address is %p\n", evil);
if (syscall(__NR_sendmmsg, s, evil, 1, MSG_CMSG_COMPAT) < 0)
err(1, "sendmmsg");
return 0;
}
Cc: David S. Miller
Signed-off-by: Andy Lutomirski
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
include/linux/socket.h | 3 +++
net/compat.c | 13 --
net/socket.c | 67 +-
3 files changed, 59 insertions(+), 24 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 2acd2e2..7e9f2d3 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -336,6 +336,9 @@ extern int put_cmsg(struct msghdr*, int level, int type,
int len, void *data);
struct timespec;
+/* The __sys_...msg variants allow MSG_CMSG_COMPAT */
+extern long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags);
+extern long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int
vlen,
unsigned int flags, struct timespec *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
diff --git a/net/compat.c b/net/compat.c
index 6def90e..8c979cc 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -733,19 +733,25 @@ static unsigned char nas[21] = {
asmlinkage long compat_sys_sendmsg(int fd, struct compat_msghdr __user *msg,
unsigned flags)
{
- return sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_sendmmsg(int fd, struct compat_mmsghdr __user *mmsg,
unsigned vlen, unsigned int flags)
{
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recvmsg(int fd, struct compat_msghdr __user *msg,
unsigned int flags)
{
- return sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recv(int fd, void __user *buf, size_t len, unsigned
flags)
@@ -767,6 +773,9 @@ asmlinkage long compat_sys_recvmmsg(int fd, struct
compat_mmsghdr __user *mmsg,
int datagrams;
struct timespec ktspec;
+ if (flags & MSG_CMSG_COMPAT)
+ return -EINVAL;
+
if (timeout == NULL)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT, NULL);
diff --git a/net/socket.c b/net/socket.c
index 68879db..cf546a3 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1876,9 +1876,9 @@ struct used_address {
unsigned int name_len;
};
-static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
-struct msghdr *msg_sys, unsigned flags,
-struct used_address *used_address)
+static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
+ struct msghdr *msg_sys, unsigned flags,
+ struct used_address *used_address)
{
struct compat_msghdr __user *msg_compat =
(struct compat_msghdr __user *)msg;
@@ -1998,22 +1998,30 @@ out:
* BSD sendmsg interface
*/
-SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned, flags)
[16/26] r8169: fix 8168evl frame padding.
3.2.48-rc1 review patch. If anyone has any objections, please let me know.
--
From: Stefan Bader
[ Upstream commits e5195c1f31f399289347e043d6abf3ffa80f0005 and
b423e9ae49d78ea3f53b131c8d5a6087aed16fd6 ]
Signed-off-by: Stefan Bader
Acked-by: Francois Romieu
Cc: hayeswang
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/realtek/r8169.c | 33 +++--
1 file changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index f698183..ed7a5a6 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5524,7 +5524,20 @@ err_out:
return -EIO;
}
-static inline void rtl8169_tso_csum(struct rtl8169_private *tp,
+static bool rtl_skb_pad(struct sk_buff *skb)
+{
+ if (skb_padto(skb, ETH_ZLEN))
+ return false;
+ skb_put(skb, ETH_ZLEN - skb->len);
+ return true;
+}
+
+static bool rtl_test_hw_pad_bug(struct rtl8169_private *tp, struct sk_buff
*skb)
+{
+ return skb->len < ETH_ZLEN && tp->mac_version == RTL_GIGA_MAC_VER_34;
+}
+
+static inline bool rtl8169_tso_csum(struct rtl8169_private *tp,
struct sk_buff *skb, u32 *opts)
{
const struct rtl_tx_desc_info *info = tx_desc_info + tp->txd_version;
@@ -5537,13 +5550,20 @@ static inline void rtl8169_tso_csum(struct
rtl8169_private *tp,
} else if (skb->ip_summed == CHECKSUM_PARTIAL) {
const struct iphdr *ip = ip_hdr(skb);
+ if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
+ return skb_checksum_help(skb) == 0 && rtl_skb_pad(skb);
+
if (ip->protocol == IPPROTO_TCP)
opts[offset] |= info->checksum.tcp;
else if (ip->protocol == IPPROTO_UDP)
opts[offset] |= info->checksum.udp;
else
WARN_ON_ONCE(1);
+ } else {
+ if (unlikely(rtl_test_hw_pad_bug(tp, skb)))
+ return rtl_skb_pad(skb);
}
+ return true;
}
static netdev_tx_t rtl8169_start_xmit(struct sk_buff *skb,
@@ -5575,6 +5595,12 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff
*skb,
if (unlikely(le32_to_cpu(txd->opts1) & DescOwn))
goto err_stop_0;
+ opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
+ opts[0] = DescOwn;
+
+ if (!rtl8169_tso_csum(tp, skb, opts))
+ goto err_update_stats;
+
len = skb_headlen(skb);
mapping = dma_map_single(d, skb->data, len, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(d, mapping))) {
@@ -5586,11 +5612,6 @@ static netdev_tx_t rtl8169_start_xmit(struct sk_buff
*skb,
tp->tx_skb[entry].len = len;
txd->addr = cpu_to_le64(mapping);
- opts[1] = cpu_to_le32(rtl8169_tx_vlan_tag(tp, skb));
- opts[0] = DescOwn;
-
- rtl8169_tso_csum(tp, skb, opts);
-
frags = rtl8169_xmit_frags(tp, skb, opts);
if (frags < 0)
goto err_dma_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/
[06/26] x86: fix build error and kconfig for ia32_emulation and binfmt
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Randy Dunlap commit d1603990ea626668c78527376d9ec084d634202d upstream. Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF when COMPAT_BINFMT_ELF is being selected. warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF) fs/built-in.o: In function `elf_core_dump': compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs' compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size' compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs' compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data' [ hpa: This was sent to me for -next but it is a low risk build fix ] Signed-off-by: Randy Dunlap Link: http://lkml.kernel.org/r/51c0b614.5000...@infradead.org Signed-off-by: H. Peter Anvin Signed-off-by: Ben Hutchings --- arch/x86/Kconfig |1 + 1 file changed, 1 insertion(+) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2120,6 +2120,7 @@ source "fs/Kconfig.binfmt" config IA32_EMULATION bool "IA32 Emulation" depends on X86_64 + select BINFMT_ELF select COMPAT_BINFMT_ELF ---help--- Include code to run 32-bit programs under a 64-bit kernel. You should -- 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/
[01/26] tilepro: work around module link error with gcc 4.7
3.2.48-rc1 review patch. If anyone has any objections, please let me know. -- From: Chris Metcalf commit 3cb3f839d306443f3d1e79b0bde1a2ad2c12b555 upstream. gcc 4.7.x is emitting calls to __ffsdi2 where previously it used to inline the appropriate ctz instructions. While this needs to be fixed in gcc, it's also easy to avoid having it cause build failures when building with those compilers by exporting __ffsdi2 to modules. Signed-off-by: Chris Metcalf Signed-off-by: Ben Hutchings --- arch/tile/lib/exports.c |2 ++ 1 file changed, 2 insertions(+) --- a/arch/tile/lib/exports.c +++ b/arch/tile/lib/exports.c @@ -90,4 +90,6 @@ uint64_t __ashrdi3(uint64_t, unsigned in EXPORT_SYMBOL(__ashrdi3); uint64_t __ashldi3(uint64_t, unsigned int); EXPORT_SYMBOL(__ashldi3); +int __ffsdi2(uint64_t); +EXPORT_SYMBOL(__ffsdi2); #endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] perf, x86: Basic Haswell LBR call stack support
On 06/25/2013 08:37 PM, Stephane Eranian wrote:
> On Tue, Jun 25, 2013 at 10:47 AM, Yan, Zheng wrote:
>> From: "Yan, Zheng"
>>
>> The new HSW call stack feature provides a facility such that
>> unfiltered call data will be collected as normal, but as return
>> instructions are executed the last captured branch record is
>> popped from the LBR stack. Thus, branch information relative to
>> leaf functions will not be captured, while preserving the call
>> stack information of the main line execution path.
>>
>> Signed-off-by: Yan, Zheng
>> ---
>> arch/x86/kernel/cpu/perf_event.h | 7 ++-
>> arch/x86/kernel/cpu/perf_event_intel.c | 2 +-
>> arch/x86/kernel/cpu/perf_event_intel_lbr.c | 89
>> ++
>> 3 files changed, 74 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/x86/kernel/cpu/perf_event.h
>> b/arch/x86/kernel/cpu/perf_event.h
>> index a74d554..e14c963 100644
>> --- a/arch/x86/kernel/cpu/perf_event.h
>> +++ b/arch/x86/kernel/cpu/perf_event.h
>> @@ -448,7 +448,10 @@ struct x86_pmu {
>> };
>>
>> enum {
>> - PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE = PERF_SAMPLE_BRANCH_MAX_SHIFT,
>> + PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT = PERF_SAMPLE_BRANCH_MAX_SHIFT,
>> + PERF_SAMPLE_BRANCH_SELECT_MAP_SIZE,
>> +
>> + PERF_SAMPLE_BRANCH_CALL_STACK = 1U <<
>> PERF_SAMPLE_BRANCH_CALL_STACK_SHIFT,
>> };
>>
>> #define x86_add_quirk(func_) \
>> @@ -681,6 +684,8 @@ void intel_pmu_lbr_init_atom(void);
>>
>> void intel_pmu_lbr_init_snb(void);
>>
>> +void intel_pmu_lbr_init_hsw(void);
>> +
>> int intel_pmu_setup_lbr_filter(struct perf_event *event);
>>
>> int p4_pmu_init(void);
>> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
>> b/arch/x86/kernel/cpu/perf_event_intel.c
>> index a6eccf1..3e92a68 100644
>> --- a/arch/x86/kernel/cpu/perf_event_intel.c
>> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
>> @@ -2276,7 +2276,7 @@ __init int intel_pmu_init(void)
>> memcpy(hw_cache_event_ids, snb_hw_cache_event_ids,
>> sizeof(hw_cache_event_ids));
>> memcpy(hw_cache_extra_regs, snb_hw_cache_extra_regs,
>> sizeof(hw_cache_extra_regs));
>>
>> - intel_pmu_lbr_init_snb();
>> + intel_pmu_lbr_init_hsw();
>>
>> x86_pmu.event_constraints = intel_hsw_event_constraints;
>> x86_pmu.pebs_constraints = intel_hsw_pebs_event_constraints;
>> diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
>> b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
>> index a72e9e9..2136320 100644
>> --- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
>> +++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
>> @@ -39,6 +39,7 @@ static enum {
>> #define LBR_IND_JMP_BIT6 /* do not capture indirect jumps */
>> #define LBR_REL_JMP_BIT7 /* do not capture relative jumps */
>> #define LBR_FAR_BIT8 /* do not capture far branches */
>> +#define LBR_CALL_STACK_BIT 9 /* enable call stack */
>>
>> #define LBR_KERNEL (1 << LBR_KERNEL_BIT)
>> #define LBR_USER (1 << LBR_USER_BIT)
>> @@ -49,6 +50,7 @@ static enum {
>> #define LBR_REL_JMP(1 << LBR_REL_JMP_BIT)
>> #define LBR_IND_JMP(1 << LBR_IND_JMP_BIT)
>> #define LBR_FAR(1 << LBR_FAR_BIT)
>> +#define LBR_CALL_STACK (1 << LBR_CALL_STACK_BIT)
>>
>> #define LBR_PLM (LBR_KERNEL | LBR_USER)
>>
>> @@ -74,24 +76,25 @@ static enum {
>> * x86control flow changes include branches, interrupts, traps, faults
>> */
>> enum {
>> - X86_BR_NONE = 0, /* unknown */
>> -
>> - X86_BR_USER = 1 << 0, /* branch target is user */
>> - X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
>> -
>> - X86_BR_CALL = 1 << 2, /* call */
>> - X86_BR_RET = 1 << 3, /* return */
>> - X86_BR_SYSCALL = 1 << 4, /* syscall */
>> - X86_BR_SYSRET = 1 << 5, /* syscall return */
>> - X86_BR_INT = 1 << 6, /* sw interrupt */
>> - X86_BR_IRET = 1 << 7, /* return from interrupt */
>> - X86_BR_JCC = 1 << 8, /* conditional */
>> - X86_BR_JMP = 1 << 9, /* jump */
>> - X86_BR_IRQ = 1 << 10,/* hw interrupt or trap or fault */
>> - X86_BR_IND_CALL = 1 << 11,/* indirect calls */
>> - X86_BR_ABORT= 1 << 12,/* transaction abort */
>> - X86_BR_IN_TX= 1 << 13,/* in transaction */
>> - X86_BR_NO_TX= 1 << 14,/* not in transaction */
>> + X86_BR_NONE = 0, /* unknown */
>> +
>> + X86_BR_USER = 1 << 0, /* branch target is user */
>> + X86_BR_KERNEL = 1 << 1, /* branch target is kernel */
>> +
>> + X86_BR_CALL = 1 << 2, /* call */
>> + X86_BR_RET = 1 << 3, /* return */
>> + X86_BR_SYSCALL = 1 << 4, /* syscall */
>> + X86_BR_SYSRET = 1 << 5, /* syscall return */
>> + X86_BR_INT = 1 << 6, /* sw interrupt */
ARM pagetable setting in Linux
Hi Will,
I have a question about arm pagetable setting in Linux .
From armV6, there is TTBR0 and TTBR1 translation base address registers in
mmu .
But I found linux only use TTBR0 for translation base address ,
Could we use TTBR0 and TTBR1 to split user task and kernel pagetables
(swapper_pg_dir)？
But I found this need set TTBCR.N ,
If PAGE_OFFSET==0xc000 , set TTBCR.N=0x2 ,
Will not work , because only ensure 0--0x00FF MVA use TTBCR0
And other MVA will use TTBCR1 ,
But if we set PAGE_OFFSET==0x8000 (2GB split ) ,
And set TTBCR.N=0x1 ,
This will make sure user task MVA use TTBCR0 and kernel MVA
Use TTBCR1 , this will make some improvement for the system .
1. Because we don’t need copy kernel first –level pagetables into every
User task’s pagetables and flush tlb (for example fork() a new process).
2. And don’t need handle kernel page fault because that user task’s kernel
Pagetable when it is not set up , need copy again( for example vmalloc()
ioremap() kmap() will change
Kernel pagetables and need update to every task pagetables ) .
3. We even can only allocate 8KB first level pagetables for user task to save
Memorys .
I am not sure if its possible to implement this on cortex-A cpus ?
And if there is some side effects if we use this in linux ?
If possible , I can make a change to do some test .
Thanks for your help .
Yalin.Wang
Software Engineer
OS Kernel
Sony Mobile Communications
Tel: +86 10 5966 9819
Phone: 18610323092
Address: No.16 Guangshun South Street, Chaoyang, Beijing, P.R.C.
sonymobile.com
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Subject: [PATCH] fs/v9fs: Remove the unused variable "err" in v9fs_vfs_getattr()
Delete the unused variable "err" in v9fs_vfs_getattr()
Signed-off-by: Gu Zheng
---
fs/9p/vfs_inode.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index d86edc8..25b018e 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -1054,13 +1054,11 @@ static int
v9fs_vfs_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat)
{
- int err;
struct v9fs_session_info *v9ses;
struct p9_fid *fid;
struct p9_wstat *st;
p9_debug(P9_DEBUG_VFS, "dentry: %p\n", dentry);
- err = -EPERM;
v9ses = v9fs_dentry2v9ses(dentry);
if (v9ses->cache == CACHE_LOOSE || v9ses->cache == CACHE_FSCACHE) {
generic_fillattr(dentry->d_inode, stat);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] pch_gbe: Add MinnowBoard support
On Tue, Jun 25, 2013 at 7:53 PM, Darren Hart wrote:
> The MinnowBoard uses an AR803x PHY with the PCH GBE.
>
> It does not implement the RGMII 2ns TX clock delay in the trace routing
> nor via strapping. Add a detection method for the board and the PHY and
> enable the tx clock delay via the registers.
>
> This PHY will hibernate without link for 10 seconds. Ensure the PHY is
> awake for probe and then disable hibernation. A future improvement would
> be to convert pch_gbe to using PHYLIB and making sure we can wake the
> PHY at the necessary times rather than permanently disabling it.
>
> Use the MinnowBoard PCI subsystem ID to identify the board and setup the
> appropriate callbacks in a new pci_id driver_data structure.
>
> Signed-off-by: Darren Hart
> Cc: "David S. Miller"
> Cc: "H. Peter Anvin"
> Cc: Peter Waskiewicz
> Cc: Andy Shevchenko
> Cc: net...@vger.kernel.org
> ---
> drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 1 +
> drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h| 2 +
> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 32
> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.c| 89
> ++
> .../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.h| 2 +
> 5 files changed, 126 insertions(+)
> ...
> diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> index 6667a6b..6f0b9e3 100644
> --- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
> +++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
>...
> +static struct pch_gbe_privdata pch_gbe_minnowboard_privdata = {
> + .phy_reset = minnow_phy_reset,
> + .phy_tx_clk_delay = pch_gbe_phy_tx_clk_delay,
> +};
> +
> static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
> {.vendor = PCI_VENDOR_ID_INTEL,
> .device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
> +.subvendor = PCI_VENDOR_ID_CIRCUITCO,
> +.subdevice = PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD,
"MINNOWBOARD" seems like a pretty generic name for something that
probably refers only to the gigabit ethernet device in the EG20T. If
you expect to use that same subdevice ID on other devices, I guess we
can add PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD to pci_ids.h. If it will
only be used for the gigabit ethernet device, we would normally not
add a #define for it and would just use the hex constant here (see the
comment at the top of pci_ids.h).
> +.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
> +.class_mask = (0x00),
> +.driver_data = (unsigned long) _gbe_minnowboard_privdata
> +},
> + {.vendor = PCI_VENDOR_ID_INTEL,
> +.device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
> .subvendor = PCI_ANY_ID,
> .subdevice = PCI_ANY_ID,
> .class = (PCI_CLASS_NETWORK_ETHERNET << 8),
--
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/8] pch_uart: Add uart_clk selection for the MinnowBoard
On Tue, Jun 25, 2013 at 06:53:22PM -0700, Darren Hart wrote:
> Use DMI_BOARD_NAME to determine if we are running on a MinnowBoard and
> set the uart clock to 50MHz if so. This removes the need to pass the
> user_uartclk to the kernel at boot time.
>
> Signed-off-by: Darren Hart
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: "H. Peter Anvin"
> Cc: Peter Waskiewicz
> Cc: Andy Shevchenko
> Cc: linux-ser...@vger.kernel.org
> ---
> drivers/tty/serial/pch_uart.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
> index 21a7e17..572d481 100644
> --- a/drivers/tty/serial/pch_uart.c
> +++ b/drivers/tty/serial/pch_uart.c
> @@ -217,6 +217,7 @@ enum {
> #define FRI2_64_UARTCLK 6400 /* 64. MHz */
> #define FRI2_48_UARTCLK 4800 /* 48. MHz */
> #define NTC1_UARTCLK 6400 /* 64. MHz */
> +#define MINNOW_UARTCLK 5000 /* 50. MHz */
>
> struct pch_uart_buffer {
> unsigned char *buf;
> @@ -398,6 +399,10 @@ static int pch_uart_get_uartclk(void)
> strstr(cmp, "nanoETXexpress-TT")))
> return NTC1_UARTCLK;
>
> + cmp = dmi_get_system_info(DMI_BOARD_NAME);
> + if (cmp && strstr(cmp, "MinnowBoard"))
> + return MINNOW_UARTCLK;
> +
You know, we do have the DMI interface to handle this in a much nicer
way instead of just randomly trying different strings over and over
until we find one that matches...
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/
Subject: [PATCH 1/2] fs/v9fs: Remove the unused variable "err" in v9fs_vfs_getattr()
Delete the unused variable "err" in v9fs_vfs_getattr()
Signed-off-by: Gu Zheng
---
fs/9p/vfs_inode.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index d86edc8..25b018e 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -1054,13 +1054,11 @@ static int
v9fs_vfs_getattr(struct vfsmount *mnt, struct dentry *dentry,
struct kstat *stat)
{
- int err;
struct v9fs_session_info *v9ses;
struct p9_fid *fid;
struct p9_wstat *st;
p9_debug(P9_DEBUG_VFS, "dentry: %p\n", dentry);
- err = -EPERM;
v9ses = v9fs_dentry2v9ses(dentry);
if (v9ses->cache == CACHE_LOOSE || v9ses->cache == CACHE_FSCACHE) {
generic_fillattr(dentry->d_inode, stat);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/3] ARM: at91/DT: enable SPI for more SoCs
> -Original Message-
> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> Sent: 2013年6月24日 18:35
> To: Jean-Christophe PLAGNIOL-VILLARD; Desroches, Ludovic; Yang, Wenyou;
> Shen, Voice; Wu, Josh
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ferre,
> Nicolas
> Subject: [PATCH 0/3] ARM: at91/DT: enable SPI for more SoCs
>
> This little series is for enabling the support of SPI on at91sam9n12 and
> sama5d3 families.
>
> Nicolas Ferre (3):
> ARM: at91/DT: fix SPI compatibility string
> ARM: at91/DT: sama5d3: add SPI DMA client infos
> ARM: at91/DT: at91sam9n12: add SPI DMA client infos
>
> arch/arm/boot/dts/at91sam9n12.dtsi | 6 ++
> arch/arm/boot/dts/sama5d3.dtsi | 10 --
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> --
> 1.8.2.2
Tested on sama5d34ek, Linux-next: next-20130624
Tested by Wenyou Yang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ��&�)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH] libata: remove dead code from libata-acpi.c
On 06/21/2013 11:25 PM, James Bottomley wrote:
> On Fri, 2013-06-21 at 08:55 +0800, Aaron Lu wrote:
>> On 06/20/2013 07:02 PM, Sergei Shtylyov wrote:
>>> Hello.
>>
>> Hi,
>>
>> Thanks for your comments.
>>
>>>
>>> On 20-06-2013 6:26, Aaron Lu wrote:
+void ata_acpi_hotplug_init(struct ata_host *host)
+{
+ int i;
+
+ for (i = 0; i < host->n_ports; i++) {
+ struct ata_port *ap = host->ports[i];
+ acpi_handle handle;
+ struct ata_device *dev;
+
+ if (!ap)
+ continue;
+
+ handle = ata_ap_acpi_handle(ap);
+ if (handle) {
+ /* we might be on a docking station */
+ register_hotplug_dock_device(handle,
+ _acpi_ap_dock_ops, ap);
>>>
>>> Please indent this line under the next character after ( above.
>>
>> Is there a link about this rule? I might have missed something about
>> coding style.
>
> The rule is follow the coding style in the file, unless there's
> something really wrong with it (which there might be in the case of
> really old drivers). The reason is that a mixture of coding styles
> makes the file much harder to read than a single consistent style.
Oh right, that's the rule I missed. Thanks for letting me know.
>
> In this case, if you look at libata-acpi.c you see all continuation
> lines of function calls are aligned with open braces.
Indeed.
-Aaron
--
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 -next] ARM: edma: remove duplicated include from edma.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- arch/arm/common/edma.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index a432e6c..39ad030 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include -- 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 -next] PM / AVS: SmartReflex: remove redundant dev_err call in omap_sr_probe()
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/power/avs/smartreflex.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/power/avs/smartreflex.c b/drivers/power/avs/smartreflex.c
index db9973b..c26acfc 100644
--- a/drivers/power/avs/smartreflex.c
+++ b/drivers/power/avs/smartreflex.c
@@ -871,10 +871,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sr_info->base = devm_ioremap_resource(>dev, mem);
- if (IS_ERR(sr_info->base)) {
- dev_err(>dev, "%s: ioremap fail\n", __func__);
+ if (IS_ERR(sr_info->base))
return PTR_ERR(sr_info->base);
- }
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 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 -next] pinctrl: vt8500: wmt: remove redundant dev_err call in wmt_pinctrl_probe()
From: Wei Yongjun
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Signed-off-by: Wei Yongjun
---
drivers/pinctrl/vt8500/pinctrl-wmt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/pinctrl/vt8500/pinctrl-wmt.c
b/drivers/pinctrl/vt8500/pinctrl-wmt.c
index fb30edf3..0cc4335 100644
--- a/drivers/pinctrl/vt8500/pinctrl-wmt.c
+++ b/drivers/pinctrl/vt8500/pinctrl-wmt.c
@@ -570,10 +570,8 @@ int wmt_pinctrl_probe(struct platform_device *pdev,
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
data->base = devm_ioremap_resource(>dev, res);
- if (IS_ERR(data->base)) {
- dev_err(>dev, "failed to map memory resource\n");
+ if (IS_ERR(data->base))
return PTR_ERR(data->base);
- }
wmt_desc.pins = data->pins;
wmt_desc.npins = data->npins;
--
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/8] pch_gbe: Use PCH_GBE_PHY_REGS_LEN instead of 32
Avoid using magic numbers when we have perfectly good defines just lying
around.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 0c1c65a..6667a6b 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -670,7 +670,7 @@ static int pch_gbe_init_phy(struct pch_gbe_adapter *adapter)
}
adapter->hw.phy.addr = adapter->mii.phy_id;
pr_debug("phy_addr = %d\n", adapter->mii.phy_id);
- if (addr == 32)
+ if (addr == PCH_GBE_PHY_REGS_LEN)
return -EAGAIN;
/* Selected the phy and isolate the rest */
for (addr = 0; addr < PCH_GBE_PHY_REGS_LEN; addr++) {
--
1.8.1.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/
[PATCH 8/8] pch_gbe: Add MinnowBoard support
The MinnowBoard uses an AR803x PHY with the PCH GBE.
It does not implement the RGMII 2ns TX clock delay in the trace routing
nor via strapping. Add a detection method for the board and the PHY and
enable the tx clock delay via the registers.
This PHY will hibernate without link for 10 seconds. Ensure the PHY is
awake for probe and then disable hibernation. A future improvement would
be to convert pch_gbe to using PHYLIB and making sure we can wake the
PHY at the necessary times rather than permanently disabling it.
Use the MinnowBoard PCI subsystem ID to identify the board and setup the
appropriate callbacks in a new pci_id driver_data structure.
Signed-off-by: Darren Hart
Cc: "David S. Miller"
Cc: "H. Peter Anvin"
Cc: Peter Waskiewicz
Cc: Andy Shevchenko
Cc: net...@vger.kernel.org
---
drivers/net/ethernet/oki-semi/pch_gbe/Kconfig | 1 +
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h| 2 +
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c | 32
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.c| 89 ++
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_phy.h| 2 +
5 files changed, 126 insertions(+)
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
index 34d05bf..a93fa6b 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/Kconfig
@@ -5,6 +5,7 @@
config PCH_GBE
tristate "OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
depends on PCI
+ depends on !MINNOWBOARD || (MINNOWBOARD=m && m) || MINNOWBOARD=y
select NET_CORE
select MII
select PTP_1588_CLOCK_PCH
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
index 7fb7e17..feacf05 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h
@@ -384,6 +384,7 @@ struct pch_gbe_mac_info {
* @revision: PHY's revision
* @reset_delay_us:HW reset delay time[us]
* @autoneg_advertised:Autoneg advertised
+ * @tx_clk_delay: Setup TX clock delay in the PHY
*/
struct pch_gbe_phy_info {
u32 addr;
@@ -391,6 +392,7 @@ struct pch_gbe_phy_info {
u32 revision;
u32 reset_delay_us;
u16 autoneg_advertised;
+ int(*tx_clk_delay)(struct pch_gbe_hw *);
};
/*!
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 6667a6b..6f0b9e3 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#define DRV_VERSION "1.01"
const char pch_driver_version[] = DRV_VERSION;
@@ -111,6 +112,11 @@ const char pch_driver_version[] = DRV_VERSION;
#define PTP_L4_MULTICAST_SA "01:00:5e:00:01:81"
#define PTP_L2_MULTICAST_SA "01:1b:19:00:00:00"
+struct pch_gbe_privdata {
+ void(*phy_reset)(void);
+ int(*phy_tx_clk_delay)(struct pch_gbe_hw *hw);
+};
+
static unsigned int copybreak __read_mostly = PCH_GBE_COPYBREAK_DEFAULT;
static int pch_gbe_mdio_read(struct net_device *netdev, int addr, int reg);
@@ -2559,6 +2565,7 @@ static int pch_gbe_probe(struct pci_dev *pdev,
{
struct net_device *netdev;
struct pch_gbe_adapter *adapter;
+ struct pch_gbe_privdata *pdata = NULL;
int ret;
ret = pci_enable_device(pdev);
@@ -2596,6 +2603,15 @@ static int pch_gbe_probe(struct pci_dev *pdev,
pci_set_drvdata(pdev, netdev);
adapter = netdev_priv(netdev);
+
+ adapter->hw.phy.tx_clk_delay = NULL;
+ if (pci_id->driver_data) {
+ pdata = (struct pch_gbe_privdata *)pci_id->driver_data;
+ adapter->hw.phy.tx_clk_delay = pdata->phy_tx_clk_delay;
+ if (pdata->phy_reset)
+ pdata->phy_reset();
+ }
+
adapter->netdev = netdev;
adapter->pdev = pdev;
adapter->hw.back = adapter;
@@ -2679,6 +2695,9 @@ static int pch_gbe_probe(struct pci_dev *pdev,
dev_dbg(>dev, "PCH Network Connection\n");
+ /* Disable hibernation on certain PHYs */
+ pch_gbe_phy_disable_hibernate(>hw);
+
device_set_wakeup_enable(>dev, 1);
return 0;
@@ -2697,9 +2716,22 @@ err_disable_device:
return ret;
}
+static struct pch_gbe_privdata pch_gbe_minnowboard_privdata = {
+ .phy_reset = minnow_phy_reset,
+ .phy_tx_clk_delay = pch_gbe_phy_tx_clk_delay,
+};
+
static DEFINE_PCI_DEVICE_TABLE(pch_gbe_pcidev_id) = {
{.vendor = PCI_VENDOR_ID_INTEL,
.device = PCI_DEVICE_ID_INTEL_IOH1_GBE,
+.subvendor = PCI_VENDOR_ID_CIRCUITCO,
+.subdevice = PCI_DEVICE_ID_CIRCUITCO_MINNOWBOARD,
+.class = (PCI_CLASS_NETWORK_ETHERNET << 8),
+.class_mask = (0x00),
+.driver_data = (unsigned long) _gbe_minnowboard_privdata
