Re: [PATCH] GICv3: Fixing 32 bit compatibility
On Mon, Sep 08, 2014 at 03:24:12PM +0100, Marc Zyngier wrote:
> Hi Robert,
>
> On 08/09/14 15:11, Robert Richter wrote:
> > From: Robert Richter
> >
> > Fixing 32 bit compatibility by using ULL for u64 constants.
> >
> > Signed-off-by: Robert Richter
> > ---
> > drivers/irqchip/irq-gic-v3.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> > index 57eaa5a0b1e3..9e13c87c7dfe 100644
> > --- a/drivers/irqchip/irq-gic-v3.c
> > +++ b/drivers/irqchip/irq-gic-v3.c
> > @@ -441,7 +441,7 @@ static u16 gic_compute_target_list(int *base_cpu, const
> > struct cpumask *mask,
> >
> > mpidr = cpu_logical_map(cpu);
> >
> > - if (cluster_id != (mpidr & ~0xffUL)) {
> > + if (cluster_id != (mpidr & ~0xffULL)) {
> > cpu--;
> > goto out;
> > }
> > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask
> > *mask, unsigned int irq)
> > smp_wmb();
> >
> > for_each_cpu_mask(cpu, *mask) {
> > - u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > + u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> > u16 tlist;
> >
> > tlist = gic_compute_target_list(, mask, cluster_id);
> >
>
> Yeah, and there are many more. I'm currently sitting on a rather long
> queue of GICv3-related 32bit patches. I'll try to get that posted shortly.
I'll hold off until you post a complete series then.
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Weird character in kernel message
On 2014.09.14 at 07:09 +0200, Markus Trippelsdorf wrote: > Just noticed this today: > > Sep 14 06:51:57 x4 kernel: [sched_delayed] ^a4CE: hpet increased min_delta_ns > to 20115 nsec > > in hex: > 20 01 34 43 45 3A 20 > > Must be a recent regression. It looks like a combination of commit 504d58745c9ca and commit 458df9fd4815b causes the issue. 458df9fd4815b changed the loglevel of printk_deferred to a hardcoded KERN_WARNING. And 504d58745c9ca changed the printk in kernel/time/clockevents.c to printk_deferred. But now the KERN_WARNING loglevel of printk_deferred in kernel/time/clockevents.c is redundant and responsible for the weird 01 34 character combination (KERN_SOH "4"). -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] irqchip: atmel-aic: add RTT irq fixup
On Wed, Sep 03, 2014 at 11:07:46AM +0200, Boris BREZILLON wrote: > The series depends on the acceptation of the RTT DT bindings proposed here > [1]. > > Best Regards, > > Boris > > [1]https://lkml.org/lkml/2014/9/3/145 Hmm, the bindings, unfortunately, still seem to be in flux. Any update? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: linux-next: Tree for Sep 1
Christoph, On Tue, Sep 02, 2014 at 10:00:07AM -0500, Christoph Lameter wrote: > On Tue, 2 Sep 2014, Christoph Lameter wrote: > > > Oww.. This is double indirection deal there. A percpu offset pointing to > > a pointer? > > > > Generally the following is true (definition from > > include/asm-generic/percpu.h that is used for ARM for raw_cpu_read): > > > > #define raw_cpu_read_4(pcp) (*raw_cpu_ptr(&(pcp))) > > I think what the issue is that we dropped the fetch of the percpu offset > in the patch. Instead we are using the address of the variable that > contains the offset. Does this patch fix it? > > > Subject: irqchip: Properly fetch the per cpu offset > > The raw_cpu_read() conversion dropped the fetch of the offset > from base->percpu_base in gic_get_percpu_base. > > Signed-off-by: Christoph Lameter Acked-by: Jason Cooper thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 00/35] arm: omap: move intc to drivers/irqchip/
On Mon, Jul 28, 2014 at 04:15:48PM -0500, Felipe Balbi wrote: > Hi folks, > > here's another rebase of the original series moving INTC > to drivers. > > There aren't many changes, only some fixes here and there > because of recent changes to irq_domain and irqchip. > > I have also added a patch to enable INTC address space > protection so that only privileged modes can access > INTC's address space. > > Patches tested on top of v3.17-rc7 with a beagle bone black, > the only plataform I have which still uses INTC. > > Tony, if you can run your PM test cases on your side, I'd > be really glad. > > cheers > > Felipe Balbi (35): > arm: omap: irq: make omap_irq_base global > arm: omap: irq: define INTC_ILR0 register > arm: omap: irq: start to remove irq_banks array > arm: omap: irq: add a global omap_nr_irqs variable > arm: omap: irq: remove rest of irq_banks usage > arm: omap: irq: remove unused macro > arm: omap: irq: switch over to intc_readl on omap_intc_handle_irq > arm: omap: irq: remove unnecessary base_addr argument > arm: omap: irq: rename omap3_intc_regs > arm: omap: irq: always define omap3 support > arm: omap: irq: reorganize code a little bit > arm: omap: irq: make intc_of_init static > arm: omap: irq: call set_handle_irq() from intc_of_init > arm: omap: irq: use IRQCHIP_DECLARE macro > arm: omap: irq: drop .handle_irq and .init_irq fields > arm: omap: irq: add specific compatibles for omap3 and am33xx devices > arm: omap: irq: use compatible flag to figure out number of IRQ lines > arm: boot: dts: am33xx/omap3: fix intc compatible flag > arm: omap: irq: drop ti,intc-size support > arm: boot: dts: omap2/3/am33xx: drop ti,intc-size > arm: omap: irq: move some more code around > arm: omap: irq: call set_handle_irq() from .init_irq > arm: omap: irq: drop omap3_intc_handle_irq() > arm: omap: irq: drop omap2_intc_handle_irq() > arm: omap: irq: remove unnecessary header > arm: omap: irq: remove nr_irqs argument > arm: omap: irq: introduce omap_nr_pending > arm: omap: irq: get rid of ifdef hack > arm: omap: intc: switch over to linear irq domain > irqchip: add irq-omap-intc.h header > arm: omap: irq: move irq.c to drivers/irqchip/ > irq: intc: minor improvement to omap_irq_pending() > irq: intc: comment style cleanup > irq: intc: remove unnecesary of_address_to_resource() call > irq: intc: enable IP protection > > arch/arm/boot/dts/am33xx.dtsi | 3 +- > arch/arm/boot/dts/omap2.dtsi | 1 - > arch/arm/boot/dts/omap3.dtsi | 3 +- > arch/arm/mach-omap2/Kconfig| 1 + > arch/arm/mach-omap2/Makefile | 3 +- > arch/arm/mach-omap2/board-3430sdp.c| 2 +- > arch/arm/mach-omap2/board-am3517crane.c| 2 +- > arch/arm/mach-omap2/board-am3517evm.c | 2 +- > arch/arm/mach-omap2/board-cm-t35.c | 3 +- > arch/arm/mach-omap2/board-cm-t3517.c | 2 +- > arch/arm/mach-omap2/board-devkit8000.c | 2 +- > arch/arm/mach-omap2/board-generic.c| 14 - > arch/arm/mach-omap2/board-ldp.c| 2 +- > arch/arm/mach-omap2/board-omap3beagle.c| 2 +- > arch/arm/mach-omap2/board-omap3logic.c | 3 +- > arch/arm/mach-omap2/board-omap3pandora.c | 2 +- > arch/arm/mach-omap2/board-omap3stalker.c | 2 +- > arch/arm/mach-omap2/board-omap3touchbook.c | 2 +- > arch/arm/mach-omap2/board-overo.c | 2 +- > arch/arm/mach-omap2/board-rx51.c | 2 +- > arch/arm/mach-omap2/board-ti8168evm.c | 1 + > arch/arm/mach-omap2/common.h | 22 -- > arch/arm/mach-omap2/cpuidle34xx.c | 1 + > arch/arm/mach-omap2/irq.c | 380 --- > arch/arm/mach-omap2/pm24xx.c | 1 + > arch/arm/mach-omap2/pm34xx.c | 1 + > drivers/irqchip/Kconfig| 5 + > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-omap-intc.c| 408 > + > include/linux/irqchip/irq-omap-intc.h | 32 +++ > 30 files changed, 468 insertions(+), 439 deletions(-) > delete mode 100644 arch/arm/mach-omap2/irq.c > create mode 100644 drivers/irqchip/irq-omap-intc.c > create mode 100644 include/linux/irqchip/irq-omap-intc.h For patches 32-35, please fix the subject line to: irqchip: omap-intc: C... With that changed, patches 30-35 are: Acked-by: Jason Cooper thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] NTB bug fixes for v3.17
Hi Linus, Below are a few NTB bug fixes for v3.17. Please consider pulling them. Thanks, Jon The following changes since commit 2ce7598c9a453e0acd0e07be7be3f5eb39608ebd: Linux 3.17-rc4 (2014-09-07 16:09:43 -0700) are available in the git repository at: git://github.com/jonmason/ntb tags/ntb-3.17 for you to fetch changes up to 3cc5ba1938eea0de372a41d1687c8030049c5e8f: ntb: Add alignment check to meet hardware requirement (2014-09-14 00:10:38 -0400) NTB driver fixes for queue spread and buffer alignment. Also, update to MAINTAINERS to reflect new e-mail address. Dave Jiang (1): ntb: Add alignment check to meet hardware requirement Jon Mason (2): NTB: correct the spread of queues over mw's MAINTAINERS: update NTB info MAINTAINERS | 3 ++- drivers/ntb/ntb_transport.c | 17 +++-- 2 files changed, 17 insertions(+), 3 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/
Weird character in kernel message
Just noticed this today: Sep 14 06:51:57 x4 kernel: [sched_delayed] ^a4CE: hpet increased min_delta_ns to 20115 nsec in hex: 20 01 34 43 45 3A 20 Must be a recent regression. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
Revised patch takes into account comments by Joe and David.
Compiling with OCTEON_MGMT_ETHERNET gives a warning
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
The patch cleans up the code.
Signed-off-by: Heinrich Schuchardt
CC: Joe Perches
CC: David S. Miller
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c
b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 979c698..6cc68b1 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -290,9 +290,10 @@ static void octeon_mgmt_clean_tx_buffers(struct
octeon_mgmt *p)
/* Read the hardware TX timestamp if one was recorded */
if (unlikely(re.s.tstamp)) {
struct skb_shared_hwtstamps ts;
+ u64 ns;
memset(, 0, sizeof(ts));
/* Read the timestamp */
- u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
+ ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
/* Remove the timestamp from the FIFO */
cvmx_write_csr(CVMX_MIXX_TSCTL(p->port), 0);
/* Tell the kernel about the timestamp */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: bluetooth-next 2014-09-14
Hi John, On Sun, Sep 14, 2014, Johan Hedberg wrote: > Here are some more patches intended for 3.18. Most of them are cleanups > or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed > channels which should now work better together with the L2CAP > information request procedure. > > Let me know if there are any issues pulling. Thanks. > > Johan > > --- > The following changes since commit 39e90c77637b3892a39f2908aea57539e961c50e: > > Bluetooth: 6lowpan: Route packets that are not meant to peer via correct > device (2014-09-09 15:51:47 +0200) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git > master This was supposed to be a reference to the for-upstream branch instead of master. Both point to the same commit at this moment but it'd be more convenient if you pull from for-upstream so that the master branch can continue living on without waiting for the pull to happen. Sorry for the extra hassle. Johan pgpqbefFxCb0h.pgp Description: PGP signature
pull request: bluetooth-next 2014-09-14
Hi John, Here are some more patches intended for 3.18. Most of them are cleanups or fixes for SMP. The only exception is a fix for BR/EDR L2CAP fixed channels which should now work better together with the L2CAP information request procedure. Let me know if there are any issues pulling. Thanks. Johan --- The following changes since commit 39e90c77637b3892a39f2908aea57539e961c50e: Bluetooth: 6lowpan: Route packets that are not meant to peer via correct device (2014-09-09 15:51:47 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git master for you to fetch changes up to 9a783a139c32a905825ee0aa9597f485ea461f76: Bluetooth: Fix re-setting RPA as expired when deferring update (2014-09-12 18:34:25 +0200) Johan Hedberg (10): Bluetooth: Fix allowing SMP Signing info PDU Bluetooth: Remove unnecessary early initialization of variable Bluetooth: Fix ignoring unknown SMP authentication requirement bits Bluetooth: Centralize disallowing SMP commands to a single place Bluetooth: Fix SMP security level when we have no IO capabilities Bluetooth: Add smp_ltk_sec_level() helper function Bluetooth: Fix L2CAP information request handling for fixed channels Bluetooth: Avoid hard-coded IO capability values in SMP Bluetooth: Expire RPA if encryption fails Bluetooth: Fix re-setting RPA as expired when deferring update net/bluetooth/hci_core.c | 1 + net/bluetooth/hci_event.c | 11 +--- net/bluetooth/l2cap_core.c | 53 --- net/bluetooth/smp.c| 57 +++--- net/bluetooth/smp.h| 8 ++ 5 files changed, 75 insertions(+), 55 deletions(-) pgp9nhtjDHpk9.pgp Description: PGP signature
"dma-coherent" property inheritance (arm vs arm64)
Hi Catalin,
Sitting here on a flight, I decided to go over a number of patches and
pondering a few things through inspection (my 64-bit ARM servers are in
the overhead bin, I guess I /could/ power them on with the in-seat power
to poke at this...but people around me would probably be even more
weirded out than they are already...so I haven't tested this). Anyway. I
think I have noticed a difference in the inheritance of dma-coherent
properties between 32-and-64-bit ARM systems:.
The behavioral default for dma_ops selection on the 64-bit ARM
architecture was changed by Ritest Harjani upstream on Apr 23 2014:
commit c7a4a7658d689f664050c45493d79adf053f226e
Author: Ritesh Harjani
Date: Wed Apr 23 06:29:46 2014 +0100
arm64: Make default dma_ops to be noncoherent
This prompted you to later send the following patch, adding two bus
notifiers (for AMBA and Platform devices, this is prior to PCI being
upstreamed), intending to allow coherent devices to be marked such:
commit 6ecba8eb51b7d23fda66388a5420be7d8688b186
Author: Catalin Marinas
Date: Fri Apr 25 15:31:45 2014 +0100
arm64: Use bus notifiers to set per-device coherent DMA ops
Thus at this point, on 32-bit systems, we have defined this function:
set_arch_dma_coherent_ops
Which is used to switch the dma_ops for a device to the coherent
methods. For example, and regardless of the architecture, this occurs in
Linux's platform code (platform.c) during device setup:
/*
* if dma-coherent property exist, call arch hook to setup
* dma coherent operations.
*/
if (of_dma_is_coherent(dev->of_node)) {
set_arch_dma_coherent_ops(dev);
dev_dbg(dev, "device is dma coherent\n");
}
Thus when we see this "dma-coherent" entry, we will make the call to set
the dma_ops over to the alternative. However, on AArch64 (or any
non-32-bit ARM architecture using of_ probe for that matter), we do not
define set_arch_dma_coherent_ops specifically, and thus the default
(empty method) is called, resulting in no actual change. Instead, on
AArch64, you rely upon a bus notifier callback that you register for
several bus types (notably there is none for PCI yet, but we'll come
back to that later once there's an upstream story there) that fires and
only responds to the device addition to the bus event thus:
static int dma_bus_notifier(struct notifier_block *nb,
unsigned long event, void *_dev)
{
struct device *dev = _dev;
if (event != BUS_NOTIFY_ADD_DEVICE)
return NOTIFY_DONE;
if (of_property_read_bool(dev->of_node, "dma-coherent"))
set_dma_ops(dev, _swiotlb_dma_ops);
return NOTIFY_OK;
}
This is used whenever an AMBA or Platform device is added to its
respective bus through walking the devicetree at setup time. However,
the logic here differs from that used in the case of the platform code
call taking effect as in the case of 32-bit ARM (drivers/of/address.c):
bool of_dma_is_coherent(struct device_node *np)
{
struct device_node *node = of_node_get(np);
while (node) {
if (of_property_read_bool(node, "dma-coherent")) {
of_node_put(node);
return true;
}
node = of_get_next_parent(node);
}
of_node_put(node);
return false;
}
Notice in the latter case we will walk up the tree and inherit nodes
from parents explicitly. Unless I am mistaken, this is a difference in
logic between the 32-bit and 64-bit cases in terms of DMA inheritance.
Further, I am trying to determine the best mechanism for handling the
case in which the dma-coherent property must be defined for other bus
types, for example the PCI bus (in which case there may not be an entry
for a specific device but we want to inherit the behavior from the Root
Complex bus device). I can just setup a notifier on device addition and
register that against the PCI bus, in which case I would want the 32-bit
ARM behavior of recursing up the tree and inheriting whatever I find
there. I am worried to learn that some are instead reverting the patch
from Ritesh because it makes everything seem all better again...sigh.
Anyway. Perhaps I am wrong and miss-interpreting this. I'm going on code
inspection not runtime since I'm on a long flight and had time to ponder
a few things. I would appreciate your thoughts on whether:
1). Is there a difference between 32-bit and 64-bit architectures?
2). Should this be the case? If it's a bug, should it be changed? Which
one should change? It seems to me that we should inherit from ancestors.
3). How would you recommend to handle the PCI bus case later? As a
notifier similar to that which you use for the other two bus types?
Thanks very much,
Jon.
P.S. Later, on ACPI based 64-bit ARM systems, we will specifically
define the inheritance rules for _CCA (Cache Coherency
Re: [PATCH] Freeing dst when the reference count <0 causes general protection fault, it could be a major security flaw as rogue app can modify dst to crash kernel.
On Sat, 2014-09-13 at 11:35 -0700, shakil A Khan wrote: > On Saturday, September 13, 2014 04:50:22 AM Eric Dumazet wrote: > > On Sat, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote: > > > Signed-off-by: Shakil A Khan > > > --- > > > > > > net/core/dst.c | 5 - > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > diff --git a/net/core/dst.c b/net/core/dst.c > > > index a028409..6a848b0 100644 > > > --- a/net/core/dst.c > > > +++ b/net/core/dst.c > > > @@ -284,7 +284,10 @@ void dst_release(struct dst_entry *dst) > > > > > > int newrefcnt; > > > > > > newrefcnt = atomic_dec_return(>__refcnt); > > > > > > - WARN_ON(newrefcnt < 0); > > > + > > > + if (WARN(newrefcnt < 0, "dst reference count less than zero")) > > > + return; > > > + > > > > > > if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) > > > > > > call_rcu(>rcu_head, dst_destroy_rcu); > > > > > > } > > > > A rogue application can not do trigger this, unless a major bug in the > > kernel exists. > > Please check this kernel trace. It is able to crash the kernel. > > general protection fault: [#1] PREEMPT SMP > Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry > nfsv4 nfs fscache lockd sunrpc tun nbd ipmi_si ipmi_watchdog ipmi_devintf > ipmi_msghandler xt_mark xt_owner ipt_MASQUERADE xt_physdev xt_state xt_LOG > iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 > nf_nat > nf_conntrack iptable_filter ip_tables xen_acpi_processor xen_pciback > xen_netback xen_blkback xen_gntalloc xen_gntdev xenfs xen_privcmd bridge stp > llc ipv6 ext4 jbd2 freq_table mperf coretemp crc32c_intel ghash_clmulni_intel > microcode pcspkr sb_edac edac_core lpc_ich mfd_core i2c_i801 sg ioatdma igb > dca i2c_algo_bit i2c_core ptp pps_core ext3 jbd mbcache sd_mod crc_t10dif > aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 ahci > libahci isci libsas scsi_transport_sas megaraid_sas wmi dm_mirror > dm_region_hash dm_log dm_mod [last unloaded: iTCO_vendor_support] > CPU: 6 PID: 15324 Comm: Not tainted 3.10.45-xen.322.17.41238 #1 > Hardware name: McAfee, Inc. ATD-6000/S4600LH, BIOS > SE5C600.86B.02.01.0002.082220131453 08/22/2013 > task: 882bc6255000 ti: 882bc61aa000 task.ti: 882bc61aa000 > RIP: e030:[] [] > ipv4_dst_destroy+0x3b/0x77 > RSP: e02b:882bc61abb48 EFLAGS: 00010296 > RAX: dead00200200 RBX: 882bc625bc80 RCX: 0001338a9b7110db > RDX: dead00100100 RSI: 82267e30 RDI: 03f4 > RBP: 882bc61abb58 R08: d5d6df8b R09: > R10: R11: R12: > R13: 820e5880 R14: 88070e584b80 R15: > FS: 7f8d3fff2700() GS:88081e6c() knlGS: > CS: e033 DS: ES: CR0: 80050033 > CR2: 0031d0e36ac0 CR3: 002db0165000 CR4: 00042660 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Stack: > 882bc61abb58 882bc625bc80 882bc61abb88 8145bfc5 > 882bc61abba8 882bc625bc80 882bc625bc80 > 882bc61abba8 8145c2c5 88070e584b80 882b991c2300 > Call Trace: > [] dst_destroy+0x29/0xbd > [] dst_release+0x58/0x67 > [] tcp_v4_do_rcv+0x11b/0x287 > [] __release_sock+0x7c/0xe7 > [] release_sock+0x2e/0x7c > [] tcp_sendmsg+0xe0/0xd41 > [] inet_sendmsg+0x7d/0xa0 > [] sock_aio_write+0x159/0x17d > [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e > [] do_sync_write+0x7f/0xa7 > [] ? rw_verify_area+0x56/0xd5 > [] vfs_write+0x144/0x170 > [] SyS_write+0x54/0x8f > [] ? __audit_syscall_exit+0x20c/0x29c > [] system_call_fastpath+0x16/0x1b > Code: fb 48 8d 87 b0 00 00 00 48 39 87 b0 00 00 00 74 4f 48 c7 c7 04 8f 3c 82 > e8 32 23 09 00 48 8b 93 b0 00 00 00 48 8b 83 b8 00 00 00 <48> 89 42 08 48 89 > 10 48 b9 00 01 10 00 00 00 ad de 48 89 8b b0 > RIP [] ipv4_dst_destroy+0x3b/0x77 > RSP > ---[ end trace d56f90482c47af91 ]--- > Kernel panic - not syncing: Fatal exception in interrupt > > > > > > Instead of trying to hide the kernel bug, we need to fix it. > There are two problems with this. First the list has somehow got out of > sync in terms of number of delete and allocate, so we need to fix that. > But at the same time refcount if <0 signifies its been already freed so we > need > not free up. > We need fix for both and my patch targets later as my system works fine with > this patch. > > > > Can you describe how this could trigger with a pristine kernel ? > This is triggered with custom software to imitate malware traffic(Kernel was > not > having any custom patch whatsoever, it was a pristine kernel 3.10.45). > Point is if an application can crash this, then it would be big security flaw > not exactly similar but like
Announcing the new TAB
Last week, the TAB held its first meeting since the TAB elections at Kernel Summit and LinuxCon last month. As is our custom, this meeting included both incoming and outgoing members, and was the chance to bring the new members up to speed as well as say goodbye to those who are completing their terms. I want to say a big thank you to our outgoing members, James Bottomley, Jesse Barnes and Ric Wheeler, who have all served faithfully and done a great job representing our community. I especially want to thank James who has served as the TAB chair since its inception and has tirelessly championed Linux and Open Source developers. Stepping into the TAB are three newly elected members, Kristen Accardi, H. Peter Anvin, and me, Grant Likely. Both Kristen and Peter are well known and respected members of our community, and I'm looking forward working with them. This is Peter's first term on the TAB, while Kristen and I have both served previously. Also, each year the TAB elects a chair to coordinate our meetings and represent the TAB on the Linux Foundation Board of Directors. Normally the chair election is held six months after the TAB general election, but since the chair was held by one of our outgoing members, our first order of business was to elect a new chair. I put my name forward, as did Thomas Gleixner and John Linville. I'm honoured and humbled to announce that the TAB selected me to do the job. I'll work hard to live up to their expectations. The members of the TAB are now: Chair: Grant Likely Vice-chair: Jonathan Corbet Kristen Accardi H. Peter Anvin Matthew Garrett Thomas Gleixner Greg Kroah-Hartman John Linville Chris Mason Sarah Sharp Cheers, g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ASoC: rockchip-i2s: dt: fix an error in the example
Reference to RK3288 TRM, fix an error in the example by swap "tx" and "rx".
Table 10-1 DMAC_BUS Request Mapping Table
Req number Source Polarity
0 I2S tx High level
1 I2S rx High level
Tested on RK3288 board.
Signed-off-by: Jianqun
---
change since v1:
- modify patch's changelog as Mark's suggestion
Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index 6c55fcf..9b82c20 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -31,7 +31,7 @@ i2s@ff89 {
#address-cells = <1>;
#size-cells = <0>;
dmas = < 0>, < 1>;
- dma-names = "rx", "tx";
+ dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = < HCLK_I2S0>, < SCLK_I2S0>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 001/001] IEEE 802.15.4: Add module parameter to mrf24j40 to allow use of external transmitters/receivers
Hi Walter,
> enhance module drivers/net/ieee802154/mrf24j40.c to allow designs that use
> external transmitters/receivers.
>
> Designs that use Microchip's MRF24J40 with external receivers and
> transmitters require the chip to
> be specifically programmed for this, by setting the "test mode register" to
> 0xf.
>
> In my testing, without this flag, I could only receive over a distance of a
> few feet. Setting this flag allows
> distances well above 100 feet.
>
> The patch adds a module parameter module_param(ext_rx_tx, bool, 0). When
> setting the parameter to true,
> the driver configures the "test mode" register of the mrf24j40 device to work
> with external tranmitters and receivers.
>
> patch applies to kernel version:3.16.0-rc4csi-git-dirty, git: commit
> cd3de83f147601356395b57a8673e9c5ff1e59d1
>
> (I'm doing a patch submission the first time. If I'm doing this wrong, I
> would appreciate feedback for how to do this better next time).
comments do not belong in the commit message. And please send patches for IEEE
802.15.4 drivers to linux-w...@vger.kernel.org mailing list.
> Signed-off-by: Walter J. Mack
>
> ---
> diff --git a/drivers/net/ieee802154/mrf24j40.c
> b/drivers/net/ieee802154/mrf24j40.c
> index 4048062..18cff47 100644
> --- a/drivers/net/ieee802154/mrf24j40.c
> +++ b/drivers/net/ieee802154/mrf24j40.c
> @@ -26,6 +26,10 @@
> #include
> #include
>
> +static bool ext_rx_tx = false ;
please fix the coding style here and not need for variable initialization.
> +module_param(ext_rx_tx, bool, 0);
The last parameter is the mode. You might want to use 0444 here at least.
> +MODULE_PARM_DESC(ext_rx_tx, " turn on statemachine to manage external
> tx/rx");
> +
> /* MRF24J40 Short Address Registers */
> #define REG_RXMCR0x00 /* Receive MAC control */
> #define REG_PANIDL 0x01 /* PAN ID (low) */
> @@ -63,6 +67,8 @@
> #define REG_SLPCON10x220
> #define REG_WAKETIMEL 0x222 /* Wake-up Time Match Value Low */
> #define REG_WAKETIMEH 0x223 /* Wake-up Time Match Value High */
> +#define REG_TESTMODE 0x22f /* test mode and state machine control
> register */
> +
> #define REG_RX_FIFO0x300 /* Receive FIFO */
>
> /* Device configuration: Only channels 11-26 on page 0 are supported. */
> @@ -669,6 +675,10 @@ static int mrf24j40_probe(struct spi_device *spi)
> write_short_reg(devrec, REG_RFCTL, 0x0);
> udelay(192);
>
> +if ( false != ext_rx_tx ){
> + write_long_reg(devrec, REG_TESTMODE, 0x0f);
> +}
> +
You need to read the coding style document and follow it.
> /* Set RX Mode. RXMCR<1:0>: 0x0 normal, 0x1 promisc, 0x2 error */
> ret = read_short_reg(devrec, REG_RXMCR, );
> if (ret)
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/2] rockchip-max98090: add driver for rockchip board with max98090
在 09/12/2014 09:42 PM, Mark Brown 写道: > On Fri, Sep 12, 2014 at 03:26:46PM +0800, Jianqun wrote: >> This patch to add driver for rockchip board using a max98090. >> >> Tested on RK3288 using a max98090. > > This appears to have two slightly different copies of the patches > threaded to it... that's a bit confusing. > So sorry for all in the mail thread, I have made a stupid thing ~ since I made many patches at a meantime ~ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: For review: user_namespace(7) man page
On 09/11/2014 08:15 AM, Andy Lutomirski wrote: > On Thu, Sep 11, 2014 at 7:47 AM, Michael Kerrisk (man-pages) > wrote: >> >> So, in the current draft of the setns(2) page, there is >> >> CLONE_NEWNS >> ... >> Since Linux 3.9, CLONE_NEWUSER also automatically implies >> CLONE_FS. >> >> Does that cover your point? Or did you mean that more needs to be said? > > Looks good, although you could add CLONE_THREAD and the rest of the > things implied by CLONE_THREAD if you want to be fancier. Yes, under CLONE_NEWUSER there is also a statement that that flag implies CLONE_THREAD, and elsewhere in the page there is the following text: [[ In addition, CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM can be specified in flags if the caller is single threaded (i.e., it is not sharing its address space with another process or thread). In this case, these flags have no effect. (Note also that specifying CLONE_THREAD automatically implies CLONE_VM, and specifying CLONE_VM automatically implies CLONE_SIGHAND.) If the process is multithreaded, then the use of these flags results in an error. ]] Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: For review: user_namespace(7) man page
On 09/11/2014 08:14 AM, Andy Lutomirski wrote: > On Thu, Sep 11, 2014 at 7:46 AM, Michael Kerrisk (man-pages) > wrote: >> Hi Eric, >> >> On 09/09/2014 09:05 AM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> Hi Andy, and Eric, >>1. The writing process must have the CAP_SETUID (CAP_SETGID) >> capability in the user namespace of the process pid. > > This checked for the opening process (and I don't actually remember > whether it's checked for the writing process). Eric, can you comment? >>> >>> We have to check for the opening processes and that changes was made >>> after I implemented my interface. Pieces of the code appear to also >>> examine the writing process and verify everything applies to it as well. >>> >>> I goofed when I designed the interface originall and had not realized >>> what a classic design error it can be to not restrict by the opening >>> process. >> >> So, I still need some help here. Should the sentence above just read: >> >> 1. The *opening* process must have the CAP_SETUID (CAP_SETGID) >>capability in the user namespace of the process pid. > > I think this is sufficient. > >> >> or must something also be said about the writing process? (If so, i'd >> appreciate a completely formed sentence or two that I can just drop into >> the man page..) > > There might be a restriction there, too, but I think it could be > removed, and I also think that it's unlikely that anyone will > encounter it. Okay. Thanks, Andy. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: rockchip-i2s: dt: swap tx and rx channed request number
在 09/14/2014 12:40 AM, Mark Brown 写道: > On Sat, Sep 13, 2014 at 09:04:41AM +0800, Jianqun wrote: >> Reference to RK3288 TRM, fix an error channel id for i2s tx and rx >> Table 10-1 DMAC_BUS Request Mapping Table >> Req number Source Polarity >> 0I2S tx High level >> 1I2S rx High level > > Applied, thanks. The changelog should've just noted that this is an > error in the example rather than the code or the binding, I was a bit > confused about this. > ok, I will do it -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver
Hi,
On Sat, Sep 13, 2014 at 12:16:01PM +0530, Kishon Vijay Abraham I wrote:
> On Saturday 13 September 2014 12:58 AM, Andy Gross wrote:
> > This patch adds a new driver for the Qualcomm USB 3.0 PHY that exists on
> > some
> > Qualcomm platforms. This driver uses the generic PHY framework and will
> > interact with the DWC3 controller.
>
> Do you have dt documentation for this driver?
see patch 1
> > +static inline void qcom_dwc3_phy_write_readback(
> > + struct qcom_dwc3_usb_phy *phy_dwc3, u32 offset,
> > + const u32 mask, u32 val)
> > +{
> > + u32 write_val, tmp = readl(phy_dwc3->base + offset);
> > +
> > + tmp &= ~mask; /* retain other bits */
> > + write_val = tmp | val;
> > +
> > + writel(write_val, phy_dwc3->base + offset);
> > +
> > + /* Read back to see if val was written */
>
> Does it fail sometime? I'm not sure if this should be present in the
> driver since this looks more of a debug code.
this was mentioned before. Silicon bug.
> > + writel_relaxed(data | SSUSB_CTRL_SS_PHY_RESET,
> > + phy_dwc3->base + SSUSB_PHY_CTRL_REG);
> > + usleep_range(2000, 2200);
>
> use msleep here..
why ? usleep_range() gives the scheduler oportunity to group timers.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/5] ASoC: rockchip-i2s: fix registers' property of rockchip i2s controller
在 09/14/2014 04:57 AM, Sergei Shtylyov 写道:
> Hello.
>
> On 9/13/2014 3:42 AM, Jianqun wrote:
>
>> Reference rockchip I2S controller TRM, modify some registers' property
>> I2S_FIFOLR: read / write, but not volatile, not precious
>> I2S_INTSR: read / write
>> I2S_CLR: volatile, register value will be cleared by read
>
>> Test on RK3288 with max98090.
>
>> Signed-off-by: Jianqun Xu
>> ---
>> sound/soc/rockchip/rockchip_i2s.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>> diff --git a/sound/soc/rockchip/rockchip_i2s.c
>> b/sound/soc/rockchip/rockchip_i2s.c
>> index 1b9b404..6595383 100644
>> --- a/sound/soc/rockchip/rockchip_i2s.c
>> +++ b/sound/soc/rockchip/rockchip_i2s.c
> [...]
>> @@ -385,8 +387,6 @@ static bool rockchip_i2s_volatile_reg(struct device
>> *dev, unsigned int reg)
>> static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
>> {
>> switch (reg) {
>> -case I2S_FIFOLR:
>> -return true;
>> default:
>> return false;
>> }
>
>Shouldn't this be folded into simple *return* false now?
That is more reasonable, thank you.
>
> WBR, Sergei
>
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: rockchip-i2s: enable "hclk" for rockchip I2S controller
在 09/14/2014 12:37 AM, Mark Brown 写道:
> On Sat, Sep 13, 2014 at 08:43:13AM +0800, Jianqun wrote:
>
>> +++ b/sound/soc/rockchip/rockchip_i2s.c
>> @@ -423,6 +423,11 @@ static int rockchip_i2s_probe(struct platform_device
>> *pdev)
>> dev_err(>dev, "Can't retrieve i2s bus clock\n");
>> return PTR_ERR(i2s->hclk);
>> }
>> +ret = clk_prepare_enable(i2s->hclk);
>> +if (ret) {
>> +dev_err(i2s->dev, "hclock enable failed %d\n", ret);
>> +return ret;
>> +}
>
> BTW: you're also missing a clk_disable_unprepare() in the remove path
> here, please send a followup fixing that.
remove function has done the clk_disable_unprepare for "hclk".
One more thing, since "i2s_clk" is enabled at runtime_resume, and is disabled
in runtime_suspend,
hasn't enable in probe, so do the "i2s_clk" to be disabled in remove ?
The current driver has disable in remove.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ASoC: rockchip-i2s: enable "hclk" for rockchip I2S controller
在 09/14/2014 12:36 AM, Mark Brown 写道: > On Sat, Sep 13, 2014 at 08:43:13AM +0800, Jianqun wrote: >> As "hclk" is used for rockchip I2S controller, driver must to enable >> it in probe. > > Applied, again this is a bug fix. How did the original submission get > tested? > The original submission is verified on rk3288 with kernel 3.10, but I had to make patches based on kernel 3.14 +, also our sdk kernel has intalized the kernel in other ways, so I missed the enable but the driver worked well. The new patches is verified on kernel 3.14, so it will easy to test. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: rockchip-i2s: fix registers' property of rockchip i2s controller
在 09/14/2014 12:36 AM, Mark Brown 写道: > On Sat, Sep 13, 2014 at 08:42:12AM +0800, Jianqun wrote: >> Reference rockchip I2S controller TRM, modify some registers' property >> I2S_FIFOLR: read / write, but not volatile, not precious >> I2S_INTSR: read / write >> I2S_CLR: volatile, register value will be cleared by read > > Applied, again this is a bug fix (volatile and precious being wrong seem > like bugs) so should have been earlier in the series. > ok, I'll re-order the patches -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Are You interested?
Greetings, I am Mr.Karim Wattara. a banker, i know that this mail will come to you as a surprise as we have never met before, but need not to worry as I am contacting you independently of my investigation and no one is informed of this communication. I need your urgent Cooperation in transferring the sum of $11.3 Million dollars immediately to your private account.The money has been here in our Bank lying dormant for years now without anybody coming for the claim of it. The fund belong to our deceased Customer Mrs.Joy Lake who perished along with her family since January 31 2000. The Banking laws here does not allow such money to stay more than 15 years,that is the reason why i need your Cooperation in transferring the money to your bank account so that we can use it to secure the future of our both families because i don''t want the money to be recalled to the bank treasury as unclaimed fund. By indicating your interest I will send you the full details on how the business will be executed. Please keep this proposal as a top secret and delete if you are not interested, Best Regards, Karim Wattara. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: rockchip-i2s: fix master mode set bit error
在 09/14/2014 12:35 AM, Mark Brown 写道: > On Sat, Sep 13, 2014 at 08:41:03AM +0800, Jianqun wrote: >> Fix error format set to I2S master or slave mode. >> Test on RK3288 board with max98090. > > Applied. Since this is a bug fix it should be one of the first patches > in the series so that it can be sent to Linus as a fix, bug fixes should > go before any other patches. > got it, I'll do it at new version patch, thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 001/001] IEEE 802.15.4: Add module parameter to mrf24j40 to allow use of external transmitters/receivers
enhance module drivers/net/ieee802154/mrf24j40.c to allow designs that
use external transmitters/receivers.
Designs that use Microchip's MRF24J40 with external receivers and
transmitters require the chip to
be specifically programmed for this, by setting the "test mode register"
to 0xf.
In my testing, without this flag, I could only receive over a distance
of a few feet. Setting this flag allows
distances well above 100 feet.
The patch adds a module parameter module_param(ext_rx_tx, bool, 0). When
setting the parameter to true,
the driver configures the "test mode" register of the mrf24j40 device to
work with external tranmitters and receivers.
patch applies to kernel version:3.16.0-rc4csi-git-dirty, git: commit
cd3de83f147601356395b57a8673e9c5ff1e59d1
(I'm doing a patch submission the first time. If I'm doing this wrong, I
would appreciate feedback for how to do this better next time).
Signed-off-by: Walter J. Mack
---
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
index 4048062..18cff47 100644
--- a/drivers/net/ieee802154/mrf24j40.c
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -26,6 +26,10 @@
#include
#include
+static bool ext_rx_tx = false ;
+module_param(ext_rx_tx, bool, 0);
+MODULE_PARM_DESC(ext_rx_tx, " turn on statemachine to manage external
tx/rx");
+
/* MRF24J40 Short Address Registers */
#define REG_RXMCR0x00 /* Receive MAC control */
#define REG_PANIDL 0x01 /* PAN ID (low) */
@@ -63,6 +67,8 @@
#define REG_SLPCON10x220
#define REG_WAKETIMEL 0x222 /* Wake-up Time Match Value Low */
#define REG_WAKETIMEH 0x223 /* Wake-up Time Match Value High */
+#define REG_TESTMODE 0x22f /* test mode and state machine control
register */
+
#define REG_RX_FIFO0x300 /* Receive FIFO */
/* Device configuration: Only channels 11-26 on page 0 are supported. */
@@ -669,6 +675,10 @@ static int mrf24j40_probe(struct spi_device *spi)
write_short_reg(devrec, REG_RFCTL, 0x0);
udelay(192);
+if ( false != ext_rx_tx ){
+ write_long_reg(devrec, REG_TESTMODE, 0x0f);
+}
+
/* Set RX Mode. RXMCR<1:0>: 0x0 normal, 0x1 promisc, 0x2 error */
ret = read_short_reg(devrec, REG_RXMCR, );
if (ret)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC/PATCH v2 01/10] Add kernel address sanitizer infrastructure.
On 09/10/14 07:31, Andrey Ryabinin wrote:
> Kernel Address sanitizer (KASan) is a dynamic memory error detector. It
> provides
> fast and comprehensive solution for finding use-after-free and out-of-bounds
> bugs.
>
> KASAN uses compile-time instrumentation for checking every memory access,
> therefore fresh GCC >= v5.0.0 required.
>
> This patch only adds infrastructure for kernel address sanitizer. It's not
> available for use yet. The idea and some code was borrowed from [1].
>
> Basic idea:
> The main idea of KASAN is to use shadow memory to record whether each byte of
> memory
> is safe to access or not, and use compiler's instrumentation to check the
> shadow memory
> on each memory access.
>
> Address sanitizer uses 1/8 of the memory addressable in kernel for shadow
> memory
> and uses direct mapping with a scale and offset to translate a memory
> address to its corresponding shadow address.
>
> Here is function to translate address to corresponding shadow address:
>
> unsigned long kasan_mem_to_shadow(unsigned long addr)
> {
> return ((addr - KASAN_SHADOW_START) >>
> KASAN_SHADOW_SCALE_SHIFT)
> + KASAN_SHADOW_START;
> }
> where KASAN_SHADOW_SCALE_SHIFT = 3.
>
> So for every 8 bytes there is one corresponding byte of shadow memory.
> The following encoding used for each shadow byte: 0 means that all 8 bytes of
> the
> corresponding memory region are valid for access; k (1 <= k <= 7) means that
> the first k bytes are valid for access, and other (8 - k) bytes are not;
> Any negative value indicates that the entire 8-bytes are unaccessible.
inaccessible.
> Different negative values used to distinguish between different kinds of
> unaccessible memory (redzones, freed memory) (see mm/kasan/kasan.h).
inaccessible
>
> To be able to detect accesses to bad memory we need a special compiler.
> Such compiler inserts a specific function calls (__asan_load*(addr),
> __asan_store*(addr))
> before each memory access of size 1, 2, 4, 8 or 16.
>
> These functions check whether memory region is valid to access or not by
> checking
> corresponding shadow memory. If access is not valid an error printed.
>
> [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel
>
> Based on work by Andrey Konovalov
>
> Signed-off-by: Andrey Ryabinin
> ---
> Documentation/kasan.txt | 180 ++
> Makefile| 10 ++-
> include/linux/kasan.h | 42 +++
> include/linux/sched.h | 3 +
> lib/Kconfig.debug | 2 +
> lib/Kconfig.kasan | 16 +
> mm/Makefile | 1 +
> mm/kasan/Makefile | 3 +
> mm/kasan/kasan.c| 188
>
> mm/kasan/kasan.h| 32 +
> mm/kasan/report.c | 183 ++
> scripts/Makefile.lib| 10 +++
> 12 files changed, 669 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/kasan.txt
> create mode 100644 include/linux/kasan.h
> create mode 100644 lib/Kconfig.kasan
> create mode 100644 mm/kasan/Makefile
> create mode 100644 mm/kasan/kasan.c
> create mode 100644 mm/kasan/kasan.h
> create mode 100644 mm/kasan/report.c
>
> diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt
> new file mode 100644
> index 000..5a9d903
> --- /dev/null
> +++ b/Documentation/kasan.txt
> @@ -0,0 +1,180 @@
> +Kernel address sanitizer
> +
> +
> +0. Overview
> +===
> +
> +Kernel Address sanitizer (KASan) is a dynamic memory error detector. It
> provides
> +fast and comprehensive solution for finding use-after-free and out-of-bounds
> bugs.
a fast and ...
> +
> +KASAN uses compile-time instrumentation for checking every memory access,
> therefore you
> +will need a special compiler: GCC >= 5.0.0.
> +
> +Currently KASAN supported only for x86_64 architecture and requires kernel
is supported
> +to be build with SLUB allocator.
built
> +
> +1. Usage
> +=
> +
> +KASAN requires the kernel to be built with a special compiler (GCC >= 5.0.0).
> +
> +To enable KASAN configure kernel with:
> +
> + CONFIG_KASAN = y
> +
> +Currently KASAN works only with SLUB.
with the SLUB memory allocator.
> +For better bug detection and nicer report enable CONFIG_STACKTRACE,
> CONFIG_SLUB_DEBUG
report,
> +and put 'slub_debug=FU' to boot cmdline.
in the boot cmdline.
Following sentence is confusing. I'm not sure how to fix it.
> +Please don't use slab poisoning with KASan (slub_debug=P), beacuse if KASan
> will
drop:
will
> +detects use after free allocation and free stacktraces will be overwritten
Re: [PATCH 0/5] usb: phy: samsung: remove old USB PHY code
On 08/23/14 02:14, Bartlomiej Zolnierkiewicz wrote:
Hi,
On Wednesday, August 20, 2014 01:12:44 PM Felipe Balbi wrote:
Hi,
On Thu, Aug 14, 2014 at 04:25:22PM +0200, Bartlomiej Zolnierkiewicz wrote:
Hi,
This patch series removes the old Samsung USB PHY drivers that
got replaced by the new ones using the generic PHY layer.
Depends on:
- next-20140813 branch of linux-next kernel
this thread seems to have died, what do I need to do with these patches?
Please apply them (patches #3, #4 and #5). Patches #1 and #2
should be applied (or Acked-by) by Kukjin Kim.
I've applied #1 and #2, sorry for late taking.
Thanks,
Kukjin
Are we deleting the phy drivers or not ?
Yes, we are deleting them. It has been agreed on by Kishon and
Vivek.
Please rebase on v3.17-rc1 and resend with all Acks in place.
Done:
https://lkml.org/lkml/2014/8/22/446
Please note that if you want to apply it to current -next kernel
(next-20140822) then you need to resolve conflict between patch
#5/5 ("usb: phy: samsung: remove old common USB PHY code") and
commit bbc66e140bab ("usb: phy: samsung: Fix wrong bit mask for
PHYPARAM1_PCS_TXDEEMPH") by simply removing the new version of
drivers/usb/phy/phy-samsung-usb.h file.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- add line after declaration
- remove return statement in empty void function
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 2703609..56604f4 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -805,6 +805,7 @@ struct ion_client *ion_client_create(struct ion_device *dev,
client, _client_fops);
if (!client->debug_root) {
char buf[256], *path;
+
path = dentry_path(dev->clients_debug_root, buf, 256);
pr_err("Failed to create client debugfs at %s/%s\n",
path, client->display_name);
@@ -1056,7 +1057,6 @@ static void *ion_dma_buf_kmap(struct dma_buf *dmabuf,
unsigned long offset)
static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
void *ptr)
{
- return;
}
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: fix coding style
- add line after declaration
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/sync.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index e7b2e02..0d37495 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -705,6 +705,7 @@ static long sync_fence_ioctl(struct file *file, unsigned
int cmd,
unsigned long arg)
{
struct sync_fence *fence = file->private_data;
+
switch (cmd) {
case SYNC_IOC_WAIT:
return sync_fence_ioctl_wait(fence, arg);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: fix coding style
- add line after declaration
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/sw_sync.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/android/sw_sync.c
b/drivers/staging/android/sw_sync.c
index a76db3f..863d4b1 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -97,6 +97,7 @@ static void sw_sync_pt_value_str(struct sync_pt *sync_pt,
char *str, int size)
{
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
+
snprintf(str, size, "%d", pt->value);
}
@@ -156,6 +157,7 @@ static int sw_sync_open(struct inode *inode, struct file
*file)
static int sw_sync_release(struct inode *inode, struct file *file)
{
struct sw_sync_timeline *obj = file->private_data;
+
sync_timeline_destroy(>obj);
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- remove return statement in empty void function
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/ion/ion_system_heap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_system_heap.c
b/drivers/staging/android/ion/ion_system_heap.c
index 6b77c51..da2a63c 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -205,7 +205,6 @@ static struct sg_table *ion_system_heap_map_dma(struct
ion_heap *heap,
static void ion_system_heap_unmap_dma(struct ion_heap *heap,
struct ion_buffer *buffer)
{
- return;
}
static int ion_system_heap_shrink(struct ion_heap *heap, gfp_t gfp_mask,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- remove return statement in void function Signed-off-by: Sorin Facaoaru --- drivers/staging/android/ion/ion_dummy_driver.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/android/ion/ion_dummy_driver.c b/drivers/staging/android/ion/ion_dummy_driver.c index 3a45e79..ce606bd 100644 --- a/drivers/staging/android/ion/ion_dummy_driver.c +++ b/drivers/staging/android/ion/ion_dummy_driver.c @@ -152,7 +152,5 @@ static void __exit ion_dummy_exit(void) dummy_heaps[ION_HEAP_TYPE_CHUNK].size); chunk_ptr = NULL; } - - return; } __exitcall(ion_dummy_exit); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- remove return statement in empty void function
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/ion/ion_chunk_heap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
b/drivers/staging/android/ion/ion_chunk_heap.c
index 9c3e49a..3e6ec2e 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -126,7 +126,6 @@ static struct sg_table *ion_chunk_heap_map_dma(struct
ion_heap *heap,
static void ion_chunk_heap_unmap_dma(struct ion_heap *heap,
struct ion_buffer *buffer)
{
- return;
}
static struct ion_heap_ops chunk_heap_ops = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- remove return statement in empty void function
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/ion/ion_carveout_heap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
b/drivers/staging/android/ion/ion_carveout_heap.c
index dcb6f21..9156d82 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -133,7 +133,6 @@ static struct sg_table *ion_carveout_heap_map_dma(struct
ion_heap *heap,
static void ion_carveout_heap_unmap_dma(struct ion_heap *heap,
struct ion_buffer *buffer)
{
- return;
}
static struct ion_heap_ops carveout_heap_ops = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] x86/efi: introduce EFI_BOOT_SERVICES_WARN
On Sat, Sep 13, 2014 at 11:36:16AM -0700, Ricardo Neri wrote: > Being more verbose about this kind of illegal access from the firmware > increases the likelihood of this kind firmware bugs to be fixed. I sincerely hope you're right and, more importantly, how do we make sure those warnings get seen in time for a fix to even be possible..? -- Regards/Gruss, Boris. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Staging: android: ion: fix coding style
- add line after declaration
- remove return statement in empty void function
Signed-off-by: Sorin Facaoaru
---
drivers/staging/android/ion/ion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 2703609..56604f4 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -805,6 +805,7 @@ struct ion_client *ion_client_create(struct ion_device *dev,
client, _client_fops);
if (!client->debug_root) {
char buf[256], *path;
+
path = dentry_path(dev->clients_debug_root, buf, 256);
pr_err("Failed to create client debugfs at %s/%s\n",
path, client->display_name);
@@ -1056,7 +1057,6 @@ static void *ion_dma_buf_kmap(struct dma_buf *dmabuf,
unsigned long offset)
static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
void *ptr)
{
- return;
}
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] blk-mq: unshared timeout handler
Duplicate the (small) timeout handler in blk-mq so that we can pass
arguments more easily to the driver timeout handler. This enables
the next patch.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 53 +
block/blk-timeout.c | 8 ++--
block/blk.h | 2 --
3 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 2d96b0d..c14d397 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -511,9 +511,15 @@ struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags,
unsigned int tag)
}
EXPORT_SYMBOL(blk_mq_tag_to_rq);
-static enum blk_eh_timer_return blk_mq_rq_timed_out(struct request *rq)
+struct blk_mq_timeout_data {
+ unsigned long next;
+ unsigned int next_set;
+};
+
+static void blk_mq_rq_timed_out(struct request *req)
{
- struct request_queue *q = rq->q;
+ struct blk_mq_ops *ops = req->q->mq_ops;
+ enum blk_eh_timer_return ret = BLK_EH_RESET_TIMER;
/*
* We know that complete is set at this point. If STARTED isn't set
@@ -524,27 +530,43 @@ static enum blk_eh_timer_return
blk_mq_rq_timed_out(struct request *rq)
* we both flags will get cleared. So check here again, and ignore
* a timeout event with a request that isn't active.
*/
- if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
- return BLK_EH_NOT_HANDLED;
-
- if (!q->mq_ops->timeout)
- return BLK_EH_RESET_TIMER;
+ if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
+ return;
- return q->mq_ops->timeout(rq);
+ if (ops->timeout)
+ ret = ops->timeout(req);
+
+ switch (ret) {
+ case BLK_EH_HANDLED:
+ __blk_mq_complete_request(req);
+ break;
+ case BLK_EH_RESET_TIMER:
+ blk_add_timer(req);
+ blk_clear_rq_complete(req);
+ break;
+ case BLK_EH_NOT_HANDLED:
+ break;
+ default:
+ printk(KERN_ERR "block: bad eh return: %d\n", ret);
+ break;
+ }
}
-struct blk_mq_timeout_data {
- unsigned long next;
- unsigned int next_set;
-};
-
static void blk_mq_check_expired(struct blk_mq_hw_ctx *hctx,
struct request *rq, void *priv, bool reserved)
{
struct blk_mq_timeout_data *data = priv;
- if (test_bit(REQ_ATOM_STARTED, >atomic_flags))
- blk_rq_check_expired(rq, >next, >next_set);
+ if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
+ return;
+
+ if (time_after_eq(jiffies, rq->deadline)) {
+ if (!blk_mark_rq_complete(rq))
+ blk_mq_rq_timed_out(rq);
+ } else if (!data->next_set || time_after(data->next, rq->deadline)) {
+ data->next = rq->deadline;
+ data->next_set = 1;
+ }
}
static void blk_mq_rq_timer(unsigned long priv)
@@ -1770,7 +1792,6 @@ struct request_queue *blk_mq_init_queue(struct
blk_mq_tag_set *set)
else
blk_queue_make_request(q, blk_sq_make_request);
- blk_queue_rq_timed_out(q, blk_mq_rq_timed_out);
if (set->timeout)
blk_queue_rq_timeout(q, set->timeout);
diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 95a0959..4d44825 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -7,7 +7,6 @@
#include
#include "blk.h"
-#include "blk-mq.h"
#ifdef CONFIG_FAIL_IO_TIMEOUT
@@ -90,10 +89,7 @@ static void blk_rq_timed_out(struct request *req)
switch (ret) {
case BLK_EH_HANDLED:
/* Can we use req->errors here? */
- if (q->mq_ops)
- __blk_mq_complete_request(req);
- else
- __blk_complete_request(req);
+ __blk_complete_request(req);
break;
case BLK_EH_RESET_TIMER:
blk_add_timer(req);
@@ -113,7 +109,7 @@ static void blk_rq_timed_out(struct request *req)
}
}
-void blk_rq_check_expired(struct request *rq, unsigned long *next_timeout,
+static void blk_rq_check_expired(struct request *rq, unsigned long
*next_timeout,
unsigned int *next_set)
{
if (time_after_eq(jiffies, rq->deadline)) {
diff --git a/block/blk.h b/block/blk.h
index 6748c4f..e515a28 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -38,8 +38,6 @@ bool __blk_end_bidi_request(struct request *rq, int error,
unsigned int nr_bytes, unsigned int bidi_bytes);
void blk_rq_timed_out_timer(unsigned long data);
-void blk_rq_check_expired(struct request *rq, unsigned long *next_timeout,
- unsigned int *next_set);
unsigned long blk_rq_timeout(unsigned long timeout);
void blk_add_timer(struct request *req);
void blk_delete_timer(struct request *);
--
1.9.1
--
To unsubscribe from this list:
[PATCH 6/6] blk-mq: pass a reserved argument to the timeout handler
Allow blk-mq to pass an argument to the timeout handler to indicate
if we're timing out a reserved or regular command. For many drivers
those need to be handled different.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c | 6 +++---
drivers/scsi/scsi_lib.c | 10 +-
include/linux/blk-mq.h | 3 ++-
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c14d397..85eb540 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -516,7 +516,7 @@ struct blk_mq_timeout_data {
unsigned int next_set;
};
-static void blk_mq_rq_timed_out(struct request *req)
+static void blk_mq_rq_timed_out(struct request *req, bool reserved)
{
struct blk_mq_ops *ops = req->q->mq_ops;
enum blk_eh_timer_return ret = BLK_EH_RESET_TIMER;
@@ -534,7 +534,7 @@ static void blk_mq_rq_timed_out(struct request *req)
return;
if (ops->timeout)
- ret = ops->timeout(req);
+ ret = ops->timeout(req, reserved);
switch (ret) {
case BLK_EH_HANDLED:
@@ -562,7 +562,7 @@ static void blk_mq_check_expired(struct blk_mq_hw_ctx *hctx,
if (time_after_eq(jiffies, rq->deadline)) {
if (!blk_mark_rq_complete(rq))
- blk_mq_rq_timed_out(rq);
+ blk_mq_rq_timed_out(rq, reserved);
} else if (!data->next_set || time_after(data->next, rq->deadline)) {
data->next = rq->deadline;
data->next_set = 1;
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index e95adaa..dc01ab2 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1932,6 +1932,14 @@ out:
return ret;
}
+static enum blk_eh_timer_return scsi_timeout(struct request *req,
+ bool reserved)
+{
+ if (reserved)
+ return BLK_EH_RESET_TIMER;
+ return scsi_times_out(req);
+}
+
static int scsi_init_request(void *data, struct request *rq,
unsigned int hctx_idx, unsigned int request_idx,
unsigned int numa_node)
@@ -2043,7 +2051,7 @@ static struct blk_mq_ops scsi_mq_ops = {
.map_queue = blk_mq_map_queue,
.queue_rq = scsi_queue_rq,
.complete = scsi_softirq_done,
- .timeout= scsi_times_out,
+ .timeout= scsi_timeout,
.init_request = scsi_init_request,
.exit_request = scsi_exit_request,
};
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 0eb0f64..3253495 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -79,6 +79,7 @@ struct blk_mq_tag_set {
typedef int (queue_rq_fn)(struct blk_mq_hw_ctx *, struct request *, bool);
typedef struct blk_mq_hw_ctx *(map_queue_fn)(struct request_queue *, const
int);
+typedef enum blk_eh_timer_return (timeout_fn)(struct request *, bool);
typedef int (init_hctx_fn)(struct blk_mq_hw_ctx *, void *, unsigned int);
typedef void (exit_hctx_fn)(struct blk_mq_hw_ctx *, unsigned int);
typedef int (init_request_fn)(void *, struct request *, unsigned int,
@@ -103,7 +104,7 @@ struct blk_mq_ops {
/*
* Called on request timeout
*/
- rq_timed_out_fn *timeout;
+ timeout_fn *timeout;
softirq_done_fn *complete;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] blk-mq: call blk_mq_start_request from ->queue_rq
When we call blk_mq_start_request from the core blk-mq code before calling into
->queue_rq there is a racy window where the timeout handler can hit before we've
fully set up the driver specific part of the command.
Move the call to blk_mq_start_request into the driver so the driver can start
the request only once it is fully set up.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c| 13 ++---
drivers/block/mtip32xx/mtip32xx.c | 2 ++
drivers/block/null_blk.c | 2 ++
drivers/block/virtio_blk.c| 2 ++
drivers/scsi/scsi_lib.c | 1 +
include/linux/blk-mq.h| 1 +
6 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 42c94c8..cab 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -380,7 +380,7 @@ void blk_mq_complete_request(struct request *rq)
}
EXPORT_SYMBOL(blk_mq_complete_request);
-static void blk_mq_start_request(struct request *rq)
+void blk_mq_start_request(struct request *rq)
{
struct request_queue *q = rq->q;
@@ -412,16 +412,18 @@ static void blk_mq_start_request(struct request *rq)
rq->nr_phys_segments++;
}
}
+EXPORT_SYMBOL(blk_mq_start_request);
static void __blk_mq_requeue_request(struct request *rq)
{
struct request_queue *q = rq->q;
trace_block_rq_requeue(q, rq);
- clear_bit(REQ_ATOM_STARTED, >atomic_flags);
- if (q->dma_drain_size && blk_rq_bytes(rq))
- rq->nr_phys_segments--;
+ if (test_and_clear_bit(REQ_ATOM_STARTED, >atomic_flags)) {
+ if (q->dma_drain_size && blk_rq_bytes(rq))
+ rq->nr_phys_segments--;
+ }
}
void blk_mq_requeue_request(struct request *rq)
@@ -729,8 +731,6 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx
*hctx)
rq = list_first_entry(_list, struct request, queuelist);
list_del_init(>queuelist);
- blk_mq_start_request(rq);
-
ret = q->mq_ops->queue_rq(hctx, rq, list_empty(_list));
switch (ret) {
case BLK_MQ_RQ_QUEUE_OK:
@@ -1177,7 +1177,6 @@ static void blk_mq_make_request(struct request_queue *q,
struct bio *bio)
int ret;
blk_mq_bio_to_request(rq, bio);
- blk_mq_start_request(rq);
/*
* For OK queue, we are done. For error, kill it. Any other
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 0e2084f..4042440 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3783,6 +3783,8 @@ static int mtip_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *rq,
if (unlikely(mtip_check_unal_depth(hctx, rq)))
return BLK_MQ_RQ_QUEUE_BUSY;
+ blk_mq_start_request(rq);
+
ret = mtip_submit_request(hctx, rq);
if (likely(!ret))
return BLK_MQ_RQ_QUEUE_OK;
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index c5b7315..332ce20 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -321,6 +321,8 @@ static int null_queue_rq(struct blk_mq_hw_ctx *hctx, struct
request *rq,
cmd->rq = rq;
cmd->nq = hctx->driver_data;
+ blk_mq_start_request(rq);
+
null_handle_cmd(cmd);
return BLK_MQ_RQ_QUEUE_OK;
}
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 13756e0..83816bf 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -205,6 +205,8 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req,
}
}
+ blk_mq_start_request(req);
+
num = blk_rq_map_sg(hctx->queue, vbr->req, vbr->sg);
if (num) {
if (rq_data_dir(vbr->req) == WRITE)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 1ec00ba..b06a355 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1890,6 +1890,7 @@ static int scsi_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req,
scsi_init_cmd_errh(cmd);
cmd->scsi_done = scsi_mq_done;
+ blk_mq_start_request(req);
reason = scsi_dispatch_cmd(cmd);
if (reason) {
scsi_set_blocked(cmd, reason);
diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 9c4e306..878b6f7 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -159,6 +159,7 @@ struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags,
unsigned int tag);
struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *, const int
ctx_index);
struct blk_mq_hw_ctx *blk_mq_alloc_single_hw_queue(struct blk_mq_tag_set *,
unsigned int, int);
+void blk_mq_start_request(struct request *rq);
void blk_mq_end_io(struct request *rq, int error);
void __blk_mq_end_io(struct request *rq, int error);
--
1.9.1
--
To unsubscribe from this list: send
[PATCH 3/6] blk-mq: rename blk_mq_end_io to blk_mq_end_request
Now that we've changed the driver API on the submission side use the
opportunity to fix up the name on the completion side to fit into the
general scheme.
Signed-off-by: Christoph Hellwig
---
block/blk-flush.c | 4 ++--
block/blk-mq.c| 16
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
drivers/block/null_blk.c | 2 +-
drivers/block/virtio_blk.c| 2 +-
drivers/scsi/scsi_lib.c | 4 ++--
include/linux/blk-mq.h| 4 ++--
7 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/block/blk-flush.c b/block/blk-flush.c
index 3cb5e9e..698e692 100644
--- a/block/blk-flush.c
+++ b/block/blk-flush.c
@@ -202,7 +202,7 @@ static bool blk_flush_complete_seq(struct request *rq,
unsigned int seq,
list_del_init(>flush.list);
blk_flush_restore_request(rq);
if (q->mq_ops)
- blk_mq_end_io(rq, error);
+ blk_mq_end_request(rq, error);
else
__blk_end_request_all(rq, error);
break;
@@ -378,7 +378,7 @@ void blk_insert_flush(struct request *rq)
*/
if (!policy) {
if (q->mq_ops)
- blk_mq_end_io(rq, 0);
+ blk_mq_end_request(rq, 0);
else
__blk_end_bidi_request(rq, 0, 0, 0);
return;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index cab..d1230ea 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -296,7 +296,7 @@ void blk_mq_clone_flush_request(struct request *flush_rq,
hctx->cmd_size);
}
-inline void __blk_mq_end_io(struct request *rq, int error)
+inline void __blk_mq_end_request(struct request *rq, int error)
{
blk_account_io_done(rq);
@@ -308,15 +308,15 @@ inline void __blk_mq_end_io(struct request *rq, int error)
blk_mq_free_request(rq);
}
}
-EXPORT_SYMBOL(__blk_mq_end_io);
+EXPORT_SYMBOL(__blk_mq_end_request);
-void blk_mq_end_io(struct request *rq, int error)
+void blk_mq_end_request(struct request *rq, int error)
{
if (blk_update_request(rq, error, blk_rq_bytes(rq)))
BUG();
- __blk_mq_end_io(rq, error);
+ __blk_mq_end_request(rq, error);
}
-EXPORT_SYMBOL(blk_mq_end_io);
+EXPORT_SYMBOL(blk_mq_end_request);
static void __blk_mq_complete_request_remote(void *data)
{
@@ -356,7 +356,7 @@ void __blk_mq_complete_request(struct request *rq)
struct request_queue *q = rq->q;
if (!q->softirq_done_fn)
- blk_mq_end_io(rq, rq->errors);
+ blk_mq_end_request(rq, rq->errors);
else
blk_mq_ipi_complete_request(rq);
}
@@ -744,7 +744,7 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx
*hctx)
pr_err("blk-mq: bad return on queue: %d\n", ret);
case BLK_MQ_RQ_QUEUE_ERROR:
rq->errors = -EIO;
- blk_mq_end_io(rq, rq->errors);
+ blk_mq_end_request(rq, rq->errors);
break;
}
@@ -1191,7 +1191,7 @@ static void blk_mq_make_request(struct request_queue *q,
struct bio *bio)
if (ret == BLK_MQ_RQ_QUEUE_ERROR) {
rq->errors = -EIO;
- blk_mq_end_io(rq, rq->errors);
+ blk_mq_end_request(rq, rq->errors);
goto done;
}
}
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 4042440..6b7e8d0 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -247,7 +247,7 @@ static void mtip_async_complete(struct mtip_port *port,
if (unlikely(cmd->unaligned))
up(>cmd_slot_unal);
- blk_mq_end_io(rq, status ? -EIO : 0);
+ blk_mq_end_request(rq, status ? -EIO : 0);
}
/*
@@ -3739,7 +3739,7 @@ static int mtip_submit_request(struct blk_mq_hw_ctx
*hctx, struct request *rq)
int err;
err = mtip_send_trim(dd, blk_rq_pos(rq), blk_rq_sectors(rq));
- blk_mq_end_io(rq, err);
+ blk_mq_end_request(rq, err);
return 0;
}
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 332ce20..ac50a29 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -177,7 +177,7 @@ static void end_cmd(struct nullb_cmd *cmd)
{
switch (queue_mode) {
case NULL_Q_MQ:
- blk_mq_end_io(cmd->rq, 0);
+ blk_mq_end_request(cmd->rq, 0);
return;
case NULL_Q_RQ:
INIT_LIST_HEAD(>rq->queuelist);
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 83816bf..f751fc3 100644
--- a/drivers/block/virtio_blk.c
+++
[PATCH 4/6] blk-mq: fix and simplify tag iteration for the timeout handler
Don't do a kmalloc from timer to handle timeouts, chances are we could be
under heavy load or similar and thus just miss out on the timeouts.
Fortunately it is very easy to just iterate over all in use tags, and doing
this properly actually cleans up the blk_mq_busy_iter API as well, and
prepares us for the next patch by passing a reserved argument to the
iterator.
Signed-off-by: Christoph Hellwig
---
block/blk-mq-tag.c | 46 +++---
block/blk-mq.c | 85 +++--
include/linux/blk-mq.h | 6 +++-
include/scsi/scsi_tcq.h | 2 +-
4 files changed, 50 insertions(+), 89 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index c1b9242..d6ea458 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -392,45 +392,37 @@ void blk_mq_put_tag(struct blk_mq_hw_ctx *hctx, unsigned
int tag,
__blk_mq_put_reserved_tag(tags, tag);
}
-static void bt_for_each_free(struct blk_mq_bitmap_tags *bt,
-unsigned long *free_map, unsigned int off)
+static void bt_for_each(struct blk_mq_hw_ctx *hctx,
+ struct blk_mq_bitmap_tags *bt, unsigned int off,
+ busy_iter_fn *fn, void *data, bool reserved)
{
- int i;
+ struct request *rq;
+ int bit, i;
for (i = 0; i < bt->map_nr; i++) {
struct blk_align_bitmap *bm = >map[i];
- int bit = 0;
-
- do {
- bit = find_next_zero_bit(>word, bm->depth, bit);
- if (bit >= bm->depth)
- break;
- __set_bit(bit + off, free_map);
- bit++;
- } while (1);
+ for (bit = find_first_bit(>word, bm->depth);
+bit < bm->depth;
+bit = find_next_bit(>word, bm->depth, bit + 1)) {
+ rq = blk_mq_tag_to_rq(hctx->tags, off + bit);
+ if (rq->q == hctx->queue)
+ fn(hctx, rq, data, reserved);
+ }
off += (1 << bt->bits_per_word);
}
}
-void blk_mq_tag_busy_iter(struct blk_mq_tags *tags,
- void (*fn)(void *, unsigned long *), void *data)
+void blk_mq_tag_busy_iter(struct blk_mq_hw_ctx *hctx, busy_iter_fn *fn,
+ void *priv)
{
- unsigned long *tag_map;
- size_t map_size;
-
- map_size = ALIGN(tags->nr_tags, BITS_PER_LONG) / BITS_PER_LONG;
- tag_map = kzalloc(map_size * sizeof(unsigned long), GFP_ATOMIC);
- if (!tag_map)
- return;
-
- bt_for_each_free(>bitmap_tags, tag_map, tags->nr_reserved_tags);
- if (tags->nr_reserved_tags)
- bt_for_each_free(>breserved_tags, tag_map, 0);
+ struct blk_mq_tags *tags = hctx->tags;
- fn(data, tag_map);
- kfree(tag_map);
+ if (tags->nr_reserved_tags)
+ bt_for_each(hctx, >breserved_tags, 0, fn, priv, true);
+ bt_for_each(hctx, >bitmap_tags, tags->nr_reserved_tags, fn, priv,
+ false);
}
EXPORT_SYMBOL(blk_mq_tag_busy_iter);
diff --git a/block/blk-mq.c b/block/blk-mq.c
index d1230ea..2d96b0d 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -511,58 +511,6 @@ struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags,
unsigned int tag)
}
EXPORT_SYMBOL(blk_mq_tag_to_rq);
-struct blk_mq_timeout_data {
- struct blk_mq_hw_ctx *hctx;
- unsigned long *next;
- unsigned int *next_set;
-};
-
-static void blk_mq_timeout_check(void *__data, unsigned long *free_tags)
-{
- struct blk_mq_timeout_data *data = __data;
- struct blk_mq_hw_ctx *hctx = data->hctx;
- unsigned int tag;
-
-/* It may not be in flight yet (this is where
-* the REQ_ATOMIC_STARTED flag comes in). The requests are
-* statically allocated, so we know it's always safe to access the
-* memory associated with a bit offset into ->rqs[].
-*/
- tag = 0;
- do {
- struct request *rq;
-
- tag = find_next_zero_bit(free_tags, hctx->tags->nr_tags, tag);
- if (tag >= hctx->tags->nr_tags)
- break;
-
- rq = blk_mq_tag_to_rq(hctx->tags, tag++);
- if (rq->q != hctx->queue)
- continue;
- if (!test_bit(REQ_ATOM_STARTED, >atomic_flags))
- continue;
-
- blk_rq_check_expired(rq, data->next, data->next_set);
- } while (1);
-}
-
-static void blk_mq_hw_ctx_check_timeout(struct blk_mq_hw_ctx *hctx,
- unsigned long *next,
- unsigned int *next_set)
-{
- struct blk_mq_timeout_data data = {
- .hctx = hctx,
- .next = next,
- .next_set = next_set,
- };
-
blk-mq timeout handling fixes
This series fixes various issues with timeout handling that Robert ran into when testing scsi-mq heavily. He tested an earlier version, and couldn't reproduce the issues anymore, although the series changed quite significantly since and should probably be retested. In summary we not only start the blk-mq timer inside the drivers ->queue_rq method after the request has been fully setup, and we also tell the drivers if we're timing out a reserved (internal) request or a real one. Many drivers including will need to handle those internal ones differently, e.g. for scsi-mq we don't even have a scsi command structure allocated for the reserved commands. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blk-mq: remove REQ_END
Pass an explicit parameter for the last request in a batch to ->queue_rq
instead of using a request flag. Besides being a cleaner and non-stateful
interface this is also required for the next patch, which fixes the blk-mq
I/O submission code to not start a time too early.
Signed-off-by: Christoph Hellwig
---
block/blk-mq.c| 22 +-
drivers/block/mtip32xx/mtip32xx.c | 3 ++-
drivers/block/null_blk.c | 3 ++-
drivers/block/virtio_blk.c| 4 ++--
drivers/scsi/scsi_lib.c | 3 ++-
include/linux/blk-mq.h| 2 +-
include/linux/blk_types.h | 2 --
7 files changed, 14 insertions(+), 25 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 383ea0c..42c94c8 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -380,7 +380,7 @@ void blk_mq_complete_request(struct request *rq)
}
EXPORT_SYMBOL(blk_mq_complete_request);
-static void blk_mq_start_request(struct request *rq, bool last)
+static void blk_mq_start_request(struct request *rq)
{
struct request_queue *q = rq->q;
@@ -411,16 +411,6 @@ static void blk_mq_start_request(struct request *rq, bool
last)
*/
rq->nr_phys_segments++;
}
-
- /*
-* Flag the last request in the series so that drivers know when IO
-* should be kicked off, if they don't do it on a per-request basis.
-*
-* Note: the flag isn't the only condition drivers should do kick off.
-* If drive is busy, the last request might not have the bit set.
-*/
- if (last)
- rq->cmd_flags |= REQ_END;
}
static void __blk_mq_requeue_request(struct request *rq)
@@ -430,8 +420,6 @@ static void __blk_mq_requeue_request(struct request *rq)
trace_block_rq_requeue(q, rq);
clear_bit(REQ_ATOM_STARTED, >atomic_flags);
- rq->cmd_flags &= ~REQ_END;
-
if (q->dma_drain_size && blk_rq_bytes(rq))
rq->nr_phys_segments--;
}
@@ -741,9 +729,9 @@ static void __blk_mq_run_hw_queue(struct blk_mq_hw_ctx
*hctx)
rq = list_first_entry(_list, struct request, queuelist);
list_del_init(>queuelist);
- blk_mq_start_request(rq, list_empty(_list));
+ blk_mq_start_request(rq);
- ret = q->mq_ops->queue_rq(hctx, rq);
+ ret = q->mq_ops->queue_rq(hctx, rq, list_empty(_list));
switch (ret) {
case BLK_MQ_RQ_QUEUE_OK:
queued++;
@@ -1189,14 +1177,14 @@ static void blk_mq_make_request(struct request_queue
*q, struct bio *bio)
int ret;
blk_mq_bio_to_request(rq, bio);
- blk_mq_start_request(rq, true);
+ blk_mq_start_request(rq);
/*
* For OK queue, we are done. For error, kill it. Any other
* error (busy), just add it to our list as we previously
* would have done
*/
- ret = q->mq_ops->queue_rq(data.hctx, rq);
+ ret = q->mq_ops->queue_rq(data.hctx, rq, true);
if (ret == BLK_MQ_RQ_QUEUE_OK)
goto done;
else {
diff --git a/drivers/block/mtip32xx/mtip32xx.c
b/drivers/block/mtip32xx/mtip32xx.c
index 5c8e7fe..0e2084f 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -3775,7 +3775,8 @@ static bool mtip_check_unal_depth(struct blk_mq_hw_ctx
*hctx,
return false;
}
-static int mtip_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *rq)
+static int mtip_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *rq,
+ bool last)
{
int ret;
diff --git a/drivers/block/null_blk.c b/drivers/block/null_blk.c
index 00d469c..c5b7315 100644
--- a/drivers/block/null_blk.c
+++ b/drivers/block/null_blk.c
@@ -313,7 +313,8 @@ static void null_request_fn(struct request_queue *q)
}
}
-static int null_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *rq)
+static int null_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *rq,
+ bool last)
{
struct nullb_cmd *cmd = blk_mq_rq_to_pdu(rq);
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 0a58140..13756e0 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -164,14 +164,14 @@ static void virtblk_done(struct virtqueue *vq)
spin_unlock_irqrestore(>vqs[qid].lock, flags);
}
-static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
+static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req,
+ bool last)
{
struct virtio_blk *vblk = hctx->queue->queuedata;
struct virtblk_req *vbr = blk_mq_rq_to_pdu(req);
unsigned long flags;
unsigned int num;
int qid = hctx->queue_num;
- const bool last = (req->cmd_flags & REQ_END) != 0;
Re: [PATCH] tpm: merge duplicate transmit_cmd() functions
Hi On Sat, Sep 13, 2014 at 11:13:53PM +0200, Peter Hüwe wrote: > Hi > > > Am Samstag, 13. September 2014, 19:35:33 schrieb Jarkko Sakkinen: > > Replaced transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c > > with a single tpm_transmit_cmd() that can be used in both files. > > > > This patch is preliminary clean up work for the TPM2 support. This > > function is needed for implementing TPM2 versions of the in-kernel > > TPM utility functions. > > > > Signed-off-by: Jarkko Sakkinen > > why the renaming? Because all the other non-static functions have tpm_ prefix. > > > > ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf, > > size_t bufsiz); > Can this be removed then? Yes, it could be declared as a static function in tpm-interface.c and removed from tpm.h. I'll make this change and send a revised patch. > > +ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, > > +int len, const char *desc); > > extern int tpm_get_timeouts(struct tpm_chip *); > > extern void tpm_gen_interrupt(struct tpm_chip *); > > extern int tpm_do_selftest(struct tpm_chip *); > > > > Peter /Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iio: adc: rockchip_saradc: add support for rk3066-tsadc variant
Heiko Stübner schrieb, Am 11.09.2014 00:22:
> Older Rockchip SoCs, at least the rk3066, used a slightly modified saradc
> for temperature measurements. This so called tsadc does not contain any
> active parts like temperature interrupts and only supports polling the
> current temperature. The returned voltage can then be converted by a
> suitable thermal driver to and actual temperature and used for thermal
> handling.
>
Looking over it again, I have a two more comments inline.
> Signed-off-by: Heiko Stuebner
> ---
> changes since v1:
> - use GENMASK instead of creating the mask manually
> as suggested by Hartmut Knaack
>
> I've also opted for simply keeping the indent mismatch in
> struct rockchip_saradc, as I don't think it's worth the churn
> it produces
>
> .../bindings/iio/adc/rockchip-saradc.txt | 2 +-
> drivers/iio/adc/rockchip_saradc.c | 62
> +-
> 2 files changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
> b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
> index 5d3ec1d..a9a5fe1 100644
> --- a/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/rockchip-saradc.txt
> @@ -1,7 +1,7 @@
> Rockchip Successive Approximation Register (SAR) A/D Converter bindings
>
> Required properties:
> -- compatible: Should be "rockchip,saradc"
> +- compatible: Should be "rockchip,saradc" or "rockchip,rk3066-tsadc"
> - reg: physical base address of the controller and length of memory mapped
> region.
> - interrupts: The interrupt number to the cpu. The interrupt specifier format
> diff --git a/drivers/iio/adc/rockchip_saradc.c
> b/drivers/iio/adc/rockchip_saradc.c
> index e074a0b..99200b7 100644
> --- a/drivers/iio/adc/rockchip_saradc.c
> +++ b/drivers/iio/adc/rockchip_saradc.c
> @@ -18,13 +18,13 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
>
> #define SARADC_DATA 0x00
> -#define SARADC_DATA_MASK 0x3ff
>
> #define SARADC_STAS 0x04
> #define SARADC_STAS_BUSY BIT(0)
> @@ -38,15 +38,22 @@
> #define SARADC_DLY_PU_SOC0x0c
> #define SARADC_DLY_PU_SOC_MASK 0x3f
>
> -#define SARADC_BITS 10
> #define SARADC_TIMEOUT msecs_to_jiffies(100)
>
> +struct rockchip_saradc_data {
> + int num_bits;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + unsigned long clk_rate;
> +};
> +
> struct rockchip_saradc {
> void __iomem*regs;
> struct clk *pclk;
> struct clk *clk;
> struct completion completion;
> struct regulator*vref;
> + const struct rockchip_saradc_data *data;
> u16 last_val;
> };
>
> @@ -90,7 +97,7 @@ static int rockchip_saradc_read_raw(struct iio_dev
> *indio_dev,
> }
>
> *val = ret / 1000;
> - *val2 = SARADC_BITS;
> + *val2 = info->data->num_bits;
> return IIO_VAL_FRACTIONAL_LOG2;
> default:
> return -EINVAL;
> @@ -103,7 +110,7 @@ static irqreturn_t rockchip_saradc_isr(int irq, void
> *dev_id)
>
> /* Read value */
> info->last_val = readl_relaxed(info->regs + SARADC_DATA);
> - info->last_val &= SARADC_DATA_MASK;
> + info->last_val &= GENMASK(info->data->num_bits - 1, 0);
>
> /* Clear irq & power down adc */
> writel_relaxed(0, info->regs + SARADC_CTRL);
> @@ -133,12 +140,44 @@ static const struct iio_chan_spec
> rockchip_saradc_iio_channels[] = {
> ADC_CHANNEL(2, "adc2"),
> };
>
> +static const struct rockchip_saradc_data saradc_data = {
> + .num_bits = 10,
> + .channels = rockchip_saradc_iio_channels,
> + .num_channels = ARRAY_SIZE(rockchip_saradc_iio_channels),
> + .clk_rate = 100,
> +};
> +
> +static const struct iio_chan_spec rockchip_rk3066_tsadc_iio_channels[] = {
> + ADC_CHANNEL(0, "adc0"),
> + ADC_CHANNEL(1, "adc1"),
> +};
> +
> +static const struct rockchip_saradc_data rk3066_tsadc_data = {
> + .num_bits = 12,
> + .channels = rockchip_rk3066_tsadc_iio_channels,
> + .num_channels = ARRAY_SIZE(rockchip_rk3066_tsadc_iio_channels),
> + .clk_rate = 5,
> +};
> +
> +static const struct of_device_id rockchip_saradc_match[] = {
> + {
> + .compatible = "rockchip,saradc",
> + .data = _data,
> + }, {
> + .compatible = "rockchip,rk3066-tsadc",
> + .data = _tsadc_data,
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, rockchip_saradc_match);
> +
> static int rockchip_saradc_probe(struct platform_device *pdev)
> {
> struct rockchip_saradc *info =
Re: [PATCH 3.2 000/131] 3.2.63-rc1 review
On Fri, 2014-09-12 at 20:59 +0900, Satoru Takeuchi wrote: > At Thu, 11 Sep 2014 06:30:06 -0700, > Guenter Roeck wrote: > > > > On 09/11/2014 05:32 AM, Ben Hutchings wrote: > > > This is the start of the stable review cycle for the 3.2.63 release. > > > There are 131 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 Sat Sep 13 12:32:13 UTC 2014. > > > Anything received after that time might be too late. > > > > > > > Build results: > > total: 111 pass: 106 fail: 5 > > Failed builds: > > microblaze:mmu_defconfig > > microblaze:nommu_defconfig > > mips:allmodconfig > > xtensa:defconfig > > xtensa:allmodconfig > > > > Qemu test results: > > total: 18 pass: 17 fail: 1 > > Failed tests: > > microblaze:microblaze_defconfig > > > > Results are as expected and an improvement over previous releases, > > where sparc64:allmodconfig used to fail as well. The failing qemu > > test was added to the list of tests only recently and is a known > > problem. > > > > Guenter > > Plus, this kernel passed my test. > > - Test Cases: >- Build this kernel. >- Boot this kernel. >- Build the latest mainline kernel with this kernel. > > - Test Tool: >https://github.com/satoru-takeuchi/test-linux-stable > > - Test Result (kernel .config, ktest config and test log): >http://satoru-takeuchi.org/test-linux-stable/results/- datetime>.tar.xz > > - Build Environment: >- OS: Debian Jessy x86_64 >- CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 >- memory: 8GB > > - Test Target Environment: >- Debian Jessy x86_64 (KVM guest on the Build Environment) >- # of vCPU: 2 >- memory: 2GB Thanks for testing! Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Re: [PATCH 3.2 000/131] 3.2.63-rc1 review
On Thu, 2014-09-11 at 06:30 -0700, Guenter Roeck wrote: > On 09/11/2014 05:32 AM, Ben Hutchings wrote: > > This is the start of the stable review cycle for the 3.2.63 release. > > There are 131 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 Sat Sep 13 12:32:13 UTC 2014. > > Anything received after that time might be too late. > > > > Build results: > total: 111 pass: 106 fail: 5 > Failed builds: > microblaze:mmu_defconfig > microblaze:nommu_defconfig > mips:allmodconfig > xtensa:defconfig > xtensa:allmodconfig > > Qemu test results: > total: 18 pass: 17 fail: 1 > Failed tests: > microblaze:microblaze_defconfig > > Results are as expected and an improvement over previous releases, > where sparc64:allmodconfig used to fail as well. The failing qemu > test was added to the list of tests only recently and is a known > problem. Thanks for testing! Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Re: [PATCH 3.2 105/131] net: Correctly set segment mac_len in skb_segment().
On Thu, 2014-09-11 at 08:48 -0400, Vlad Yasevich wrote: > On 09/11/2014 08:32 AM, Ben Hutchings wrote: > > 3.2.63-rc1 review patch. If anyone has any objections, please let me know. > > > > -- > > > > From: Vlad Yasevich > > > > [ Upstream commit fcdfe3a7fa4cb74391d42b6a26dc07c20dab1d82 ] > > > > When performing segmentation, the mac_len value is copied right > > out of the original skb. However, this value is not always set correctly > > (like when the packet is VLAN-tagged) and we'll end up copying a bad > > value. > > > > One way to demonstrate this is to configure a VM which tags > > packets internally and turn off VLAN acceleration on the forwarding > > bridge port. The packets show up corrupt like this: > > 16:18:24.985548 52:54:00:ab:be:25 > 52:54:00:26:ce:a3, ethertype 802.1Q > > (0x8100), length 1518: vlan 100, p 0, ethertype 0x05e0, > > 0x: 8cdb 1c7c 8cdb 0064 4006 b59d 0a00 6402 ...|...d@.d. > > 0x0010: 0a00 6401 9e0d b441 0a5e 64ec 0330 14fa ..dA.^d..0.. > > 0x0020: 29e3 01c9 f871 0101 080a 000a e833)q.3 > > 0x0030: 000f 8c75 6e65 7470 6572 6600 6e65 7470 ...unetperf.netp > > 0x0040: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp > > 0x0050: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp > > 0x0060: 6572 6600 6e65 7470 6572 6600 6e65 7470 erf.netperf.netp > > ... > > > > This also leads to awful throughput as GSO packets are dropped and > > cause retransmissions. > > > > The solution is to set the mac_len using the values already available > > in then new skb. We've already adjusted all of the header offset, so we > > might as well correctly figure out the mac_len using skb_reset_mac_len(). > > After this change, packets are segmented correctly and performance > > is restored. > > > > CC: Eric Dumazet > > Signed-off-by: Vlad Yasevich > > Signed-off-by: David S. Miller > > Signed-off-by: Ben Hutchings > > --- > > net/core/skbuff.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/net/core/skbuff.c b/net/core/skbuff.c > > index 7121d9b..0ccfb53 100644 > > --- a/net/core/skbuff.c > > +++ b/net/core/skbuff.c > > @@ -2669,7 +2669,6 @@ struct sk_buff *skb_segment(struct sk_buff *skb, u32 > > features) > > tail = nskb; > > > > __copy_skb_header(nskb, skb); > > - nskb->mac_len = skb->mac_len; > > > > /* nskb and skb might have different headroom */ > > if (nskb->ip_summed == CHECKSUM_PARTIAL) > > @@ -2679,6 +2678,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, u32 > > features) > > skb_set_network_header(nskb, skb->mac_len); > > nskb->transport_header = (nskb->network_header + > > skb_network_header_len(skb)); > > + skb_reset_mac_len(nskb); > > This will not fix the problem here because the network header above will > already be set incorrectly based on the old mac_len. > > This patch depends on > commit 030737bcc3c404e273e97dbe06fe9561699a411b > Author: Eric Dumazet > Date: Sat Oct 19 11:42:54 2013 -0700 > > net: generalize skb_segment() > > that correctly populates the header offsets in the new segment. I can't apply that because 3.2 doesn't even have the skb_headers_offset_update() function. So I'm going to drop this patch for now, but if you or David can provide a complete backport for this fix I would very much appreciate it. Ben. -- Ben Hutchings I'm always amazed by the number of people who take up solipsism because they heard someone else explain it. - E*Borg on alt.fan.pratchett signature.asc Description: This is a digitally signed message part
Re: [PATCH 6/8] arm: mach-orion5x: Convert pr_warning to pr_warn
Joe, On Sat, Sep 13, 2014 at 11:31:17AM -0700, Joe Perches wrote: > Use the more common pr_warn. > > Other miscellanea: > > o Realign arguments > > Signed-off-by: Joe Perches > --- > arch/arm/mach-orion5x/dns323-setup.c | 8 > arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +- > arch/arm/mach-orion5x/ts209-setup.c| 2 +- > arch/arm/mach-orion5x/ts409-setup.c| 2 +- > arch/arm/mach-orion5x/ts78xx-setup.c | 4 ++-- > 5 files changed, 9 insertions(+), 9 deletions(-) Applied to mvebu/soc with Andrew's Ack. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: bpf: correctly handle errors in sk_attach_filter()
From: Sasha Levin Date: Sat, 13 Sep 2014 00:06:30 -0400 > Commit "net: bpf: make eBPF interpreter images read-only" has changed bpf_prog > to be vmalloc()ed but never handled some of the errors paths of the old code. > > On error within sk_attach_filter (which userspace can easily trigger), we'd > kfree() the vmalloc()ed memory, and leak the internal bpf_work_struct. > > Signed-off-by: Sasha Levin Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv2] net/macb: Add hardware revision information during probe
From: Alexandre Belloni Date: Sat, 13 Sep 2014 01:57:49 +0200 > From: Bo Shen > > Print the IP revision when probing. > > Signed-off-by: Bo Shen > Signed-off-by: Nicolas Ferre > --- > Changes in v2: > - condense information on one line Applied, 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/
Jeg skal bruge dine HASTER RESPOND
Jeg skal bruge dine HASTER RESPOND Jeg bruger dette medie til at informere dig om transaktionen for overførsel på $ 2150 (Twenty-en million fem hundrede tusinde dollars) i min bank i Kina til dig som modtager. Det vil være 100% sikker, er den finansielle officer af den afdøde kunden. Kontakt venligst på min private e-mail nedenfor for eventuelle spørgsmål og yderligere information. Med venlig hilsen sang Chin e-post: chinsang...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] parisc fixes for v3.17
Hi Linus, please pull the latest parisc architecture fixes for kernel 3.17 from git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.17-1 Most important patch is a new Light Weigth Syscall (LWS) for 8, 16, 32 and 64 bit atomic CAS operations which is required in order to be able to implement the atomic gcc builtins on our platform. Other than that, we wire up the seccomp, getrandom and memfd_create syscalls, fixes a minor off-by-one bug and a wrong printk string. Thanks, Helge Dan Carpenter (1): parisc: sys_hpux: NUL terminator is one past the end Guy Martin (1): parisc: Implement new LWS CAS supporting 64 bit operations. Hans Wennborg (1): parisc: dino: fix %d confusingly prefixed with 0x in format string Helge Deller (1): parisc: Wire up seccomp, getrandom and memfd_create syscalls arch/parisc/Kconfig | 16 +++ arch/parisc/hpux/sys_hpux.c | 2 +- arch/parisc/include/asm/seccomp.h | 16 +++ arch/parisc/include/asm/thread_info.h | 5 +- arch/parisc/include/uapi/asm/unistd.h | 5 +- arch/parisc/kernel/ptrace.c | 6 + arch/parisc/kernel/syscall.S | 233 +- arch/parisc/kernel/syscall_table.S| 3 + drivers/parisc/dino.c | 2 +- 9 files changed, 280 insertions(+), 8 deletions(-) create mode 100644 arch/parisc/include/asm/seccomp.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sd: assign more appropriate log levels for two messages
KERN_ERR is too high severity for an "assumption" message, so I moved
them down to KERN_WARNING
Signed-off-by: Steven Honeyman
---
drivers/scsi/sd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 2c2041c..bb7d6e9 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2468,7 +2468,7 @@ sd_read_cache_type(struct scsi_disk *sdkp,
unsigned char *buffer)
}
}
-sd_first_printk(KERN_ERR, sdkp, "No Caching mode page found\n");
+sd_first_printk(KERN_WARNING, sdkp, "No Caching mode page found\n");
goto defaults;
Page_found:
@@ -2518,7 +2518,7 @@ defaults:
"Assuming drive cache: write back\n");
sdkp->WCE = 1;
} else {
-sd_first_printk(KERN_ERR, sdkp,
+sd_first_printk(KERN_WARNING, sdkp,
"Assuming drive cache: write through\n");
sdkp->WCE = 0;
}
--
2.1.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/
Subject: [PATCH] sdhci: change a warning message from pr_err to pr_warn
This is just a warning, so I've given it a more appropriate log level
Signed-off-by: Steven Honeyman
---
drivers/mmc/host/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 37b2a9a..6e9ba15 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2768,7 +2768,7 @@ int sdhci_add_host(struct sdhci_host *host)
host->version = (host->version & SDHCI_SPEC_VER_MASK)
>> SDHCI_SPEC_VER_SHIFT;
if (host->version > SDHCI_SPEC_300) {
-pr_err("%s: Unknown controller version (%d). "
+pr_warn("%s: Unknown controller version (%d). "
"You may experience problems.\n", mmc_hostname(mmc),
host->version);
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tpm: merge duplicate transmit_cmd() functions
Hi Am Samstag, 13. September 2014, 19:35:33 schrieb Jarkko Sakkinen: > Replaced transmit_cmd() functions in tpm-interface.c and tpm-sysfs.c > with a single tpm_transmit_cmd() that can be used in both files. > > This patch is preliminary clean up work for the TPM2 support. This > function is needed for implementing TPM2 versions of the in-kernel > TPM utility functions. > > Signed-off-by: Jarkko Sakkinen why the renaming? > > ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf, >size_t bufsiz); Can this be removed then? > +ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_cmd_t *cmd, > + int len, const char *desc); > extern int tpm_get_timeouts(struct tpm_chip *); > extern void tpm_gen_interrupt(struct tpm_chip *); > extern int tpm_do_selftest(struct tpm_chip *); Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 RESEND] SYSV: logging update
-use current logging functions
-replace no level printk by pr_err
-add debug.c / sysv_err function to include sb->s_id
-use pr_fmt with standard KBUILD_MODNAME ": "
-use __builtin_return_address to display function name
logging format is now:
sysv: (sb->s_id) sysv_fill_super [sysv]: msg
Cc: Christoph Hellwig
Cc: Joe Perches
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
V3:
Suggestions by Joe Perches:
-use builtin function(0) instead of __func__
-use const sb in sysv_err
-use standard KBUILD_MODNAME ": " fmt
-remove \n from sysv_err
V2: add sb->s_id in logging (suggested by Christoph Hellwig)
fs/sysv/Makefile | 2 +-
fs/sysv/balloc.c | 24 +++-
fs/sysv/debug.c | 15 +++
fs/sysv/ialloc.c | 12 +---
fs/sysv/inode.c | 15 ++-
fs/sysv/itree.c | 2 +-
fs/sysv/super.c | 28 +++-
fs/sysv/sysv.h | 3 +++
8 files changed, 53 insertions(+), 48 deletions(-)
create mode 100644 fs/sysv/debug.c
diff --git a/fs/sysv/Makefile b/fs/sysv/Makefile
index 3591f9d..46721fb 100644
--- a/fs/sysv/Makefile
+++ b/fs/sysv/Makefile
@@ -5,4 +5,4 @@
obj-$(CONFIG_SYSV_FS) += sysv.o
sysv-objs := ialloc.o balloc.o inode.o itree.o file.o dir.o \
-namei.o super.o symlink.o
+namei.o super.o symlink.o debug.o
diff --git a/fs/sysv/balloc.c b/fs/sysv/balloc.c
index 921c053..3473fb9 100644
--- a/fs/sysv/balloc.c
+++ b/fs/sysv/balloc.c
@@ -56,7 +56,7 @@ void sysv_free_block(struct super_block * sb, sysv_zone_t nr)
return;
if (block < sbi->s_firstdatazone || block >= sbi->s_nzones) {
- printk("sysv_free_block: trying to free block not in
datazone\n");
+ sysv_err(sb, "trying to free block not in datazone\n");
return;
}
@@ -64,7 +64,7 @@ void sysv_free_block(struct super_block * sb, sysv_zone_t nr)
count = fs16_to_cpu(sbi, *sbi->s_bcache_count);
if (count > sbi->s_flc_size) {
- printk("sysv_free_block: flc_count > flc_size\n");
+ sysv_err(sb, "flc_count > flc_size\n");
mutex_unlock(>s_lock);
return;
}
@@ -76,7 +76,7 @@ void sysv_free_block(struct super_block * sb, sysv_zone_t nr)
block += sbi->s_block_base;
bh = sb_getblk(sb, block);
if (!bh) {
- printk("sysv_free_block: getblk() failed\n");
+ sysv_err(sb, "getblk() failed\n");
mutex_unlock(>s_lock);
return;
}
@@ -118,8 +118,7 @@ sysv_zone_t sysv_new_block(struct super_block * sb)
*sbi->s_bcache_count = cpu_to_fs16(sbi, count);
if (block < sbi->s_firstdatazone || block >= sbi->s_nzones) {
- printk("sysv_new_block: new block %d is not in data zone\n",
- block);
+ sysv_err(sb, "new block %d is not in data zone\n", block);
goto Enospc;
}
@@ -128,14 +127,14 @@ sysv_zone_t sysv_new_block(struct super_block * sb)
block += sbi->s_block_base;
if (!(bh = sb_bread(sb, block))) {
- printk("sysv_new_block: cannot read free-list block\n");
+ sysv_err(sb, "cannot read free-list block\n");
/* retry this same block next time */
*sbi->s_bcache_count = cpu_to_fs16(sbi, 1);
goto Enospc;
}
count = fs16_to_cpu(sbi, *(__fs16*)bh->b_data);
if (count > sbi->s_flc_size) {
- printk("sysv_new_block: free-list block with >flc_size
entries\n");
+ sysv_err(sb, "free-list block with >flc_size
entries\n");
brelse(bh);
goto Enospc;
}
@@ -215,22 +214,21 @@ done:
return count;
Einval:
- printk("sysv_count_free_blocks: new block %d is not in data zone\n",
- block);
+ sysv_err(sb, "new block %d is not in data zone\n", block);
goto trust_sb;
Eio:
- printk("sysv_count_free_blocks: cannot read free-list block\n");
+ sysv_err(sb, "cannot read free-list block\n");
goto trust_sb;
E2big:
- printk("sysv_count_free_blocks: >flc_size entries in free-list
block\n");
+ sysv_err(sb, ">flc_size entries in free-list block\n");
if (bh)
brelse(bh);
trust_sb:
count = sb_count;
goto done;
Ecount:
- printk("sysv_count_free_blocks: free block count was %d, "
- "correcting to %d\n", sb_count, count);
+ sysv_err(sb, "free block count was %d, correcting to %d\n",
+sb_count, count);
if (!(sb->s_flags & MS_RDONLY)) {
*sbi->s_free_blocks = cpu_to_fs32(sbi, count);
dirty_sb(sb);
diff --git a/fs/sysv/debug.c
[GIT pull] timer fixes for 3.17
Linus,
please pull the latest timers-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
timers-urgent-for-linus
The timer department is not too proud about the following fixes:
- Deal with a long standing rounding bug in the timeval to jiffies
conversion. It's a real issue and this fix fell through the cracks
for quite some time.
- Another round of alarmtimer fixes. Finally this code gets used more
widely and the subtle issues hidden for quite some time are noticed
and fixed. Nothing really exciting, just the itty bitty details
which bite the serious users here and there.
Thanks,
tglx
-->
Andrew Hunter (1):
jiffies: Fix timeval conversion to jiffies
Richard Larocque (3):
alarmtimer: Return relative times in timer_gettime
alarmtimer: Do not signal SIGEV_NONE timers
alarmtimer: Lock k_itimer during timer callback
include/linux/jiffies.h | 12 ---
kernel/time/alarmtimer.c | 34 +++--
kernel/time/time.c | 56 +++-
3 files changed, 54 insertions(+), 48 deletions(-)
diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 1f44466c1e9d..c367cbdf73ab 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -258,23 +258,11 @@ extern unsigned long preset_lpj;
#define SEC_JIFFIE_SC (32 - SHIFT_HZ)
#endif
#define NSEC_JIFFIE_SC (SEC_JIFFIE_SC + 29)
-#define USEC_JIFFIE_SC (SEC_JIFFIE_SC + 19)
#define SEC_CONVERSION ((unsigned long)u64)NSEC_PER_SEC << SEC_JIFFIE_SC)
+\
TICK_NSEC -1) / (u64)TICK_NSEC))
#define NSEC_CONVERSION ((unsigned long)u64)1 << NSEC_JIFFIE_SC) +\
TICK_NSEC -1) / (u64)TICK_NSEC))
-#define USEC_CONVERSION \
-((unsigned long)u64)NSEC_PER_USEC << USEC_JIFFIE_SC) +\
-TICK_NSEC -1) / (u64)TICK_NSEC))
-/*
- * USEC_ROUND is used in the timeval to jiffie conversion. See there
- * for more details. It is the scaled resolution rounding value. Note
- * that it is a 64-bit value. Since, when it is applied, we are already
- * in jiffies (albit scaled), it is nothing but the bits we will shift
- * off.
- */
-#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1)
/*
* The maximum jiffie value is (MAX_INT >> 1). Here we translate that
* into seconds. The 64-bit case will overflow if we are not careful,
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 4aec4a457431..a7077d3ae52f 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -464,18 +464,26 @@ static enum alarmtimer_type clock2alarm(clockid_t clockid)
static enum alarmtimer_restart alarm_handle_timer(struct alarm *alarm,
ktime_t now)
{
+ unsigned long flags;
struct k_itimer *ptr = container_of(alarm, struct k_itimer,
it.alarm.alarmtimer);
- if (posix_timer_event(ptr, 0) != 0)
- ptr->it_overrun++;
+ enum alarmtimer_restart result = ALARMTIMER_NORESTART;
+
+ spin_lock_irqsave(>it_lock, flags);
+ if ((ptr->it_sigev_notify & ~SIGEV_THREAD_ID) != SIGEV_NONE) {
+ if (posix_timer_event(ptr, 0) != 0)
+ ptr->it_overrun++;
+ }
/* Re-add periodic timers */
if (ptr->it.alarm.interval.tv64) {
ptr->it_overrun += alarm_forward(alarm, now,
ptr->it.alarm.interval);
- return ALARMTIMER_RESTART;
+ result = ALARMTIMER_RESTART;
}
- return ALARMTIMER_NORESTART;
+ spin_unlock_irqrestore(>it_lock, flags);
+
+ return result;
}
/**
@@ -541,18 +549,22 @@ static int alarm_timer_create(struct k_itimer *new_timer)
* @new_timer: k_itimer pointer
* @cur_setting: itimerspec data to fill
*
- * Copies the itimerspec data out from the k_itimer
+ * Copies out the current itimerspec data
*/
static void alarm_timer_get(struct k_itimer *timr,
struct itimerspec *cur_setting)
{
- memset(cur_setting, 0, sizeof(struct itimerspec));
+ ktime_t relative_expiry_time =
+ alarm_expires_remaining(&(timr->it.alarm.alarmtimer));
+
+ if (ktime_to_ns(relative_expiry_time) > 0) {
+ cur_setting->it_value = ktime_to_timespec(relative_expiry_time);
+ } else {
+ cur_setting->it_value.tv_sec = 0;
+ cur_setting->it_value.tv_nsec = 0;
+ }
- cur_setting->it_interval =
- ktime_to_timespec(timr->it.alarm.interval);
- cur_setting->it_value =
- ktime_to_timespec(timr->it.alarm.alarmtimer.node.expires);
- return;
+ cur_setting->it_interval = ktime_to_timespec(timr->it.alarm.interval);
Re: [PATCH 4/5] ASoC: rockchip-i2s: fix registers' property of rockchip i2s controller
Hello.
On 9/13/2014 3:42 AM, Jianqun wrote:
Reference rockchip I2S controller TRM, modify some registers' property
I2S_FIFOLR: read / write, but not volatile, not precious
I2S_INTSR: read / write
I2S_CLR: volatile, register value will be cleared by read
Test on RK3288 with max98090.
Signed-off-by: Jianqun Xu
---
sound/soc/rockchip/rockchip_i2s.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_i2s.c
b/sound/soc/rockchip/rockchip_i2s.c
index 1b9b404..6595383 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
[...]
@@ -385,8 +387,6 @@ static bool rockchip_i2s_volatile_reg(struct device *dev,
unsigned int reg)
static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
- case I2S_FIFOLR:
- return true;
default:
return false;
}
Shouldn't this be folded into simple *return* false now?
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 0/2] r8169: fix rx vlan
From: Hayes Wang Date: Fri, 12 Sep 2014 11:35:10 +0800 > There are two issues for hw rx vlan. The patches are > used to fix them. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next v2] r8152: support VLAN
From: Hayes Wang Date: Fri, 12 Sep 2014 10:43:11 +0800 > Support hw VLAN for tx and rx. And enable them by default. > > Signed-off-by: Hayes Wang Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT pull] futex fix for 3.17
Linus,
please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
A oneliner bugfix for the jinxed futex code:
- Drop has bucket lock in the error exit path. I really could slap
myself for intruducing that bug while fixing all the other horror in
that code three month ago ...
Thanks,
tglx
-->
Thomas Gleixner (1):
futex: Unlock hb->lock in futex_wait_requeue_pi() error path
kernel/futex.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/futex.c b/kernel/futex.c
index d3a9d946d0b7..815d7af2ffe8 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2592,6 +2592,7 @@ static int futex_wait_requeue_pi(u32 __user *uaddr,
unsigned int flags,
* shared futexes. We need to compare the keys:
*/
if (match_futex(, )) {
+ queue_unlock(hb);
ret = -EINVAL;
goto out_put_keys;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4 linux-next] brcm80211: use container_of to resolve dma_info from dma_pub
Use container_of instead of casting first structure member.
Compiled but untested.
Signed-off-by: Fabian Frederick
---
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
index 4fb9635..796f5f9 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
@@ -746,7 +746,7 @@ dma64_dd_upd(struct dma_info *di, struct dma64desc *ddring,
/* !! may be called with core in reset */
void dma_detach(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -842,7 +842,7 @@ static void _dma_rxenable(struct dma_info *di)
void dma_rxinit(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -924,7 +924,7 @@ static struct sk_buff *_dma_getnextrxp(struct dma_info *di,
bool forceall)
*/
int dma_rx(struct dma_pub *pub, struct sk_buff_head *skb_list)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
struct sk_buff_head dma_frames;
struct sk_buff *p, *next;
uint len;
@@ -1022,7 +1022,7 @@ static bool dma64_txidle(struct dma_info *di)
*/
bool dma_rxfill(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
struct sk_buff *p;
u16 rxin, rxout;
u32 flags = 0;
@@ -1106,7 +1106,7 @@ bool dma_rxfill(struct dma_pub *pub)
void dma_rxreclaim(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
struct sk_buff *p;
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -1126,7 +1126,7 @@ void dma_counterreset(struct dma_pub *pub)
/* get the address of the var in order to change later */
unsigned long dma_getvar(struct dma_pub *pub, const char *name)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
if (!strcmp(name, ""))
return (unsigned long)&(di->dma.txavail);
@@ -1137,7 +1137,7 @@ unsigned long dma_getvar(struct dma_pub *pub, const char
*name)
void dma_txinit(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
u32 control = D64_XC_XE;
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -1170,7 +1170,7 @@ void dma_txinit(struct dma_pub *pub)
void dma_txsuspend(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -1182,7 +1182,7 @@ void dma_txsuspend(struct dma_pub *pub)
void dma_txresume(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
brcms_dbg_dma(di->core, "%s:\n", di->name);
@@ -1194,7 +1194,7 @@ void dma_txresume(struct dma_pub *pub)
bool dma_txsuspended(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
return (di->ntxd == 0) ||
((bcma_read32(di->core,
@@ -1204,7 +1204,7 @@ bool dma_txsuspended(struct dma_pub *pub)
void dma_txreclaim(struct dma_pub *pub, enum txd_range range)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
struct sk_buff *p;
brcms_dbg_dma(di->core, "%s: %s\n",
@@ -1225,7 +1225,7 @@ void dma_txreclaim(struct dma_pub *pub, enum txd_range
range)
bool dma_txreset(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
u32 status;
if (di->ntxd == 0)
@@ -1252,7 +1252,7 @@ bool dma_txreset(struct dma_pub *pub)
bool dma_rxreset(struct dma_pub *pub)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
u32 status;
if (di->nrxd == 0)
@@ -1377,7 +1377,7 @@ static void dma_update_txavail(struct dma_info *di)
int dma_txfast(struct brcms_c_info *wlc, struct dma_pub *pub,
struct sk_buff *p)
{
- struct dma_info *di = (struct dma_info *)pub;
+ struct dma_info *di = container_of(pub, struct dma_info, dma);
[PATCH 3/4 linux-next] brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub
Use container_of instead of casting first structure member.
Compiled but untested.
Signed-off-by: Fabian Frederick
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 122 ++---
.../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 6 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c| 8 +-
3 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
index 57ecc05..941b1e4 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c
@@ -128,19 +128,19 @@ static const u8 ofdm_rate_lookup[] = {
void wlc_phyreg_enter(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
wlapi_bmac_ucode_wake_override_phyreg_set(pi->sh->physhim);
}
void wlc_phyreg_exit(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
wlapi_bmac_ucode_wake_override_phyreg_clear(pi->sh->physhim);
}
void wlc_radioreg_enter(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
wlapi_bmac_mctrl(pi->sh->physhim, MCTL_LOCK_RADIO, MCTL_LOCK_RADIO);
udelay(10);
@@ -148,7 +148,7 @@ void wlc_radioreg_enter(struct brcms_phy_pub *pih)
void wlc_radioreg_exit(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
(void)bcma_read16(pi->d11core, D11REGOFFS(phyversion));
pi->phy_wreg = 0;
@@ -586,7 +586,7 @@ err:
void wlc_phy_detach(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
if (pih) {
if (--pi->refcnt)
@@ -613,7 +613,7 @@ bool
wlc_phy_get_phyversion(struct brcms_phy_pub *pih, u16 *phytype, u16 *phyrev,
u16 *radioid, u16 *radiover)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
*phytype = (u16) pi->pubpi.phy_type;
*phyrev = (u16) pi->pubpi.phy_rev;
*radioid = pi->pubpi.radioid;
@@ -624,19 +624,19 @@ wlc_phy_get_phyversion(struct brcms_phy_pub *pih, u16
*phytype, u16 *phyrev,
bool wlc_phy_get_encore(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
return pi->pubpi.abgphy_encore;
}
u32 wlc_phy_get_coreflags(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
return pi->pubpi.coreflags;
}
void wlc_phy_anacore(struct brcms_phy_pub *pih, bool on)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
if (ISNPHY(pi)) {
if (on) {
@@ -673,7 +673,7 @@ void wlc_phy_anacore(struct brcms_phy_pub *pih, bool on)
u32 wlc_phy_clk_bwbits(struct brcms_phy_pub *pih)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
u32 phy_bw_clkbits = 0;
@@ -698,14 +698,14 @@ u32 wlc_phy_clk_bwbits(struct brcms_phy_pub *pih)
void wlc_phy_por_inform(struct brcms_phy_pub *ppi)
{
- struct brcms_phy *pi = (struct brcms_phy *) ppi;
+ struct brcms_phy *pi = container_of(ppi, struct brcms_phy, pubpi_ro);
pi->phy_init_por = true;
}
void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool lock)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
pi->edcrs_threshold_lock = lock;
@@ -717,14 +717,14 @@ void wlc_phy_edcrs_lock(struct brcms_phy_pub *pih, bool
lock)
void wlc_phy_initcal_enable(struct brcms_phy_pub *pih, bool initcal)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
pi->do_initcal = initcal;
}
void wlc_phy_hw_clk_state_upd(struct brcms_phy_pub *pih, bool newstate)
{
- struct brcms_phy *pi = (struct brcms_phy *) pih;
+ struct brcms_phy *pi = container_of(pih, struct brcms_phy, pubpi_ro);
if (!pi || !pi->sh)
return;
@@ -734,7 +734,7 @@ void wlc_phy_hw_clk_state_upd(struct brcms_phy_pub *pih,
bool newstate)
void wlc_phy_hw_state_upd(struct brcms_phy_pub *pih, bool
[PATCH 2/4 linux-next] bna: use container_of to resolve bufdesc_ex from bufdesc
Use container_of instead of casting first structure member.
Compiled but untested.
Signed-off-by: Fabian Frederick
---
drivers/net/ethernet/brocade/bna/bna_enet.c | 9 ++---
drivers/net/ethernet/brocade/bna/bna_tx_rx.c | 4 ++--
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bna_enet.c
b/drivers/net/ethernet/brocade/bna/bna_enet.c
index 13f9636..903466e 100644
--- a/drivers/net/ethernet/brocade/bna/bna_enet.c
+++ b/drivers/net/ethernet/brocade/bna/bna_enet.c
@@ -107,7 +107,8 @@ bna_bfi_ethport_admin_rsp(struct bna_ethport *ethport,
{
struct bfi_enet_enable_req *admin_req =
>bfi_enet_cmd.admin_req;
- struct bfi_enet_rsp *rsp = (struct bfi_enet_rsp *)msghdr;
+ struct bfi_enet_rsp *rsp =
+ container_of(msghdr, struct bfi_enet_rsp, mh);
switch (admin_req->enable) {
case BNA_STATUS_T_ENABLED:
@@ -133,7 +134,8 @@ bna_bfi_ethport_lpbk_rsp(struct bna_ethport *ethport,
{
struct bfi_enet_diag_lb_req *diag_lb_req =
>bfi_enet_cmd.lpbk_req;
- struct bfi_enet_rsp *rsp = (struct bfi_enet_rsp *)msghdr;
+ struct bfi_enet_rsp *rsp =
+ container_of(msghdr, struct bfi_enet_rsp, mh);
switch (diag_lb_req->enable) {
case BNA_STATUS_T_ENABLED:
@@ -161,7 +163,8 @@ static void
bna_bfi_attr_get_rsp(struct bna_ioceth *ioceth,
struct bfi_msgq_mhdr *msghdr)
{
- struct bfi_enet_attr_rsp *rsp = (struct bfi_enet_attr_rsp *)msghdr;
+ struct bfi_enet_attr_rsp *rsp =
+ container_of(msghdr, struct bfi_enet_attr_rsp, mh);
/**
* Store only if not set earlier, since BNAD can override the HW
diff --git a/drivers/net/ethernet/brocade/bna/bna_tx_rx.c
b/drivers/net/ethernet/brocade/bna/bna_tx_rx.c
index 85e6354..8ee3fdc 100644
--- a/drivers/net/ethernet/brocade/bna/bna_tx_rx.c
+++ b/drivers/net/ethernet/brocade/bna/bna_tx_rx.c
@@ -715,7 +715,7 @@ bna_bfi_rxf_ucast_set_rsp(struct bna_rxf *rxf,
struct bfi_msgq_mhdr *msghdr)
{
struct bfi_enet_rsp *rsp =
- (struct bfi_enet_rsp *)msghdr;
+ container_of(msghdr, struct bfi_enet_rsp, mh);
if (rsp->error) {
/* Clear ucast from cache */
@@ -732,7 +732,7 @@ bna_bfi_rxf_mcast_add_rsp(struct bna_rxf *rxf,
struct bfi_enet_mcast_add_req *req =
>bfi_enet_cmd.mcast_add_req;
struct bfi_enet_mcast_add_rsp *rsp =
- (struct bfi_enet_mcast_add_rsp *)msghdr;
+ container_of(msghdr, struct bfi_enet_mcast_add_rsp, mh);
bna_rxf_mchandle_attach(rxf, (u8 *)>mac_addr,
ntohs(rsp->handle));
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4 linux-next] net: fec: use container_of to resolve bufdesc_ex from bufdesc
Use container_of instead of casting first structure member. ARM cross-compiled but untested. Signed-off-by: Fabian Frederick --- drivers/net/ethernet/freescale/fec_main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c index 89355a7..f1a99d2 100644 --- a/drivers/net/ethernet/freescale/fec_main.c +++ b/drivers/net/ethernet/freescale/fec_main.c @@ -572,7 +572,7 @@ fec_enet_txq_put_data_tso(struct sk_buff *skb, struct net_device *ndev, struct fec_enet_private *fep = netdev_priv(ndev); const struct platform_device_id *id_entry = platform_get_device_id(fep->pdev); - struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp; + struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc); unsigned short status; unsigned int estatus = 0; dma_addr_t addr; @@ -631,7 +631,7 @@ fec_enet_txq_put_hdr_tso(struct sk_buff *skb, struct net_device *ndev, const struct platform_device_id *id_entry = platform_get_device_id(fep->pdev); int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb); - struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp; + struct bufdesc_ex *ebdp = container_of(bdp, struct bufdesc_ex, desc); void *bufaddr; unsigned long dmabuf; unsigned short status; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4 linux-next] drivers/net: use container_of where possible
Small patchset using container_of instead of casting on first structure member address. Fabian Frederick (4): net: fec: use container_of to resolve bufdesc_ex from bufdesc bna: use container_of to resolve bufdesc_ex from bufdesc brcm80211: use container_of to resolve brcms_phy from brcms_phy_pub brcm80211: use container_of to resolve dma_info from dma_pub drivers/net/ethernet/brocade/bna/bna_enet.c| 9 +- drivers/net/ethernet/brocade/bna/bna_tx_rx.c | 4 +- drivers/net/ethernet/freescale/fec_main.c | 4 +- drivers/net/wireless/brcm80211/brcmsmac/dma.c | 38 +++ .../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 122 ++--- .../net/wireless/brcm80211/brcmsmac/phy/phy_lcn.c | 6 +- .../net/wireless/brcm80211/brcmsmac/phy/phy_n.c| 8 +- 7 files changed, 97 insertions(+), 94 deletions(-) -- 1.8.4.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 v5 3/3] iio: accel: BMC150: add support for other Bosch chips
On 10/09/14 20:43, Srinivas Pandruvada wrote:
> On Wed, 2014-09-10 at 20:35 +0100, Jonathan Cameron wrote:
>> On 02/09/14 10:30, Laurentiu Palcu wrote:
>>> The following chips are either similar or have only the resolution
>>> different. Hence, change this driver to support these chips too:
>>>
>>> BMI055 - combo chip (accelerometer part is identical to BMC150's)
>>> BMA255 - identical to BMC150's accelerometer
>>> BMA222E - 8 bit resolution
>>> BMA250E - 10 bit resolution
>>> BMA280 - 14 bit resolution
>>>
>>> Additionally:
>>> * add bmc150_accel_match_acpi_device() function to check that the device
>>>has been enumerated through ACPI;
>>> * rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
>>>since the ACPI matching has been moved to the new function. Also, this
>>>will allow for the GPIO matching to be done against a device tree too,
>>> not only
>>>ACPI tree;
>>> * rename bmc150_scale_info struct member 'range' to 'reg_range' to be
>>>consistent with the naming convention used elsewhere in the driver
>>>and declare it u8, instead of int;
>>> * change CONFIG description to list all supported chips;
>>>
>>> Signed-off-by: Laurentiu Palcu
>> Looks fine to me, though I'm not really in a fit state to review right now.
>> Srinivas, do you want to give an Ack?
> Sure
>
> Acked-by: Srinivas Pandruvada
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play.
Thanks,
Jonathan
>
>>> ---
>>>
>>> Changes in v5:
>>> * addressed Joe's suggestion to rewrite a small portion of the code to
>>> make it
>>>more readable;
>>> * changed the CONFIG description according to Srinivas's advise;
>>>
>>> Changes in v4:
>>> * address Peter's comments: see 3rd bullet in the commit's message. As a
>>> result, do
>>>some re-indentation to make lines fit 80 chars;
>>>
>>> Changes in v3:
>>> * remove the chip id macros since they were not used anywhere else and put
>>> the id
>>>values directly in the chip info table;
>>> * fix the unnecessary casting from const char * to char * and back;
>>>
>>> laurentiu
>>>
>>> drivers/iio/accel/Kconfig| 4 +-
>>> drivers/iio/accel/bmc150-accel.c | 234
>>> +--
>>> 2 files changed, 178 insertions(+), 60 deletions(-)
>>>
>>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>>> index 01b857e..01a2151 100644
>>> --- a/drivers/iio/accel/Kconfig
>>> +++ b/drivers/iio/accel/Kconfig
>>> @@ -23,7 +23,9 @@ config BMC150_ACCEL
>>> select IIO_BUFFER
>>> select IIO_TRIGGERED_BUFFER
>>> help
>>> - Say yes here to build support for the Bosch BMC150 accelerometer.
>>> + Say yes here to build support for the following Bosch accelerometers:
>>> + BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
>>> +
>>> Currently this only supports the device via an i2c interface.
>>>
>>> This is a combo module with both accelerometer and magnetometer.
>>> diff --git a/drivers/iio/accel/bmc150-accel.c
>>> b/drivers/iio/accel/bmc150-accel.c
>>> index 0e6566a..22c096c 100644
>>> --- a/drivers/iio/accel/bmc150-accel.c
>>> +++ b/drivers/iio/accel/bmc150-accel.c
>>> @@ -1,5 +1,12 @@
>>> /*
>>> - * BMC150 3-axis accelerometer driver
>>> + * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
>>> + * - BMC150
>>> + * - BMI055
>>> + * - BMA255
>>> + * - BMA250E
>>> + * - BMA222E
>>> + * - BMA280
>>> + *
>>> * Copyright (c) 2014, Intel Corporation.
>>> *
>>> * This program is free software; you can redistribute it and/or modify it
>>> @@ -34,7 +41,6 @@
>>> #define BMC150_ACCEL_GPIO_NAME "bmc150_accel_int"
>>>
>>> #define BMC150_ACCEL_REG_CHIP_ID 0x00
>>> -#define BMC150_ACCEL_CHIP_ID_VAL 0xFA
>>>
>>> #define BMC150_ACCEL_REG_INT_STATUS_2 0x0B
>>> #define BMC150_ACCEL_ANY_MOTION_MASK 0x07
>>> @@ -126,6 +132,18 @@ enum bmc150_power_modes {
>>> BMC150_ACCEL_SLEEP_MODE_SUSPEND = 0x04,
>>> };
>>>
>>> +struct bmc150_scale_info {
>>> + int scale;
>>> + u8 reg_range;
>>> +};
>>> +
>>> +struct bmc150_accel_chip_info {
>>> + u8 chip_id;
>>> + const struct iio_chan_spec *channels;
>>> + int num_channels;
>>> + const struct bmc150_scale_info scale_table[4];
>>> +};
>>> +
>>> struct bmc150_accel_data {
>>> struct i2c_client *client;
>>> struct iio_trigger *dready_trig;
>>> @@ -140,6 +158,7 @@ struct bmc150_accel_data {
>>> bool dready_trigger_on;
>>> bool motion_trigger_on;
>>> int64_t timestamp;
>>> + const struct bmc150_accel_chip_info *chip_info;
>>> };
>>>
>>> static const struct {
>>> @@ -168,16 +187,8 @@ static const struct {
>>> {0x0F, 1} };
>>>
>>> static const struct {
>>> - int scale;
>>> - int range;
>>> -} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
>>> -{19122,
[PATCH v3 0/3] net: Add Keystone NetCP ethernet driver support
Update v3 after incorporating Jamal and David Miller's comment/suggestion from earlier versions [1] [2]. I would like to get these merged for upcoming 3.18 merge window if there are no concerns on this version. After per the discussion here [3], the controversial custom exports have been dropped now. And for future future offload support additions, we will plug into generic frameworks as an when they are available. The network coprocessor (NetCP) is a hardware accelerator that processes Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet switch sub-module to send and receive packets. NetCP also includes a packet accelerator (PA) module to perform packet classification operations such as header matching, and packet modification operations such as checksum generation. NetCP can also optionally include a Security Accelerator(SA) capable of performing IPSec operations on ingress/egress packets. Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates per Ethernet port. Both GBE and XGBE network processors supported using common driver. It is also designed to handle future variants of NetCP. Cc: David Miller Cc: Rob Herring Cc: Grant Likely Cc: Sandeep Nair Sandeep Nair (3): Documentation: dt: net: Add binding doc for Keystone NetCP ethernet driver net: Add Keystone NetCP ethernet driver MAINTAINER: net: Add TI NETCP Ethernet driver entry .../devicetree/bindings/net/keystone-netcp.txt | 197 ++ MAINTAINERS|6 + drivers/net/ethernet/ti/Kconfig| 16 +- drivers/net/ethernet/ti/Makefile |4 + drivers/net/ethernet/ti/netcp.h| 227 ++ drivers/net/ethernet/ti/netcp_core.c | 2266 drivers/net/ethernet/ti/netcp_ethss.c | 2178 +++ drivers/net/ethernet/ti/netcp_sgmii.c | 130 ++ drivers/net/ethernet/ti/netcp_xgbepcsr.c | 502 + 9 files changed, 5523 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/keystone-netcp.txt create mode 100644 drivers/net/ethernet/ti/netcp.h create mode 100644 drivers/net/ethernet/ti/netcp_core.c create mode 100644 drivers/net/ethernet/ti/netcp_ethss.c create mode 100644 drivers/net/ethernet/ti/netcp_sgmii.c create mode 100644 drivers/net/ethernet/ti/netcp_xgbepcsr.c Regards, Santosh [1] https://lkml.org/lkml/2014/4/22/805 [2] https://lkml.org/lkml/2014/8/15/218 [3] https://lkml.org/lkml/2014/9/11/691 -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] Documentation: dt: net: Add binding doc for Keystone NetCP ethernet driver
From: Sandeep Nair The network coprocessor (NetCP) is a hardware accelerator that processes Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet switch sub-module to send and receive packets. NetCP also includes a packet accelerator (PA) module to perform packet classification operations such as header matching, and packet modification operations such as checksum generation. NetCP can also optionally include a Security Accelerator(SA) capable of performing IPSec operations on ingress/egress packets. Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates per Ethernet port. NetCP Subsystem device tree layout looks something like below: - NetCP subsystem(10G or 1G) - | |-> NetCP Devices ->| | |-> GBE/XGBE Switch | | | |-> Packet Accelerator | | | |-> Security Accelerator | | | |-> NetCP Interfaces -> | |-> Ethernet Port 0 | |-> Ethernet Port 1 | |-> Ethernet Port 2 | |-> Ethernet Port 3 Common driver supports GBE as well XGBE network processors. Cc: Rob Herring Cc: Grant Likely Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: David Miller Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar --- .../devicetree/bindings/net/keystone-netcp.txt | 197 1 file changed, 197 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/keystone-netcp.txt diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt b/Documentation/devicetree/bindings/net/keystone-netcp.txt new file mode 100644 index 000..a7d061b --- /dev/null +++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt @@ -0,0 +1,197 @@ +This document describes the device tree bindings associated with the +keystone network coprocessor(NetCP) driver support. + +The network coprocessor (NetCP) is a hardware accelerator that processes +Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsytem with a ethernet +switch sub-module to send and receive packets. NetCP also includes a packet +accelerator (PA) module to perform packet classification operations such as +header matching, and packet modification operations such as checksum +generation. NetCP can also optionally include a Security Accelerator (SA) +capable of performing IPSec operations on ingress/egress packets. + +Keystone II SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which +includes a 3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates +per Ethernet port. + +Keystone NetCP driver has a plug-in module architecture where each of the NetCP +sub-modules exist as a loadable kernel module which plug in to the netcp core. +These sub-modules are represented as "netcp-devices" in the dts bindings. It is +mandatory to have the ethernet switch sub-module for the ethernet interface to +be operational. Any other sub-module like the PA is optional. + +NetCP Ethernet SubSystem Layout: + +- + NetCP subsystem(10G or 1G) +- + | + |-> NetCP Devices ->| + | |-> GBE/XGBE Switch + | | + | |-> Packet Accelerator + | | + | |-> Security Accelerator + | + | + | + |-> NetCP Interfaces -> | + |-> Ethernet Port 0 + | + |-> Ethernet Port 1 + | + |-> Ethernet Port 2 + | + |-> Ethernet Port 3 + + +NetCP subsystem properties: +Required properties: +- compatible: Should be "ti,netcp-1.0" +- clocks: phandle to the reference clocks for the subsystem. +- dma-id: Navigator packet dma instance id. + +Optional properties: +- reg: register location and the size for the following register + regions in the specified order. + - Efuse MAC address register +- dma-coherent:Present if dma operations are coherent +- big-endian: Keystone devices can be operated in a mode where the DSP is in + the big endian mode. In such cases enable this option. This + option should also be enabled if the ARM is operated in + big endian mode with the DSP in little endian. + +NetCP device properties: Device
[PATCH v3 3/3] MAINTAINER: net: Add TI NETCP Ethernet driver entry
From: Sandeep Nair Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 134483f..7b1c41d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9038,6 +9038,12 @@ F: drivers/power/lp8788-charger.c F: drivers/regulator/lp8788-*.c F: include/linux/mfd/lp8788*.h +TI NETCP ETHERNET DRIVER +M: Sandeep Nair +L: net...@vger.kernel.org +S: Maintained +F: drivers/net/ethernet/ti/netcp* + TI TWL4030 SERIES SOC CODEC DRIVER M: Peter Ujfalusi L: alsa-de...@alsa-project.org (moderated for non-subscribers) -- 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] iio: adc: xilinx-xadc: assign auxiliary channels address correctly
On 12/09/14 18:25, Lars-Peter Clausen wrote:
> On 09/11/2014 10:55 AM, Subbaraya Sundeep Bhatta wrote:
>> This patch fixes incorrect logic for assigning address
>> to auxiliary channels of xilinx xadc.
>>
>> Signed-off-by: Subbaraya Sundeep Bhatta
>
> Acked-by: Lars-Peter Clausen
Applied to the fixes-togreg branch of iio.git and flagged
for stable.
Thanks,
Jonathan
>
>> ---
>> drivers/iio/adc/xilinx-xadc-core.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/iio/adc/xilinx-xadc-core.c
>> b/drivers/iio/adc/xilinx-xadc-core.c
>> index fd2745c..626b397 100644
>> --- a/drivers/iio/adc/xilinx-xadc-core.c
>> +++ b/drivers/iio/adc/xilinx-xadc-core.c
>> @@ -1126,7 +1126,7 @@ static int xadc_parse_dt(struct iio_dev *indio_dev,
>> struct device_node *np,
>> chan->address = XADC_REG_VPVN;
>> } else {
>> chan->scan_index = 15 + reg;
>> -chan->scan_index = XADC_REG_VAUX(reg - 1);
>> +chan->address = XADC_REG_VAUX(reg - 1);
>> }
>> num_channels++;
>> chan++;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
From: Joe Perches Date: Sat, 13 Sep 2014 12:11:12 -0700 > On Sat, 2014-09-13 at 21:05 +0200, Heinrich Schuchardt wrote: >> Compiling with OCTEON_MGMT_ETHERNET gives a warning >> drivers/net/ethernet/octeon/octeon_mgmt.c:295:4: >> warning: ISO C90 forbids mixed declarations and code >> [-Wdeclaration-after-statement] > > Maybe better to move the memset after the declaration. Totally agree, keep the variable in the innermost scope in which it is used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/5] regulator/axp20x: use axp2xx consolidated header
On 12/09/14 00:15, Jacob Pan wrote:
> AXP20x driver has been extended to support axp288 variant. Header file
> and common data structures has also been renamed to suit the new
> scope of devices supported.
>
> This patch makes use of the renamed header and structure.
>
> Acked-by: Mark Brown
> Signed-off-by: Jacob Pan
> ---
> drivers/regulator/axp20x-regulator.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 004aadb..c9b6803 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -20,7 +20,7 @@
> #include
> #include
> #include
> -#include
> +#include
Err, doesn't this break bisection. Rename 'must' be done in one go, not
split across patches.
> #include
> #include
>
> @@ -161,7 +161,7 @@ static struct of_regulator_match axp20x_matches[] = {
>
> static int axp20x_set_dcdc_freq(struct platform_device *pdev, u32 dcdcfreq)
> {
> - struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp2xx_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
>
> if (dcdcfreq < 750) {
> dcdcfreq = 750;
> @@ -232,7 +232,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev
> *rdev, int id, u32 work
> static int axp20x_regulator_probe(struct platform_device *pdev)
> {
> struct regulator_dev *rdev;
> - struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp2xx_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> struct regulator_config config = { };
> struct regulator_init_data *init_data;
> int ret, i;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/5] mfd/axp20x: rename files to support more devices
On 12/09/14 00:15, Jacob Pan wrote:
> More XPowers PMIC devices can be supported by extending this driver, so
> rename it to axp2xx to cover axp288 variant.
>
> Acked-by: Lee Jones
> Signed-off-by: Jacob Pan
I'm not sure this rename is a good idea (or the original wild
card was for that matter).
For example, just a quick look at the xpowers website shows there is a AXP228
which just got swept up by the name change.
Best plan, in my view, is to always name a driver after an individual part it
supports and rely on Kconfig description to say what else is supported.
Bit late here, but perhaps best not to make things worse!
> ---
> drivers/mfd/Kconfig | 7 ---
> drivers/mfd/Makefile | 2 +-
> drivers/mfd/{axp20x.c => axp2xx.c} | 6 +++---
> include/linux/mfd/{axp20x.h => axp2xx.h} | 6 +++---
> 4 files changed, 11 insertions(+), 10 deletions(-)
> rename drivers/mfd/{axp20x.c => axp2xx.c} (97%)
> rename include/linux/mfd/{axp20x.h => axp2xx.h} (98%)
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index de5abf2..42a70a3 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -67,14 +67,15 @@ config MFD_BCM590XX
> help
> Support for the BCM590xx PMUs from Broadcom
>
> -config MFD_AXP20X
> - bool "X-Powers AXP20X"
> +config MFD_AXP2XX
> + bool "X-Powers AXP2XX"
> select MFD_CORE
> select REGMAP_I2C
> select REGMAP_IRQ
> depends on I2C=y
> help
> - If you say Y here you get support for the X-Powers AXP202 and AXP209.
> + If you say Y here you get support for the X-Powers AXP202, AXP209 and
> + AXP288 power management IC (PMIC).
> This driver include only the core APIs. You have to select individual
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 3fcfdfc..8d0beb2 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -103,7 +103,7 @@ obj-$(CONFIG_PMIC_DA9052) += da9052-irq.o
> obj-$(CONFIG_PMIC_DA9052)+= da9052-core.o
> obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
> obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
> -obj-$(CONFIG_MFD_AXP20X) += axp20x.o
> +obj-$(CONFIG_MFD_AXP2XX) += axp2xx.o
>
> obj-$(CONFIG_MFD_LP3943) += lp3943.o
> obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp2xx.c
> similarity index 97%
> rename from drivers/mfd/axp20x.c
> rename to drivers/mfd/axp2xx.c
> index dee6539..332a8a0 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp2xx.c
> @@ -1,7 +1,7 @@
> /*
> - * axp20x.c - MFD core driver for the X-Powers AXP202 and AXP209
> + * axp2xx.c - MFD core driver for the X-Powers AXP202 and AXP209
> *
> - * AXP20x comprises an adaptive USB-Compatible PWM charger, 2 BUCK DC-DC
> + * AXP2xx comprises an adaptive USB-Compatible PWM charger, 2 BUCK DC-DC
> * converters, 5 LDOs, multiple 12-bit ADCs of voltage, current and
> temperature
> * as well as 4 configurable GPIOs.
> *
> @@ -21,7 +21,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp2xx.h
> similarity index 98%
> rename from include/linux/mfd/axp20x.h
> rename to include/linux/mfd/axp2xx.h
> index d0e31a2..a36d91b 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp2xx.h
> @@ -8,8 +8,8 @@
> * published by the Free Software Foundation.
> */
>
> -#ifndef __LINUX_MFD_AXP20X_H
> -#define __LINUX_MFD_AXP20X_H
> +#ifndef __LINUX_MFD_AXP2XX_H
> +#define __LINUX_MFD_AXP2XX_H
>
> enum {
> AXP202_ID = 0,
> @@ -177,4 +177,4 @@ struct axp20x_dev {
> longvariant;
> };
>
> -#endif /* __LINUX_MFD_AXP20X_H */
> +#endif /* __LINUX_MFD_AXP2XX_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: [PATCHv3 0/8] target: Save memory on unused se_dev_entrys and se_luns
On Tue, Jul 29, 2014 at 03:15:11PM +0200, Christoph Hellwig wrote: > Nic, > > any progress on looking over these? Seems like there's actually > nothing at all queued up for 3.17 in the target tree, or am І missing > something? ping again. We're getting closer to the end of the 3.18 merge window and there still hasn't been a response. Should Andy just send the patches directly to Linus once 3.18 opens given that they have been out on the list since Jun 23? (with a positive review from me and no negative one) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] iio: add documentation for current attribute
On 12/09/14 00:15, Jacob Pan wrote: > Add documentation for input current raw reading and scale. > > Signed-off-by: Jacob Pan The content is fine, but please look at how the other types are handled. The raw attribute is described along with the units etc in it's own section, but the _scale attribute just gets lumped in with the equivalent for all the other channel types. Thanks, Jonathan > --- > Documentation/ABI/testing/sysfs-bus-iio | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio > b/Documentation/ABI/testing/sysfs-bus-iio > index d760b02..3c76bd8 100644 > --- a/Documentation/ABI/testing/sysfs-bus-iio > +++ b/Documentation/ABI/testing/sysfs-bus-iio > @@ -1028,3 +1028,11 @@ Contact: linux-...@vger.kernel.org > Description: > Raw value of rotation from true/magnetic north measured with > or without compensation from tilt sensors. > + > +What:/sys/bus/iio/devices/iio:deviceX/in_currentX_raw > +What:/sys/bus/iio/devices/iio:deviceX/in_currentX_scale > +KernelVersion: 3.18 > +Contact: linux-...@vger.kernel.org > +Description: > + Raw current measurement from channel X. Units after application > of > + scale and offset are milliamps. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Bisected Problem with LSI PCI FC Adapter
Dirk Gouders writes: > Bjorn Helgaas writes: > >> I want to fix this regression before v3.17. Dirk, can you test the >> following patch on top of v3.17-rc2? I'm hoping you can try this on your >> test machine in conjunction with your acpi_pci_root_add() and >> pci_scan_device() patches. If I understand correctly, you were able to >> reproduce the FC adapter not showing up, and if you can verify that it does >> show with those patches + this revert, I think that's good enough for now. > > I tried this patch on the test machine but after rebooting I lost remote > access -- details will have to wait until tonight. > > Independent of the result of this test I planned to go to the office, > this evening to also do this test on the VX50 and to also try Yinghai's > suggestion to reset the PCIe link on it. I'd like to see if the > behavior of the VX50 differs from that of the test machine. > > Probably obvious but did I undestand correctly that Yinghai's patches + > > echo 1 > /sys/bus/.../pcie_link_disable > echo 0 > /sys/bus/.../pcie_link_disable > > is exactly identical to this? > > setpci -s ... 0xc0.b=0x18 > setpci -s ... 0xc0.b=0x08 > > Please let me know if there is anything else you want me to test on the > VX50. So, I did some tests on the VX50 which probably wasn't the worst idea, because it behaves different than the test machine. Summary: 1) Bjorn's back pocket patch works on the VX50. On the test machine it causes a trace, mount_root has to do with it. I tried to use netconsole but it complained the interface were not ready. 2) Reset with setpci as above did not work on the VX50. 3) Reset with Bjorn's commands DEV=00:0e.0 setpci -s$DEV BRIDGE_CONTROL.W=0x0040 sleep 1 setpci -s$DEV BRIDGE_CONTROL.W=0x sleep 1 echo 1 > /sys/bus/pci/rescan let the FC adapter appear but there are errors that I cannot really interpret. 4) Reset with Yinghai's patches and echo 1 > /sys/bus/pci/devices/\:00\:0e.0/pcie_link_disable echo 0 > /sys/bus/pci/devices/\:00\:0e.0/pcie_link_disable echo 1 > /sys/bus/pci/rescan gives a similar resut to 3). I will apply dmesg and lspci output at the end, hoping the numbering above allows proper assignment. Dirk 1) lspci and dmesg with back pocket patch -+-[:80]-+-00.0 NVIDIA Corporation CK804 Memory Controller | +-01.0 NVIDIA Corporation CK804 Memory Controller | +-07.0 NVIDIA Corporation CK804 Serial ATA Controller | +-08.0 NVIDIA Corporation CK804 Serial ATA Controller | +-0a.0 NVIDIA Corporation CK804 Ethernet Controller | +-0b.0-[81-85]-- | +-0c.0-[86-8a]-- | +-0d.0-[8b-8f]-- | \-0e.0-[90-94]-- \-[:00]-+-00.0 NVIDIA Corporation CK804 Memory Controller +-01.0 NVIDIA Corporation CK804 ISA Bridge +-01.1 NVIDIA Corporation CK804 SMBus +-02.0 NVIDIA Corporation CK804 USB Controller +-02.1 NVIDIA Corporation CK804 USB Controller +-06.0 NVIDIA Corporation CK804 IDE +-07.0 NVIDIA Corporation CK804 Serial ATA Controller +-08.0 NVIDIA Corporation CK804 Serial ATA Controller +-09.0-[01]--+-06.0 Intel Corporation 82541GI Gigabit Ethernet Controller |\-09.0 XGI Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core) +-0a.0 NVIDIA Corporation CK804 Ethernet Controller +-0b.0-[02]-- +-0c.0-[03]-- +-0d.0-[05]-- +-0e.0-[0a]00.0 LSI Logic / Symbios Logic FC949ES Fibre Channel Adapter +-18.0 Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration +-18.1 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map +-18.2 Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller +-18.3 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control +-18.4 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control +-19.0 Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration +-19.1 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map +-19.2 Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller +-19.3 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Miscellaneous Control +-19.4 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Link Control +-1a.0 Advanced Micro Devices, Inc. [AMD] Family 10h Processor HyperTransport Configuration +-1a.1 Advanced Micro Devices, Inc. [AMD] Family 10h Processor Address Map +-1a.2 Advanced Micro Devices, Inc. [AMD] Family 10h Processor DRAM Controller
Re: [RFC 3/3] zram: add swap_get_free hint
On Thu, Sep 4, 2014 at 7:59 PM, Minchan Kim wrote:
> Hi Heesub,
>
> On Thu, Sep 04, 2014 at 03:26:14PM +0900, Heesub Shin wrote:
>> Hello Minchan,
>>
>> First of all, I agree with the overall purpose of your patch set.
>
> Thank you.
>
>>
>> On 09/04/2014 10:39 AM, Minchan Kim wrote:
>> >This patch implement SWAP_GET_FREE handler in zram so that VM can
>> >know how many zram has freeable space.
>> >VM can use it to stop anonymous reclaiming once zram is full.
>> >
>> >Signed-off-by: Minchan Kim
>> >---
>> > drivers/block/zram/zram_drv.c | 18 ++
>> > 1 file changed, 18 insertions(+)
>> >
>> >diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>> >index 88661d62e46a..8e22b20aa2db 100644
>> >--- a/drivers/block/zram/zram_drv.c
>> >+++ b/drivers/block/zram/zram_drv.c
>> >@@ -951,6 +951,22 @@ static int zram_slot_free_notify(struct block_device
>> >*bdev,
>> > return 0;
>> > }
>> >
>> >+static int zram_get_free_pages(struct block_device *bdev, long *free)
>> >+{
>> >+struct zram *zram;
>> >+struct zram_meta *meta;
>> >+
>> >+zram = bdev->bd_disk->private_data;
>> >+meta = zram->meta;
>> >+
>> >+if (!zram->limit_pages)
>> >+return 1;
>> >+
>> >+*free = zram->limit_pages - zs_get_total_pages(meta->mem_pool);
>>
>> Even if 'free' is zero here, there may be free spaces available to
>> store more compressed pages into the zs_pool. I mean calculation
>> above is not quite accurate and wastes memory, but have no better
>> idea for now.
>
> Yeb, good point.
>
> Actually, I thought about that but in this patchset, I wanted to
> go with conservative approach which is a safe guard to prevent
> system hang which is terrible than early OOM kill.
>
> Whole point of this patchset is to add a facility to VM and VM
> collaborates with zram via the interface to avoid worst case
> (ie, system hang) and logic to throttle could be enhanced by
> several approaches in future but I agree my logic was too simple
> and conservative.
>
> We could improve it with [anti|de]fragmentation in future but
> at the moment, below simple heuristic is not too bad for first
> step. :)
>
>
> ---
> drivers/block/zram/zram_drv.c | 15 ++-
> drivers/block/zram/zram_drv.h | 1 +
> 2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 8e22b20aa2db..af9dfe6a7d2b 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -410,6 +410,7 @@ static bool zram_free_page(struct zram *zram, size_t
> index)
> atomic64_sub(zram_get_obj_size(meta, index),
> >stats.compr_data_size);
> atomic64_dec(>stats.pages_stored);
> + atomic_set(>alloc_fail, 0);
>
> meta->table[index].handle = 0;
> zram_set_obj_size(meta, index, 0);
> @@ -600,10 +601,12 @@ static int zram_bvec_write(struct zram *zram, struct
> bio_vec *bvec, u32 index,
> alloced_pages = zs_get_total_pages(meta->mem_pool);
> if (zram->limit_pages && alloced_pages > zram->limit_pages) {
> zs_free(meta->mem_pool, handle);
> + atomic_inc(>alloc_fail);
> ret = -ENOMEM;
> goto out;
> }
This isn't going to work well at all with swap. There will be,
minimum, 32 failures to write a swap page before GET_FREE finally
indicates it's full, and even then a single free during those 32
failures will restart the counter, so it could be dozens or hundreds
(or more) swap write failures before the zram device is marked as
full. And then, a single zram free will move it back to non-full and
start the write failures over again.
I think it would be better to just check for actual fullness (i.e.
alloced_pages > limit_pages) at the start of write, and fail if so.
That will allow a single write to succeed when it crosses into
fullness, and the if GET_FREE is changed to a simple IS_FULL and uses
the same check (alloced_pages > limit_pages), then swap shouldn't see
any write failures (or very few), and zram will stay full until enough
pages are freed that it really does move under limit_pages.
>
> + atomic_set(>alloc_fail, 0);
> update_used_max(zram, alloced_pages);
>
> cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
> @@ -951,6 +954,7 @@ static int zram_slot_free_notify(struct block_device
> *bdev,
> return 0;
> }
>
> +#define FULL_THRESH_HOLD 32
> static int zram_get_free_pages(struct block_device *bdev, long *free)
> {
> struct zram *zram;
> @@ -959,12 +963,13 @@ static int zram_get_free_pages(struct block_device
> *bdev, long *free)
> zram = bdev->bd_disk->private_data;
> meta = zram->meta;
>
> - if (!zram->limit_pages)
> - return 1;
> -
> - *free = zram->limit_pages - zs_get_total_pages(meta->mem_pool);
> + if (zram->limit_pages &&
> + (atomic_read(>alloc_fail) >
Re: [PATCH] Freeing dst when the reference count <0 causes general protection fault, it could be a major security flaw as rogue app can modify dst to crash kernel.
From: Shakil k Date: Sat, 13 Sep 2014 10:46:39 -0700 > On Sat, Sep 13, 2014 at 4:50 AM, Eric Dumazet > wrote: > >> Can you describe how this could trigger with a pristine kernel ? >> This can be reproduced with our custom network traffic to simulate malware. >> > Point is the user can modify certain packets and can cause a kernel crash > causing blackout to all the linux boxes hosting services :( Eric is kindly asking you exactly how to reproduce the crash, so he can 1) fix it and 2) generate a test case that gets run all the time in the future. Please answer his question directly instead of steering the conversation endless towards other aspects. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v2 1/5] xen, blkfront: port to the the multi-queue block layer API
> +static int blkfront_queue_rq(struct blk_mq_hw_ctx *hctx, struct request *req)
> {
> + struct blkfront_info *info = req->rq_disk->private_data;
>
> + spin_lock_irq(>io_lock);
> + if (RING_FULL(>ring))
> + goto wait;
>
> - blk_start_request(req);
> + if ((req->cmd_type != REQ_TYPE_FS) ||
> + ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> + !info->flush_op)) {
> + req->errors = -EIO;
> + blk_mq_complete_request(req);
> + spin_unlock_irq(>io_lock);
> + return BLK_MQ_RQ_QUEUE_ERROR;
As mentioned during the last round this should only return
BLK_MQ_RQ_QUEUE_ERROR, and not also set req->errors and complete the
request.
> + }
>
> + if (blkif_queue_request(req)) {
> + blk_mq_requeue_request(req);
> + goto wait;
Same here, this should only return BLK_MQ_RQ_QUEUE_BUSY after the wait
label, but not also requeue the request. While the error case above
is harmless due to the double completion protection in blk-mq, this one
actually is actively harmful.
> wait:
> + /* Avoid pointless unplugs. */
> + blk_mq_stop_hw_queue(hctx);
> + spin_unlock_irq(>io_lock);
In general you should try to do calls into the blk_mq code without holding
your locks to simplify the locking hierachy and reduce lock hold times.
> -static void kick_pending_request_queues(struct blkfront_info *info)
> +static void kick_pending_request_queues(struct blkfront_info *info,
> + unsigned long *flags)
> {
> if (!RING_FULL(>ring)) {
> - /* Re-enable calldowns. */
> - blk_start_queue(info->rq);
> - /* Kick things off immediately. */
> - do_blkif_request(info->rq);
> + spin_unlock_irqrestore(>io_lock, *flags);
> + blk_mq_start_stopped_hw_queues(info->rq, 0);
> + spin_lock_irqsave(>io_lock, *flags);
> }
The second paramter to blk_mq_start_stopped_hw_queues is a bool,
so you should pass false instead of 0 here.
Also the locking in this area seems wrong as most callers immediately
acquire and/or release the io_lock, so it seems more useful in general
to expect this function to be called without it.
> static void blkif_restart_queue(struct work_struct *work)
> {
> struct blkfront_info *info = container_of(work, struct blkfront_info,
> work);
> + unsigned long flags;
>
> - spin_lock_irq(>io_lock);
> + spin_lock_irqsave(>io_lock, flags);
There shouldn't be any need to ever take a lock as _irqsave from a work
queue handler.
Note that you might be able to get rid of your own workqueue here by
simply using blk_mq_start_stopped_hw_queues with the async paramter set
to true.
>
> - error = (bret->status == BLKIF_RSP_OKAY) ? 0 : -EIO;
> + error = req->errors = (bret->status == BLKIF_RSP_OKAY) ? 0 :
> -EIO;
I don't think you need the error variable any more as blk-mq always uses
req->errors to pass the errno value.
> - kick_pending_request_queues(info);
> + kick_pending_request_queues(info, );
>
> list_for_each_entry_safe(req, n, , queuelist) {
> /* Requeue pending requests (flush or discard) */
> list_del_init(>queuelist);
> BUG_ON(req->nr_phys_segments > segs);
> - blk_requeue_request(info->rq, req);
> + blk_mq_requeue_request(req);
Note that blk_mq_requeue_request calls will need a
blk_mq_kick_requeue_list call to be actually requeued. It should be
fine to have one past this loop here.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/8] arm: mach-orion5x: Convert pr_warning to pr_warn
On Sat, Sep 13, 2014 at 11:31:17AM -0700, Joe Perches wrote:
> Use the more common pr_warn.
>
> Other miscellanea:
>
> o Realign arguments
>
> Signed-off-by: Joe Perches
Acked-by: Andrew Lunn
Andrew
> ---
> arch/arm/mach-orion5x/dns323-setup.c | 8
> arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
> arch/arm/mach-orion5x/ts209-setup.c| 2 +-
> arch/arm/mach-orion5x/ts409-setup.c| 2 +-
> arch/arm/mach-orion5x/ts78xx-setup.c | 4 ++--
> 5 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-orion5x/dns323-setup.c
> b/arch/arm/mach-orion5x/dns323-setup.c
> index 56edeab..09d2a26 100644
> --- a/arch/arm/mach-orion5x/dns323-setup.c
> +++ b/arch/arm/mach-orion5x/dns323-setup.c
> @@ -550,7 +550,7 @@ static int __init dns323_identify_rev(void)
> break;
> }
> if (i >= 1000) {
> - pr_warning("DNS-323: Timeout accessing PHY, assuming rev B1\n");
> + pr_warn("DNS-323: Timeout accessing PHY, assuming rev B1\n");
> return DNS323_REV_B1;
> }
> writel((3 << 21)/* phy ID reg */ |
> @@ -562,7 +562,7 @@ static int __init dns323_identify_rev(void)
> break;
> }
> if (i >= 1000) {
> - pr_warning("DNS-323: Timeout reading PHY, assuming rev B1\n");
> + pr_warn("DNS-323: Timeout reading PHY, assuming rev B1\n");
> return DNS323_REV_B1;
> }
> pr_debug("DNS-323: Ethernet PHY ID 0x%x\n", reg & 0x);
> @@ -577,8 +577,8 @@ static int __init dns323_identify_rev(void)
> case 0x0e10: /* MV88E1118 */
> return DNS323_REV_C1;
> default:
> - pr_warning("DNS-323: Unknown PHY ID 0x%04x, assuming rev B1\n",
> -reg & 0x);
> + pr_warn("DNS-323: Unknown PHY ID 0x%04x, assuming rev B1\n",
> + reg & 0x);
> }
> return DNS323_REV_B1;
> }
> diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c
> b/arch/arm/mach-orion5x/terastation_pro2-setup.c
> index 6208d12..1208674 100644
> --- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
> +++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
> @@ -349,7 +349,7 @@ static void __init tsp2_init(void)
> gpio_free(TSP2_RTC_GPIO);
> }
> if (tsp2_i2c_rtc.irq == 0)
> - pr_warning("tsp2_init: failed to get RTC IRQ\n");
> + pr_warn("tsp2_init: failed to get RTC IRQ\n");
> i2c_register_board_info(0, _i2c_rtc, 1);
>
> /* register Terastation Pro II specific power-off method */
> diff --git a/arch/arm/mach-orion5x/ts209-setup.c
> b/arch/arm/mach-orion5x/ts209-setup.c
> index 9136797..c725b7c 100644
> --- a/arch/arm/mach-orion5x/ts209-setup.c
> +++ b/arch/arm/mach-orion5x/ts209-setup.c
> @@ -314,7 +314,7 @@ static void __init qnap_ts209_init(void)
> gpio_free(TS209_RTC_GPIO);
> }
> if (qnap_ts209_i2c_rtc.irq == 0)
> - pr_warning("qnap_ts209_init: failed to get RTC IRQ\n");
> + pr_warn("qnap_ts209_init: failed to get RTC IRQ\n");
> i2c_register_board_info(0, _ts209_i2c_rtc, 1);
>
> /* register tsx09 specific power-off method */
> diff --git a/arch/arm/mach-orion5x/ts409-setup.c
> b/arch/arm/mach-orion5x/ts409-setup.c
> index 5c079d31..cf2ab53 100644
> --- a/arch/arm/mach-orion5x/ts409-setup.c
> +++ b/arch/arm/mach-orion5x/ts409-setup.c
> @@ -302,7 +302,7 @@ static void __init qnap_ts409_init(void)
> gpio_free(TS409_RTC_GPIO);
> }
> if (qnap_ts409_i2c_rtc.irq == 0)
> - pr_warning("qnap_ts409_init: failed to get RTC IRQ\n");
> + pr_warn("qnap_ts409_init: failed to get RTC IRQ\n");
> i2c_register_board_info(0, _ts409_i2c_rtc, 1);
> platform_device_register(_leds);
>
> diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c
> b/arch/arm/mach-orion5x/ts78xx-setup.c
> index db16dae..1b704d3 100644
> --- a/arch/arm/mach-orion5x/ts78xx-setup.c
> +++ b/arch/arm/mach-orion5x/ts78xx-setup.c
> @@ -403,8 +403,8 @@ static void ts78xx_fpga_supports(void)
> /* enable devices if magic matches */
> switch ((ts78xx_fpga.id >> 8) & 0xff) {
> case TS7800_FPGA_MAGIC:
> - pr_warning("unrecognised FPGA revision 0x%.2x\n",
> - ts78xx_fpga.id & 0xff);
> + pr_warn("unrecognised FPGA revision 0x%.2x\n",
> + ts78xx_fpga.id & 0xff);
> ts78xx_fpga.supports.ts_rtc.present = 1;
> ts78xx_fpga.supports.ts_nand.present = 1;
> ts78xx_fpga.supports.ts_rng.present = 1;
> --
> 1.8.1.2.459.gbcd45b4.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH/RFC] rtc: rtc-twl: Fixed nested IRQ handling in resume from suspend
On Sat, 13 Sep 2014, Laurent Pinchart wrote: > The TWL RTC interrupt is a double-nested threaded interrupt, handled > through the TWL SIH (Secondary Interrupt Handler) and PIH (Primary > Interrupt Handler). > > When the system is woken up from suspend by a TWL RTC alarm interrupt, > the TWL PIH and SIH are enabled first (due to the normal IRQ enabling > sequence for the PIH and to the IRQF_EARLY_RESUME flag for the SIH) > before the TWL RTC interrupt gets enabled. This results on the interrupt > being processed by the TWL primary interrupt handler, forwarded to the > nested SIH, and then marked as pending for the RTC by handle_nested_irq > called from the SIH. > > The RTC interrupt then eventually gets reenabled the kernel, which will > try to call its top half interrupt handler. As the interrupt is a nested > threaded IRQ, its primary handler has been set to the > irq_nested_primary_handler function, which is never supposed to be > called and generates a WARN_ON, without waking the IRQ thread up. > > Fix this by setting the IRQF_EARLY_RESUME for the TWL RTC interrupt to > ensure it gets enabled before the parent handlers try to process it. > > This is likely a bit of a hack, I have a feeling that a more generic > solution that would fix the problem for all nested threaded IRQs enabled > as a wake up source by enable_irq_wake would be better. Indeed. It's a hack. This is not the first abuse of IRQF_EARLY_RESUME which is used to "fix" ordering issues with nested thread handlers. I haven't come around yet to analyze the issue and come up with a proper core side mechanism to handle that case. I put it on the "look at it while trapped in a tin can" list. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
On Sat, 2014-09-13 at 21:05 +0200, Heinrich Schuchardt wrote:
> Compiling with OCTEON_MGMT_ETHERNET gives a warning
> drivers/net/ethernet/octeon/octeon_mgmt.c:295:4:
> warning: ISO C90 forbids mixed declarations and code
> [-Wdeclaration-after-statement]
Maybe better to move the memset after the declaration.
> diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c
> b/drivers/net/ethernet/octeon/octeon_mgmt.c
[]
> @@ -254,6 +254,7 @@ static void octeon_mgmt_clean_tx_buffers(struct
> octeon_mgmt *p)
> struct sk_buff *skb;
> int cleaned = 0;
> unsigned long flags;
> + u64 ns;
>
> mix_orcnt.u64 = cvmx_read_csr(p->mix + MIX_ORCNT);
> while (mix_orcnt.s.orcnt) {
> @@ -292,7 +293,7 @@ static void octeon_mgmt_clean_tx_buffers(struct
> octeon_mgmt *p)
> struct skb_shared_hwtstamps ts;
> memset(, 0, sizeof(ts));
> /* Read the timestamp */
> - u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
> + ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
> /* Remove the timestamp from the FIFO */
> cvmx_write_csr(CVMX_MIXX_TSCTL(p->port), 0);
> /* Tell the kernel about the timestamp */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] netdev: octeon_mgmt: ISO C90 forbids mixed declarations and code
Compiling with OCTEON_MGMT_ETHERNET gives a warning
drivers/net/ethernet/octeon/octeon_mgmt.c:295:4:
warning: ISO C90 forbids mixed declarations and code
[-Wdeclaration-after-statement]
The patch cleans up the code.
Signed-off-by: Heinrich Schuchardt
---
drivers/net/ethernet/octeon/octeon_mgmt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c
b/drivers/net/ethernet/octeon/octeon_mgmt.c
index 979c698..8af453a 100644
--- a/drivers/net/ethernet/octeon/octeon_mgmt.c
+++ b/drivers/net/ethernet/octeon/octeon_mgmt.c
@@ -254,6 +254,7 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt
*p)
struct sk_buff *skb;
int cleaned = 0;
unsigned long flags;
+ u64 ns;
mix_orcnt.u64 = cvmx_read_csr(p->mix + MIX_ORCNT);
while (mix_orcnt.s.orcnt) {
@@ -292,7 +293,7 @@ static void octeon_mgmt_clean_tx_buffers(struct octeon_mgmt
*p)
struct skb_shared_hwtstamps ts;
memset(, 0, sizeof(ts));
/* Read the timestamp */
- u64 ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
+ ns = cvmx_read_csr(CVMX_MIXX_TSTAMP(p->port));
/* Remove the timestamp from the FIFO */
cvmx_write_csr(CVMX_MIXX_TSCTL(p->port), 0);
/* Tell the kernel about the timestamp */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 2/3] mm: add swap_get_free hint for zram
On Wed, Sep 3, 2014 at 9:39 PM, Minchan Kim wrote:
> VM uses nr_swap_pages as one of information when it does
> anonymous reclaim so that VM is able to throttle amount of swap.
>
> Normally, the nr_swap_pages is equal to freeable space of swap disk
> but for zram, it doesn't match because zram can limit memory usage
> by knob(ie, mem_limit) so although VM can see lots of free space
> from zram disk, zram can make fail intentionally once the allocated
> space is over to limit. If it happens, VM should notice it and
> stop reclaimaing until zram can obtain more free space but there
> is a good way to do at the moment.
>
> This patch adds new hint SWAP_GET_FREE which zram can return how
> many of freeable space it has. With using that, this patch adds
> __swap_full which returns true if the zram is full and substract
> remained freeable space of the zram-swap from nr_swap_pages.
> IOW, VM sees there is no more swap space of zram so that it stops
> anonymous reclaiming until swap_entry_free free a page and increase
> nr_swap_pages again.
>
> Signed-off-by: Minchan Kim
> ---
> include/linux/blkdev.h | 1 +
> mm/swapfile.c | 45 +++--
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 17437b2c18e4..c1199806e0f1 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -1611,6 +1611,7 @@ static inline bool blk_integrity_is_initialized(struct
> gendisk *g)
>
> enum swap_blk_hint {
> SWAP_SLOT_FREE,
> + SWAP_GET_FREE,
> };
>
> struct block_device_operations {
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 4bff521e649a..72737e6dd5e5 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -484,6 +484,22 @@ new_cluster:
> *scan_base = tmp;
> }
>
> +static bool __swap_full(struct swap_info_struct *si)
> +{
> + if (si->flags & SWP_BLKDEV) {
> + long free;
> + struct gendisk *disk = si->bdev->bd_disk;
> +
> + if (disk->fops->swap_hint)
> + if (!disk->fops->swap_hint(si->bdev,
> + SWAP_GET_FREE,
> + ))
> + return free <= 0;
> + }
> +
> + return si->inuse_pages == si->pages;
> +}
> +
> static unsigned long scan_swap_map(struct swap_info_struct *si,
>unsigned char usage)
> {
> @@ -583,11 +599,21 @@ checks:
> if (offset == si->highest_bit)
> si->highest_bit--;
> si->inuse_pages++;
> - if (si->inuse_pages == si->pages) {
> + if (__swap_full(si)) {
This check is done after an available offset has already been
selected. So if the variable-size blkdev is full at this point, then
this is incorrect, as swap will try to store a page at the current
selected offset.
> + struct gendisk *disk = si->bdev->bd_disk;
> +
> si->lowest_bit = si->max;
> si->highest_bit = 0;
> spin_lock(_avail_lock);
> plist_del(>avail_list, _avail_head);
> + /*
> +* If zram is full, it decreases nr_swap_pages
> +* for stopping anonymous page reclaim until
> +* zram has free space. Look at swap_entry_free
> +*/
> + if (disk->fops->swap_hint)
Simply checking for the existence of swap_hint isn't enough to know
we're using zram...
> + atomic_long_sub(si->pages - si->inuse_pages,
> + _swap_pages);
> spin_unlock(_avail_lock);
> }
> si->swap_map[offset] = usage;
> @@ -796,6 +822,7 @@ static unsigned char swap_entry_free(struct
> swap_info_struct *p,
>
> /* free if no reference */
> if (!usage) {
> + struct gendisk *disk = p->bdev->bd_disk;
> dec_cluster_info_page(p, p->cluster_info, offset);
> if (offset < p->lowest_bit)
> p->lowest_bit = offset;
> @@ -808,6 +835,21 @@ static unsigned char swap_entry_free(struct
> swap_info_struct *p,
> if (plist_node_empty(>avail_list))
> plist_add(>avail_list,
> _avail_head);
> + if ((p->flags & SWP_BLKDEV) &&
> + disk->fops->swap_hint) {
freeing an entry from a full variable-size blkdev doesn't mean it's
not still full. In this case with zsmalloc, freeing one handle
doesn't actually free any memory unless it was the only handle left in
its containing zspage, and therefore it's possible that it is still
full at this point.
> + atomic_long_add(p->pages -
> +
[PATCH 6/6] x86/efi: introduce EFI_BOOT_SERVICES_WARN
There may exist buggy implementations of UEFI firmaware that may still
try to access the EFI_BOOT_SERVICES_* memory regions after the call to
ExitBootServices() has been made. This is a violation of the UEFI
specification.
If selected, this debug option will print a warning message if the
conditions mentioned above are met. Along with the warning, the EFI
platform code will fix up the page fault so that the firmware can
proceed further. We are sure that the page fault will be caused by the
firmware trying to access an unmapped page as the kernel has reserved
such pages.
If not selected, EFI_BOOT_SERVICES_CODE/DATA memory regions will be
reserved and mapped along with the runtime memory regions so that the
buggy firmware does not cause any page faults when trying to accessing
such memory regions. This is the approach from Matthew Garrett in commit
916f676f8dc0 ("x86, efi: Retain boot service code until after switching
to virtual mode").
Being more verbose about this kind of illegal access from the firmware
increases the likelihood of this kind firmware bugs to be fixed.
Signed-off-by: Ricardo Neri
---
arch/x86/Kconfig| 12
arch/x86/platform/efi/efi.c | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 778178f..d1c958a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1565,6 +1565,18 @@ config EFI_MIXED
If unsure, say N.
+config EFI_BOOT_SERVICES_WARN
+ bool "Warn about illegal accesses to BOOT_SERVICES memory"
+ depends on EFI
+ ---help---
+ Enable this debug feature to make the kernel issue a warning if
+ memory regions marked as EFI_BOOT_SERVICES_CODE/DATA are
+ accessed after the kernel calls ExitBootServices() on the
+ firmware. Please see the UEFI specification for details on
+ the expectations of memory usage.
+
+ If unsure, say N.
+
config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index fd52004..c67637b 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -689,7 +689,7 @@ static void * __init efi_map_regions(int *count, int
*pg_shift)
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
md = p;
if (!(md->attribute & EFI_MEMORY_RUNTIME)) {
-#ifdef CONFIG_X86_64
+#if defined(CONFIG_X86_64) && !defined(CONFIG_EFI_BOOT_SERVICES_WARN)
if (md->type != EFI_BOOT_SERVICES_CODE &&
md->type != EFI_BOOT_SERVICES_DATA)
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] yx86/efi: fixup faults from UEFI firmware
Buggy UEFI firmware implementations may try to access the EFI_BOOT_SERVICES_* memory regions even after those regions have been surrendered to the kernel (after calling ExitBootServices() on the firmware). If such regions are not mapped, a page fault will be generated. Fix that up. We are sure that we will not have false positives as those memory regions are reserved and the kernel cannot use them. Signed-off-by: Ricardo Neri --- arch/x86/mm/fault.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index a241946..f084912 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -14,6 +14,7 @@ #include /* hstate_index_to_shift*/ #include /* prefetchw*/ #include /* exception_enter(), ... */ +#include /* fixup for buggy UEFI firmware*/ #include /* dotraplinkage, ... */ #include/* pgd_*(), ... */ @@ -702,6 +703,13 @@ no_context(struct pt_regs *regs, unsigned long error_code, return; /* +* Try to fixup faults caused by illegal access to BOOT_SERVICES_* +* regions by UEFI firmware. +*/ + if (efi_boot_services_fixup(address)) + return; + + /* * Oops. The kernel tried to access some bad page. We'll have to * terminate things with extreme prejudice: */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] x86/efi: use efi_memory_descriptor in convenience functions
Rather than duplicating the code to lookup for the memory descriptor of
a given physical address, use the utility function efi_memory_descriptor.
Signed-off-by: Ricardo Neri
---
arch/x86/platform/efi/efi.c | 26 ++
drivers/firmware/efi/efi.c | 36 +++-
2 files changed, 21 insertions(+), 41 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 782d617..d45decf 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -924,36 +924,22 @@ efi_memory_desc_t *efi_memory_descriptor(unsigned long
phys_addr)
u32 efi_mem_type(unsigned long phys_addr)
{
efi_memory_desc_t *md;
- void *p;
- if (!efi_enabled(EFI_MEMMAP))
- return 0;
+ md = efi_memory_descriptor(phys_addr);
+ if (md)
+ return md->type;
- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
- md = p;
- if ((md->phys_addr <= phys_addr) &&
- (phys_addr < (md->phys_addr +
- (md->num_pages << EFI_PAGE_SHIFT
- return md->type;
- }
return 0;
}
u64 efi_mem_attributes(unsigned long phys_addr)
{
efi_memory_desc_t *md;
- void *p;
- if (!efi_enabled(EFI_MEMMAP))
- return 0;
+ md = efi_memory_descriptor(phys_addr);
+ if (md)
+ return md->attribute;
- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
- md = p;
- if ((md->phys_addr <= phys_addr) &&
- (phys_addr < (md->phys_addr +
- (md->num_pages << EFI_PAGE_SHIFT
- return md->attribute;
- }
return 0;
}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 64ecbb5..29c85fe 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -206,29 +206,23 @@ subsys_initcall(efisubsys_init);
*/
void __iomem *efi_lookup_mapped_addr(u64 phys_addr)
{
- struct efi_memory_map *map;
- void *p;
- map = efi.memmap;
- if (!map)
+ efi_memory_desc_t *md;
+
+ md = efi_memory_descriptor(phys_addr);
+
+ if (!md)
return NULL;
- if (WARN_ON(!map->map))
+
+ if (!md->virt_addr)
return NULL;
- for (p = map->map; p < map->map_end; p += map->desc_size) {
- efi_memory_desc_t *md = p;
- u64 size = md->num_pages << EFI_PAGE_SHIFT;
- u64 end = md->phys_addr + size;
- if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
- md->type != EFI_BOOT_SERVICES_CODE &&
- md->type != EFI_BOOT_SERVICES_DATA)
- continue;
- if (!md->virt_addr)
- continue;
- if (phys_addr >= md->phys_addr && phys_addr < end) {
- phys_addr += md->virt_addr - md->phys_addr;
- return (__force void __iomem *)(unsigned long)phys_addr;
- }
- }
- return NULL;
+
+ if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
+ md->type != EFI_BOOT_SERVICES_CODE &&
+ md->type != EFI_BOOT_SERVICES_DATA)
+ return NULL;
+
+ phys_addr += md->virt_addr - md->phys_addr;
+ return (__force void __iomem *)(unsigned long)phys_addr;
}
static __initdata efi_config_table_type_t common_tables[] = {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] x86/efi: add code to fixup page faults in BOOT_SERVICES_* regions
As per the UEFI specification, accesses to BOOT_SERVICES_* memory
regions by the UEFI firmware are illegal after the OS has called
ExitBootServices. However, buggy firmware implementations may still
access these regions after such call.
The current approach of the kernel is to reserve and map all the
EFI_BOOT_SERVICES_* memory regions until efi_free_boot_services() is
called so that the buggy firmware can freely access such regions.
A good way to detect these illegal accesses is to not map (but only
reserve) these regions so that the accesses generate a page fault that
the kernel can detect. Upon detection, the fault is fixed-up (i.e., the
region is mapped for the buggy firmware to use). As the pages are
reserved, the fixup is safe.
Thus, rather than just silently allowing the buggy firmware to proceed,
we detect the access and complain about it. Of course, this function
will be called by the page fault handler fixup code in a subsequent
patch.
Ideally, the new memory map with the just mapped region should be passed
to the firmware. However, as per the UEFI specification,
SetVirtualAddressMap may be called only once. Subsequent calls will
return EFI_UNSUPPORTED. Thus, it is pointless to pass the new map.
Furthermore, all the EFI_RUNTIME_SERVICES_* should already be mapped at
this point.
Also, at this point, the virtual address of the system table should have
been found. Thus, there is no need to look for it in the just-mapped
region.
Finally, this new mapping will not impact a reboot from kexec, as kexec
is only concerned about runtime memory regions.
Signed-off-by: Ricardo Neri
---
arch/x86/platform/efi/efi.c | 29 +
include/linux/efi.h | 8
2 files changed, 37 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index d45decf..2e78083 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -954,3 +954,32 @@ static int __init parse_efi_cmdline(char *str)
return 0;
}
early_param("efi", parse_efi_cmdline);
+
+#ifdef CONFIG_EFI_BOOT_SERVICES_WARN
+static const char boot_services_warning[] =
+"Fixing illegal access to BOOT_SERVICES_*. Bug in EFI firmware?\n";
+
+int efi_boot_services_fixup(unsigned long phys_addr)
+{
+ efi_memory_desc_t *md;
+
+ md = efi_memory_descriptor(phys_addr);
+
+ if (!md)
+ return 0;
+
+ if (md->type == EFI_BOOT_SERVICES_CODE ||
+ md->type == EFI_BOOT_SERVICES_DATA) {
+ /*
+* If the page fault was caused by an acccess to BOOT_SERVICES_*
+* memory regions, just map the region... and warn about it.
+* By now we should have found the virtual address of the system
+* table. Thus, no need to update.
+*/
+ pr_warn_once("%s", (char *)_services_warning);
+ efi_map_region(md);
+ return 1;
+ }
+ return 0;
+}
+#endif
diff --git a/include/linux/efi.h b/include/linux/efi.h
index b36b588..fbdc412 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -875,6 +875,14 @@ extern void efi_initialize_iomem_resources(struct resource
*code_resource,
struct resource *data_resource, struct resource *bss_resource);
extern void efi_get_time(struct timespec *now);
extern void efi_reserve_boot_services(void);
+#ifdef CONFIG_EFI_BOOT_SERVICES_WARN
+extern int efi_boot_services_fixup(unsigned long phys_addr);
+#else
+static inline int efi_boot_services_fixup(unsigned long phys_addr)
+{
+ return 0;
+}
+#endif
extern int efi_get_fdt_params(struct efi_fdt_params *params, int verbose);
extern struct efi_memory_map memmap;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] x86/efi: find mem descriptor from phys address
Several functions (efi_mem_type, efi_mem_attributes,
efi_lookup_mapped_addr) scan the memory map looking for the memory
descriptor to which a given physical address belongs for various
purposes.
The scan functionality is duplicated in all the three functions. The
common functionality is consolidated into a single function that three
functions mentioned above may call.
When checking the validity of the validity of the memory map, use
efi_enabled(), provided for this purpose.
Signed-off-by: Ricardo Neri
---
arch/x86/platform/efi/efi.c | 21 -
include/linux/efi.h | 1 +
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 850da94..782d617 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -900,8 +900,27 @@ void __init efi_enter_virtual_mode(void)
}
/*
- * Convenience functions to obtain memory types and attributes
+ * Convenience functions to obtain memory descriptors,
+ * memory types and attributes
*/
+efi_memory_desc_t *efi_memory_descriptor(unsigned long phys_addr)
+{
+ efi_memory_desc_t *md;
+ void *p;
+
+ if (!efi_enabled(EFI_MEMMAP))
+ return NULL;
+
+ for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ md = p;
+ if ((md->phys_addr <= phys_addr) &&
+ (phys_addr < (md->phys_addr +
+ (md->num_pages << EFI_PAGE_SHIFT
+ return md;
+ }
+ return NULL;
+}
+
u32 efi_mem_type(unsigned long phys_addr)
{
efi_memory_desc_t *md;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 45cb4ff..b36b588 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -866,6 +866,7 @@ static inline efi_status_t efi_query_variable_store(u32
attributes, unsigned lon
extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
extern int efi_config_init(efi_config_table_type_t *arch_tables);
extern u64 efi_get_iobase (void);
+extern efi_memory_desc_t *efi_memory_descriptor(unsigned long phys_addr);
extern u32 efi_mem_type (unsigned long phys_addr);
extern u64 efi_mem_attributes (unsigned long phys_addr);
extern u64 efi_mem_attribute (unsigned long phys_addr, unsigned long size);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] Warn about illegal accesses to EFI_BOOT_SERVICES_* memory
The UEFI specification states that the firmware shall not access the
BOOT_SERVICES_DATA/CODE * memory regions after the operating system has
called ExitBootServices on it. Thus, the operating system is free to use
such regions as it sees fit. Still, buggy UEFI firmware implementations
may want to keep accessing these regions.
The current approach of the kernel is to reserve and map the
EFI_BOOT_SERVICES_* regions until efi_free_boot_services() is called
(after calling SetVirtualAddressMap() on the firmware). Further details
are show in the commit 916f676f8dc0 ("x86, efi: Retain boot service code
until after switching to virtual mode") by Matthew Garrett.
A drawback of the current approach is that silently working around this
kind of illegal accesses encourages the perpetuation of these bugs in
UEFI firmware implementations. Rather, this set of patches proposes a
more verbose behavior: continue reserving the EFI_BOOT_SERVICES_* regions
but not map them. If they are not mapped, any access will cause a page
fault that we can catch. Once the fault is catched, the kernel will fix
it up (i.e., map the page for the firmware to use it) and, more important,
complain about it.
We are guaranteed to not have false positives (i.e., page faults caused
by bad kernel code) as these memory regions are still reserved.
Besides fixing up the illegal accesses, no further action is required to
update the memory map the firmware sees. This is true because after boot,
the firmware would require access to the runtime services memory only,
which should be mapped before calling SetVirtualAddressMap. Furthermore,
a second attempt to update the virtual address map will result in a
EFI_UNSUPPORTED from the firmware, as per the UEFI specification.
Also, there is no need to update the system table as it should have been
when mapping the rest of the memory regions.
Finally, kexec is concerned only about the runtime services memory
sections. Thus we don't need any special arrangements for kexec.
The four last patches of the set implement this approach. The first two
provide a rework for code reuse of the convenience functions that look
for the descriptor of a physical memory address when then be used by the
proposed solution.
Ricardo Neri (6):
x86/efi: Add function to obtain mem descriptor from phys address
x86/efi: Use efi_memory_descriptor in mem convenience functions
x86/efi: Add function to fixup page faults in BOOT_SERVICES_* regions
x86/efi: Remove __init attribute from memory mapping functions
yx86/efi: Fixup faults from UEFI firmware
x86/efi: Introduce EFI_BOOT_SERVICES_WARN
arch/x86/Kconfig | 12
arch/x86/include/asm/efi.h | 4 +--
arch/x86/mm/fault.c| 8 +
arch/x86/platform/efi/efi.c| 66 --
arch/x86/platform/efi/efi_32.c | 2 +-
arch/x86/platform/efi/efi_64.c | 8 ++---
drivers/firmware/efi/efi.c | 36 ++-
include/linux/efi.h| 9 ++
8 files changed, 101 insertions(+), 44 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] x86/efi: remove __init attribute from memory mapping functions
Even though these functions are called at kernel boot, they will
also be used by the page fault handler to fixup access to BOOT_SERVICES_*
regions, which do not have the __init attribute.
Signed-off-by: Ricardo Neri
---
arch/x86/include/asm/efi.h | 4 ++--
arch/x86/platform/efi/efi.c| 2 +-
arch/x86/platform/efi/efi_32.c | 2 +-
arch/x86/platform/efi/efi_64.c | 8
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 044a2fd..d427a35 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -94,12 +94,12 @@ extern void efi_call_phys_prelog(void);
extern void efi_call_phys_epilog(void);
extern void efi_unmap_memmap(void);
extern void efi_memory_uc(u64 addr, unsigned long size);
-extern void __init efi_map_region(efi_memory_desc_t *md);
+extern void efi_map_region(efi_memory_desc_t *md);
extern void __init efi_map_region_fixed(efi_memory_desc_t *md);
extern void efi_sync_low_kernel_mappings(void);
extern int efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages);
extern void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned
num_pages);
-extern void __init old_map_region(efi_memory_desc_t *md);
+extern void old_map_region(efi_memory_desc_t *md);
extern void __init runtime_code_page_mkexec(void);
extern void __init efi_runtime_mkexec(void);
extern void __init efi_dump_pagetable(void);
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 2e78083..fd52004 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -547,7 +547,7 @@ void efi_memory_uc(u64 addr, unsigned long size)
set_memory_uc(addr, npages);
}
-void __init old_map_region(efi_memory_desc_t *md)
+void old_map_region(efi_memory_desc_t *md)
{
u64 start_pfn, end_pfn, end;
unsigned long size;
diff --git a/arch/x86/platform/efi/efi_32.c b/arch/x86/platform/efi/efi_32.c
index 9ee3491..766dcaf 100644
--- a/arch/x86/platform/efi/efi_32.c
+++ b/arch/x86/platform/efi/efi_32.c
@@ -47,7 +47,7 @@ int efi_setup_page_tables(unsigned long pa_memmap, unsigned
num_pages)
}
void efi_cleanup_page_tables(unsigned long pa_memmap, unsigned num_pages) {}
-void __init efi_map_region(efi_memory_desc_t *md)
+void efi_map_region(efi_memory_desc_t *md)
{
old_map_region(md);
}
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 290d397..32434ed 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -199,7 +199,7 @@ void efi_cleanup_page_tables(unsigned long pa_memmap,
unsigned num_pages)
kernel_unmap_pages_in_pgd(pgd, pa_memmap, num_pages);
}
-static void __init __map_region(efi_memory_desc_t *md, u64 va)
+static void __map_region(efi_memory_desc_t *md, u64 va)
{
pgd_t *pgd = (pgd_t *)__va(real_mode_header->trampoline_pgd);
unsigned long pf = 0;
@@ -212,7 +212,7 @@ static void __init __map_region(efi_memory_desc_t *md, u64
va)
md->phys_addr, va);
}
-void __init efi_map_region(efi_memory_desc_t *md)
+void efi_map_region(efi_memory_desc_t *md)
{
unsigned long size = md->num_pages << PAGE_SHIFT;
u64 pa = md->phys_addr;
@@ -273,8 +273,8 @@ void __init efi_map_region_fixed(efi_memory_desc_t *md)
__map_region(md, md->virt_addr);
}
-void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
-u32 type, u64 attribute)
+void __iomem *efi_ioremap(unsigned long phys_addr, unsigned long size,
+ u32 type, u64 attribute)
{
unsigned long last_map_pfn;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Freeing dst when the reference count <0 causes general protection fault, it could be a major security flaw as rogue app can modify dst to crash kernel.
On Saturday, September 13, 2014 04:50:22 AM Eric Dumazet wrote: > On Sat, 2014-09-13 at 01:27 -0700, Shakil A Khan wrote: > > Signed-off-by: Shakil A Khan > > --- > > > > net/core/dst.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/net/core/dst.c b/net/core/dst.c > > index a028409..6a848b0 100644 > > --- a/net/core/dst.c > > +++ b/net/core/dst.c > > @@ -284,7 +284,10 @@ void dst_release(struct dst_entry *dst) > > > > int newrefcnt; > > > > newrefcnt = atomic_dec_return(>__refcnt); > > > > - WARN_ON(newrefcnt < 0); > > + > > + if (WARN(newrefcnt < 0, "dst reference count less than zero")) > > + return; > > + > > > > if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt) > > > > call_rcu(>rcu_head, dst_destroy_rcu); > > > > } > > A rogue application can not do trigger this, unless a major bug in the > kernel exists. Please check this kernel trace. It is able to crash the kernel. general protection fault: [#1] PREEMPT SMP Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 nfs fscache lockd sunrpc tun nbd ipmi_si ipmi_watchdog ipmi_devintf ipmi_msghandler xt_mark xt_owner ipt_MASQUERADE xt_physdev xt_state xt_LOG iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables xen_acpi_processor xen_pciback xen_netback xen_blkback xen_gntalloc xen_gntdev xenfs xen_privcmd bridge stp llc ipv6 ext4 jbd2 freq_table mperf coretemp crc32c_intel ghash_clmulni_intel microcode pcspkr sb_edac edac_core lpc_ich mfd_core i2c_i801 sg ioatdma igb dca i2c_algo_bit i2c_core ptp pps_core ext3 jbd mbcache sd_mod crc_t10dif aesni_intel ablk_helper cryptd lrw gf128mul glue_helper aes_x86_64 ahci libahci isci libsas scsi_transport_sas megaraid_sas wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: iTCO_vendor_support] CPU: 6 PID: 15324 Comm: Not tainted 3.10.45-xen.322.17.41238 #1 Hardware name: McAfee, Inc. ATD-6000/S4600LH, BIOS SE5C600.86B.02.01.0002.082220131453 08/22/2013 task: 882bc6255000 ti: 882bc61aa000 task.ti: 882bc61aa000 RIP: e030:[] [] ipv4_dst_destroy+0x3b/0x77 RSP: e02b:882bc61abb48 EFLAGS: 00010296 RAX: dead00200200 RBX: 882bc625bc80 RCX: 0001338a9b7110db RDX: dead00100100 RSI: 82267e30 RDI: 03f4 RBP: 882bc61abb58 R08: d5d6df8b R09: R10: R11: R12: R13: 820e5880 R14: 88070e584b80 R15: FS: 7f8d3fff2700() GS:88081e6c() knlGS: CS: e033 DS: ES: CR0: 80050033 CR2: 0031d0e36ac0 CR3: 002db0165000 CR4: 00042660 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Stack: 882bc61abb58 882bc625bc80 882bc61abb88 8145bfc5 882bc61abba8 882bc625bc80 882bc625bc80 882bc61abba8 8145c2c5 88070e584b80 882b991c2300 Call Trace: [] dst_destroy+0x29/0xbd [] dst_release+0x58/0x67 [] tcp_v4_do_rcv+0x11b/0x287 [] __release_sock+0x7c/0xe7 [] release_sock+0x2e/0x7c [] tcp_sendmsg+0xe0/0xd41 [] inet_sendmsg+0x7d/0xa0 [] sock_aio_write+0x159/0x17d [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] do_sync_write+0x7f/0xa7 [] ? rw_verify_area+0x56/0xd5 [] vfs_write+0x144/0x170 [] SyS_write+0x54/0x8f [] ? __audit_syscall_exit+0x20c/0x29c [] system_call_fastpath+0x16/0x1b Code: fb 48 8d 87 b0 00 00 00 48 39 87 b0 00 00 00 74 4f 48 c7 c7 04 8f 3c 82 e8 32 23 09 00 48 8b 93 b0 00 00 00 48 8b 83 b8 00 00 00 <48> 89 42 08 48 89 10 48 b9 00 01 10 00 00 00 ad de 48 89 8b b0 RIP [] ipv4_dst_destroy+0x3b/0x77 RSP ---[ end trace d56f90482c47af91 ]--- Kernel panic - not syncing: Fatal exception in interrupt > > Instead of trying to hide the kernel bug, we need to fix it. There are two problems with this. First the list has somehow got out of sync in terms of number of delete and allocate, so we need to fix that. But at the same time refcount if <0 signifies its been already freed so we need not free up. We need fix for both and my patch targets later as my system works fine with this patch. > > Can you describe how this could trigger with a pristine kernel ? This is triggered with custom software to imitate malware traffic(Kernel was not having any custom patch whatsoever, it was a pristine kernel 3.10.45). Point is if an application can crash this, then it would be big security flaw not exactly similar but like SSL love bug, which can be exploited to bring down systems. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] arm: mach-ep93xx: Convert pr_warning to pr_warn
Use the more common pr_warn.
Other miscellanea:
o Coalesce formats
Signed-off-by: Joe Perches
---
arch/arm/mach-ep93xx/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ep93xx/core.c b/arch/arm/mach-ep93xx/core.c
index 0e571f1..c75c678 100644
--- a/arch/arm/mach-ep93xx/core.c
+++ b/arch/arm/mach-ep93xx/core.c
@@ -454,9 +454,9 @@ void __init ep93xx_register_i2c(struct
i2c_gpio_platform_data *data,
* CMOS driver.
*/
if (data->sda_is_open_drain && data->sda_pin != EP93XX_GPIO_LINE_EEDAT)
- pr_warning("sda != EEDAT, open drain has no effect\n");
+ pr_warn("sda != EEDAT, open drain has no effect\n");
if (data->scl_is_open_drain && data->scl_pin != EP93XX_GPIO_LINE_EECLK)
- pr_warning("scl != EECLK, open drain has no effect\n");
+ pr_warn("scl != EECLK, open drain has no effect\n");
__raw_writel((data->sda_is_open_drain << 1) |
(data->scl_is_open_drain << 0),
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] arm: mach-orion5x: Convert pr_warning to pr_warn
Use the more common pr_warn.
Other miscellanea:
o Realign arguments
Signed-off-by: Joe Perches
---
arch/arm/mach-orion5x/dns323-setup.c | 8
arch/arm/mach-orion5x/terastation_pro2-setup.c | 2 +-
arch/arm/mach-orion5x/ts209-setup.c| 2 +-
arch/arm/mach-orion5x/ts409-setup.c| 2 +-
arch/arm/mach-orion5x/ts78xx-setup.c | 4 ++--
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-orion5x/dns323-setup.c
b/arch/arm/mach-orion5x/dns323-setup.c
index 56edeab..09d2a26 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -550,7 +550,7 @@ static int __init dns323_identify_rev(void)
break;
}
if (i >= 1000) {
- pr_warning("DNS-323: Timeout accessing PHY, assuming rev B1\n");
+ pr_warn("DNS-323: Timeout accessing PHY, assuming rev B1\n");
return DNS323_REV_B1;
}
writel((3 << 21)/* phy ID reg */ |
@@ -562,7 +562,7 @@ static int __init dns323_identify_rev(void)
break;
}
if (i >= 1000) {
- pr_warning("DNS-323: Timeout reading PHY, assuming rev B1\n");
+ pr_warn("DNS-323: Timeout reading PHY, assuming rev B1\n");
return DNS323_REV_B1;
}
pr_debug("DNS-323: Ethernet PHY ID 0x%x\n", reg & 0x);
@@ -577,8 +577,8 @@ static int __init dns323_identify_rev(void)
case 0x0e10: /* MV88E1118 */
return DNS323_REV_C1;
default:
- pr_warning("DNS-323: Unknown PHY ID 0x%04x, assuming rev B1\n",
- reg & 0x);
+ pr_warn("DNS-323: Unknown PHY ID 0x%04x, assuming rev B1\n",
+ reg & 0x);
}
return DNS323_REV_B1;
}
diff --git a/arch/arm/mach-orion5x/terastation_pro2-setup.c
b/arch/arm/mach-orion5x/terastation_pro2-setup.c
index 6208d12..1208674 100644
--- a/arch/arm/mach-orion5x/terastation_pro2-setup.c
+++ b/arch/arm/mach-orion5x/terastation_pro2-setup.c
@@ -349,7 +349,7 @@ static void __init tsp2_init(void)
gpio_free(TSP2_RTC_GPIO);
}
if (tsp2_i2c_rtc.irq == 0)
- pr_warning("tsp2_init: failed to get RTC IRQ\n");
+ pr_warn("tsp2_init: failed to get RTC IRQ\n");
i2c_register_board_info(0, _i2c_rtc, 1);
/* register Terastation Pro II specific power-off method */
diff --git a/arch/arm/mach-orion5x/ts209-setup.c
b/arch/arm/mach-orion5x/ts209-setup.c
index 9136797..c725b7c 100644
--- a/arch/arm/mach-orion5x/ts209-setup.c
+++ b/arch/arm/mach-orion5x/ts209-setup.c
@@ -314,7 +314,7 @@ static void __init qnap_ts209_init(void)
gpio_free(TS209_RTC_GPIO);
}
if (qnap_ts209_i2c_rtc.irq == 0)
- pr_warning("qnap_ts209_init: failed to get RTC IRQ\n");
+ pr_warn("qnap_ts209_init: failed to get RTC IRQ\n");
i2c_register_board_info(0, _ts209_i2c_rtc, 1);
/* register tsx09 specific power-off method */
diff --git a/arch/arm/mach-orion5x/ts409-setup.c
b/arch/arm/mach-orion5x/ts409-setup.c
index 5c079d31..cf2ab53 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -302,7 +302,7 @@ static void __init qnap_ts409_init(void)
gpio_free(TS409_RTC_GPIO);
}
if (qnap_ts409_i2c_rtc.irq == 0)
- pr_warning("qnap_ts409_init: failed to get RTC IRQ\n");
+ pr_warn("qnap_ts409_init: failed to get RTC IRQ\n");
i2c_register_board_info(0, _ts409_i2c_rtc, 1);
platform_device_register(_leds);
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c
b/arch/arm/mach-orion5x/ts78xx-setup.c
index db16dae..1b704d3 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -403,8 +403,8 @@ static void ts78xx_fpga_supports(void)
/* enable devices if magic matches */
switch ((ts78xx_fpga.id >> 8) & 0xff) {
case TS7800_FPGA_MAGIC:
- pr_warning("unrecognised FPGA revision 0x%.2x\n",
- ts78xx_fpga.id & 0xff);
+ pr_warn("unrecognised FPGA revision 0x%.2x\n",
+ ts78xx_fpga.id & 0xff);
ts78xx_fpga.supports.ts_rtc.present = 1;
ts78xx_fpga.supports.ts_nand.present = 1;
ts78xx_fpga.supports.ts_rng.present = 1;
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] arm: mach-davinci: Convert pr_warning to pr_warn
Use the more common pr_warn.
Other miscellanea:
o Coalesce formats
o Realign arguments
Signed-off-by: Joe Perches
---
arch/arm/mach-davinci/board-da830-evm.c| 76 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 6 +--
arch/arm/mach-davinci/board-mityomapl138.c | 38 +++
arch/arm/mach-davinci/board-neuros-osd2.c | 3 +-
arch/arm/mach-davinci/time.c | 6 +--
5 files changed, 55 insertions(+), 74 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 5623131..c73cd88 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -145,8 +145,7 @@ static __init void da830_evm_usb_init(void)
/* USB_REFCLKIN is not used. */
ret = davinci_cfg_reg(DA830_USB0_DRVVBUS);
if (ret)
- pr_warning("%s: USB 2.0 PinMux setup failed: %d\n",
- __func__, ret);
+ pr_warn("%s: USB 2.0 PinMux setup failed: %d\n", __func__, ret);
else {
/*
* TPS2065 switch @ 5V supplies 1 A (sustains 1.5 A),
@@ -154,14 +153,14 @@ static __init void da830_evm_usb_init(void)
*/
ret = da8xx_register_usb20(1000, 3);
if (ret)
- pr_warning("%s: USB 2.0 registration failed: %d\n",
- __func__, ret);
+ pr_warn("%s: USB 2.0 registration failed: %d\n",
+ __func__, ret);
}
ret = davinci_cfg_reg_list(da830_evm_usb11_pins);
if (ret) {
- pr_warning("%s: USB 1.1 PinMux setup failed: %d\n",
- __func__, ret);
+ pr_warn("%s: USB 1.1 PinMux setup failed: %d\n",
+ __func__, ret);
return;
}
@@ -183,8 +182,8 @@ static __init void da830_evm_usb_init(void)
ret = da8xx_register_usb11(_evm_usb11_pdata);
if (ret)
- pr_warning("%s: USB 1.1 registration failed: %d\n",
- __func__, ret);
+ pr_warn("%s: USB 1.1 registration failed: %d\n",
+ __func__, ret);
}
static const short da830_evm_mcasp1_pins[] = {
@@ -252,31 +251,30 @@ static inline void da830_evm_init_mmc(void)
ret = davinci_cfg_reg_list(da830_evm_mmc_sd_pins);
if (ret) {
- pr_warning("da830_evm_init: mmc/sd mux setup failed: %d\n",
- ret);
+ pr_warn("da830_evm_init: mmc/sd mux setup failed: %d\n", ret);
return;
}
ret = gpio_request(DA830_MMCSD_WP_PIN, "MMC WP");
if (ret) {
- pr_warning("da830_evm_init: can not open GPIO %d\n",
- DA830_MMCSD_WP_PIN);
+ pr_warn("da830_evm_init: can not open GPIO %d\n",
+ DA830_MMCSD_WP_PIN);
return;
}
gpio_direction_input(DA830_MMCSD_WP_PIN);
ret = gpio_request(DA830_MMCSD_CD_PIN, "MMC CD\n");
if (ret) {
- pr_warning("da830_evm_init: can not open GPIO %d\n",
- DA830_MMCSD_CD_PIN);
+ pr_warn("da830_evm_init: can not open GPIO %d\n",
+ DA830_MMCSD_CD_PIN);
return;
}
gpio_direction_input(DA830_MMCSD_CD_PIN);
ret = da8xx_register_mmcsd0(_evm_mmc_config);
if (ret) {
- pr_warning("da830_evm_init: mmc/sd registration failed: %d\n",
- ret);
+ pr_warn("da830_evm_init: mmc/sd registration failed: %d\n",
+ ret);
gpio_free(DA830_MMCSD_WP_PIN);
}
}
@@ -404,20 +402,18 @@ static inline void da830_evm_init_nand(int mux_mode)
int ret;
if (HAS_MMC) {
- pr_warning("WARNING: both MMC/SD and NAND are "
- "enabled, but they share AEMIF pins.\n"
- "\tDisable MMC/SD for NAND support.\n");
+ pr_warn("WARNING: both MMC/SD and NAND are enabled, but they
share AEMIF pins.\n"
+ "\tDisable MMC/SD for NAND support.\n");
return;
}
ret = davinci_cfg_reg_list(da830_evm_emif25_pins);
if (ret)
- pr_warning("da830_evm_init: emif25 mux setup failed: %d\n",
- ret);
+ pr_warn("da830_evm_init: emif25 mux setup failed: %d\n", ret);
ret = platform_device_register(_evm_nand_device);
if (ret)
- pr_warning("da830_evm_init: NAND device not registered.\n");
+ pr_warn("da830_evm_init: NAND device not registered.\n");
if (davinci_aemif_setup(_evm_nand_device))
pr_warn("%s: Cannot configure AEMIF.\n", __func__);
@@ -435,12
[PATCH 4/8] arm: mach-imx: Convert pr_warning to pr_warn
Use the more common pr_warn.
Signed-off-by: Joe Perches
---
arch/arm/mach-imx/mach-armadillo5x0.c | 2 +-
arch/arm/mach-imx/mach-mx31_3ds.c | 4 ++--
arch/arm/mach-imx/mach-mx31lite.c | 2 +-
arch/arm/mach-imx/mach-pcm037.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-imx/mach-armadillo5x0.c
b/arch/arm/mach-imx/mach-armadillo5x0.c
index a7e9bd2..f206052 100644
--- a/arch/arm/mach-imx/mach-armadillo5x0.c
+++ b/arch/arm/mach-imx/mach-armadillo5x0.c
@@ -537,7 +537,7 @@ static void __init armadillo5x0_init(void)
gpio_free(ARMADILLO5X0_RTC_GPIO);
}
if (armadillo5x0_i2c_rtc.irq == 0)
- pr_warning("armadillo5x0_init: failed to get RTC IRQ\n");
+ pr_warn("armadillo5x0_init: failed to get RTC IRQ\n");
i2c_register_board_info(1, _i2c_rtc, 1);
/* USB */
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c
b/arch/arm/mach-imx/mach-mx31_3ds.c
index 453f41a..65a0dc0 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -307,7 +307,7 @@ static int mx31_3ds_sdhc1_init(struct device *dev,
ret = gpio_request_array(mx31_3ds_sdhc1_gpios,
ARRAY_SIZE(mx31_3ds_sdhc1_gpios));
if (ret) {
- pr_warning("Unable to request the SD/MMC GPIOs.\n");
+ pr_warn("Unable to request the SD/MMC GPIOs.\n");
return ret;
}
@@ -316,7 +316,7 @@ static int mx31_3ds_sdhc1_init(struct device *dev,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
"sdhc1-detect", data);
if (ret) {
- pr_warning("Unable to request the SD/MMC card-detect IRQ.\n");
+ pr_warn("Unable to request the SD/MMC card-detect IRQ.\n");
goto gpio_free;
}
diff --git a/arch/arm/mach-imx/mach-mx31lite.c
b/arch/arm/mach-imx/mach-mx31lite.c
index 57eac6f..4822a17 100644
--- a/arch/arm/mach-imx/mach-mx31lite.c
+++ b/arch/arm/mach-imx/mach-mx31lite.c
@@ -270,7 +270,7 @@ static void __init mx31lite_init(void)
/* SMSC9117 IRQ pin */
ret = gpio_request(IOMUX_TO_GPIO(MX31_PIN_SFS6), "sms9117-irq");
if (ret)
- pr_warning("could not get LAN irq gpio\n");
+ pr_warn("could not get LAN irq gpio\n");
else {
gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_SFS6));
smsc911x_resources[1].start =
diff --git a/arch/arm/mach-imx/mach-pcm037.c b/arch/arm/mach-imx/mach-pcm037.c
index 8eb1570..6d87941 100644
--- a/arch/arm/mach-imx/mach-pcm037.c
+++ b/arch/arm/mach-imx/mach-pcm037.c
@@ -58,7 +58,7 @@ static int __init pcm037_variant_setup(char *str)
if (!strcmp("eet", str))
pcm037_instance = PCM037_EET;
else if (strcmp("pcm970", str))
- pr_warning("Unknown pcm037 baseboard variant %s\n", str);
+ pr_warn("Unknown pcm037 baseboard variant %s\n", str);
return 1;
}
@@ -624,7 +624,7 @@ static void __init pcm037_init(void)
/* LAN9217 IRQ pin */
ret = gpio_request(IOMUX_TO_GPIO(MX31_PIN_GPIO3_1), "lan9217-irq");
if (ret)
- pr_warning("could not get LAN irq gpio\n");
+ pr_warn("could not get LAN irq gpio\n");
else {
gpio_direction_input(IOMUX_TO_GPIO(MX31_PIN_GPIO3_1));
smsc911x_resources[1].start =
--
1.8.1.2.459.gbcd45b4.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
