Re: [RFC 1/1] MicroSemi Switchtec management interface driver
On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote:
> +struct switchtec_dev {
> + struct pci_dev *pdev;
> + struct msix_entry *msix;
> + struct device *dev;
> + struct kref kref;
Why do you have a pointer to a device, yet a kref as well? Just have
this structure embed a 'struct device' in itself, like you did for a
kref, and you will be fine. Otherwise you are dealing with two
different sets of reference counting here, for no good reason.
> +
> + unsigned int event_irq;
> +
> + void __iomem *mmio;
> + struct mrpc_regs __iomem *mmio_mrpc;
> + struct ntb_info_regs __iomem *mmio_ntb;
> + struct part_cfg_regs __iomem *mmio_part_cfg;
> +
> + /*
> + * The mrpc mutex must be held when accessing the other
> + * mrpc fields
> + */
> + struct mutex mrpc_mutex;
> + struct list_head mrpc_queue;
> + int mrpc_busy;
> + struct work_struct mrpc_work;
> + struct delayed_work mrpc_timeout;
> +};
> +
> +#define stdev_pdev(stdev) ((stdev)->pdev)
> +#define stdev_pdev_dev(stdev) (&stdev_pdev(stdev)->dev)
> +#define stdev_name(stdev) pci_name(stdev_pdev(stdev))
> +#define stdev_dev(stdev) ((stdev)->dev)
Ick, just open code these please. That's a huge hint your use of the
driver model is not correct :)
thanks,
greg k-h
Re: [PATCH v2] x86/floppy: use designated initializers
* Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook
> ---
> v2:
> - aligned rhs of initializer, ingo
> ---
> arch/x86/include/asm/floppy.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
> index 1c7eefe32502..202fe3e1fae8 100644
> --- a/arch/x86/include/asm/floppy.h
> +++ b/arch/x86/include/asm/floppy.h
> @@ -229,18 +229,18 @@ static struct fd_routine_l {
> int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
> } fd_routine[] = {
> {
> - request_dma,
> - free_dma,
> - get_dma_residue,
> - dma_mem_alloc,
> - hard_dma_setup
> + ._request_dma = request_dma,
> + ._free_dma =free_dma,
> + ._get_dma_residue = get_dma_residue,
> + ._dma_mem_alloc = dma_mem_alloc,
> + ._dma_setup = hard_dma_setup
> },
> {
> - vdma_request_dma,
> - vdma_nop,
> - vdma_get_dma_residue,
> - vdma_mem_alloc,
> - vdma_dma_setup
> + ._request_dma = vdma_request_dma,
> + ._free_dma =vdma_nop,
> + ._get_dma_residue = vdma_get_dma_residue,
> + ._dma_mem_alloc = vdma_mem_alloc,
> + ._dma_setup = vdma_dma_setup
That's not how we organize named initializers, we do:
._request_dma = vdma_request_dma,
._free_dma = vdma_nop,
._get_dma_residue = vdma_get_dma_residue,
._dma_mem_alloc = vdma_mem_alloc,
._dma_setup = vdma_dma_setup
I have fixed up the patch.
Thanks,
Ingo
Re: [PATCH 0/2] z3fold fixes
On Tue, Nov 29, 2016 at 11:39 PM, Andrew Morton
wrote:
> On Tue, 29 Nov 2016 17:33:19 -0500 Dan Streetman wrote:
>
>> On Sat, Nov 26, 2016 at 2:15 PM, Vitaly Wool wrote:
>> > Here come 2 patches with z3fold fixes for chunks counting and locking. As
>> > commit 50a50d2 ("z3fold: don't fail kernel build is z3fold_header is too
>> > big") was NAK'ed [1], I would suggest that we removed that one and the
>> > next z3fold commit cc1e9c8 ("z3fold: discourage use of pages that weren't
>> > compacted") and applied the coming 2 instead.
>>
>> Instead of adding these onto all the previous ones, could you redo the
>> entire z3fold series? I think it'll be simpler to review the series
>> all at once and that would remove some of the stuff from previous
>> patches that shouldn't be there.
>>
>> If that's ok with Andrew, of course, but I don't think any of the
>> z3fold patches have been pushed to Linus yet.
>
> Sounds good to me. I had a few surprise rejects when merging these
> two, which indicates that things might be out of sync.
>
> I presently have:
>
> z3fold-limit-first_num-to-the-actual-range-of-possible-buddy-indexes.patch
> z3fold-make-pages_nr-atomic.patch
> z3fold-extend-compaction-function.patch
> z3fold-use-per-page-spinlock.patch
> z3fold-discourage-use-of-pages-that-werent-compacted.patch
> z3fold-fix-header-size-related-issues.patch
> z3fold-fix-locking-issues.patch
My initial suggestion was to have it the following way:
z3fold-limit-first_num-to-the-actual-range-of-possible-buddy-indexes.patch
z3fold-make-pages_nr-atomic.patch
z3fold-extend-compaction-function.patch
z3fold-use-per-page-spinlock.patch
z3fold-fix-header-size-related-issues.patch
z3fold-fix-locking-issues.patch
I would prefer to keep the fix-XXX patches separate since e. g.
z3fold-fix-header-size-related-issues.patch concerns also the problems
that have been in the code for a while now. I am ok with folding these
into the relevant main patches but once again, given that some fixes
are related to the code that is already merged, I don't see why it
would be better.
~vitaly
[tip:x86/urgent] x86/floppy: Use designated initializers
Commit-ID: ffc7dc8d838c6403a550021e4f28a737334d80a7
Gitweb: http://git.kernel.org/tip/ffc7dc8d838c6403a550021e4f28a737334d80a7
Author: Kees Cook
AuthorDate: Sat, 17 Dec 2016 13:37:05 -0800
Committer: Ingo Molnar
CommitDate: Sun, 18 Dec 2016 09:25:38 +0100
x86/floppy: Use designated initializers
Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.
Signed-off-by: Kees Cook
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20161217213705.GA1248@beast
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/floppy.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
index 1c7eefe..7ec59ed 100644
--- a/arch/x86/include/asm/floppy.h
+++ b/arch/x86/include/asm/floppy.h
@@ -229,18 +229,18 @@ static struct fd_routine_l {
int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
} fd_routine[] = {
{
- request_dma,
- free_dma,
- get_dma_residue,
- dma_mem_alloc,
- hard_dma_setup
+ ._request_dma = request_dma,
+ ._free_dma = free_dma,
+ ._get_dma_residue = get_dma_residue,
+ ._dma_mem_alloc = dma_mem_alloc,
+ ._dma_setup = hard_dma_setup
},
{
- vdma_request_dma,
- vdma_nop,
- vdma_get_dma_residue,
- vdma_mem_alloc,
- vdma_dma_setup
+ ._request_dma = vdma_request_dma,
+ ._free_dma = vdma_nop,
+ ._get_dma_residue = vdma_get_dma_residue,
+ ._dma_mem_alloc = vdma_mem_alloc,
+ ._dma_setup = vdma_dma_setup
}
};
Re: [PATCH] x86/head: Refactor 32-bit pgtable setup
* Boris Ostrovsky wrote: > On 12/08/2016 11:33 PM, Ingo Molnar wrote: > > * Boris Ostrovsky wrote: > > > >> The new Xen PVH entry point requires page tables to be setup by the > >> kernel since it is entered with paging disabled. > >> > >> Pull the common code out of head_32.S so that mk_early_pgtbl_32 can be > >> invoked from both the new Xen entry point and the existing startup_32 > >> code. > >> > >> Convert resulting common code to C. > >> > >> Signed-off-by: Boris Ostrovsky > >> --- > >> This is replacement for https://lkml.org/lkml/2016/10/14/434, with > >> assembly code re-written in C as requested by Ingo. > >> > >> > >> arch/x86/include/asm/pgtable_32.h | 32 ++ > >> arch/x86/kernel/head32.c | 62 +++ > >> arch/x86/kernel/head_32.S | 122 > >> +++--- > >> 3 files changed, 101 insertions(+), 115 deletions(-) > > Whee, I love it! And the code is so much more readable! > > > > Did you have any particular robustness problems (difficult to resolve > > crashes) > > while developing it, or was it reasonably straightforward to do? > > There was nothing particularly difficult beyond understanding current > code. That, of course, is not to say that there were no crashes but > developing this on a guest gives you pretty good insight into why/where > you crashed. > > This was tested on bare-metal (in case you are wondering), but obviously > more testing is always good. Ok, cool! Would you like to carry this with your other Xen dependencies? If yes: Acked-by: Ingo Molnar If not then I can pick it up and get it to Linus in v4.10. Thanks, Ingo
Re: [PATCH v5 2/6] [media] rc-main: split setup and unregister functions
Hi Sean, > On Fri, Dec 16, 2016 at 12:10:26PM +, Sean Young wrote: > > Sorry to add to your woes, but there are some checkpatch warnings and > > errors. Please can you correct these. One is below. > > Actually, the changes are pretty minor, I can fix them up before sending > them to Mauro. Sorry for bothering you. yes, it's an error on the previous code: ERROR: do not initialise statics to false #109: FILE: drivers/media/rc/rc-main.c:1521: + static bool raw_init = false; /* raw decoders loaded? */ total: 1 errors, 0 warnings, 196 lines checked I noticed this already before, but I preferred to leave it in its original status. No worries, if you want I will send the fix, it's indeed quite an easy fix. Thanks, Andi
[PATCH v2] USB: serial: f81534: Detect errors from f81534_logic_to_phy_port()
With gcc 4.1.2:
drivers/usb/serial/f81534.c: In function ‘f81534_port_probe’:
drivers/usb/serial/f81534.c:1250: warning: comparison is always false due
to limited range of data type
f81534_logic_to_phy_port() may return a negative error value, which is
ignored by assigning it to u8 f81534_port_private.phy_num.
Use an intermediate variable of type int to fix this.
While at it, forward the actual error code instead of converting it to
-ENODEV, and drop the useless check for F81534_NUM_PORT, as the callee
always returns a valid port number in case of success.
Fixes: 0c9bd6004d258d46 ("USB: serial: add Fintek F81532/534 driver")
Signed-off-by: Geert Uytterhoeven
---
v2:
- Drop useless check for F81534_NUM_PORT.
---
drivers/usb/serial/f81534.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/serial/f81534.c b/drivers/usb/serial/f81534.c
index 8282a6a18fee83f6..22f23a429a95cb6a 100644
--- a/drivers/usb/serial/f81534.c
+++ b/drivers/usb/serial/f81534.c
@@ -1237,6 +1237,7 @@ static int f81534_attach(struct usb_serial *serial)
static int f81534_port_probe(struct usb_serial_port *port)
{
struct f81534_port_private *port_priv;
+ int ret;
port_priv = devm_kzalloc(&port->dev, sizeof(*port_priv), GFP_KERNEL);
if (!port_priv)
@@ -1246,10 +1247,11 @@ static int f81534_port_probe(struct usb_serial_port
*port)
mutex_init(&port_priv->mcr_mutex);
/* Assign logic-to-phy mapping */
- port_priv->phy_num = f81534_logic_to_phy_port(port->serial, port);
- if (port_priv->phy_num < 0 || port_priv->phy_num >= F81534_NUM_PORT)
- return -ENODEV;
+ ret = f81534_logic_to_phy_port(port->serial, port);
+ if (ret < 0)
+ return ret;
+ port_priv->phy_num = ret;
usb_set_serial_port_data(port, port_priv);
dev_dbg(&port->dev, "%s: port_number: %d, phy_num: %d\n", __func__,
port->port_number, port_priv->phy_num);
--
1.9.1
Re: [PATCH 3/3] mm: make pagoff_t type 64-bit
On Fri, Dec 16, 2016 at 04:25:14PM +0530, Yury Norov wrote: > 1 leave things as is. 32-bit architectures will have no option to >mmap big offsets, and no one cares - as usual. And that's the only sensible option.
[PATCH] Staging:comedi:cb_pcidas64=>Fixed checkpatch warnings
From: devendra sharma
Signed-off-by Devendra Sharma
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index cb9c269..946c580 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -1500,10 +1500,9 @@ static int alloc_and_init_dma_members(struct
comedi_device *dev)
if (ao_cmd_is_supported(board)) {
devpriv->ao_buffer[i] =
dma_alloc_coherent(&pcidev->dev,
- DMA_BUFFER_SIZE,
- &devpriv->
- ao_buffer_bus_addr[i],
- GFP_KERNEL);
+ DMA_BUFFER_SIZE,
+ &devpriv->ao_buffer_bus_addr[i],
+ GFP_KERNEL);
if (!devpriv->ao_buffer[i])
return -ENOMEM;
}
@@ -2476,18 +2475,15 @@ static int setup_channel_queue(struct comedi_device
*dev,
for (i = 0; i < cmd->chanlist_len; i++) {
bits = 0;
/* set channel */
- bits |= adc_chan_bits(CR_CHAN(cmd->
- chanlist[i]));
+ bits |= adc_chan_bits(
+ CR_CHAN(cmd->chanlist[i]));
/* set gain */
bits |= ai_range_bits_6xxx(dev,
- CR_RANGE(cmd->
- chanlist
- [i]));
+ CR_RANGE(cmd->chanlist[i]));
/* set single-ended / differential */
bits |= se_diff_bit_6xxx(dev,
-CR_AREF(cmd->
-chanlist[i]) ==
-AREF_DIFF);
+CR_AREF(cmd->chanlist[i]) ==
+AREF_DIFF);
if (CR_AREF(cmd->chanlist[i]) == AREF_COMMON)
bits |= ADC_COMMON_BIT;
/* mark end of queue */
--
2.7.4
Re: [PATCH] Staging:comedi:cb_pcidas64=>Fixed checkpatch warnings
On Sun, 2016-12-18 at 15:06 +0530, Devendra Sharma wrote:
> From: devendra sharma
[]
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
[]
> @@ -1500,10 +1500,9 @@ static int alloc_and_init_dma_members(struct
> comedi_device *dev)
> if (ao_cmd_is_supported(board)) {
> devpriv->ao_buffer[i] =
> dma_alloc_coherent(&pcidev->dev,
> -DMA_BUFFER_SIZE,
> -&devpriv->
> -ao_buffer_bus_addr[i],
> -GFP_KERNEL);
> +DMA_BUFFER_SIZE,
> +&devpriv->ao_buffer_bus_addr[i],
> +GFP_KERNEL);
> if (!devpriv->ao_buffer[i])
> return -ENOMEM;
> }
Please just exceed 80 columns instead.
dma_alloc_coherent(&pcidev->dev,
DMA_BUFFER_SIZE,
&devpriv->ao_buffer_bus_addr[i],
GFP_KERNEL);
etc...
Linux 3.12.69
I'm announcing the release of the 3.12.69 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Alex Williamson (2):
PCI: Fix devfn for VPD access through function 0
PCI: Use function 0 VPD for identical functions, regular VPD for others
Amir Vadai (1):
net/sched: pedit: make sure that offset is valid
Andreas Larsson (1):
sparc32: Fix inverted invalid_frame_pointer checks on sigreturns
Andrey Grodzovsky (1):
scsi: mpt3sas: Fix secure erase premature termination
Andrey Ryabinin (1):
mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]
Andy Lutomirski (1):
x86/traps: Ignore high word of regs->cs in early_fixup_exception()
Brian Norris (2):
mtd: blkdevs: fix potential deadlock + lockdep warnings
mwifiex: printk() overflow with 32-byte SSIDs
Chris Metcalf (1):
tile: avoid using clocksource_cyc2ns with absolute cycle count
Cyrille Pitchen (1):
i2c: at91: fix write transfers by clearing pending interrupt first
Ding Tianhong (1):
rcu: Fix soft lockup for rcu_nocb_kthread
Doug Brown (1):
USB: serial: ftdi_sio: add support for TI CC3200 LaunchPad
Eli Cooper (2):
ipv6: Set skb->protocol properly for local output
ipv4: Set skb->protocol properly for local output
Eric Dumazet (2):
net/dccp: fix use-after-free in dccp_invalid_packet
net: avoid signed overflows for SO_{SND|RCV}BUFFORCE
Guillaume Nault (1):
l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()
Jeremy Linton (1):
net: sky2: Fix shutdown crash
Jiri Slaby (1):
Linux 3.12.69
Jisheng Zhang (1):
x86/idle: Restore trace_cpu_idle to mwait_idle() calls
Johan Hovold (1):
pwm: Fix device reference leak
Johannes Berg (1):
cfg80211: limit scan results cache size
Johannes Thumshirn (1):
PCI: Export pcie_find_root_port
John Johansen (1):
apparmor: fix change_hat not finding hat after policy replacement
Kees Cook (1):
net: ping: check minimum size on ICMP header length
Michel Dänzer (1):
drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on
Paolo Abeni (1):
ip6_tunnel: disable caching when the traffic class is inherited
Paul Jakma (1):
USB: serial: cp210x: add ID for the Zone DPMX
Peter Chen (1):
usb: chipidea: move the lock initialization to core file
Peter Hurley (1):
tty: audit: Fix audit source
Petr Vandrovec (1):
Fix USB CB/CBI storage devices with CONFIG_VMAP_STACK=y
Philip Pettersson (1):
packet: fix race condition in packet_set_ring
Radim Krčmář (1):
KVM: x86: drop error recovery in em_jmp_far and em_ret_far
Takashi Iwai (1):
ALSA: pcm : Call kill_fasync() in stream lock
Thomas Tai (2):
sparc64: Fix find_node warning if numa node cannot be found
sparc64: fix compile warning section mismatch in find_node()
Vitaly Kuznetsov (1):
kernel/panic.c: turn off locks debug before releasing console lock
Vlad Yasevich (1):
Revert "drivers/net: Disable UFO through virtio"
Makefile| 2 +-
arch/sparc/kernel/signal_32.c | 4 +-
arch/sparc/mm/init_64.c | 71 +--
arch/tile/kernel/time.c | 4 +-
arch/x86/kernel/head_32.S | 2 +-
arch/x86/kernel/process.c | 2 +
arch/x86/kvm/emulate.c | 36 +++---
drivers/gpu/drm/radeon/atombios_crtc.c | 2 +
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 2 +
drivers/i2c/busses/i2c-at91.c | 58 ---
drivers/mtd/mtd_blkdevs.c | 10 +--
drivers/net/ethernet/marvell/sky2.c | 13
drivers/net/macvtap.c | 13 ++--
drivers/net/tun.c | 19 +++--
drivers/net/virtio_net.c| 24 +++
drivers/net/wireless/mwifiex/cfg80211.c | 13 ++--
drivers/pci/access.c| 27 ++-
drivers/pci/pcie/aer/aer_inject.c | 14
drivers/pci/quirks.c| 20 +-
drivers/pwm/sysfs.c | 2 +
drivers/scsi/mpt3sas/mpt3sas_scsih.c| 14
drivers/tty/n_tty.c | 2 +-
drivers/tty/tty_audit.c | 2 +-
drivers/usb/chipidea/core.c | 1 +
drivers/usb/chipidea/udc.c | 2 -
drivers/usb/serial/cp210x.c | 1 +
drivers/usb/serial/ftdi_sio.c | 2 +
drivers/usb/serial/ftdi_sio_ids.h | 6 ++
drivers/usb/storage/transport.c | 7 +-
inc
Re: [PATCH] Staging:comedi:cb_pcidas64=>Fixed checkpatch warnings
On Sun, Dec 18, 2016 at 03:06:18PM +0530, Devendra Sharma wrote: > From: devendra sharma > > Signed-off-by Devendra Sharma I can't take patches without any changelog text :(
[PATCH] Staging:comedi:cb_pcidas64=>Fixed check patch warnings
Fixed check patch warnings about multiple line dereferencing
Signed-off-by: Devendra Sharma
---
drivers/staging/comedi/drivers/cb_pcidas64.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
b/drivers/staging/comedi/drivers/cb_pcidas64.c
index cb9c269..946c580 100644
--- a/drivers/staging/comedi/drivers/cb_pcidas64.c
+++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
@@ -1500,10 +1500,9 @@ static int alloc_and_init_dma_members(struct
comedi_device *dev)
if (ao_cmd_is_supported(board)) {
devpriv->ao_buffer[i] =
dma_alloc_coherent(&pcidev->dev,
- DMA_BUFFER_SIZE,
- &devpriv->
- ao_buffer_bus_addr[i],
- GFP_KERNEL);
+ DMA_BUFFER_SIZE,
+ &devpriv->ao_buffer_bus_addr[i],
+ GFP_KERNEL);
if (!devpriv->ao_buffer[i])
return -ENOMEM;
}
@@ -2476,18 +2475,15 @@ static int setup_channel_queue(struct comedi_device
*dev,
for (i = 0; i < cmd->chanlist_len; i++) {
bits = 0;
/* set channel */
- bits |= adc_chan_bits(CR_CHAN(cmd->
- chanlist[i]));
+ bits |= adc_chan_bits(
+ CR_CHAN(cmd->chanlist[i]));
/* set gain */
bits |= ai_range_bits_6xxx(dev,
- CR_RANGE(cmd->
- chanlist
- [i]));
+ CR_RANGE(cmd->chanlist[i]));
/* set single-ended / differential */
bits |= se_diff_bit_6xxx(dev,
-CR_AREF(cmd->
-chanlist[i]) ==
-AREF_DIFF);
+CR_AREF(cmd->chanlist[i]) ==
+AREF_DIFF);
if (CR_AREF(cmd->chanlist[i]) == AREF_COMMON)
bits |= ADC_COMMON_BIT;
/* mark end of queue */
--
2.7.4
Re: [PATCH] Staging:comedi:cb_pcidas64=>Fixed check patch warnings
On Sun, Dec 18, 2016 at 03:43:15PM +0530, devendra sharma wrote:
> Fixed check patch warnings about multiple line dereferencing
What does that mean?
>
> Signed-off-by: Devendra Sharma
> ---
> drivers/staging/comedi/drivers/cb_pcidas64.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
> index cb9c269..946c580 100644
> --- a/drivers/staging/comedi/drivers/cb_pcidas64.c
> +++ b/drivers/staging/comedi/drivers/cb_pcidas64.c
> @@ -1500,10 +1500,9 @@ static int alloc_and_init_dma_members(struct
> comedi_device *dev)
> if (ao_cmd_is_supported(board)) {
> devpriv->ao_buffer[i] =
> dma_alloc_coherent(&pcidev->dev,
> -DMA_BUFFER_SIZE,
> -&devpriv->
> -ao_buffer_bus_addr[i],
> -GFP_KERNEL);
> +DMA_BUFFER_SIZE,
> +&devpriv->ao_buffer_bus_addr[i],
> +GFP_KERNEL);
> if (!devpriv->ao_buffer[i])
> return -ENOMEM;
> }
> @@ -2476,18 +2475,15 @@ static int setup_channel_queue(struct comedi_device
> *dev,
> for (i = 0; i < cmd->chanlist_len; i++) {
> bits = 0;
> /* set channel */
> - bits |= adc_chan_bits(CR_CHAN(cmd->
> - chanlist[i]));
> + bits |= adc_chan_bits(
> + CR_CHAN(cmd->chanlist[i]));
That doesn't look better to me, does it to you?
checkpatch is a guide, don't let it make you write code that isn't easy
to understand.
thanks,
greg k-h
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 12/18/2016, 12:59 AM, Linus Torvalds wrote: > On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote: >> >> Yes, disk drivers won't load: >> [2.141973] virtio_pci: disagrees about version of symbol mcount >> [2.144415] virtio_pci: Unknown symbol mcount (err -22) > > This makes no sense. > > mcount isn't even one of the symbols that the patch by Adam is touching. asm-prototypes.h in his patch includes asm/ftrace.h, where the function is declared. That should be enough IIUC scripts/Makefile.build. > There's something else screwed up here. Not to mention that others > don't have your issue. I suppose people don't run i386 kernels or have different config. > Do you have some other hacks in this area? Are you testing actual > plain 4.9, or do you (for example) still carry Arnd's patch around > that turned out to not work (reverted by f27c2f69cc8e in my tree)? Not at all. This was plain 4.9 packaged by suse -- only rpm-related fixes. I tried plain 4.9 without rpm right now with the same output: # insmod soundcore.ko [ 31.582326] soundcore: disagrees about version of symbol mcount [ 31.586183] soundcore: Unknown symbol mcount (err -22) insmod: ERROR: could not insert module soundcore.ko: Invalid parameters $ git describe @ v4.9 $ git status HEAD detached at v4.9 thanks, -- js suse labs
Re: wl1251 & mac address & calibration data
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from the
>>> existing mess. A solution to help both the old API and new API is
>>> possible for the "fallback mechanism" though -- but for that I can
>>> only refer you at this point to some of Daniel Wagner and Tom
>>> Gunderson's firmwared deamon prospect. It should help pave the way
>>> for a clean solution and help address other stupid issues.
>>
>> The firmwared project is hosted here
>>
>> https://github.com/teg/firmwared
>>
>> As Luis pointed out, firmwared relies on
>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>
> I know. But it does not mean that I cannot enable this option at kernel
> compile time.
>
> Bigger problem is that currently request_firmware() first try to load
> firmware directly from VFS and after that (if fails) fallback to user
> helper.
>
> So I would need to extend kernel firmware code with new function (or
> flag) to not use VFS and try only user mode helper.
Why do you need the user-mode helper anyway. This is all static data,
right? So why not cook up a firmware file in user-space once and put it
in /lib/firmware for the driver to request directly. Seems a bit
overkill to have a {e,}udev or whatever daemon running if the result is
always the same. Just my 2 cents.
Regards,
Arend
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 18-12-2016 11:49, Jiri Slaby wrote: > On 12/18/2016, 12:59 AM, Linus Torvalds wrote: >> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote: >>> >>> Yes, disk drivers won't load: >>> [2.141973] virtio_pci: disagrees about version of symbol mcount >>> [2.144415] virtio_pci: Unknown symbol mcount (err -22) >> >> This makes no sense. >> >> mcount isn't even one of the symbols that the patch by Adam is touching. > > asm-prototypes.h in his patch includes asm/ftrace.h, where the function > is declared. That should be enough IIUC scripts/Makefile.build. > >> There's something else screwed up here. Not to mention that others >> don't have your issue. > > I suppose people don't run i386 kernels or have different config. > >> Do you have some other hacks in this area? Are you testing actual >> plain 4.9, or do you (for example) still carry Arnd's patch around >> that turned out to not work (reverted by f27c2f69cc8e in my tree)? > > Not at all. This was plain 4.9 packaged by suse -- only rpm-related > fixes. I tried plain 4.9 without rpm right now with the same output: > # insmod soundcore.ko > [ 31.582326] soundcore: disagrees about version of symbol mcount > [ 31.586183] soundcore: Unknown symbol mcount (err -22) > insmod: ERROR: could not insert module soundcore.ko: Invalid parameters I hit an mcount issue a while back (years?) which was due to building a driver with gcc v4.x while kernel was built using gcc v4.y. Not claiming that is your issue though. Regards, Arend
Re: wl1251 & mac address & calibration data
On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> On 16-12-2016 11:40, Pali Rohár wrote:
> > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> >>> For the new API a solution for "fallback mechanisms" should be
> >>> clean though and I am looking to stay as far as possible from the
> >>> existing mess. A solution to help both the old API and new API is
> >>> possible for the "fallback mechanism" though -- but for that I
> >>> can only refer you at this point to some of Daniel Wagner and
> >>> Tom Gunderson's firmwared deamon prospect. It should help pave
> >>> the way for a clean solution and help address other stupid
> >>> issues.
> >>
> >> The firmwared project is hosted here
> >>
> >> https://github.com/teg/firmwared
> >>
> >> As Luis pointed out, firmwared relies on
> >> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
> >
> > I know. But it does not mean that I cannot enable this option at
> > kernel compile time.
> >
> > Bigger problem is that currently request_firmware() first try to
> > load firmware directly from VFS and after that (if fails) fallback
> > to user helper.
> >
> > So I would need to extend kernel firmware code with new function
> > (or flag) to not use VFS and try only user mode helper.
>
> Why do you need the user-mode helper anyway. This is all static data,
> right?
Those are static data, but device specific!
> So why not cook up a firmware file in user-space once and put
> it in /lib/firmware for the driver to request directly.
1. Violates FHS
2. Does not work for readonly /, readonly /lib, readonly /lib/firmware
3. Backup & restore of rootfs between same devices does not work (as
rootfs now contains device specific data).
4. Sharing one rootfs (either via nfs or other technology) does not work
for more devices (even in state when rootfs is used only by one device
at one time).
And it is common that N900 developers have rootfs in laptop and via usb
(cdc_ether) exports it over nfs to N900 device and boot system. It
basically break booting from one nfs-exported rootfs, as that export
become model specific...
> Seems a bit
> overkill to have a {e,}udev or whatever daemon running if the result
> is always the same. Just my 2 cents.
No it is not. It will break couple of other things in Linux and device
and model specific calibration data should not be in /lib/firmware! That
directory is used for firmware files, not calibration.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
[PATCH v6 6/6] [media] rc: add support for IR LEDs driven through SPI
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through an rc character device. The chardev
is handled by the LIRC framework and its functionality basically
provides:
- write: the driver gets a pulse/space signal and translates it
to a binary signal that will be streamed to the IR led through
the SPI framework.
- set frequency: sets the frequency whith which the data should
be sent. This is handle with ioctl with the
LIRC_SET_SEND_CARRIER flag (as per lirc documentation)
- set duty cycle: this is also handled with ioctl with the
LIRC_SET_SEND_DUTY_CYCLE flag. The driver handles duty cycles
of 50%, 60%, 70%, 75%, 80% and 90%, calculated on 16bit data.
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
val = 60;
ret = ioctl(fd, LIRC_SET_SEND_DUTY_CYCLE, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
drivers/media/rc/Kconfig | 9 +++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-spi.c | 199 ++
3 files changed, 209 insertions(+)
create mode 100644 drivers/media/rc/ir-spi.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca15ab3..3351e25d6176 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
To compile this driver as a module, choose M here: the
module will be called redrat3.
+config IR_SPI
+ tristate "SPI connected IR LED"
+ depends on SPI && LIRC
+ ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee301e2..938c98b82b22 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index ..d45c60352093
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+/* pulse value for different duty cycles */
+#define IR_SPI_PULSE_DC_50 0xff00
+#define IR_SPI_PULSE_DC_60 0xfc00
+#define IR_SPI_PULSE_DC_70 0xf800
+#define IR_SPI_PULSE_DC_75 0xf000
+#define IR_SPI_PULSE_DC_80 0xc000
+#define IR_SPI_PULSE_DC_90 0x8000
+
+#define IR_SPI_DEFAULT_FREQUENCY 38000
+#define IR_SPI_BIT_PER_WORD8
+#define IR_SPI_MAX_BUFSIZE 4096
+
+struct ir_spi_data {
+ u32 freq;
+ u8 duty_cycle;
+ bool negated;
+
+ u16 tx_buf[IR_SPI_MAX_BUFSIZE];
+ u16 pulse;
+ u16 space;
+
+ struct rc_dev *rc;
+ struct spi_device *spi;
+ struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev,
+ unsigned int *buffer, unsigned int count)
+{
+ int i;
+ int ret;
+ unsigned int len = 0;
+ struct ir_spi_data *idata = dev->priv;
+ struct spi_transfer xfer;
+
+ /* convert the pulse/space signal to raw binary signal */
+ for (i = 0; i < count; i++) {
+ int j;
+ u16 val = ((i+1) % 2) ? idata->pulse : idata->space;
+
+ if (len + buffer[i] >= IR_SPI_MAX_BUFSIZE)
+ return -EINVAL;
+
+ /*
+* the first value in buffer is a pulse, so that 0, 2, 4, ...
+* cont
[PATCH v6 2/6] [media] rc-main: split setup and unregister functions
Move the input device allocation, map and protocol handling to
different functions.
This patch fixes the following checkpatch error as well:
ERROR: do not initialise statics to false
#1438: FILE: drivers/media/rc/rc-main.c:1438:
+ static bool raw_init = false; /* raw decoders loaded? */
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
drivers/media/rc/rc-main.c | 143 +
1 file changed, 81 insertions(+), 62 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a6bbceb7147f..7c8411a40305 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1436,16 +1436,12 @@ struct rc_dev *devm_rc_allocate_device(struct device
*dev,
}
EXPORT_SYMBOL_GPL(devm_rc_allocate_device);
-int rc_register_device(struct rc_dev *dev)
+static int rc_setup_rx_device(struct rc_dev *dev)
{
- static bool raw_init = false; /* raw decoders loaded? */
- struct rc_map *rc_map;
- const char *path;
- int attr = 0;
- int minor;
int rc;
+ struct rc_map *rc_map;
- if (!dev || !dev->map_name)
+ if (!dev->map_name)
return -EINVAL;
rc_map = rc_map_get(dev->map_name);
@@ -1454,6 +1450,19 @@ int rc_register_device(struct rc_dev *dev)
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
+ rc = ir_setkeytable(dev, rc_map);
+ if (rc)
+ return rc;
+
+ if (dev->change_protocol) {
+ u64 rc_type = (1ll << rc_map->rc_type);
+
+ rc = dev->change_protocol(dev, &rc_type);
+ if (rc < 0)
+ goto out_table;
+ dev->enabled_protocols = rc_type;
+ }
+
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
set_bit(EV_MSC, dev->input_dev->evbit);
@@ -1463,6 +1472,61 @@ int rc_register_device(struct rc_dev *dev)
if (dev->close)
dev->input_dev->close = ir_close;
+ /*
+* Default delay of 250ms is too short for some protocols, especially
+* since the timeout is currently set to 250ms. Increase it to 500ms,
+* to avoid wrong repetition of the keycodes. Note that this must be
+* set after the call to input_register_device().
+*/
+ dev->input_dev->rep[REP_DELAY] = 500;
+
+ /*
+* As a repeat event on protocols like RC-5 and NEC take as long as
+* 110/114ms, using 33ms as a repeat period is not the right thing
+* to do.
+*/
+ dev->input_dev->rep[REP_PERIOD] = 125;
+
+ dev->input_dev->dev.parent = &dev->dev;
+ memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
+ dev->input_dev->phys = dev->input_phys;
+ dev->input_dev->name = dev->input_name;
+
+ /* rc_open will be called here */
+ rc = input_register_device(dev->input_dev);
+ if (rc)
+ goto out_table;
+
+ return 0;
+
+out_table:
+ ir_free_table(&dev->rc_map);
+
+ return rc;
+}
+
+static void rc_free_rx_device(struct rc_dev *dev)
+{
+ if (!dev)
+ return;
+
+ ir_free_table(&dev->rc_map);
+
+ input_unregister_device(dev->input_dev);
+ dev->input_dev = NULL;
+}
+
+int rc_register_device(struct rc_dev *dev)
+{
+ static bool raw_init; /* 'false' default value, raw decoders loaded? */
+ const char *path;
+ int attr = 0;
+ int minor;
+ int rc;
+
+ if (!dev)
+ return -EINVAL;
+
minor = ida_simple_get(&rc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
if (minor < 0)
return minor;
@@ -1486,39 +1550,15 @@ int rc_register_device(struct rc_dev *dev)
if (rc)
goto out_unlock;
- rc = ir_setkeytable(dev, rc_map);
- if (rc)
- goto out_dev;
-
- dev->input_dev->dev.parent = &dev->dev;
- memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
- dev->input_dev->phys = dev->input_phys;
- dev->input_dev->name = dev->input_name;
-
- rc = input_register_device(dev->input_dev);
- if (rc)
- goto out_table;
-
- /*
-* Default delay of 250ms is too short for some protocols, especially
-* since the timeout is currently set to 250ms. Increase it to 500ms,
-* to avoid wrong repetition of the keycodes. Note that this must be
-* set after the call to input_register_device().
-*/
- dev->input_dev->rep[REP_DELAY] = 500;
-
- /*
-* As a repeat event on protocols like RC-5 and NEC take as long as
-* 110/114ms, using 33ms as a repeat period is not the right thing
-* to do.
-*/
- dev->input_dev->rep[REP_PERIOD] = 125;
-
path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
dev_info(&dev->dev, "%s as %s\n",
dev->inp
[PATCH v6 4/6] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters
Raw IR transmitters do not need any thread listening for
occurring events. Check the driver type before running the
thread.
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
drivers/media/rc/rc-ir-raw.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 1c42a9f2f290..9938e42e0c0b 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -270,12 +270,19 @@ int ir_raw_event_register(struct rc_dev *dev)
INIT_KFIFO(dev->raw->kfifo);
spin_lock_init(&dev->raw->lock);
- dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
- "rc%u", dev->minor);
- if (IS_ERR(dev->raw->thread)) {
- rc = PTR_ERR(dev->raw->thread);
- goto out;
+ /*
+* raw transmitters do not need any event registration
+* because the event is coming from userspace
+*/
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
+ "rc%u", dev->minor);
+
+ if (IS_ERR(dev->raw->thread)) {
+ rc = PTR_ERR(dev->raw->thread);
+ goto out;
+ }
}
mutex_lock(&ir_raw_handler_lock);
--
2.11.0
[PATCH v6 3/6] [media] rc-core: add support for IR raw transmitters
IR raw transmitter driver type is specified in the enum
rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
devices that transmit raw stream of bit to a receiver.
The data are provided by userspace applications, therefore they
don't need any input device allocation, but still they need to be
registered as raw devices.
Suggested-by: Sean Young
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
drivers/media/rc/rc-main.c | 42 +-
include/media/rc-core.h| 9 ++---
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 7c8411a40305..f527fe1f50ba 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1365,20 +1365,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type
type)
if (!dev)
return NULL;
- dev->input_dev = input_allocate_device();
- if (!dev->input_dev) {
- kfree(dev);
- return NULL;
- }
+ if (type != RC_DRIVER_IR_RAW_TX) {
+ dev->input_dev = input_allocate_device();
+ if (!dev->input_dev) {
+ kfree(dev);
+ return NULL;
+ }
+
+ dev->input_dev->getkeycode = ir_getkeycode;
+ dev->input_dev->setkeycode = ir_setkeycode;
+ input_set_drvdata(dev->input_dev, dev);
- dev->input_dev->getkeycode = ir_getkeycode;
- dev->input_dev->setkeycode = ir_setkeycode;
- input_set_drvdata(dev->input_dev, dev);
+ setup_timer(&dev->timer_keyup, ir_timer_keyup,
+ (unsigned long)dev);
- spin_lock_init(&dev->rc_map.lock);
- spin_lock_init(&dev->keylock);
+ spin_lock_init(&dev->rc_map.lock);
+ spin_lock_init(&dev->keylock);
+ }
mutex_init(&dev->lock);
- setup_timer(&dev->timer_keyup, ir_timer_keyup, (unsigned long)dev);
dev->dev.type = &rc_dev_type;
dev->dev.class = &rc_class;
@@ -1507,7 +1511,7 @@ static int rc_setup_rx_device(struct rc_dev *dev)
static void rc_free_rx_device(struct rc_dev *dev)
{
- if (!dev)
+ if (!dev || dev->driver_type == RC_DRIVER_IR_RAW_TX)
return;
ir_free_table(&dev->rc_map);
@@ -1537,7 +1541,8 @@ int rc_register_device(struct rc_dev *dev)
atomic_set(&dev->initialized, 0);
dev->dev.groups = dev->sysfs_groups;
- dev->sysfs_groups[attr++] = &rc_dev_protocol_attr_grp;
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX)
+ dev->sysfs_groups[attr++] = &rc_dev_protocol_attr_grp;
if (dev->s_filter)
dev->sysfs_groups[attr++] = &rc_dev_filter_attr_grp;
if (dev->s_wakeup_filter)
@@ -1555,11 +1560,14 @@ int rc_register_device(struct rc_dev *dev)
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
- rc = rc_setup_rx_device(dev);
- if (rc)
- goto out_dev;
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ rc = rc_setup_rx_device(dev);
+ if (rc)
+ goto out_dev;
+ }
- if (dev->driver_type == RC_DRIVER_IR_RAW) {
+ if (dev->driver_type == RC_DRIVER_IR_RAW ||
+ dev->driver_type == RC_DRIVER_IR_RAW_TX) {
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
raw_init = true;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index ba92c86c47ff..e6cb336b4668 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -32,13 +32,16 @@ do {
\
/**
* enum rc_driver_type - type of the RC output
*
- * @RC_DRIVER_SCANCODE:Driver or hardware generates a scancode
- * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
- * It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_SCANCODE: Driver or hardware generates a scancode
+ * @RC_DRIVER_IR_RAW: Driver or hardware generates pulse/space sequences.
+ * It needs a Infra-Red pulse/space decoder
+ * @RC_DRIVER_IR_RAW_TX: Device transmitter only,
+ * driver requires pulse/space data sequence.
*/
enum rc_driver_type {
RC_DRIVER_SCANCODE = 0,
RC_DRIVER_IR_RAW,
+ RC_DRIVER_IR_RAW_TX,
};
/**
--
2.11.0
[PATCH v6 5/6] Documentation: bindings: add documentation for ir-spi device driver
Document the ir-spi driver's binding which is a IR led driven
through the SPI line.
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
.../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
diff --git a/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
new file mode 100644
index ..896b6997cf30
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/spi-ir-led.txt
@@ -0,0 +1,29 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+ - compatible: should be "ir-spi-led".
+
+Optional properties:
+ - duty-cycle: 8 bit balue that represents the percentage of one period
+ in which the signal is active. It can be 50, 60, 70, 75, 80 or 90.
+ - led-active-low: boolean value that specifies whether the output is
+ negated with a NOT gate.
+ - power-supply: specifies the power source. It can either be a regulator
+ or a gpio which enables a regulator, i.e. a regulator-fixed as
+ described in
+ Documentation/devicetree/bindings/regulator/fixed-regulator.txt
+
+Example:
+
+ irled@0 {
+ compatible = "ir-spi-led";
+ reg = <0x0>;
+ spi-max-frequency = <500>;
+ power-supply = <&vdd_led>;
+ led-active-low;
+ duty-cycle = /bits/ 8 <60>;
+ };
--
2.11.0
[PATCH v6 1/6] [media] rc-main: assign driver type during allocation
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Change accordingly all the drivers calling rc_allocate_device()
so that the device type is specified during the rc device
allocation. Whenever the device type is not specified, it will be
set as RC_DRIVER_SCANCODE which was the default '0' value.
Suggested-by: Sean Young
Signed-off-by: Andi Shyti
Reviewed-by: Sean Young
---
drivers/hid/hid-picolcd_cir.c | 3 +--
drivers/media/cec/cec-core.c| 3 +--
drivers/media/common/siano/smsir.c | 3 +--
drivers/media/i2c/ir-kbd-i2c.c | 2 +-
drivers/media/pci/bt8xx/bttv-input.c| 2 +-
drivers/media/pci/cx23885/cx23885-input.c | 11 +--
drivers/media/pci/cx88/cx88-input.c | 3 +--
drivers/media/pci/dm1105/dm1105.c | 3 +--
drivers/media/pci/mantis/mantis_input.c | 2 +-
drivers/media/pci/saa7134/saa7134-input.c | 2 +-
drivers/media/pci/smipcie/smipcie-ir.c | 3 +--
drivers/media/pci/ttpci/budget-ci.c | 2 +-
drivers/media/rc/ati_remote.c | 3 +--
drivers/media/rc/ene_ir.c | 3 +--
drivers/media/rc/fintek-cir.c | 3 +--
drivers/media/rc/gpio-ir-recv.c | 3 +--
drivers/media/rc/igorplugusb.c | 3 +--
drivers/media/rc/iguanair.c | 3 +--
drivers/media/rc/img-ir/img-ir-hw.c | 2 +-
drivers/media/rc/img-ir/img-ir-raw.c| 3 +--
drivers/media/rc/imon.c | 3 +--
drivers/media/rc/ir-hix5hd2.c | 3 +--
drivers/media/rc/ite-cir.c | 3 +--
drivers/media/rc/mceusb.c | 3 +--
drivers/media/rc/meson-ir.c | 3 +--
drivers/media/rc/nuvoton-cir.c | 3 +--
drivers/media/rc/rc-loopback.c | 3 +--
drivers/media/rc/rc-main.c | 9 ++---
drivers/media/rc/redrat3.c | 3 +--
drivers/media/rc/serial_ir.c| 3 +--
drivers/media/rc/st_rc.c| 3 +--
drivers/media/rc/streamzap.c| 3 +--
drivers/media/rc/sunxi-cir.c| 3 +--
drivers/media/rc/ttusbir.c | 3 +--
drivers/media/rc/winbond-cir.c | 3 +--
drivers/media/usb/au0828/au0828-input.c | 3 +--
drivers/media/usb/cx231xx/cx231xx-input.c | 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 3 +--
drivers/media/usb/dvb-usb/dvb-usb-remote.c | 3 +--
drivers/media/usb/em28xx/em28xx-input.c | 2 +-
drivers/media/usb/tm6000/tm6000-input.c | 3 +--
include/media/rc-core.h | 6 --
42 files changed, 50 insertions(+), 85 deletions(-)
diff --git a/drivers/hid/hid-picolcd_cir.c b/drivers/hid/hid-picolcd_cir.c
index 96286510f42e..38b0ea8d89e0 100644
--- a/drivers/hid/hid-picolcd_cir.c
+++ b/drivers/hid/hid-picolcd_cir.c
@@ -108,12 +108,11 @@ int picolcd_init_cir(struct picolcd_data *data, struct
hid_report *report)
struct rc_dev *rdev;
int ret = 0;
- rdev = rc_allocate_device();
+ rdev = rc_allocate_device(RC_DRIVER_IR_RAW);
if (!rdev)
return -ENOMEM;
rdev->priv = data;
- rdev->driver_type = RC_DRIVER_IR_RAW;
rdev->allowed_protocols = RC_BIT_ALL;
rdev->open = picolcd_cir_open;
rdev->close= picolcd_cir_close;
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab83a8a1..37217e205040 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -239,7 +239,7 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
#if IS_REACHABLE(CONFIG_RC_CORE)
/* Prepare the RC input device */
- adap->rc = rc_allocate_device();
+ adap->rc = rc_allocate_device(RC_DRIVER_SCANCODE);
if (!adap->rc) {
pr_err("cec-%s: failed to allocate memory for rc_dev\n",
name);
@@ -259,7 +259,6 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
adap->rc->input_id.vendor = 0;
adap->rc->input_id.product = 0;
adap->rc->input_id.version = 1;
- adap->rc->driver_type = RC_DRIVER_SCANCODE;
adap->rc->driver_name = CEC_NAME;
adap->rc->allowed_protocols = RC_BIT_CEC;
adap->rc->priv = adap;
diff --git a/drivers/media/common/siano/smsir.c
b/drivers/media/common/siano/smsir.c
index 41f2a3939979..ee30c7b8fb15 100644
--- a/drivers/media/common/siano/smsir.c
+++ b/drivers/media/common/siano/smsir.c
@@ -58,7 +58,7 @@ int sms_ir_init(struct smscore_device_t *coredev)
struct rc_dev *dev;
pr_debug("Allocating rc device\n")
[PATCH v6 0/6] Add support for IR transmitters
Hi, The main goal is to add support in the rc framework for IR transmitters, which currently is only supported by lirc but that is not the preferred way. The last patch adds support for an IR transmitter driven by the MOSI line of an SPI controller, it's the case of the Samsung TM2(e) board which support is currently ongoing. The last patch adds support for an IR transmitter driven by the MOSI line of an SPI controller, it's the case of the Samsung TM2(e) board which support is currently ongoing. The patchset is based on next-20161218, while the media directory is a bit more outdated. Thanks, Andi Changelog from version 5: - patch 1: fixed rebase conflict on drivers/media/cec/cec-core.c patch 2: fixed checkpatch error patch 3: restored a Kbuild Test Robot error fix which was lost in v5 Changelog from version 4: - patch 2: fixed a slip on a copy/paste which caused the breakage of the input interface for receivers. Thanks again Sean! Changelog from version 3: - Added the patches Sean's review. patch 1: commit ddbf7d5a has introduced the devm_* managed version of rc_allocate_device and rc_register_device, this patch has been rebased on top of it and adds the driver type as a parameter of the devm_rc_allocate_device. patch 3: fixes a warning from the kbuild test robot patch 5: after a discussion with Rob, despite mine, Jacek's and Mauro's objections [*] the binding has been placed under leds/irled/spi-ir-led.txt patch 6: uses the new devm_* allocation and registration rc functions [*] https://www.spinics.net/lists/linux-leds/msg07062.html https://www.spinics.net/lists/linux-leds/msg07164.html https://www.spinics.net/lists/linux-leds/msg07167.html Changelog from version 2: - The original patch number 5 has been abandoned because it was not bringing much benenfit. patch 1: rebased on the new kernel. patch 3: removed the sysfs attribute protocol for transmitters patch 5: the binding has been moved to the leds section instead of the media. Fixed all the comments from Rob patch 6: fixed all the comments from Sean added also Sean's review. Changelog from version 1: - The RFC is now PATCH. The main difference is that this version doesn't try to add the any bit streaming protocol and doesn't modify any LIRC interface specification. patch 1: updates all the drivers using rc_allocate_device patch 2: fixed errors and warning reported from the kbuild test robot patch 5: this patch has been dropped and replaced with a new one which avoids waiting for transmitters. patch 6: added new properties to the dts specification patch 7: the driver uses the pulse/space input and converts it to a bit stream. Andi Shyti (6): [media] rc-main: assign driver type during allocation [media] rc-main: split setup and unregister functions [media] rc-core: add support for IR raw transmitters [media] rc-ir-raw: do not generate any receiving thread for raw transmitters Documentation: bindings: add documentation for ir-spi device driver [media] rc: add support for IR LEDs driven through SPI .../devicetree/bindings/leds/irled/spi-ir-led.txt | 29 +++ drivers/hid/hid-picolcd_cir.c | 3 +- drivers/media/cec/cec-core.c | 3 +- drivers/media/common/siano/smsir.c | 3 +- drivers/media/i2c/ir-kbd-i2c.c | 2 +- drivers/media/pci/bt8xx/bttv-input.c | 2 +- drivers/media/pci/cx23885/cx23885-input.c | 11 +- drivers/media/pci/cx88/cx88-input.c| 3 +- drivers/media/pci/dm1105/dm1105.c | 3 +- drivers/media/pci/mantis/mantis_input.c| 2 +- drivers/media/pci/saa7134/saa7134-input.c | 2 +- drivers/media/pci/smipcie/smipcie-ir.c | 3 +- drivers/media/pci/ttpci/budget-ci.c| 2 +- drivers/media/rc/Kconfig | 9 + drivers/media/rc/Makefile | 1 + drivers/media/rc/ati_remote.c | 3 +- drivers/media/rc/ene_ir.c | 3 +- drivers/media/rc/fintek-cir.c | 3 +- drivers/media/rc/gpio-ir-recv.c| 3 +- drivers/media/rc/igorplugusb.c | 3 +- drivers/media/rc/iguanair.c| 3 +- drivers/media/rc/img-ir/img-ir-hw.c| 2 +- drivers/media/rc/img-ir/img-ir-raw.c | 3 +- drivers/media/rc/imon.c| 3 +- drivers/media/rc/ir-hix5hd2.c | 3 +- drivers/media/rc/ir-spi.c | 199 + drivers/media/rc/ite-cir.c
Re: wl1251 & mac address & calibration data
On 18-12-2016 12:04, Pali Rohár wrote:
> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>> On 16-12-2016 11:40, Pali Rohár wrote:
>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> For the new API a solution for "fallback mechanisms" should be
> clean though and I am looking to stay as far as possible from the
> existing mess. A solution to help both the old API and new API is
> possible for the "fallback mechanism" though -- but for that I
> can only refer you at this point to some of Daniel Wagner and
> Tom Gunderson's firmwared deamon prospect. It should help pave
> the way for a clean solution and help address other stupid
> issues.
The firmwared project is hosted here
https://github.com/teg/firmwared
As Luis pointed out, firmwared relies on
FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>>>
>>> I know. But it does not mean that I cannot enable this option at
>>> kernel compile time.
>>>
>>> Bigger problem is that currently request_firmware() first try to
>>> load firmware directly from VFS and after that (if fails) fallback
>>> to user helper.
>>>
>>> So I would need to extend kernel firmware code with new function
>>> (or flag) to not use VFS and try only user mode helper.
>>
>> Why do you need the user-mode helper anyway. This is all static data,
>> right?
>
> Those are static data, but device specific!
So what?
>> So why not cook up a firmware file in user-space once and put
>> it in /lib/firmware for the driver to request directly.
>
> 1. Violates FHS
How?
> 2. Does not work for readonly /, readonly /lib, readonly /lib/firmware
Que?
> 3. Backup & restore of rootfs between same devices does not work (as
> rootfs now contains device specific data).
True.
> 4. Sharing one rootfs (either via nfs or other technology) does not work
> for more devices (even in state when rootfs is used only by one device
> at one time).
Indeed.
> And it is common that N900 developers have rootfs in laptop and via usb
> (cdc_ether) exports it over nfs to N900 device and boot system. It
> basically break booting from one nfs-exported rootfs, as that export
> become model specific...
These are all you choices and more a logistic issue. If your take is
that udev is the way to solve those, fine by me.
>> Seems a bit
>> overkill to have a {e,}udev or whatever daemon running if the result
>> is always the same. Just my 2 cents.
>
> No it is not. It will break couple of other things in Linux and device
Now I am curious. What "couple of other things" will be broken.
> and model specific calibration data should not be in /lib/firmware! That
> directory is used for firmware files, not calibration.
What is "firmware"? Really. These are binary blobs required to make the
device work. And guess what, your device needs calibration data. Why
make the distinction.
Regards,
Arend
Re: [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
On 16 December 2016 at 21:51, Arnd Bergmann wrote: > On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote: >> >> Can't we use the old >> >> tst lr, #1 >> moveq pc, lr >> bx lr >> >> trick? (where bx lr needs to be emitted as a plain opcode to hide it >> from the assembler) >> > > Yes, that should work around the specific problem in theory, but back > when Jonas tried it, it still didn't work. There may also be other > problems in that configuration. > This should do the trick as well, I think: diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 9f157e7c51e7..3bfb32010234 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -835,7 +835,12 @@ ENDPROC(__switch_to) .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB +#ifdef CONFIG_CPU_32v4 + str \reg, [sp, #-4]! + ldr pc, [sp], #4 +#else bx \reg +#endif #else ret \reg #endif with the added benefit that we don't clobber the N and Z flags. Of course, this will result in all CPUs using a non-optimal sequence if support for v4 is compiled in.
[PATCH] lib/Kconfig.debug: fix frv build failure
The build of frv allmodconfig was failing with the errors like:
/tmp/cc0JSPc3.s: Assembler messages:
/tmp/cc0JSPc3.s:1839: Error: symbol `.LSLT0' is already defined
/tmp/cc0JSPc3.s:1842: Error: symbol `.LASLTP0' is already defined
/tmp/cc0JSPc3.s:1969: Error: symbol `.LELTP0' is already defined
/tmp/cc0JSPc3.s:1970: Error: symbol `.LELT0' is already defined
Commit: 866ced950bcd ("kbuild: Support split debug info v4") introduced
splitting the debug info and keeping that in a separate file.
Somehow, the frv-linux gcc did not like that and I am guessing that
instead of splitting it started copying. The first report about this
is at: https://lists.01.org/pipermail/kbuild-all/2015-July/010527.html.
Reported-by: Fengguang Wu
Cc: Andi Kleen
Fixes: 866ced950bcd ("kbuild: Support split debug info v4")
Signed-off-by: Sudip Mukherjee
---
I will try and see if this can work with frv and if still fails I will
open a bug report with gcc. But meanwhile this is the easiest option
to solve build failure of frv.
Hi Fengguang,
As frv arch will start building with this patch after a long time, it
will give new warnings which your script will consider to be new
warnings introduced by this patch.
lib/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 18ffa80..2bdb1c6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -165,7 +165,7 @@ config DEBUG_INFO_REDUCED
config DEBUG_INFO_SPLIT
bool "Produce split debuginfo in .dwo files"
- depends on DEBUG_INFO
+ depends on DEBUG_INFO && !FRV
help
Generate debug info into separate .dwo files. This significantly
reduces the build directory size for builds with DEBUG_INFO,
--
1.9.1
Re: wl1251 & mac address & calibration data
On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
> On 18-12-2016 12:04, Pali Rohár wrote:
> > On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> >> On 16-12-2016 11:40, Pali Rohár wrote:
> >>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> > For the new API a solution for "fallback mechanisms" should be
> > clean though and I am looking to stay as far as possible from
> > the existing mess. A solution to help both the old API and new
> > API is possible for the "fallback mechanism" though -- but for
> > that I can only refer you at this point to some of Daniel
> > Wagner and Tom Gunderson's firmwared deamon prospect. It
> > should help pave the way for a clean solution and help address
> > other stupid issues.
>
> The firmwared project is hosted here
>
> https://github.com/teg/firmwared
>
> As Luis pointed out, firmwared relies on
> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
> >>>
> >>> I know. But it does not mean that I cannot enable this option at
> >>> kernel compile time.
> >>>
> >>> Bigger problem is that currently request_firmware() first try to
> >>> load firmware directly from VFS and after that (if fails)
> >>> fallback to user helper.
> >>>
> >>> So I would need to extend kernel firmware code with new function
> >>> (or flag) to not use VFS and try only user mode helper.
> >>
> >> Why do you need the user-mode helper anyway. This is all static
> >> data, right?
> >
> > Those are static data, but device specific!
>
> So what?
>
> >> So why not cook up a firmware file in user-space once and put
> >> it in /lib/firmware for the driver to request directly.
> >
> > 1. Violates FHS
>
> How?
>
> > 2. Does not work for readonly /, readonly /lib, readonly
> > /lib/firmware
>
> Que?
>
> > 3. Backup & restore of rootfs between same devices does not work
> > (as rootfs now contains device specific data).
>
> True.
>
> > 4. Sharing one rootfs (either via nfs or other technology) does not
> > work for more devices (even in state when rootfs is used only by
> > one device at one time).
>
> Indeed.
>
> > And it is common that N900 developers have rootfs in laptop and via
> > usb (cdc_ether) exports it over nfs to N900 device and boot
> > system. It basically break booting from one nfs-exported rootfs,
> > as that export become model specific...
>
> These are all you choices and more a logistic issue. If your take is
> that udev is the way to solve those, fine by me.
>
> >> Seems a bit
> >> overkill to have a {e,}udev or whatever daemon running if the
> >> result is always the same. Just my 2 cents.
> >
> > No it is not. It will break couple of other things in Linux and
> > device
>
> Now I am curious. What "couple of other things" will be broken.
>
> > and model specific calibration data should not be in /lib/firmware!
> > That directory is used for firmware files, not calibration.
>
> What is "firmware"? Really. These are binary blobs required to make
> the device work. And guess what, your device needs calibration data.
> Why make the distinction.
>
> Regards,
> Arend
File wl1251-nvs.bin is provided by linux-firmware package and contains
default data which should be overriden by model specific calibrated
data.
But overwriting that one file is not possible as it next update of
linux-firmware package will overwrite it back. It break any normal usage
of package management.
Also it is ridiculously broken by design if some "boot" files needs to
be overwritten to initialize hardware properly. To not break booting you
need to overwrite that file before first boot. But without booting
device you cannot read calibration data. So some hack with autoreboot
after boot is needed. And how to detect that we have real overwritten
calibration data and not default one from linux-firmware? Any heuristic
or checks will be broken here. And no, nothing like you need to reboot
your device now (and similar concept) from windows world is not
accepted.
"firmware" is one for chip. Any N900 device with wl1251 chip needs
exactly same firmware "wl1251-fw.bin". But every N900 needs different
calibration data which is not firmware.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v3 0/7] power: supply: tps65217: Support USB charger feature
Hi, On Sun, Dec 18, 2016 at 11:54:25AM +0900, Milo Kim wrote: > TPS65217 device supports two charger inputs - AC and USB. > Currently, only AC charger is supported. This patch-set > adds USB charger feature. Tested on Beaglebone black. Thanks for your patchset. We are currently in the merge window and your patchset will appear in linux-next once 4.10-rc1 has been tagged by Linus Torvalds. Until then I queued it into this branch: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/log/?h=for-next-next -- Sebastian signature.asc Description: PGP signature
[PATCH 2/4] mm: add new mmget() helper
Apart from adding the helper function itself, the rest of the kernel is
converted mechanically using:
git grep -l 'atomic_inc.*mm_users' | xargs sed -i
's/atomic_inc(&\(.*\)->mm_users);/mmget\(\1\);/'
git grep -l 'atomic_inc.*mm_users' | xargs sed -i
's/atomic_inc(&\(.*\)\.mm_users);/mmget\(\&\1\);/'
This is needed for a later patch that hooks into the helper, but might be
a worthwhile cleanup on its own.
(Michal Hocko provided most of the kerneldoc comment.)
Cc: Andrew Morton
Acked-by: Michal Hocko
Signed-off-by: Vegard Nossum
---
arch/arc/kernel/smp.c | 2 +-
arch/blackfin/mach-common/smp.c | 2 +-
arch/frv/mm/mmu-context.c | 2 +-
arch/metag/kernel/smp.c | 2 +-
arch/sh/kernel/smp.c| 2 +-
arch/xtensa/kernel/smp.c| 2 +-
include/linux/sched.h | 21 +
kernel/fork.c | 4 ++--
mm/swapfile.c | 10 +-
virt/kvm/async_pf.c | 2 +-
10 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index 9cbc7aba3ede..eec70cb71db1 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -124,7 +124,7 @@ void start_kernel_secondary(void)
/* MMU, Caches, Vector Table, Interrupts etc */
setup_processor();
- atomic_inc(&mm->mm_users);
+ mmget(mm);
mmgrab(mm);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
diff --git a/arch/blackfin/mach-common/smp.c b/arch/blackfin/mach-common/smp.c
index bc5617ef7128..a2e6db2ce811 100644
--- a/arch/blackfin/mach-common/smp.c
+++ b/arch/blackfin/mach-common/smp.c
@@ -307,7 +307,7 @@ void secondary_start_kernel(void)
local_irq_disable();
/* Attach the new idle task to the global mm. */
- atomic_inc(&mm->mm_users);
+ mmget(mm);
mmgrab(mm);
current->active_mm = mm;
diff --git a/arch/frv/mm/mmu-context.c b/arch/frv/mm/mmu-context.c
index 81757d55a5b5..3473bde77f56 100644
--- a/arch/frv/mm/mmu-context.c
+++ b/arch/frv/mm/mmu-context.c
@@ -188,7 +188,7 @@ int cxn_pin_by_pid(pid_t pid)
task_lock(tsk);
if (tsk->mm) {
mm = tsk->mm;
- atomic_inc(&mm->mm_users);
+ mmget(mm);
ret = 0;
}
task_unlock(tsk);
diff --git a/arch/metag/kernel/smp.c b/arch/metag/kernel/smp.c
index af9cff547a19..c622293254e4 100644
--- a/arch/metag/kernel/smp.c
+++ b/arch/metag/kernel/smp.c
@@ -344,7 +344,7 @@ asmlinkage void secondary_start_kernel(void)
* All kernel threads share the same mm context; grab a
* reference and switch to it.
*/
- atomic_inc(&mm->mm_users);
+ mmget(mm);
mmgrab(mm);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index ee379c699c08..edc4769b047e 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -179,7 +179,7 @@ asmlinkage void start_secondary(void)
enable_mmu();
mmgrab(mm);
- atomic_inc(&mm->mm_users);
+ mmget(mm);
current->active_mm = mm;
#ifdef CONFIG_MMU
enter_lazy_tlb(mm, current);
diff --git a/arch/xtensa/kernel/smp.c b/arch/xtensa/kernel/smp.c
index 9bf5cea3bae4..fcea72019df7 100644
--- a/arch/xtensa/kernel/smp.c
+++ b/arch/xtensa/kernel/smp.c
@@ -135,7 +135,7 @@ void secondary_start_kernel(void)
/* All kernel threads share the same mm context. */
- atomic_inc(&mm->mm_users);
+ mmget(mm);
mmgrab(mm);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 6ce46220bda2..9fc07aaf5c97 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2955,6 +2955,27 @@ static inline void mmdrop_async(struct mm_struct *mm)
}
}
+/**
+ * mmget() - Pin the address space associated with a &struct mm_struct.
+ * @mm: The address space to pin.
+ *
+ * Make sure that the address space of the given &struct mm_struct doesn't
+ * go away. This does not protect against parts of the address space being
+ * modified or freed, however.
+ *
+ * Never use this function to pin this address space for an
+ * unbounded/indefinite amount of time.
+ *
+ * Use mmput() to release the reference acquired by mmget().
+ *
+ * See also for an in-depth explanation
+ * of &mm_struct.mm_count vs &mm_struct.mm_users.
+ */
+static inline void mmget(struct mm_struct *mm)
+{
+ atomic_inc(&mm->mm_users);
+}
+
static inline bool mmget_not_zero(struct mm_struct *mm)
{
return atomic_inc_not_zero(&mm->mm_users);
diff --git a/kernel/fork.c b/kernel/fork.c
index 869b8ccc00bf..0e2aaa1837b3 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -994,7 +994,7 @@ struct mm_struct *get_task_mm(struct task_struct *task)
[PATCH 4/4] mm: clarify mm_struct.mm_{users,count} documentation
Clarify documentation relating to mm_users and mm_count, and switch to
kernel-doc syntax.
Signed-off-by: Vegard Nossum
---
include/linux/mm_types.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 08d947fc4c59..316c3e1fc226 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -407,8 +407,27 @@ struct mm_struct {
unsigned long task_size;/* size of task vm space */
unsigned long highest_vm_end; /* highest vma end address */
pgd_t * pgd;
- atomic_t mm_users; /* How many users with user
space? */
- atomic_t mm_count; /* How many references to
"struct mm_struct" (users count as 1) */
+
+ /**
+* @mm_users: The number of users including userspace.
+*
+* Use mmget()/mmget_not_zero()/mmput() to modify. When this drops
+* to 0 (i.e. when the task exits and there are no other temporary
+* reference holders), we also release a reference on @mm_count
+* (which may then free the &struct mm_struct if @mm_count also
+* drops to 0).
+*/
+ atomic_t mm_users;
+
+ /**
+* @mm_count: The number of references to &struct mm_struct
+* (@mm_users count as 1).
+*
+* Use mmgrab()/mmdrop() to modify. When this drops to 0, the
+* &struct mm_struct is freed.
+*/
+ atomic_t mm_count;
+
atomic_long_t nr_ptes; /* PTE page table pages */
#if CONFIG_PGTABLE_LEVELS > 2
atomic_long_t nr_pmds; /* PMD page table pages */
--
2.11.0.1.gaa10c3f
[PATCH 3/4] mm: use mmget_not_zero() helper
We already have the helper, we can convert the rest of the kernel
mechanically using:
git grep -l 'atomic_inc_not_zero.*mm_users' | xargs sed -i
's/atomic_inc_not_zero(&\(.*\)->mm_users)/mmget_not_zero\(\1\)/'
This is needed for a later patch that hooks into the helper, but might be
a worthwhile cleanup on its own.
Cc: Andrew Morton
Acked-by: Michal Hocko
Signed-off-by: Vegard Nossum
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
drivers/iommu/intel-svm.c | 2 +-
fs/proc/base.c | 4 ++--
fs/proc/task_mmu.c | 4 ++--
fs/proc/task_nommu.c| 2 +-
kernel/events/uprobes.c | 2 +-
mm/swapfile.c | 2 +-
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1f27529cb48e..89be48ed7c77 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -507,7 +507,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
*_work)
flags |= FOLL_WRITE;
ret = -EFAULT;
- if (atomic_inc_not_zero(&mm->mm_users)) {
+ if (mmget_not_zero(mm)) {
down_read(&mm->mmap_sem);
while (pinned < npages) {
ret = get_user_pages_remote
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index cb72e0011310..51f2b228723f 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -579,7 +579,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
if (!svm->mm)
goto bad_req;
/* If the mm is already defunct, don't handle faults. */
- if (!atomic_inc_not_zero(&svm->mm->mm_users))
+ if (!mmget_not_zero(svm->mm))
goto bad_req;
down_read(&svm->mm->mmap_sem);
vma = find_extend_vma(svm->mm, address);
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 32f04999d930..ec7304f5117a 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -845,7 +845,7 @@ static ssize_t mem_rw(struct file *file, char __user *buf,
return -ENOMEM;
copied = 0;
- if (!atomic_inc_not_zero(&mm->mm_users))
+ if (!mmget_not_zero(mm))
goto free;
/* Maybe we should limit FOLL_FORCE to actual ptrace users? */
@@ -953,7 +953,7 @@ static ssize_t environ_read(struct file *file, char __user
*buf,
return -ENOMEM;
ret = 0;
- if (!atomic_inc_not_zero(&mm->mm_users))
+ if (!mmget_not_zero(mm))
goto free;
down_read(&mm->mmap_sem);
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 958f32545064..6c07c7813b26 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -167,7 +167,7 @@ static void *m_start(struct seq_file *m, loff_t *ppos)
return ERR_PTR(-ESRCH);
mm = priv->mm;
- if (!mm || !atomic_inc_not_zero(&mm->mm_users))
+ if (!mm || !mmget_not_zero(mm))
return NULL;
down_read(&mm->mmap_sem);
@@ -1352,7 +1352,7 @@ static ssize_t pagemap_read(struct file *file, char
__user *buf,
unsigned long end_vaddr;
int ret = 0, copied = 0;
- if (!mm || !atomic_inc_not_zero(&mm->mm_users))
+ if (!mm || !mmget_not_zero(mm))
goto out;
ret = -EINVAL;
diff --git a/fs/proc/task_nommu.c b/fs/proc/task_nommu.c
index 37175621e890..1ef97cfcf422 100644
--- a/fs/proc/task_nommu.c
+++ b/fs/proc/task_nommu.c
@@ -219,7 +219,7 @@ static void *m_start(struct seq_file *m, loff_t *pos)
return ERR_PTR(-ESRCH);
mm = priv->mm;
- if (!mm || !atomic_inc_not_zero(&mm->mm_users))
+ if (!mm || !mmget_not_zero(mm))
return NULL;
down_read(&mm->mmap_sem);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 215871bda3a2..f164fe8ca5ff 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -741,7 +741,7 @@ build_map_info(struct address_space *mapping, loff_t
offset, bool is_register)
continue;
}
- if (!atomic_inc_not_zero(&vma->vm_mm->mm_users))
+ if (!mmget_not_zero(vma->vm_mm))
continue;
info = prev;
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 914c31cc143c..5502feef0a4a 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -1493,7 +1493,7 @@ int try_to_unuse(unsigned int type, bool frontswap,
while (swap_count(*swap_map) && !retval &&
(p = p->next) != &start_mm->mmlist) {
mm = list_entry(p, struct mm_struct, mmlist);
- if (!atomic_inc_not_zero(&mm->mm_users))
+
[PATCH 1/4] mm: add new mmgrab() helper
Apart from adding the helper function itself, the rest of the kernel is converted mechanically using: git grep -l 'atomic_inc.*mm_count' | xargs sed -i 's/atomic_inc(&\(.*\)->mm_count);/mmgrab\(\1\);/' git grep -l 'atomic_inc.*mm_count' | xargs sed -i 's/atomic_inc(&\(.*\)\.mm_count);/mmgrab\(\&\1\);/' This is needed for a later patch that hooks into the helper, but might be a worthwhile cleanup on its own. (Michal Hocko provided most of the kerneldoc comment.) Cc: Andrew Morton Acked-by: Michal Hocko Signed-off-by: Vegard Nossum --- arch/alpha/kernel/smp.c | 2 +- arch/arc/kernel/smp.c| 2 +- arch/arm/kernel/smp.c| 2 +- arch/arm64/kernel/smp.c | 2 +- arch/blackfin/mach-common/smp.c | 2 +- arch/hexagon/kernel/smp.c| 2 +- arch/ia64/kernel/setup.c | 2 +- arch/m32r/kernel/setup.c | 2 +- arch/metag/kernel/smp.c | 2 +- arch/mips/kernel/traps.c | 2 +- arch/mn10300/kernel/smp.c| 2 +- arch/parisc/kernel/smp.c | 2 +- arch/powerpc/kernel/smp.c| 2 +- arch/s390/kernel/processor.c | 2 +- arch/score/kernel/traps.c| 2 +- arch/sh/kernel/smp.c | 2 +- arch/sparc/kernel/leon_smp.c | 2 +- arch/sparc/kernel/smp_64.c | 2 +- arch/sparc/kernel/sun4d_smp.c| 2 +- arch/sparc/kernel/sun4m_smp.c| 2 +- arch/sparc/kernel/traps_32.c | 2 +- arch/sparc/kernel/traps_64.c | 2 +- arch/tile/kernel/smpboot.c | 2 +- arch/x86/kernel/cpu/common.c | 4 ++-- arch/xtensa/kernel/smp.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_process.c | 2 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +- drivers/infiniband/hw/hfi1/file_ops.c| 2 +- fs/proc/base.c | 4 ++-- fs/userfaultfd.c | 2 +- include/linux/sched.h| 22 ++ kernel/exit.c| 2 +- kernel/futex.c | 2 +- kernel/sched/core.c | 4 ++-- mm/khugepaged.c | 2 +- mm/ksm.c | 2 +- mm/mmu_context.c | 2 +- mm/mmu_notifier.c| 2 +- mm/oom_kill.c| 4 ++-- virt/kvm/kvm_main.c | 2 +- 40 files changed, 65 insertions(+), 43 deletions(-) diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c index 46bf263c3153..acb4b146a607 100644 --- a/arch/alpha/kernel/smp.c +++ b/arch/alpha/kernel/smp.c @@ -144,7 +144,7 @@ smp_callin(void) alpha_mv.smp_callin(); /* All kernel threads share the same mm context. */ - atomic_inc(&init_mm.mm_count); + mmgrab(&init_mm); current->active_mm = &init_mm; /* inform the notifiers about the new cpu */ diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c index 88674d972c9d..9cbc7aba3ede 100644 --- a/arch/arc/kernel/smp.c +++ b/arch/arc/kernel/smp.c @@ -125,7 +125,7 @@ void start_kernel_secondary(void) setup_processor(); atomic_inc(&mm->mm_users); - atomic_inc(&mm->mm_count); + mmgrab(mm); current->active_mm = mm; cpumask_set_cpu(cpu, mm_cpumask(mm)); diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 7dd14e8395e6..c6514ce0fcbc 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -371,7 +371,7 @@ asmlinkage void secondary_start_kernel(void) * reference and switch to it. */ cpu = smp_processor_id(); - atomic_inc(&mm->mm_count); + mmgrab(mm); current->active_mm = mm; cpumask_set_cpu(cpu, mm_cpumask(mm)); diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c index cb87234cfcf2..959e41196cba 100644 --- a/arch/arm64/kernel/smp.c +++ b/arch/arm64/kernel/smp.c @@ -222,7 +222,7 @@ asmlinkage void secondary_start_kernel(void) * All kernel threads share the same mm context; grab a * reference and switch to it. */ - atomic_inc(&mm->mm_count); + mmgrab(mm); current->active_mm = mm; /* diff --git a/arch/blackfin/mach-common/smp.c b/arch/blackfin/mach-common/smp.c index 23c4ef5f8bdc..bc5617ef7128 100644 --- a/arch/blackfin/mach-common/smp.c +++ b/arch/blackfin/mach-common/smp.c @@ -308,7 +308,7 @@ void secondary_start_kernel(void) /* Attach the new idle task to the global mm. */ atomic_inc(&mm->mm_users); - atomic_inc(&mm->mm_count); + mmgrab(mm); current->active_mm = mm; preempt_disable(); diff --git a/arch/hexagon/kernel/smp.c b/arch/hexagon/kernel/smp.c index 983bae7d2665..c02a6455839e 100644 --- a/arch/hexagon/kernel/smp.c +++ b/arch
[PATCH] scripts: checkincludes: add exit message for no duplicates found
If no duplicates found, inform user.
Signed-off-by: Cheah Kok Cheong
---
scripts/checkincludes.pl | 13 +
1 file changed, 13 insertions(+)
diff --git a/scripts/checkincludes.pl b/scripts/checkincludes.pl
index 97b2c61..2bf234c 100755
--- a/scripts/checkincludes.pl
+++ b/scripts/checkincludes.pl
@@ -37,6 +37,13 @@ if ($#ARGV >= 1) {
}
}
+my $dup_counter = 0;
+
+sub nodup_count {
+ ++$dup_counter;
+ return;
+}
+
foreach my $file (@ARGV) {
open(my $f, '<', $file)
or die "Cannot open $file: $!.\n";
@@ -57,6 +64,7 @@ foreach my $file (@ARGV) {
foreach my $filename (keys %includedfiles) {
if ($includedfiles{$filename} > 1) {
print "$file: $filename is included more than
once.\n";
+ nodup_count();
}
}
next;
@@ -73,6 +81,7 @@ foreach my $file (@ARGV) {
if ($includedfiles{$filename} > 1) {
$includedfiles{$filename}--;
$dups++;
+ nodup_count();
} else {
print {$f} $_;
}
@@ -87,3 +96,7 @@ foreach my $file (@ARGV) {
}
close($f);
}
+
+if ($dup_counter == 0) {
+ print "No duplicate includes found.\n";
+}
--
2.7.4
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 18.12.2016 13:03, Arend Van Spriel wrote: > On 18-12-2016 11:49, Jiri Slaby wrote: >> On 12/18/2016, 12:59 AM, Linus Torvalds wrote: >>> On Sat, Dec 17, 2016 at 12:57 AM, Jiri Slaby wrote: Yes, disk drivers won't load: [2.141973] virtio_pci: disagrees about version of symbol mcount [2.144415] virtio_pci: Unknown symbol mcount (err -22) >>> >>> This makes no sense. >>> >>> mcount isn't even one of the symbols that the patch by Adam is touching. >> >> asm-prototypes.h in his patch includes asm/ftrace.h, where the function >> is declared. That should be enough IIUC scripts/Makefile.build. >> >>> There's something else screwed up here. Not to mention that others >>> don't have your issue. >> >> I suppose people don't run i386 kernels or have different config. >> >>> Do you have some other hacks in this area? Are you testing actual >>> plain 4.9, or do you (for example) still carry Arnd's patch around >>> that turned out to not work (reverted by f27c2f69cc8e in my tree)? >> >> Not at all. This was plain 4.9 packaged by suse -- only rpm-related >> fixes. I tried plain 4.9 without rpm right now with the same output: >> # insmod soundcore.ko >> [ 31.582326] soundcore: disagrees about version of symbol mcount >> [ 31.586183] soundcore: Unknown symbol mcount (err -22) >> insmod: ERROR: could not insert module soundcore.ko: Invalid parameters > > I hit an mcount issue a while back (years?) which was due to building a > driver with gcc v4.x while kernel was built using gcc v4.y. Not claiming > that is your issue though. I've usually had the same thing happen to me if things were compiled with different gcc versions . Essentially in newer gcc (starting with 4.6 I believe) CC_USING_FENTRY is defined, meaning that there is no mcount() symbol but rather __fentry__. This is the likely problem here. > > Regards, > Arend >
Re: [PATCH net-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
Hi Florian, Hi Jerome, On Wed, Nov 30, 2016 at 2:15 AM, Florian Fainelli wrote: > On 11/29/2016 05:13 PM, David Miller wrote: >> From: Florian Fainelli >> Date: Tue, 29 Nov 2016 16:43:20 -0800 >> >>> On 11/29/2016 04:38 PM, David Miller wrote: From: Jerome Brunet Date: Mon, 28 Nov 2016 10:46:45 +0100 > This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F). > The platform seems to enter LPI on the Rx path too often while performing > relatively high TX transfer. This eventually break the link (both Tx and > Rx), and require to bring the interface down and up again to get the Rx > path working again. > > The root cause of this issue is not fully understood yet but disabling EEE > advertisement on the PHY prevent this feature to be negotiated. > With this change, the link is stable and reliable, with the expected > throughput performance. > > The patchset adds options in the generic phy driver to disable EEE > advertisement, through device tree. The way it is done is very similar > to the handling of the max-speed property. Patches 1-3 applied to net-next, thanks. >>> >>> Meh, there was a v4 submitted shortly after, and I objected to the whole >>> idea of using that kind of Device Tree properties to disable EEE, we can >>> send reverts though.. >> >> Sorry, I lost this in all the discussion, I can revert. > > Yeah, I can understand why, these freaking PHYs tend to generate a lot > of noise and discussion... > >> >> Just send me a revert of the entire merge commit >> a152c91889556df17ca6d8ea134fb2cb4ac9f893 with a short >> description of why and I'll apply it. > > OK, I will talk with Jerome first to make sure that we are in agreement > with the solution to deploy to fix the OdroidC2 problem first. simply because I'm curious: what was the outcome of your discussion? can we stay with the current solution or are any changes required? Regards, Martin
Re: [PATCH] drm/nouveau: use designated initializers
On Fri, Dec 16, 2016 at 05:04:42PM -0800, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook
Merged all drm ones except the amdgpu one (I'll leave that one to Alex) to
drm-misc for 4.11 (so will show up in linux-next after xmas or so).
-Daniel
> ---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index a6dbe8258040..ec4668a41e01 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -107,10 +107,10 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager
> *man,
> }
>
> const struct ttm_mem_type_manager_func nouveau_vram_manager = {
> - nouveau_vram_manager_init,
> - nouveau_vram_manager_fini,
> - nouveau_vram_manager_new,
> - nouveau_vram_manager_del,
> + .init = nouveau_vram_manager_init,
> + .takedown = nouveau_vram_manager_fini,
> + .get_node = nouveau_vram_manager_new,
> + .put_node = nouveau_vram_manager_del,
> };
>
> static int
> @@ -184,11 +184,11 @@ nouveau_gart_manager_debug(struct ttm_mem_type_manager
> *man, const char *prefix)
> }
>
> const struct ttm_mem_type_manager_func nouveau_gart_manager = {
> - nouveau_gart_manager_init,
> - nouveau_gart_manager_fini,
> - nouveau_gart_manager_new,
> - nouveau_gart_manager_del,
> - nouveau_gart_manager_debug
> + .init = nouveau_gart_manager_init,
> + .takedown = nouveau_gart_manager_fini,
> + .get_node = nouveau_gart_manager_new,
> + .put_node = nouveau_gart_manager_del,
> + .debug = nouveau_gart_manager_debug
> };
>
> /*XXX*/
> @@ -257,11 +257,11 @@ nv04_gart_manager_debug(struct ttm_mem_type_manager
> *man, const char *prefix)
> }
>
> const struct ttm_mem_type_manager_func nv04_gart_manager = {
> - nv04_gart_manager_init,
> - nv04_gart_manager_fini,
> - nv04_gart_manager_new,
> - nv04_gart_manager_del,
> - nv04_gart_manager_debug
> + .init = nv04_gart_manager_init,
> + .takedown = nv04_gart_manager_fini,
> + .get_node = nv04_gart_manager_new,
> + .put_node = nv04_gart_manager_del,
> + .debug = nv04_gart_manager_debug
> };
>
> int
> --
> 2.7.4
>
>
> --
> Kees Cook
> Nexus Security
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[GIT pull] irq fix for 4.10
Linus,
please pull the latest irq-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
irq-urgent-for-linus
A fix for the irq affinity spread algorithm so it handles non linear node
numbering nicely.
Thanks,
tglx
-->
Guilherme G. Piccoli (1):
genirq/affinity: Fix node generation from cpumask
kernel/irq/affinity.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
index 9be9bda7c1f9..4544b115f5eb 100644
--- a/kernel/irq/affinity.c
+++ b/kernel/irq/affinity.c
@@ -37,10 +37,10 @@ static void irq_spread_init_one(struct cpumask *irqmsk,
struct cpumask *nmsk,
static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t
*nodemsk)
{
- int n, nodes;
+ int n, nodes = 0;
/* Calculate the number of nodes in the supplied affinity mask */
- for (n = 0, nodes = 0; n < num_online_nodes(); n++) {
+ for_each_online_node(n) {
if (cpumask_intersects(mask, cpumask_of_node(n))) {
node_set(n, *nodemsk);
nodes++;
@@ -82,7 +82,7 @@ irq_create_affinity_masks(int nvecs, const struct
irq_affinity *affd)
nodes = get_nodes_in_cpumask(cpu_online_mask, &nodemsk);
/*
-* If the number of nodes in the mask is less than or equal the
+* If the number of nodes in the mask is greater than or equal the
* number of vectors we just spread the vectors across the nodes.
*/
if (affv <= nodes) {
Re: crash during oom reaper
On 2016/12/16 22:14, Michal Hocko wrote:
> On Fri 16-12-16 16:07:30, Kirill A. Shutemov wrote:
>> On Fri, Dec 16, 2016 at 01:56:50PM +0100, Michal Hocko wrote:
>>> On Fri 16-12-16 15:35:55, Kirill A. Shutemov wrote:
On Fri, Dec 16, 2016 at 12:42:43PM +0100, Michal Hocko wrote:
> On Fri 16-12-16 13:44:38, Kirill A. Shutemov wrote:
>> On Fri, Dec 16, 2016 at 11:11:13AM +0100, Michal Hocko wrote:
>>> On Fri 16-12-16 10:43:52, Vegard Nossum wrote:
>>> [...]
I don't think it's a bug in the OOM reaper itself, but either of the
following two patches will fix the problem (without my understand how
or
why):
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index ec9f11d4f094..37b14b2e2af4 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -485,7 +485,7 @@ static bool __oom_reap_task_mm(struct task_struct
*tsk,
struct mm_struct *mm)
*/
mutex_lock(&oom_lock);
- if (!down_read_trylock(&mm->mmap_sem)) {
+ if (!down_write_trylock(&mm->mmap_sem)) {
>>>
>>> __oom_reap_task_mm is basically the same thing as MADV_DONTNEED and that
>>> doesn't require the exlusive mmap_sem. So this looks correct to me.
>>
>> BTW, shouldn't we filter out all VM_SPECIAL VMAs there? Or VM_PFNMAP at
>> least.
>>
>> MADV_DONTNEED doesn't touch VM_PFNMAP, but I don't see anything matching
>> on __oom_reap_task_mm() side.
>
> I guess you are right and we should match the MADV_DONTNEED behavior
> here. Care to send a patch?
Below. Testing required.
>> Other difference is that you use unmap_page_range() witch doesn't touch
>> mmu_notifiers. MADV_DONTNEED goes via zap_page_range(), which invalidates
>> the range. Not sure if it can make any difference here.
>
> Which mmu notifier would care about this? I am not really familiar with
> those users so I might miss something easily.
No idea either.
Is there any reason not to use zap_page_range here too?
>>>
>>> Yes, zap_page_range is much more heavy and performs operations which
>>> might lock AFAIR which I really would like to prevent from.
>>
>> What exactly can block there? I don't see anything with that potential.
>
> I would have to rememeber all the details. This is mostly off-topic for
> this particular thread so I think it would be better if you could send a
> full patch separatelly and we can discuss it there?
>
zap_page_range() calls mmu_notifier_invalidate_range_start().
mmu_notifier_invalidate_range_start() calls
__mmu_notifier_invalidate_range_start().
__mmu_notifier_invalidate_range_start() calls
srcu_read_lock()/srcu_read_unlock().
This means that zap_page_range() might sleep.
I don't know what individual notifier will do, but for example
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
.invalidate_range_start = i915_gem_userptr_mn_invalidate_range_start,
};
i915_gem_userptr_mn_invalidate_range_start() calls flush_workqueue()
which means that we can OOM livelock if work item involves memory allocation.
Some of other notifiers call mutex_lock()/mutex_unlock().
Even if none of currently in-tree notifier users are blocked on memory
allocation, I think it is not guaranteed that future changes/users won't be
blocked on memory allocation.
[GIT pull] smp/hotplug fixes for 4.10
Linus,
please pull the latest smp-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
smp-urgent-for-linus
Two fixlets for cpu hotplug:
- Fix a subtle ordering problem with the dummy timer. This happened to
work before the conversion by chance due to initcall ordering.
- Fix the function comment for __cpuhp_setup_state().
Thanks,
tglx
-->
Boris Ostrovsky (1):
cpu/hotplug: Clarify description of __cpuhp_setup_state() return value
Thomas Gleixner (1):
clocksource/dummy_timer: Move hotplug callback after the real timers
include/linux/cpuhotplug.h | 3 ++-
kernel/cpu.c | 6 +-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 22acee76cf4c..2ab7bf53d529 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -101,7 +101,6 @@ enum cpuhp_state {
CPUHP_AP_ARM_L2X0_STARTING,
CPUHP_AP_ARM_ARCH_TIMER_STARTING,
CPUHP_AP_ARM_GLOBAL_TIMER_STARTING,
- CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_JCORE_TIMER_STARTING,
CPUHP_AP_EXYNOS4_MCT_TIMER_STARTING,
CPUHP_AP_ARM_TWD_STARTING,
@@ -115,6 +114,8 @@ enum cpuhp_state {
CPUHP_AP_KVM_ARM_VGIC_INIT_STARTING,
CPUHP_AP_KVM_ARM_VGIC_STARTING,
CPUHP_AP_KVM_ARM_TIMER_STARTING,
+ /* Must be the last timer callback */
+ CPUHP_AP_DUMMY_TIMER_STARTING,
CPUHP_AP_ARM_XEN_STARTING,
CPUHP_AP_ARM_CORESIGHT_STARTING,
CPUHP_AP_ARM_CORESIGHT4_STARTING,
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 217fd2e7f435..5339aca811d2 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1586,7 +1586,11 @@ EXPORT_SYMBOL_GPL(__cpuhp_state_add_instance);
* @startup: startup callback function
* @teardown: teardown callback function
*
- * Returns 0 if successful, otherwise a proper error code
+ * Returns:
+ * On success:
+ * Positive state number if @state is CPUHP_AP_ONLINE_DYN
+ * 0 for all other states
+ * On failure: proper (negative) error code
*/
int __cpuhp_setup_state(enum cpuhp_state state,
const char *name, bool invoke,
[PATCH] media: dvb: dmx: fixed coding style issues of spacing
Fixed coding style issues of spacing
Signed-off-by: Devendra Sharma
---
drivers/media/dvb-core/dmxdev.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index efe55a3..cd240a2 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -151,6 +151,7 @@ static int dvb_dvr_open(struct inode *inode, struct file
*file)
if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
void *mem;
+
if (!dvbdev->readers) {
mutex_unlock(&dmxdev->mutex);
return -EBUSY;
@@ -202,6 +203,7 @@ static int dvb_dvr_release(struct inode *inode, struct file
*file)
dvbdev->readers++;
if (dmxdev->dvr_buffer.data) {
void *mem = dmxdev->dvr_buffer.data;
+ /*memory barrier*/
mb();
spin_lock_irq(&dmxdev->lock);
dmxdev->dvr_buffer.data = NULL;
@@ -876,7 +878,7 @@ static int dvb_dmxdev_pes_filter_set(struct dmxdev *dmxdev,
dvb_dmxdev_filter_stop(dmxdevfilter);
dvb_dmxdev_filter_reset(dmxdevfilter);
- if ((unsigned)params->pes_type > DMX_PES_OTHER)
+ if ((unsigned int)params->pes_type > DMX_PES_OTHER)
return -EINVAL;
dmxdevfilter->type = DMXDEV_TYPE_PES;
@@ -1125,7 +1127,7 @@ static int dvb_demux_release(struct inode *inode, struct
file *file)
mutex_lock(&dmxdev->mutex);
dmxdev->dvbdev->users--;
- if(dmxdev->dvbdev->users==1 && dmxdev->exit==1) {
+ if (dmxdev->dvbdev->users == 1 && dmxdev->exit == 1) {
mutex_unlock(&dmxdev->mutex);
wake_up(&dmxdev->dvbdev->wait_queue);
} else
@@ -1263,14 +1265,14 @@ EXPORT_SYMBOL(dvb_dmxdev_init);
void dvb_dmxdev_release(struct dmxdev *dmxdev)
{
- dmxdev->exit=1;
+ dmxdev->exit = 1;
if (dmxdev->dvbdev->users > 1) {
wait_event(dmxdev->dvbdev->wait_queue,
- dmxdev->dvbdev->users==1);
+ dmxdev->dvbdev->users == 1);
}
if (dmxdev->dvr_dvbdev->users > 1) {
wait_event(dmxdev->dvr_dvbdev->wait_queue,
- dmxdev->dvr_dvbdev->users==1);
+ dmxdev->dvr_dvbdev->users == 1);
}
dvb_unregister_device(dmxdev->dvbdev);
--
2.7.4
[GIT pull] timer fix for 4.10
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
Prevent NULL pointer dereferencing in the tick broadcast code. Old bug,
which got unearthed by the hotplug ordering problem.
Thanks,
tglx
-->
Thomas Gleixner (1):
tick/broadcast: Prevent NULL pointer dereference
kernel/time/tick-broadcast.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f6aae7977824..d2a20e83ebae 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -871,6 +871,9 @@ void tick_broadcast_setup_oneshot(struct clock_event_device
*bc)
{
int cpu = smp_processor_id();
+ if (!bc)
+ return;
+
/* Set it up only once ! */
if (bc->event_handler != tick_handle_oneshot_broadcast) {
int was_periodic = clockevent_state_periodic(bc);
regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
Hello,
while testing kernel 4.9 I run into a weird issue with the ath9k driver.
I can boot the box in console mode and it stay up sometime but is not usable.
from dmesg :
===
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G I
---
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){..}, at: []
ath_tx_edma_tasklet+0x0/0x460 [ath9k]
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.9-fw1 #1
Hardware name: FUJITSU PRIMERGY TX200 S5
/D2709, BIOS 6.00 Rev. 1.14.2709 02/04/2013
88043ee03f38 812cf0f3 81a11540 0001
88043ee03f68 810b7865 81a55d58 88043efcedc0
88083cb1ca00 00d1 88043ee03f88 810dbfe8
Call Trace:
[] dump_stack+0x86/0xc3
[] lockdep_rcu_suspicious+0xc5/0x100
[] rcu_eqs_enter_common.constprop.62+0x128/0x130
[] rcu_irq_exit+0x38/0x70
[] irq_exit+0x74/0xd0
[] do_IRQ+0x71/0x130
[] common_interrupt+0x8c/0x8c
[] ? cpuidle_enter_state+0x156/0x220
[] cpuidle_enter+0x12/0x20
[] call_cpuidle+0x1e/0x40
[] cpu_startup_entry+0x11d/0x210
[] rest_init+0x12c/0x140
[] start_kernel+0x40f/0x41c
[] ? early_idt_handler_array+0x120/0x120
[] x86_64_start_reservations+0x2a/0x2c
[] x86_64_start_kernel+0xeb/0xf8
...
perf: interrupt took too long (2766 > 2500), lowering
kernel.perf_event_max_sample_rate to 72000
perf: interrupt took too long (3510 > 3457), lowering
kernel.perf_event_max_sample_rate to 56000
perf: interrupt took too long (4689 > 4387), lowering
kernel.perf_event_max_sample_rate to 42000
perf: interrupt took too long (5980 > 5861), lowering
kernel.perf_event_max_sample_rate to 33000
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-15): P0
(detected by 5, t=65002 jiffies, g=3241, c=3240, q=8520)
swapper/0 R running task0 0 0 0x
81a03e90 8139bf30 81ae30b8 810253a9
88083cb1e600 81ae30a0 0002 81ae30b8
81ae2fe0 81a03ed0 81472814 001823671b47
Call Trace:
[] ? acpi_idle_enter+0x116/0x1fb
[] ? cpuidle_enter_state+0x134/0x220
[] ? cpuidle_enter+0x12/0x20
[] ? call_cpuidle+0x1e/0x40
[] ? cpu_startup_entry+0x11d/0x210
[] ? rest_init+0x12c/0x140
[] ? start_kernel+0x40f/0x41c
[] ? early_idt_handler_array+0x120/0x120
[] ? x86_64_start_reservations+0x2a/0x2c
[] ? x86_64_start_kernel+0xeb/0xf8
swapper/0 R running task0 0 0 0x
81a03e90 8139bf30 81ae30b8 810253a9
88083cb1e600 81ae30a0 0002 81ae30b8
81ae2fe0 81a03ed0 81472814 001823671b47
Call Trace:
[] ? acpi_idle_enter+0x116/0x1fb
[] ? cpuidle_enter_state+0x134/0x220
[] ? cpuidle_enter+0x12/0x20
[] ? call_cpuidle+0x1e/0x40
[] ? cpu_startup_entry+0x11d/0x210
[] ? rest_init+0x12c/0x140
[] ? start_kernel+0x40f/0x41c
[] ? early_idt_handler_array+0x120/0x120
[] ? x86_64_start_reservations+0x2a/0x2c
[] ? x86_64_start_kernel+0xeb/0xf8
perf: interrupt took too long (7746 > 7475), lowering
kernel.perf_event_max_sample_rate to 25000
systemd-hostnamed.service: State 'stop-sigterm' timed out. Killing.
systemd-hostnamed.service: Killing process 1507 (systemd-hostnam) with signal
SIGKILL.
perf: interrupt took too long (10065 > 9682), lowering
kernel.perf_event_max_sample_rate to 19000
perf: interrupt took too long (12596 > 12581), lowering
kernel.perf_event_max_sample_rate to 15000
INFO: task systemd-hostnam:1507 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-hostnam D0 1507 1 0x0002
88043a29f200 c460 88043ab0a1c0 88043cdc
88043f9d6718 c9000b67fb88 8157ff6e c9000b67fbf8
88043ab0abc0 88043f9d6718 88043ab0a1c0
Call Trace:
[] ? __schedule+0x2ce/0x810
[] schedule+0x3b/0x90
[] schedule_timeout+0x222/0x3a0
[] ? debug_smp_processor_id+0x17/0x20
[] ? debug_smp_processor_id+0x17/0x20
[] ? get_lock_stats+0x19/0x50
[] ? _raw_spin_unlock_irq+0x27/0x50
[] ? __this_cpu_preempt_check+0x13/0x20
[] ? trace_hardirqs_on_caller+0xef/0x200
[] wait_for_common+0xca/0x180
[] ? wake_up_q+0x80/0x80
[] wait_for_completion+0x18/0x20
[] __wait_rcu_gp+0xc5/0x100
[] synchronize_rcu.part.53+0x2d/0x50
[] ? __call_rcu.constprop.59+0x270/0x270
[] ? rcu_panic+0x20/0x20
[] ? wait_for_common+0x39/0x180
[] synchronize_rcu+0x27/0x90
[] namespace_unlock+0x47/0x60
[] drop_collec
Re: [PATCH v6 4/5] PM / runtime: Use device links
Hi Rafael,
spotted what looks like a bug in the device links runtime PM code:
When resuming a device, __rpm_callback() calls rpm_get_suppliers(dev):
> + retval = rpm_get_suppliers(dev);
> + if (retval)
> + goto fail;
This will walk the list of suppliers and call pm_runtime_get_sync()
for each of them:
> +static int rpm_get_suppliers(struct device *dev)
> +{
> + struct device_link *link;
> +
> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node) {
> + int retval;
[...]
> + retval = pm_runtime_get_sync(link->supplier);
> + if (retval < 0) {
> + pm_runtime_put_noidle(link->supplier);
> + return retval;
If pm_runtime_get_sync() failed, e.g. because runtime PM is disabled
on a supplier, the function will put the reference of the failed
supplier and return.
Back in __rpm_callback() we jump to the fail mark, where we call
rpm_put_suppliers().
> + fail:
> + rpm_put_suppliers(dev);
> +
> + device_links_read_unlock(idx);
This walks the list of suppliers and releases a ref for each of them:
> +static void rpm_put_suppliers(struct device *dev)
> +{
> + struct device_link *link;
> +
> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node)
> + if (link->rpm_active &&
> + READ_ONCE(link->status) != DL_STATE_SUPPLIER_UNBIND) {
> + pm_runtime_put(link->supplier);
> + link->rpm_active = false;
> + }
> +}
This looks wrong: We've already put a ref on the failed supplier, so here
we're putting another one. And if there are further suppliers in the list
following the failed one, we'll decrement their refcount even though we've
never incremented it.
Thanks,
Lukas
[GIT pull] x86 fixes and cleanups for 4.10
Linus,
please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
This set of updates contains:
- Robustification for the logical package managment. Cures the AMD and
virtualization issues.
- Put the correct start_cpu() return address on the stack of the idle
task.
- Fixups for the fallout of the nodeid <-> cpuid persistent mapping
modifciations
- Move the x86/MPX specific mm_struct member to the arch specific
mm_context where it belongs
- Cleanups for C89 struct initializers and useless function arguments
Thanks,
tglx
-->
Boris Ostrovsky (2):
x86/acpi: Use proper macro for invalid node
ACPI/NUMA: Do not map pxm to node when NUMA is turned off
Josh Poimboeuf (2):
x86/boot/64: Use 'push' instead of 'call' in start_cpu()
x86/boot/64: Push correct start_cpu() return address
Kees Cook (1):
x86/floppy: Use designated initializers
Kirill A. Shutemov (1):
x86/mm: Drop unused argument 'removed' from sync_global_pgds()
Mark Rutland (1):
x86/mpx: Move bd_addr to mm_context_t
Thomas Gleixner (2):
x86/smpboot: Make logical package management more robust
x86/smpboot: Prevent false positive out of bounds cpumask access warning
arch/arm64/include/asm/numa.h | 2 ++
arch/arm64/mm/numa.c | 2 +-
arch/ia64/include/asm/numa.h | 2 ++
arch/x86/include/asm/floppy.h | 20 ++---
arch/x86/include/asm/mmu.h| 4 +++
arch/x86/include/asm/mpx.h| 4 +--
arch/x86/include/asm/pgtable_64.h | 3 +-
arch/x86/kernel/acpi/boot.c | 2 +-
arch/x86/kernel/apic/apic.c | 15 --
arch/x86/kernel/cpu/common.c | 24 ++--
arch/x86/kernel/head_64.S | 5 ++--
arch/x86/kernel/smpboot.c | 59 +++
arch/x86/mm/fault.c | 2 +-
arch/x86/mm/init_64.c | 24 +---
arch/x86/mm/mpx.c | 10 +++
arch/x86/mm/numa.c| 2 +-
arch/x86/xen/smp.c| 6
drivers/acpi/numa.c | 2 +-
include/linux/cpumask.h | 5
include/linux/mm_types.h | 4 ---
20 files changed, 77 insertions(+), 120 deletions(-)
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e491fd..bf466d1876e3 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -15,6 +15,8 @@ int __node_distance(int from, int to);
extern nodemask_t numa_nodes_parsed __initdata;
+extern bool numa_off;
+
/* Mappings between node number and cpus on that node. */
extern cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
void numa_clear_node(unsigned int cpu);
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 4b32168cf91a..b388a99fea7b 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -35,7 +35,7 @@ static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] =
NUMA_NO_NODE };
static int numa_distance_cnt;
static u8 *numa_distance;
-static bool numa_off;
+bool numa_off;
static __init int numa_parse_early_param(char *opt)
{
diff --git a/arch/ia64/include/asm/numa.h b/arch/ia64/include/asm/numa.h
index 2db0a6c6daa5..ebef7f40aabb 100644
--- a/arch/ia64/include/asm/numa.h
+++ b/arch/ia64/include/asm/numa.h
@@ -65,6 +65,8 @@ extern int paddr_to_nid(unsigned long paddr);
#define local_nodeid (cpu_to_node_map[smp_processor_id()])
+#define numa_off 0
+
extern void map_cpu_to_node(int cpu, int nid);
extern void unmap_cpu_from_node(int cpu, int nid);
extern void numa_clear_node(int cpu);
diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
index 1c7eefe32502..7ec59edde154 100644
--- a/arch/x86/include/asm/floppy.h
+++ b/arch/x86/include/asm/floppy.h
@@ -229,18 +229,18 @@ static struct fd_routine_l {
int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
} fd_routine[] = {
{
- request_dma,
- free_dma,
- get_dma_residue,
- dma_mem_alloc,
- hard_dma_setup
+ ._request_dma = request_dma,
+ ._free_dma = free_dma,
+ ._get_dma_residue = get_dma_residue,
+ ._dma_mem_alloc = dma_mem_alloc,
+ ._dma_setup = hard_dma_setup
},
{
- vdma_request_dma,
- vdma_nop,
- vdma_get_dma_residue,
- vdma_mem_alloc,
- vdma_dma_setup
+ ._request_dma = vdma_request_dma,
+ ._free_dma = vdma_nop,
+ ._get_dma_residue = vdma_get_dma_residue,
+ ._dma_mem_alloc = vdma_mem_alloc,
+ ._dma_setup = vdma_dma_setup
}
};
diff --git a/arch/x
Re: [PATCH] kbuild: disable -ffunction-sections on gcc-4.7 with ftrace
Hi,
On Fri, Dec 16, 2016 at 6:24 PM, Arnd Bergmann wrote:
> When ftrace is enabled and we build with gcc-4.7 or older, we
> get a warning for each file on architectures that select
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:
>
> warning: -ffunction-sections disabled; it makes profiling impossible [enabled
> by default]
>
> This turns off function sections in that specific case, leaving
> it enabled for all other configurations.
>
> Fixes: b67067f1176d ("kbuild: allow archs to select link dead code/data
> elimination")
> Signed-off-by: Arnd Bergmann
> ---
> Makefile | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index 4fb4b889c862..7dfd0aa4f3f7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -638,7 +638,11 @@ KBUILD_CFLAGS += $(call
> cc-option,-fno-delete-null-pointer-checks,)
> KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
>
> ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> +ifdef CONFIG_FUNCTION_TRACER
> +KBUILD_CFLAGS += $(call cc-ifversion, -ge,0409,$(call
> cc-option,-ffunction-sections,))
s/0409/0408/ ?
Thanks,
Namhyung
> +else
> KBUILD_CFLAGS += $(call cc-option,-ffunction-sections,)
> +endif
> KBUILD_CFLAGS += $(call cc-option,-fdata-sections,)
> endif
>
> --
> 2.9.0
>
Re: [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
On Sun, Dec 18, 2016 at 11:57:00AM +, Ard Biesheuvel wrote: > On 16 December 2016 at 21:51, Arnd Bergmann wrote: > > On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote: > >> > >> Can't we use the old > >> > >> tst lr, #1 > >> moveq pc, lr > >> bx lr > >> > >> trick? (where bx lr needs to be emitted as a plain opcode to hide it > >> from the assembler) > >> > > > > Yes, that should work around the specific problem in theory, but back > > when Jonas tried it, it still didn't work. There may also be other > > problems in that configuration. > > > > This should do the trick as well, I think: > > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S > index 9f157e7c51e7..3bfb32010234 100644 > --- a/arch/arm/kernel/entry-armv.S > +++ b/arch/arm/kernel/entry-armv.S > @@ -835,7 +835,12 @@ ENDPROC(__switch_to) > > .macro usr_ret, reg > #ifdef CONFIG_ARM_THUMB > +#ifdef CONFIG_CPU_32v4 > + str \reg, [sp, #-4]! > + ldr pc, [sp], #4 > +#else > bx \reg > +#endif > #else > ret \reg > #endif > > with the added benefit that we don't clobber the N and Z flags. Of > course, this will result in all CPUs using a non-optimal sequence if > support for v4 is compiled in. We don't clobber those flags anyway. bx doesn't change any of the flags. 'ret' devolves into either bx or a mov instruction. A mov instruction without 's' does not change the flags either. So there is no "added benefit". In fact, there's only detrimental effects. str and ldr are going to be several cycles longer than the plain mov. In any case, the "CONFIG_CPU_32v4" alone doesn't hack it, we also have CONFIG_CPU_32v3 to also consider. In any case, I prefer the solution previously posted - to test bit 0 of the PC, and select the instruction based on that. It'll take some assembly level macros to handle all cases. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 12/18/2016, 02:27 PM, Nikolay Borisov wrote: > This is the likely problem here. No, it is not. How could a rpm be built with two compilers? Moreover, with some modules, __put_user_1 and others are reported instead of mcount. -- js suse labs
[PATCH V2 0/2] mm/memblock.c: fix potential bug and code refine
Here are two patch of mm/memblock.c. [1]. A trivial code refine in memblock_is_region_memory(), which removes an unnecessary check on base address. [2]. The original code forgets to check the return value of memblock_reserve(), which may lead to potential problem. The patch fix this. --- v2: remove a trivial code refine, which is already fixed in upstream Wei Yang (2): mm/memblock.c: trivial code refine in memblock_is_region_memory() mm/memblock.c: check return value of memblock_reserve() in memblock_virt_alloc_internal() include/linux/memblock.h |5 ++--- mm/memblock.c|8 +++- 2 files changed, 5 insertions(+), 8 deletions(-) -- 1.7.9.5
[PATCH V2 1/2] mm/memblock.c: trivial code refine in memblock_is_region_memory()
The base address is already guaranteed to be in the region by memblock_search(). This patch removes the check on base. Signed-off-by: Wei Yang --- mm/memblock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/memblock.c b/mm/memblock.c index 7608bc3..cd85303 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1615,7 +1615,7 @@ int __init_memblock memblock_is_region_memory(phys_addr_t base, phys_addr_t size if (idx == -1) return 0; - return memblock.memory.regions[idx].base <= base && + return /* memblock.memory.regions[idx].base <= base && */ (memblock.memory.regions[idx].base + memblock.memory.regions[idx].size) >= end; } -- 2.5.0
[PATCH V2 2/2] mm/memblock.c: check return value of memblock_reserve() in memblock_virt_alloc_internal()
memblock_reserve() may fail in case there is not enough regions.
This patch checks the return value.
Signed-off-by: Wei Yang
---
mm/memblock.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index cd85303..93fa687 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1274,18 +1274,17 @@ static void * __init memblock_virt_alloc_internal(
if (max_addr > memblock.current_limit)
max_addr = memblock.current_limit;
-
again:
alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
nid, flags);
- if (alloc)
+ if (alloc && !memblock_reserve(alloc, size))
goto done;
if (nid != NUMA_NO_NODE) {
alloc = memblock_find_in_range_node(size, align, min_addr,
max_addr, NUMA_NO_NODE,
flags);
- if (alloc)
+ if (alloc && !memblock_reserve(alloc, size))
goto done;
}
@@ -1303,7 +1302,6 @@ static void * __init memblock_virt_alloc_internal(
return NULL;
done:
- memblock_reserve(alloc, size);
ptr = phys_to_virt(alloc);
memset(ptr, 0, size);
--
2.5.0
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 18.12.2016 16:45, Jiri Slaby wrote: > Moreover, with some modules, __put_user_1 and others are reported > instead of mcount. nm vmlinux | grep __fentry__ nm vmlinux | grep mcount What do these report ? I bet you that in your vmlinux the first one would return something like : 822f1810 T __fentry__ 827fdc20 r __kcrctab___fentry__ 82809461 r __kstrtab___fentry__ 827e6c20 R __ksymtab___fentry__ and nothing for the second. Whereas doing nm on the module in question would give nothing for __fentry__ and something like: U mcount
Re: [PATCH] ARM: disallow ARM_THUMB for ARMv4 builds
On 18 December 2016 at 14:16, Russell King - ARM Linux wrote: > On Sun, Dec 18, 2016 at 11:57:00AM +, Ard Biesheuvel wrote: >> On 16 December 2016 at 21:51, Arnd Bergmann wrote: >> > On Friday, December 16, 2016 5:20:22 PM CET Ard Biesheuvel wrote: >> >> >> >> Can't we use the old >> >> >> >> tst lr, #1 >> >> moveq pc, lr >> >> bx lr >> >> >> >> trick? (where bx lr needs to be emitted as a plain opcode to hide it >> >> from the assembler) >> >> >> > >> > Yes, that should work around the specific problem in theory, but back >> > when Jonas tried it, it still didn't work. There may also be other >> > problems in that configuration. >> > >> >> This should do the trick as well, I think: >> >> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S >> index 9f157e7c51e7..3bfb32010234 100644 >> --- a/arch/arm/kernel/entry-armv.S >> +++ b/arch/arm/kernel/entry-armv.S >> @@ -835,7 +835,12 @@ ENDPROC(__switch_to) >> >> .macro usr_ret, reg >> #ifdef CONFIG_ARM_THUMB >> +#ifdef CONFIG_CPU_32v4 >> + str \reg, [sp, #-4]! >> + ldr pc, [sp], #4 >> +#else >> bx \reg >> +#endif >> #else >> ret \reg >> #endif >> >> with the added benefit that we don't clobber the N and Z flags. Of >> course, this will result in all CPUs using a non-optimal sequence if >> support for v4 is compiled in. > > We don't clobber those flags anyway. bx doesn't change any of the flags. > 'ret' devolves into either bx or a mov instruction. A mov instruction > without 's' does not change the flags either. > The 'added benefit' is with respect to the tst/moveq/bx sequence, which clobbers the N and Z flags. > So there is no "added benefit". In fact, there's only detrimental > effects. str and ldr are going to be several cycles longer than the > plain mov. > Yes, but the kuser helpers are documented as preserving all flags and registers except the ones that are documents as clobbered. I agree it is highly unlikely that clobbering the N and Z flags is going to break anything, but it is an ABI change nonetheless. > In any case, the "CONFIG_CPU_32v4" alone doesn't hack it, we also have > CONFIG_CPU_32v3 to also consider. > I don't think there are any configurations where CONFIG_CPU_32v3 are CONFIG_ARM_THUMB are both enabled. The ARMv4 case is significant because it can be enabled as part of a v4/v5 multiplatform configuration. > In any case, I prefer the solution previously posted - to test bit 0 of > the PC, and select the instruction based on that. It'll take some > assembly level macros to handle all cases. > The only issue I spotted is that the kuser_get_tls routine has only two instruction slots for the return sequence, but we can easily work around that by moving the TLS hardware instruction around in the template (and update the memcpy accordingly in kuser_init() It does appear that the tst/moveq/bx failed to work correctly when tested on FA526, according to the link quoted by Arnd. But the below builds ok for me on a v4/v4t/v5 multiarch configuration (apologies on behalf of Gmail for the whitespace corruption, I can resend it as a proper patch) diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index 9f157e7c51e7..e849965e3136 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -833,9 +833,21 @@ ENDPROC(__switch_to) */ THUMB( .arm ) + .irp i, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14 + .set .Lreg_\i, \i + .endr + .set .Lreg_ip, 12 + .set .Lreg_lr, 14 + .macro usr_ret, reg #ifdef CONFIG_ARM_THUMB +#if defined(CONFIG_CPU_32v3) || defined(CONFIG_CPU_32v4) + tst \reg, #1 @ preserves the C and V flags + moveq pc, \reg + .word 0xe12fff10 | .Lreg_\reg @ correct order for LE and BE32 +#else bx \reg +#endif #else ret \reg #endif @@ -1001,11 +1013,10 @@ kuser_cmpxchg32_fixup: __kuser_get_tls: @ 0x0fe0 ldr r0, [pc, #(16 - 8)] @ read TLS, set in kuser_get_tls_init usr_ret lr - mrc p15, 0, r0, c13, c0, 3 @ 0x0fe8 hardware TLS code kuser_pad __kuser_get_tls, 16 - .rep 3 .word 0 @ 0x0ff0 software TLS value, then - .endr @ pad up to __kuser_helper_version + mrc p15, 0, r0, c13, c0, 3 @ 0x0ff4 hardware TLS code + .word 0 @ pad up to __kuser_helper_version __kuser_helper_version: @ 0x0ffc .word ((__kuser_helper_end - __kuser_helper_start) >> 5) diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c index bc698383e822..7746090bd930 100644 --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -777,10 +777,10 @@ static void __init kuser_init(void *vectors) /* * vectors + 0xfe0 = __kuser_get_tls - * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8 + * vectors + 0xff4 = hardware TLS instruction at 0x0ff4 */ if (tls_emu || has_tls_reg) - memcpy(vectors + 0xfe0, vectors + 0xfe8, 4); + memcpy(vectors + 0xfe0, vectors + 0xff4, 4); } #else static inline void __init kuser_init(void *vectors)
Re: [GIT PULL] kbuild changes for v4.9-rc1
On 12/18/2016, 03:54 PM, Nikolay Borisov wrote: > > > On 18.12.2016 16:45, Jiri Slaby wrote: >> Moreover, with some modules, __put_user_1 and others are reported >> instead of mcount. > > > nm vmlinux | grep __fentry__ > nm vmlinux | grep mcount > > What do these report ? I bet you that in your vmlinux the first one > would return something like : > > 822f1810 T __fentry__ > 827fdc20 r __kcrctab___fentry__ > 82809461 r __kstrtab___fentry__ > 827e6c20 R __ksymtab___fentry__ > and nothing for the second. Whereas doing nm on the module in question > would give nothing for __fentry__ and something like: U mcount Well, I have just won a beer: $ nm vmlinux | grep mcount w __crc_mcount c0b3bd34 r __kcrctab_mcount c0b41692 r __kstrtab_mcount c0b2dd04 R __ksymtab_mcount c0896130 T mcount c0c9ee20 T __start_mcount_loc c0cba89c T __stop_mcount_loc $ nm vmlinux | grep __fentry__ $ nm sound/soundcore.ko | grep mcount U mcount No, I am really not stupid. We compile the kernels like this for over a decade and it really broke with 4.9. Applying the patch fixes the problem. Reverting it, makes it recur. regards, -- js suse labs
Re: [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths
From: "Mintz, Yuval" Date: Sun, 18 Dec 2016 06:33:50 + >> From: Colin Ian King >> >> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd >> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also >> setting *pp_ent to NULL to be safe. >> >> Found with static analysis by CoverityScan, CIDs 1389468-1389470 >> >> Signed-off-by: Colin Ian King > ... >> +err: >> +kfree(*pp_ent); >> +*pp_ent = NULL; >> + >> +return rc; >> } > > Hi Colin - thanks for this. > It would have been preferable to return the previously allocated spq entry. > I.e., do: > > +err: > + qed_spq_return_entry(p_hwfn, *pp_ent); > + *pp_ent = NULL; > + return rc; Looking at this last night, I came to the same conclusion.
Re: [PATCH v6 4/5] PM / runtime: Use device links
On Sun, Dec 18, 2016 at 3:01 PM, Lukas Wunner wrote:
> Hi Rafael,
>
> spotted what looks like a bug in the device links runtime PM code:
>
> When resuming a device, __rpm_callback() calls rpm_get_suppliers(dev):
>
>> + retval = rpm_get_suppliers(dev);
>> + if (retval)
>> + goto fail;
>
>
> This will walk the list of suppliers and call pm_runtime_get_sync()
> for each of them:
>
>> +static int rpm_get_suppliers(struct device *dev)
>> +{
>> + struct device_link *link;
>> +
>> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node) {
>> + int retval;
> [...]
>> + retval = pm_runtime_get_sync(link->supplier);
>> + if (retval < 0) {
>> + pm_runtime_put_noidle(link->supplier);
>> + return retval;
>
>
> If pm_runtime_get_sync() failed, e.g. because runtime PM is disabled
> on a supplier, the function will put the reference of the failed
> supplier and return.
>
> Back in __rpm_callback() we jump to the fail mark, where we call
> rpm_put_suppliers().
>
>> + fail:
>> + rpm_put_suppliers(dev);
>> +
>> + device_links_read_unlock(idx);
>
>
> This walks the list of suppliers and releases a ref for each of them:
>
>> +static void rpm_put_suppliers(struct device *dev)
>> +{
>> + struct device_link *link;
>> +
>> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node)
>> + if (link->rpm_active &&
>> + READ_ONCE(link->status) != DL_STATE_SUPPLIER_UNBIND) {
>> + pm_runtime_put(link->supplier);
>> + link->rpm_active = false;
>> + }
>> +}
>
>
> This looks wrong: We've already put a ref on the failed supplier, so here
> we're putting another one.
Are we? I would think link->rpm_active would be false for the failed
one, wouldn't it?
> And if there are further suppliers in the list
> following the failed one, we'll decrement their refcount even though we've
> never incremented it.
I'm not following you here, sorry.
Thanks,
Rafael
Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
On Sun, Dec 18, 2016 at 02:52:48PM +0100, Gabriel C wrote:
> Hello,
>
> while testing kernel 4.9 I run into a weird issue with the ath9k driver.
>
> I can boot the box in console mode and it stay up sometime but is not usable.
Looks to me like someone forgot an rcu_read_unlock() somewhere. Given that
the unmatched rcu_read_lock() appears in ath_tx_edma_tasklet(), perhaps
that is also where the missing rcu_read_unlock() is. And sure enough,
in the middle of this function we have the following:
fifo_list = &txq->txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
return;
}
This will of course return while still in an RCU read-side critical
section. The caller cannot tell the difference between a return here
and falling off the end of the function, so this is likely the bug.
Or one of the bugs, anyway. Copying the author and committer for
their thoughts.
Please try the patch at the end of this email.
Thanx, Paul
> from dmesg :
>
> ===
> [ INFO: suspicious RCU usage. ]
> 4.9-fw1 #1 Tainted: G I
> ---
> kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 1
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
> #0: (rcu_read_lock){..}, at: []
> ath_tx_edma_tasklet+0x0/0x460 [ath9k]
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.9-fw1 #1
> Hardware name: FUJITSU PRIMERGY TX200 S5
> /D2709, BIOS 6.00 Rev. 1.14.2709 02/04/2013
> 88043ee03f38 812cf0f3 81a11540 0001
> 88043ee03f68 810b7865 81a55d58 88043efcedc0
> 88083cb1ca00 00d1 88043ee03f88 810dbfe8
> Call Trace:
>
> [] dump_stack+0x86/0xc3
> [] lockdep_rcu_suspicious+0xc5/0x100
> [] rcu_eqs_enter_common.constprop.62+0x128/0x130
> [] rcu_irq_exit+0x38/0x70
> [] irq_exit+0x74/0xd0
> [] do_IRQ+0x71/0x130
> [] common_interrupt+0x8c/0x8c
>
> [] ? cpuidle_enter_state+0x156/0x220
> [] cpuidle_enter+0x12/0x20
> [] call_cpuidle+0x1e/0x40
> [] cpu_startup_entry+0x11d/0x210
> [] rest_init+0x12c/0x140
> [] start_kernel+0x40f/0x41c
> [] ? early_idt_handler_array+0x120/0x120
> [] x86_64_start_reservations+0x2a/0x2c
> [] x86_64_start_kernel+0xeb/0xf8
commit 5a16fed76936184a7ac22e466cf39bd8bb5ee65e
Author: Paul E. McKenney
Date: Sun Dec 18 07:49:00 2016 -0800
drivers/ath: Add missing rcu_read_unlock() to ath_tx_edma_tasklet()
Commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
added rcu_read_lock() and rcu_read_unlock() around the body of
ath_tx_edma_tasklet(), but failed to add the needed rcu_read_unlock()
before a "return" in the middle of this function. This commit therefore
adds the missing rcu_read_unlock().
Reported-by: Gabriel C
Signed-off-by: Paul E. McKenney
Cc: Felix Fietkau
Cc: Kalle Valo
Cc: QCA ath9k Development
Cc:
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = &txq->txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+ rcu_read_unlock();
return;
}
Re: crash during oom reaper
On Sun 18-12-16 22:47:07, Tetsuo Handa wrote:
> On 2016/12/16 22:14, Michal Hocko wrote:
[...]
> > I would have to rememeber all the details. This is mostly off-topic for
> > this particular thread so I think it would be better if you could send a
> > full patch separatelly and we can discuss it there?
> >
>
> zap_page_range() calls mmu_notifier_invalidate_range_start().
> mmu_notifier_invalidate_range_start() calls
> __mmu_notifier_invalidate_range_start().
> __mmu_notifier_invalidate_range_start() calls
> srcu_read_lock()/srcu_read_unlock().
> This means that zap_page_range() might sleep.
>
> I don't know what individual notifier will do, but for example
>
> static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
> .invalidate_range_start =
> i915_gem_userptr_mn_invalidate_range_start,
> };
>
> i915_gem_userptr_mn_invalidate_range_start() calls flush_workqueue()
> which means that we can OOM livelock if work item involves memory allocation.
> Some of other notifiers call mutex_lock()/mutex_unlock().
>
> Even if none of currently in-tree notifier users are blocked on memory
> allocation, I think it is not guaranteed that future changes/users won't be
> blocked on memory allocation.
Kirill has sent this as a separate patchset [1]. Could you follow up on
that there please?
http://lkml.kernel.org/r/20161216141556.75130-4-kirill.shute...@linux.intel.com
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
Hi,
On 18.12.2016 01:15, Francois Romieu wrote:
> Pavel Machek :
> [...]
>> Won't this up/down the interface, in a way userspace can observe?
>
> It won't up/down the interface as it doesn't exactly mimic what the
> network code does (there's more than rtnl_lock).
>
Right. Userspace wont see link down/up, but it will see carrier off/on.
But this is AFAIK acceptable for a rare situation like a tx error.
> For the same reason it's broken if it races with the transmit path: it
> can release driver resources while the transmit path uses these.
>
> Btw the points below may not matter/hurt much for a proof a concept
> but they would need to be addressed as well:
> 1) unchecked (and avoidable) extra error paths due to stmmac_release()
> 2) racy cancel_work_sync. Low probability as it is, an irq + error could
>take place right after cancel_work_sync
It was indeed only meant as a proof of concept. Nevertheless the race is not
good, since one can run into it when faking the tx error for testings purposes.
So below is a slightly improved version of the restart handling.
Its not meant as a final version either. But maybe we can use it as a starting
point.
> Lino, have you considered via-rhine.c since its "move work from irq to
> workqueue context" changes that started in
> 7ab87ff4c770eed71e3777936299292739fcd0fe [*] ?
> It's a shameless plug - originated in r8169.c - but it should be rather
> close to what the sxgbe and friends require. Thought / opinion ?
>
Not really. There are a few drivers that I use to look into if I want to know
how certain things are done correctly (e.g the sky2 or the intel drivers)
because
I think they are well implemented.
But you seem to have put some thoughts into various race condition problems
in the via-rhine driver and I can image that sxgbe and stmmac still have some
of these issues, too.
> [*] Including fixes/changes in:
> - 3a5a883a8a663b930908cae4abe5ec913b9b2fd2
Ok, the issues you fixed here are concerning the tx_curr and tx_dirty
pointers. For now this is not needed in stmmac and sxgbe since the
tx completion handlers in both drivers are not lock-free like in
the via-rhine.c but are synchronized with xmit by means of the xmit_lock.
> - e1efa87241272104d6a12c8b9fcdc4f62634d447
Yep, a sync of the dma descriptors before the hardware gets ownership of the tx
tail
idx is missing in the stmmac, too.
> - 810f19bcb862f8889b27e0c9d9eceac9593925dd
> - e45af497950a89459a0c4b13ffd91e1729fffef4
> - a926592f5e4e900f3fa903298c4619a131e60963
I think we should use netif_tx_disable() instead of netif_stop_queue(), too, in
case of restart to avoid a possible schedule of the xmit function while we
restart.
So this is also part of the new patch.
Again the patch is only compile tested.
Regards,
Lino
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 95 +++
2 files changed, 63 insertions(+), 33 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index eab04ae..9c240d7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -131,6 +131,7 @@ struct stmmac_priv {
u32 rx_tail_addr;
u32 tx_tail_addr;
u32 mss;
+ struct work_struct tx_err_work;
#ifdef CONFIG_DEBUG_FS
struct dentry *dbgfs_dir;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3e40578..5762750 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1403,37 +1403,6 @@ static inline void stmmac_disable_dma_irq(struct
stmmac_priv *priv)
}
/**
- * stmmac_tx_err - to manage the tx error
- * @priv: driver private structure
- * Description: it cleans the descriptors and restarts the transmission
- * in case of transmission errors.
- */
-static void stmmac_tx_err(struct stmmac_priv *priv)
-{
- int i;
- netif_stop_queue(priv->dev);
-
- priv->hw->dma->stop_tx(priv->ioaddr);
- dma_free_tx_skbufs(priv);
- for (i = 0; i < DMA_TX_SIZE; i++)
- if (priv->extend_desc)
- priv->hw->desc->init_tx_desc(&priv->dma_etx[i].basic,
-priv->mode,
-(i == DMA_TX_SIZE - 1));
- else
- priv->hw->desc->init_tx_desc(&priv->dma_tx[i],
-priv->mode,
-(i == DMA_TX_SIZE - 1));
- priv->dirty_tx = 0;
- priv->cur_tx = 0;
- netdev_reset_queue(priv->dev);
- priv->hw->dma->start_tx(priv->ioaddr);
-
- priv->dev->stats.tx_errors++;
- netif_wake_queue(priv->dev);
-}
-
-/**
* stmmac_dma_interrupt - DMA ISR
* @priv: driver private s
Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
Hi,
A patch for this is already floating on the ML for a while now latest:
(ath9k: do not return early to fix rcu unlocking)
Hopefully Kalle will include it in one of his upcoming pull requests.
Greetings,
Tobias
On 18.12.2016 16:59, Paul E. McKenney wrote:
On Sun, Dec 18, 2016 at 02:52:48PM +0100, Gabriel C wrote:
Hello,
while testing kernel 4.9 I run into a weird issue with the ath9k driver.
I can boot the box in console mode and it stay up sometime but is not usable.
Looks to me like someone forgot an rcu_read_unlock() somewhere. Given that
the unmatched rcu_read_lock() appears in ath_tx_edma_tasklet(), perhaps
that is also where the missing rcu_read_unlock() is. And sure enough,
in the middle of this function we have the following:
fifo_list = &txq->txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
return;
}
This will of course return while still in an RCU read-side critical
section. The caller cannot tell the difference between a return here
and falling off the end of the function, so this is likely the bug.
Or one of the bugs, anyway. Copying the author and committer for
their thoughts.
Please try the patch at the end of this email.
Thanx, Paul
from dmesg :
===
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G I
---
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){..}, at: []
ath_tx_edma_tasklet+0x0/0x460 [ath9k]
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.9-fw1 #1
Hardware name: FUJITSU PRIMERGY TX200 S5
/D2709, BIOS 6.00 Rev. 1.14.2709 02/04/2013
88043ee03f38 812cf0f3 81a11540 0001
88043ee03f68 810b7865 81a55d58 88043efcedc0
88083cb1ca00 00d1 88043ee03f88 810dbfe8
Call Trace:
[] dump_stack+0x86/0xc3
[] lockdep_rcu_suspicious+0xc5/0x100
[] rcu_eqs_enter_common.constprop.62+0x128/0x130
[] rcu_irq_exit+0x38/0x70
[] irq_exit+0x74/0xd0
[] do_IRQ+0x71/0x130
[] common_interrupt+0x8c/0x8c
[] ? cpuidle_enter_state+0x156/0x220
[] cpuidle_enter+0x12/0x20
[] call_cpuidle+0x1e/0x40
[] cpu_startup_entry+0x11d/0x210
[] rest_init+0x12c/0x140
[] start_kernel+0x40f/0x41c
[] ? early_idt_handler_array+0x120/0x120
[] x86_64_start_reservations+0x2a/0x2c
[] x86_64_start_kernel+0xeb/0xf8
commit 5a16fed76936184a7ac22e466cf39bd8bb5ee65e
Author: Paul E. McKenney
Date: Sun Dec 18 07:49:00 2016 -0800
drivers/ath: Add missing rcu_read_unlock() to ath_tx_edma_tasklet()
Commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
added rcu_read_lock() and rcu_read_unlock() around the body of
ath_tx_edma_tasklet(), but failed to add the needed rcu_read_unlock()
before a "return" in the middle of this function. This commit therefore
adds the missing rcu_read_unlock().
Reported-by: Gabriel C
Signed-off-by: Paul E. McKenney
Cc: Felix Fietkau
Cc: Kalle Valo
Cc: QCA ath9k Development
Cc:
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 52bfbb988611..857d5ae09a1d 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2787,6 +2787,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
fifo_list = &txq->txq_fifo[txq->txq_tailidx];
if (list_empty(fifo_list)) {
ath_txq_unlock(sc, txq);
+ rcu_read_unlock();
return;
}
Re: [PATCH 2/5] dmaengine: Add support for custom data mapping
On Thu, Dec 15, 2016 at 03:25:52PM +0530, Abhishek Sahu wrote:
> The current DMA APIs only support SGL or data in generic format.
> The QCA BAM DMA engine data cannot be mapped with already
> available APIs due to following reasons.
>
> 1. The QCA BAM DMA engine uses custom flags which cannot be
>mapped with generic DMA engine flags.
> 2. Some peripheral driver like QCA QPIC NAND/LCD requires to
>set specific flags (Like NWD, EOT) for some of the descriptors
>in scatter gather list. The already available mapping APIs take
>flags parameter in API itself and there is no support for
>passing DMA specific flags for each SGL entry.
>
> Now this patch adds the support for making the DMA descriptor from
> custom data with new DMA mapping function prep_dma_custom_mapping.
> The peripheral driver will pass the custom data in this function and
> DMA engine driver will form the descriptor according to its own
> logic. In future, this API can be used by any other DMA engine
> drivers also which are unable to do DMA mapping with already
> available API’s.
>
> Signed-off-by: Abhishek Sahu
> ---
> include/linux/dmaengine.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index cc535a4..6324c1f 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -692,6 +692,8 @@ struct dma_filter {
> * be called after period_len bytes have been transferred.
> * @device_prep_interleaved_dma: Transfer expression in a generic way.
> * @device_prep_dma_imm_data: DMA's 8 byte immediate data to the dst address
> + * @device_prep_dma_custom_mapping: prepares a dma operation from dma driver
> + * specific custom data
> * @device_config: Pushes a new configuration to a channel, return 0 or an
> error
> * code
> * @device_pause: Pauses any transfer happening on a channel. Returns
> @@ -783,6 +785,9 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_imm_data)(
> struct dma_chan *chan, dma_addr_t dst, u64 data,
> unsigned long flags);
> + struct dma_async_tx_descriptor *(*device_prep_dma_custom_mapping)(
> + struct dma_chan *chan, void *data,
> + unsigned long flags);
This needs a discussion. Why do you need to add a new API for framework.
What are NWD and EOT flags, cna you details out the flags?
--
~Vinod
Re: ipc: BUG: sem_unlock unlocks non-locked lock
On Fri, 16 Dec 2016, Dmitry Vyukov wrote: [ BUG: bad unlock balance detected! ] 4.9.0+ #89 Not tainted Thanks for the report, I can reproduce the issue as of (which I obviously should have tested with lockdep): 370b262c896 (ipc/sem: avoid idr tree lookup for interrupted semop) I need to think more about it this evening, but I believe the issue to be the potentially bogus locknum in the unlock path, as we are calling sem_lock without updating the variable. I'll send a patch after more testing. This fixes it for me: diff --git a/ipc/sem.c b/ipc/sem.c index e08b94851922..fba6139e7208 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops, } rcu_read_lock(); - sem_lock(sma, sops, nsops); + sem_lock(sma, sops, nsops); if (!ipc_valid_object(&sma->sem_perm)) goto out_unlock_free; Thanks, Davidlohr
Re: ipc: BUG: sem_unlock unlocks non-locked lock
On Sun, 18 Dec 2016, Bueso wrote: On Fri, 16 Dec 2016, Dmitry Vyukov wrote: [ BUG: bad unlock balance detected! ] 4.9.0+ #89 Not tainted Thanks for the report, I can reproduce the issue as of (which I obviously should have tested with lockdep): 370b262c896 (ipc/sem: avoid idr tree lookup for interrupted semop) I need to think more about it this evening, but I believe the issue to be the potentially bogus locknum in the unlock path, as we are calling sem_lock without updating the variable. I'll send a patch after more testing. This fixes it for me: diff --git a/ipc/sem.c b/ipc/sem.c index e08b94851922..fba6139e7208 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops, } rcu_read_lock(); - sem_lock(sma, sops, nsops); + sem_lock(sma, sops, nsops); *sigh*, that would be: locknum = sem_lock(sma, sops, nsops);
Re: [BUG] kernel freeze, rcu_sched self-detected stall on CPU
On Sat, 17 Dec 2016, Johanna Abrahamsson wrote: I will try to investigate this further but as I have limited knowledge of RCU and how the kernel works with semaphores don't expect any miracles :) Please see if this helps: https://lkml.org/lkml/2016/12/18/79 Thanks, Davidlohr
Re: [PATCH 2/2] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically
On Sat 17-12-16 20:17:07, Tetsuo Handa wrote: [...] > I feel that allowing access to memory reserves based on __GFP_NOFAIL might not > make sense. My understanding is that actual I/O operation triggered by I/O > requests by filesystem code are processed by other threads. Even if we grant > access to memory reserves to GFP_NOFS | __GFP_NOFAIL allocations by fs code, > I think that it is possible that memory allocations by underlying bio code > fails to make a further progress unless memory reserves are granted as well. IO layer should rely on mempools to guarantee a forward progress. > Below is a typical trace which I observe under OOM lockuped situation (though > this trace is from an OOM stress test using XFS). > > > [ 1845.187246] MemAlloc: kworker/2:1(14498) flags=0x4208060 switches=323636 > seq=48 gfp=0x240(GFP_NOIO) order=0 delay=430400 uninterruptible > [ 1845.187248] kworker/2:1 D12712 14498 2 0x0080 > [ 1845.187251] Workqueue: events_freezable_power_ disk_events_workfn > [ 1845.187252] Call Trace: > [ 1845.187253] ? __schedule+0x23f/0xba0 > [ 1845.187254] schedule+0x38/0x90 > [ 1845.187255] schedule_timeout+0x205/0x4a0 > [ 1845.187256] ? del_timer_sync+0xd0/0xd0 > [ 1845.187257] schedule_timeout_uninterruptible+0x25/0x30 > [ 1845.187258] __alloc_pages_nodemask+0x1035/0x10e0 > [ 1845.187259] ? alloc_request_struct+0x14/0x20 > [ 1845.187261] alloc_pages_current+0x96/0x1b0 > [ 1845.187262] ? bio_alloc_bioset+0x20f/0x2e0 > [ 1845.187264] bio_copy_kern+0xc4/0x180 > [ 1845.187265] blk_rq_map_kern+0x6f/0x120 > [ 1845.187268] __scsi_execute.isra.23+0x12f/0x160 > [ 1845.187270] scsi_execute_req_flags+0x8f/0x100 > [ 1845.187271] sr_check_events+0xba/0x2b0 [sr_mod] > [ 1845.187274] cdrom_check_events+0x13/0x30 [cdrom] > [ 1845.187275] sr_block_check_events+0x25/0x30 [sr_mod] > [ 1845.187276] disk_check_events+0x5b/0x150 > [ 1845.187277] disk_events_workfn+0x17/0x20 > [ 1845.187278] process_one_work+0x1fc/0x750 > [ 1845.187279] ? process_one_work+0x167/0x750 > [ 1845.187279] worker_thread+0x126/0x4a0 > [ 1845.187280] kthread+0x10a/0x140 > [ 1845.187281] ? process_one_work+0x750/0x750 > [ 1845.187282] ? kthread_create_on_node+0x60/0x60 > [ 1845.187283] ret_from_fork+0x2a/0x40 > > > I think that this GFP_NOIO allocation request needs to consume more memory > reserves > than GFP_NOFS allocation request to make progress. AFAIU, this is an allocation path which doesn't block a forward progress on a regular IO. It is merely a check whether there is a new medium in the CDROM (aka regular polling of the device). I really fail to see any reason why this one should get any access to memory reserves at all. I actually do not see any reason why it should be NOIO in the first place but I am not familiar with this code much so there might be some reasons for that. The fact that it might stall under a heavy memory pressure is sad but who actually cares? > Do we want to add __GFP_NOFAIL to this GFP_NOIO allocation request > in order to allow access to memory reserves as well as GFP_NOFS | > __GFP_NOFAIL allocation request? Why? -- Michal Hocko SUSE Labs
Re: [PATCH v6 4/5] PM / runtime: Use device links
On Sun, Dec 18, 2016 at 04:53:26PM +0100, Rafael J. Wysocki wrote:
> On Sun, Dec 18, 2016 at 3:01 PM, Lukas Wunner wrote:
> > Hi Rafael,
> >
> > spotted what looks like a bug in the device links runtime PM code:
> >
> > When resuming a device, __rpm_callback() calls rpm_get_suppliers(dev):
> >
> >> + retval = rpm_get_suppliers(dev);
> >> + if (retval)
> >> + goto fail;
> >
> >
> > This will walk the list of suppliers and call pm_runtime_get_sync()
> > for each of them:
> >
> >> +static int rpm_get_suppliers(struct device *dev)
> >> +{
> >> + struct device_link *link;
> >> +
> >> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node) {
> >> + int retval;
> > [...]
> >> + retval = pm_runtime_get_sync(link->supplier);
> >> + if (retval < 0) {
> >> + pm_runtime_put_noidle(link->supplier);
> >> + return retval;
> >
> >
> > If pm_runtime_get_sync() failed, e.g. because runtime PM is disabled
> > on a supplier, the function will put the reference of the failed
> > supplier and return.
> >
> > Back in __rpm_callback() we jump to the fail mark, where we call
> > rpm_put_suppliers().
> >
> >> + fail:
> >> + rpm_put_suppliers(dev);
> >> +
> >> + device_links_read_unlock(idx);
> >
> >
> > This walks the list of suppliers and releases a ref for each of them:
> >
> >> +static void rpm_put_suppliers(struct device *dev)
> >> +{
> >> + struct device_link *link;
> >> +
> >> + list_for_each_entry_rcu(link, &dev->links.suppliers, c_node)
> >> + if (link->rpm_active &&
> >> + READ_ONCE(link->status) != DL_STATE_SUPPLIER_UNBIND) {
> >> + pm_runtime_put(link->supplier);
> >> + link->rpm_active = false;
> >> + }
> >> +}
> >
> >
> > This looks wrong: We've already put a ref on the failed supplier, so here
> > we're putting another one.
>
> Are we? I would think link->rpm_active would be false for the failed
> one, wouldn't it?
Ah, so link->rpm_active means the consumer is holding a ref on the supplier.
Missed that, sorry for the false alarm and thanks for the clarification.
Lukas
Re: [PATCH 3/3] iio: cros_ec_activity: add ChromeOS EC Activity Sensors
Hi Gwendal, [auto build test ERROR on iio/togreg] [also build test ERROR on next-20161216] [cannot apply to v4.9] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Thierry-Escande/mfd-cros_ec-Add-activity-motion-sense-definitions/20161206-002239 base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg config: um-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: # save the attached .config to linux build tree make ARCH=um All errors (new ones prefixed by >>): ERROR: "devm_gpiod_get_optional" [net/rfkill/rfkill-gpio.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/regulator/tps62360-regulator.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/regulator/pwm-regulator.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/regulator/max8973-regulator.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/regulator/max8952.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/regulator/lp872x.ko] undefined! ERROR: "devm_gpio_request" [drivers/pps/clients/pps-gpio.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/power/supply/sbs-battery.ko] undefined! ERROR: "devm_gpio_request" [drivers/power/supply/max8903_charger.ko] undefined! ERROR: "devm_gpiod_get_index" [drivers/power/supply/bq25890_charger.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24735-charger.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/power/supply/bq24257_charger.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/nfc/st21nfca/st21nfca_i2c.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/nfc/st-nci/st-nci_i2c.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/nfc/nxp-nci/nxp-nci_i2c.ko] undefined! ERROR: "devm_gpio_free" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/nfc/nfcmrvl/nfcmrvl.ko] undefined! ERROR: "devm_gpiod_get" [drivers/nfc/fdp/fdp_i2c.ko] undefined! ERROR: "devm_gpio_request" [drivers/net/phy/mdio-gpio.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/net/phy/at803x.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/net/dsa/mv88e6xxx/mv88e6xxx.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/leds/leds-lt3593.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/leds/leds-lp8860.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/leds/leds-lp55xx-common.ko] undefined! ERROR: "devm_gpiod_get" [drivers/leds/leds-ktd2692.ko] undefined! ERROR: "devm_get_gpiod_from_child" [drivers/leds/leds-gpio.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/leds/leds-gpio.ko] undefined! ERROR: "devm_gpiod_get_index" [drivers/iio/proximity/sx9500.ko] undefined! ERROR: "devm_gpiod_get_index" [drivers/iio/pressure/hp03.ko] undefined! ERROR: "devm_gpiod_get" [drivers/iio/pressure/bmp280.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/iio/magnetometer/ak8975.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/iio/dac/ad5592r-base.ko] undefined! >> ERROR: "cros_ec_cmd_xfer_status" >> [drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.ko] undefined! ERROR: "devm_gpiod_get_index" [drivers/iio/accel/mma9551.ko] undefined! ERROR: "devm_gpiod_get_optional" [drivers/i2c/muxes/i2c-mux-pca954x.ko] undefined! ERROR: "devm_gpiod_get" [drivers/extcon/extcon-usb-gpio.ko] undefined! ERROR: "devm_gpiod_get" [drivers/extcon/extcon-max3355.ko] undefined! ERROR: "devm_gpio_request_one" [drivers/extcon/extcon-gpio.ko] undefined! ERROR: "devm_gpiod_get" [drivers/bluetooth/hci_uart.ko] undefined! ERROR: "devm_ioremap_resource" [drivers/auxdisplay/img-ascii-lcd.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH 4/4] x86/microcode/AMD: Use native_cpuid() in load_ucode_amd_bsp()
From: Boris Ostrovsky
When CONFIG_PARAVIRT is selected, cpuid() becomes a call. Since
for 32-bit kernels load_ucode_amd_bsp() is executed before paging
is enabled the call cannot be completed (as kernel virtual addresses
are not reachable yet).
Use native_cpuid() instead which is an asm wrapper for the CPUID
instruction.
Signed-off-by: Boris Ostrovsky
Cc: Jürgen Gross
Cc: x86-ml
Link:
http://lkml.kernel.org/r/1481906392-3847-1-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index dc80acfa922d..6a31e2691f3a 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -301,6 +301,7 @@ static bool get_builtin_microcode(struct cpio_data *cp,
unsigned int family)
void __init load_ucode_amd_bsp(unsigned int family)
{
struct ucode_cpu_info *uci;
+ u32 eax, ebx, ecx, edx;
struct cpio_data cp;
const char *path;
bool use_pa;
@@ -322,7 +323,10 @@ void __init load_ucode_amd_bsp(unsigned int family)
return;
/* Get BSP's CPUID.EAX(1), needed in load_microcode_amd() */
- uci->cpu_sig.sig = cpuid_eax(1);
+ eax = 1;
+ ecx = 0;
+ native_cpuid(&eax, &ebx, &ecx, &edx);
+ uci->cpu_sig.sig = eax;
apply_microcode_early_amd(cp.data, cp.size, true, NULL);
}
--
2.11.0
[PATCH 0/4] x86/microcode: Some 4.10 fixes
From: Borislav Petkov Hi, here are 4 fixes for tip/urgent which address issues Boris and Jürgen reported while testing latest upstream on xen. As a result, let's just not load it at all when running on a hypervisor and be done with the d*icking around. Please apply, thanks. Boris Ostrovsky (1): x86/microcode/AMD: Use native_cpuid() in load_ucode_amd_bsp() Borislav Petkov (3): x86/microcode/AMD: Make find_proper_container() sane again x86/microcode/AMD: Sanitize apply_microcode_early_amd() x86/microcode/AMD: Do not load when running on a hypervisor arch/x86/kernel/cpu/microcode/amd.c | 56 +--- arch/x86/kernel/cpu/microcode/core.c | 28 -- 2 files changed, 52 insertions(+), 32 deletions(-) -- 2.11.0
[PATCH 2/4] x86/microcode/AMD: Sanitize apply_microcode_early_amd()
From: Borislav Petkov
Make it simply return bool to denote whether it found a container or not
and return the pointer to the container and its size in the handed-in
container pointer instead, as returning a struct was just silly.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 31f4e3f94d46..dc80acfa922d 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -216,17 +216,18 @@ static int __apply_microcode_amd(struct microcode_amd
*mc_amd)
* and on 32-bit during save_microcode_in_initrd_amd() -- we can call
* load_microcode_amd() to save equivalent cpu table and microcode patches in
* kernel heap memory.
+ *
+ * Returns true if container found (sets @ret_cont), false otherwise.
*/
-static struct container
-apply_microcode_early_amd(void *ucode, size_t size, bool save_patch)
+static bool apply_microcode_early_amd(void *ucode, size_t size, bool
save_patch,
+ struct container *ret_cont)
{
- struct container ret = { NULL, 0 };
u8 (*patch)[PATCH_MAX_SIZE];
+ u32 rev, *header, *new_rev;
+ struct container ret;
int offset, left;
- u32 rev, *header;
- u8 *data;
u16 eq_id = 0;
- u32 *new_rev;
+ u8 *data;
#ifdef CONFIG_X86_32
new_rev = (u32 *)__pa_nodebug(&ucode_new_rev);
@@ -237,11 +238,11 @@ apply_microcode_early_amd(void *ucode, size_t size, bool
save_patch)
#endif
if (check_current_patch_level(&rev, true))
- return (struct container){ NULL, 0 };
+ return false;
eq_id = find_proper_container(ucode, size, &ret);
if (!eq_id)
- return (struct container){ NULL, 0 };
+ return false;
this_equiv_id = eq_id;
header = (u32 *)ret.data;
@@ -275,7 +276,11 @@ apply_microcode_early_amd(void *ucode, size_t size, bool
save_patch)
data += offset;
left -= offset;
}
- return ret;
+
+ if (ret_cont)
+ *ret_cont = ret;
+
+ return true;
}
static bool get_builtin_microcode(struct cpio_data *cp, unsigned int family)
@@ -319,7 +324,7 @@ void __init load_ucode_amd_bsp(unsigned int family)
/* Get BSP's CPUID.EAX(1), needed in load_microcode_amd() */
uci->cpu_sig.sig = cpuid_eax(1);
- apply_microcode_early_amd(cp.data, cp.size, true);
+ apply_microcode_early_amd(cp.data, cp.size, true, NULL);
}
#ifdef CONFIG_X86_32
@@ -351,7 +356,7 @@ void load_ucode_amd_ap(unsigned int family)
* This would set amd_ucode_patch above so that the following APs can
* use it directly instead of going down this path again.
*/
- apply_microcode_early_amd(cp.data, cp.size, true);
+ apply_microcode_early_amd(cp.data, cp.size, true, NULL);
}
#else
void load_ucode_amd_ap(unsigned int family)
@@ -389,8 +394,7 @@ void load_ucode_amd_ap(unsigned int family)
}
}
- cont = apply_microcode_early_amd(cp.data, cp.size, false);
- if (!(cont.data && cont.size)) {
+ if (!apply_microcode_early_amd(cp.data, cp.size, false, &cont))
{
cont.size = -1;
return;
}
--
2.11.0
[PATCH 1/4] x86/microcode/AMD: Make find_proper_container() sane again
From: Borislav Petkov
Fixup signature and retvals, return the container struct through the
passed in pointer, not as a function return value.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/microcode/amd.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/amd.c
b/arch/x86/kernel/cpu/microcode/amd.c
index 6f353bdb3a25..31f4e3f94d46 100644
--- a/arch/x86/kernel/cpu/microcode/amd.c
+++ b/arch/x86/kernel/cpu/microcode/amd.c
@@ -116,10 +116,11 @@ static inline u16 find_equiv_id(struct equiv_cpu_entry
*equiv_cpu_table,
/*
* This scans the ucode blob for the proper container as we can have multiple
- * containers glued together.
+ * containers glued together. Returns the equivalence ID from the equivalence
+ * table or 0 if none found.
*/
-static struct container
-find_proper_container(u8 *ucode, size_t size, u16 *ret_id)
+static u16
+find_proper_container(u8 *ucode, size_t size, struct container *ret_cont)
{
struct container ret = { NULL, 0 };
u32 eax, ebx, ecx, edx;
@@ -138,7 +139,7 @@ find_proper_container(u8 *ucode, size_t size, u16 *ret_id)
if (header[0] != UCODE_MAGIC ||
header[1] != UCODE_EQUIV_CPU_TABLE_TYPE || /* type */
header[2] == 0)/* size */
- return ret;
+ return eq_id;
eax = 0x0001;
ecx = 0;
@@ -163,8 +164,9 @@ find_proper_container(u8 *ucode, size_t size, u16 *ret_id)
* ucode update loop below
*/
left = ret.size - offset;
- *ret_id = eq_id;
- return ret;
+
+ *ret_cont = ret;
+ return eq_id;
}
/*
@@ -189,7 +191,7 @@ find_proper_container(u8 *ucode, size_t size, u16 *ret_id)
ucode = data;
}
- return ret;
+ return eq_id;
}
static int __apply_microcode_amd(struct microcode_amd *mc_amd)
@@ -237,7 +239,7 @@ apply_microcode_early_amd(void *ucode, size_t size, bool
save_patch)
if (check_current_patch_level(&rev, true))
return (struct container){ NULL, 0 };
- ret = find_proper_container(ucode, size, &eq_id);
+ eq_id = find_proper_container(ucode, size, &ret);
if (!eq_id)
return (struct container){ NULL, 0 };
@@ -443,7 +445,7 @@ int __init save_microcode_in_initrd_amd(unsigned int fam)
return -EINVAL;
}
- cont = find_proper_container(cp.data, cp.size, &eq_id);
+ eq_id = find_proper_container(cp.data, cp.size, &cont);
if (!eq_id) {
cont.size = -1;
return -EINVAL;
--
2.11.0
[PATCH 3/4] x86/microcode/AMD: Do not load when running on a hypervisor
From: Borislav Petkov
Doing so is completely void of sense for multiple reasons so prevent
it. Set dis_ucode_ldr to true and thus disable the microcode loader by
default to address xen pv guests which execute the AP path but not the
BSP path.
By having it turned off by default, the APs won't run into the loader
either.
Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the
xen pv one. That one gets the aforementioned "fix".
Also, improve the detection method by caching the final decision whether
to continue loading in dis_ucode_ldr and do it once on the BSP. The APs
then simply test that value.
Signed-off-by: Borislav Petkov
Tested-by: Juergen Gross
Acked-by: Juergen Gross
Tested-by: Boris Ostrovsky
---
arch/x86/kernel/cpu/microcode/core.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/core.c
b/arch/x86/kernel/cpu/microcode/core.c
index 6996413c78c3..c4bb2f7169f6 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -44,7 +44,7 @@
#define DRIVER_VERSION "2.2"
static struct microcode_ops*microcode_ops;
-static bool dis_ucode_ldr;
+static bool dis_ucode_ldr = true;
LIST_HEAD(microcode_cache);
@@ -76,6 +76,7 @@ struct cpu_info_ctx {
static bool __init check_loader_disabled_bsp(void)
{
static const char *__dis_opt_str = "dis_ucode_ldr";
+ u32 a, b, c, d;
#ifdef CONFIG_X86_32
const char *cmdline = (const char *)__pa_nodebug(boot_command_line);
@@ -88,8 +89,23 @@ static bool __init check_loader_disabled_bsp(void)
bool *res = &dis_ucode_ldr;
#endif
- if (cmdline_find_option_bool(cmdline, option))
- *res = true;
+ if (!have_cpuid_p())
+ return *res;
+
+ a = 1;
+ c = 0;
+ native_cpuid(&a, &b, &c, &d);
+
+ /*
+* CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
+* completely accurate as xen pv guests don't see that CPUID bit set but
+* that's good enough as they don't land on the BSP path anyway.
+*/
+ if (c & BIT(31))
+ return *res;
+
+ if (cmdline_find_option_bool(cmdline, option) <= 0)
+ *res = false;
return *res;
}
@@ -121,9 +137,6 @@ void __init load_ucode_bsp(void)
if (check_loader_disabled_bsp())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_cpuid_vendor();
family = x86_cpuid_family();
@@ -157,9 +170,6 @@ void load_ucode_ap(void)
if (check_loader_disabled_ap())
return;
- if (!have_cpuid_p())
- return;
-
vendor = x86_cpuid_vendor();
family = x86_cpuid_family();
--
2.11.0
[PATCH] staging: emxx_udc: Fix CamelCase styling issue
Converts from CamelCase to the recommended style.
Signed-off-by: Afonso Bordado
---
drivers/staging/emxx_udc/emxx_udc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/emxx_udc/emxx_udc.c
b/drivers/staging/emxx_udc/emxx_udc.c
index 3f42fa8..cf5cdd8 100644
--- a/drivers/staging/emxx_udc/emxx_udc.c
+++ b/drivers/staging/emxx_udc/emxx_udc.c
@@ -553,25 +553,25 @@ static void _nbu2ss_dma_unmap_single(
/*-*/
/* Endpoint 0 OUT Transfer (PIO) */
-static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
+static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
{
u32 i;
int nret = 0;
- u32 iWordLength = 0;
- union usb_reg_access *pBuf32 = (union usb_reg_access *)pBuf;
+ u32 i_word_length = 0;
+ union usb_reg_access *p_buf32 = (union usb_reg_access *)p_buf;
/**/
/* Read Length */
- iWordLength = length / sizeof(u32);
+ i_word_length = length / sizeof(u32);
/**/
/* PIO Read */
- if (iWordLength) {
- for (i = 0; i < iWordLength; i++) {
- pBuf32->dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
- pBuf32++;
+ if (i_word_length) {
+ for (i = 0; i < i_word_length; i++) {
+ p_buf32->dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
+ p_buf32++;
}
- nret = iWordLength * sizeof(u32);
+ nret = i_word_length * sizeof(u32);
}
return nret;
--
2.9.3
Re: [RFC 1/1] MicroSemi Switchtec management interface driver
Hi Greg,
Thanks for the quick review!
On 18/12/16 12:51 AM, Greg Kroah-Hartman wrote:
On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote:
+struct switchtec_dev {
+ struct pci_dev *pdev;
+ struct msix_entry *msix;
+ struct device *dev;
+ struct kref kref;
Why do you have a pointer to a device, yet a kref as well? Just have
this structure embed a 'struct device' in itself, like you did for a
kref, and you will be fine. Otherwise you are dealing with two
different sets of reference counting here, for no good reason.
Ok, understood. I had referenced the device dax driver which did it this
way in 4.8 but looks like it was changed to the way you suggest in 4.9.
+#define stdev_pdev(stdev) ((stdev)->pdev)
+#define stdev_pdev_dev(stdev) (&stdev_pdev(stdev)->dev)
+#define stdev_name(stdev) pci_name(stdev_pdev(stdev))
+#define stdev_dev(stdev) ((stdev)->dev)
Ick, just open code these please. That's a huge hint your use of the
driver model is not correct :)
Ok, will do. For reference, I was copying
drivers/ntb/hw/intel/ntb_hw_intel.h
which does a similar thing.
Logan
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
Hi! > > - e1efa87241272104d6a12c8b9fcdc4f62634d447 > > Yep, a sync of the dma descriptors before the hardware gets ownership of the > tx tail > idx is missing in the stmmac, too. Thanks for the hint. Actually, the driver uses smp_wmb() which is completely crazy, and probably misses rmb() in clean_tx, too. Anyway, I did not notice there are dma_ variants, too... we clearly need them. Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] Staging:comedi:cb_pcidas64=>Fixed check patch warnings
On Sun, 2016-12-18 at 15:43 +0530, devendra sharma wrote:
> Fixed check patch warnings about multiple line dereferencing
[].
> diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c
> b/drivers/staging/comedi/drivers/cb_pcidas64.c
[]
> @@ -2476,18 +2475,15 @@ static int setup_channel_queue(struct comedi_device
> *dev,
> for (i = 0; i < cmd->chanlist_len; i++) {
> bits = 0;
> /* set channel */
> - bits |= adc_chan_bits(CR_CHAN(cmd->
> - chanlist[i]));
> + bits |= adc_chan_bits(
> + CR_CHAN(cmd->chanlist[i]));
> /* set gain */
> bits |= ai_range_bits_6xxx(dev,
> -CR_RANGE(cmd->
> - chanlist
> - [i]));
> +CR_RANGE(cmd->chanlist[i]));
> /* set single-ended / differential */
> bits |= se_diff_bit_6xxx(dev,
> - CR_AREF(cmd->
> - chanlist[i]) ==
> - AREF_DIFF);
> + CR_AREF(cmd->chanlist[i]) ==
> + AREF_DIFF);
> if (CR_AREF(cmd->chanlist[i]) == AREF_COMMON)
> bits |= ADC_COMMON_BIT;
> /* mark end of queue */
This would be better handled by using a temporary like:
for (i = 0; i < cmd->chanlist_len; i++) {
list = cmd->chanlist[i];
/* set channel */
bits |= adc_chan_bits(CR_CHAN(list));
/* set gain */
bits |= ai_range_bmts_6xxx(dev, CR_RANGE(list));
/* set single-ended / differential */
bits |= se_diff_bit_6xxx(dev,
CR_AREF(list) ==
AREF_DIFF);
if (CR_AREF(list) == AREF_COMMON)
bits |= ADC_COMMON_BIT;
Or moving the indented block into a separate function.
Re: [PATCH] staging: emxx_udc: Fix CamelCase styling issue
On Sun, 2016-12-18 at 16:46 +, Afonso Bordado wrote:
> Converts from CamelCase to the recommended style.
>
> Signed-off-by: Afonso Bordado
> ---
> drivers/staging/emxx_udc/emxx_udc.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/staging/emxx_udc/emxx_udc.c
> b/drivers/staging/emxx_udc/emxx_udc.c
> index 3f42fa8..cf5cdd8 100644
> --- a/drivers/staging/emxx_udc/emxx_udc.c
> +++ b/drivers/staging/emxx_udc/emxx_udc.c
> @@ -553,25 +553,25 @@ static void _nbu2ss_dma_unmap_single(
>
> /*-*/
> /* Endpoint 0 OUT Transfer (PIO) */
> -static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *pBuf, u32 length)
> +static int EP0_out_PIO(struct nbu2ss_udc *udc, u8 *p_buf, u32 length)
> {
> u32 i;
> int nret = 0;
> - u32 iWordLength = 0;
> - union usb_reg_access *pBuf32 = (union usb_reg_access *)pBuf;
> + u32 i_word_length = 0;
> + union usb_reg_access *p_buf32 = (union usb_reg_access *)p_buf;
>
> /**/
> /* Read Length */
> - iWordLength = length / sizeof(u32);
> + i_word_length = length / sizeof(u32);
>
> /**/
> /* PIO Read */
> - if (iWordLength) {
> - for (i = 0; i < iWordLength; i++) {
> - pBuf32->dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> - pBuf32++;
> + if (i_word_length) {
> + for (i = 0; i < i_word_length; i++) {
> + p_buf32->dw = _nbu2ss_readl(&udc->p_regs->EP0_READ);
> + p_buf32++;
> }
> - nret = iWordLength * sizeof(u32);
> + nret = i_word_length * sizeof(u32);
> }
>
> return nret;
Instead of merely converting Hungarian CamelCase to lowercase
with underscores where word transitions occurred, try reading
the code and making sense of what it does to perhaps find a
better variable name instead. Maybe eliminate the variable
altogether.
iWordLength could be reads or numreads
btw: what happens if length is not a multiple of sizeof(u32)?
nret is more commonly ret
p_buf is also not common linux naming, buf is more common.
Re: [PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c
On 12/18/2016 01:46 AM, Greg KH wrote: On Sat, Dec 17, 2016 at 08:42:53PM -0600, Scott Matheina wrote: Signed-off-by: Scott Matheina I can't take patches without any changelog text :( Yah. Forgot to add the description. Added for v2. --- drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c index a6e3af7..4e371ed 100644 --- a/drivers/staging/fbtft/fb_agm1264k-fl.c +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c @@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...) va_end(args); fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, - par->info->device, u8, buf, len, "%s: ", __func__); - } + par->info->device, u8, buf, len, + "%s: ", __func__); +} I don't think you did this correctly, do you? I looked at this, and made a change to the line break, but if you're talking about the code itself then I'll have to dig into the books to figure that out. Starting small and learn from reading the code and making some small changes while I figure it out.
[PATCH v2] fix code alignment with open parenthesis
These changes where identified by checkpatch.pl as needed changes to
align the code with the linux development coding style. The several
lines of text where aligned with the precending parenthesis.
Signed-off-by: Scott Matheina
Changes to be committed:
modified: drivers/staging/fbtft/fb_agm1264k-fl.c
---
drivers/staging/fbtft/fb_agm1264k-fl.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index a6e3af7..4ee76db 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -185,9 +185,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len,
...)
buf[i] = (u8)va_arg(args, unsigned int);
va_end(args);
- fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
- par->info->device, u8, buf, len, "%s: ", __func__);
- }
+ fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, par->info->device,
+ u8, buf, len, "%s: ", __func__);
+}
va_start(args, len);
@@ -246,7 +246,7 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
ys, int xe, int ye)
static void
construct_line_bitmap(struct fbtft_par *par, u8 *dest, signed short *src,
- int xs, int xe, int y)
+ int xs, int xe, int y)
{
int x, i;
@@ -361,7 +361,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
/* left half of display */
if (addr_win.xs < par->info->var.xres / 2) {
construct_line_bitmap(par, buf, convert_buf,
- addr_win.xs, par->info->var.xres / 2, y);
+ addr_win.xs,
+ par->info->var.xres / 2, y);
len = par->info->var.xres / 2 - addr_win.xs;
@@ -382,8 +383,9 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
/* right half of display */
if (addr_win.xe >= par->info->var.xres / 2) {
construct_line_bitmap(par, buf,
- convert_buf, par->info->var.xres / 2,
- addr_win.xe + 1, y);
+ convert_buf,
+ par->info->var.xres / 2,
+ addr_win.xe + 1, y);
len = addr_win.xe + 1 - par->info->var.xres / 2;
@@ -413,7 +415,7 @@ static int write_vmem(struct fbtft_par *par, size_t offset,
size_t len)
static int write(struct fbtft_par *par, void *buf, size_t len)
{
fbtft_par_dbg_hex(DEBUG_WRITE, par, par->info->device, u8, buf, len,
- "%s(len=%d): ", __func__, len);
+ "%s(len=%d): ", __func__, len);
gpio_set_value(par->RW, 0); /* set write mode */
--
2.7.4
Re: [PATCH v6] soc: qcom: Add SoC info driver
On 12/17/2016 6:56 AM, Stephen Boyd wrote:
> On 12/15, Imran Khan wrote:
>> On 12/14/2016 5:56 AM, Stephen Boyd wrote:
>>> On 12/12, Imran Khan wrote:
The SoC info driver provides information such as Chip ID,
Chip family, serial number and other such details about
Qualcomm SoCs.
>>>
>>> Yes but why do we care?
>>>
>>
>> We intend to expose some standard SoC attributes (like soc-id) of
>> QCOM SoCs to user space, so that if needed the user space utilities
>> (like antutu) can query such information using sysfs interface.
>> A further example can be a user space script (say Android's init.rc)
>> which reads soc-id and does some gpio settings based on the soc-id.
>
> Please include such information into the commit text.
>
Sure. I will.
>>
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index 18ec52f..c598cac 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -85,6 +85,9 @@
/* Max number of processors/hosts in a system */
#define SMEM_HOST_COUNT 9
+
+extern void qcom_socinfo_init(struct platform_device *pdev);
>>>
>>> We can't put this into a header file?
>>>
>>
>> We can. In fact earlier I had put it in smem.h but since smem.h is public
>> API for smem I removed it from there. As it was only a single function
>> I used this extern declaration. Please let me know if it is acceptable.
>> If it is not acceptable I will create a socinfo.h and will put this
>> declaration
>> there.
>
> I'm not sure we care about public vs. non-public APIs
> intermingled in the same file. Did anyone ask for it to be moved
> out of the header file? smem.h seems like a fine place to put.
>
I had discussed this with Bjorn and it was recommended to keep it out of
smem.h. If needed I can move it back there.
>>
>>
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
new file mode 100644
index 000..57e23dfc
--- /dev/null
+++ b/drivers/soc/qcom/socinfo.c
+
+/* Hardware platform types */
+static const char *const hw_platform[] = {
+ [0] = "Unknown",
+ [1] = "Surf",
+ [2] = "FFA",
+ [3] = "Fluid",
+ [4] = "SVLTE_FFA",
+ [5] = "SLVTE_SURF",
+ [7] = "MDM_MTP_NO_DISPLAY",
+ [8] = "MTP",
+ [9] = "Liquid",
+ [10] = "Dragon",
+ [11] = "QRD",
+ [13] = "HRD",
+ [14] = "DTV",
+ [21] = "RCM",
+ [23] = "STP",
+ [24] = "SBC",
+};
>>>
>>> These only make sense on qcom platforms. Other boards can reuse
>>> the numbers here and have their own names for the platform field,
>>> so it doesn't seem like a good idea to do this in the kernel.
>>>
>>
>> Sorry could not understand this. Do you mean that we should only expose
>> the information that we can via generic soc_device_attribute.
>> This object is being used for hw_platform attribute which we are
>> explicitly creating in sysfs, so it should not conflict with other's
>> implementation.
>> Or do you mean to just show the numbers and avoid the strings.
>> I am using strings as I think in any case they will be more
>> informative and also there are not many types/subtypes in any case.
>> May be we can keep only those types/subtypes that are more frequent.
>>
>> I may be completely wrong in understanding the comment here so could
>> you kindly elaborate this a bit.
>
> I mean that the number 8 for example could mean MTP on qcom
> platforms but to an ODM that isn't qcom (i.e. some phone
> manufacturer) the number 8 could mean "wonderbolt 345". We really
> have no way to control this number as it's completely arbitrary
> what it means.
>
Yes. The numbers used here can have different meaning for different ODMs.
But these attributes (hw_patform type/subtype etc.) are outside the
generic soc_device_attribute so I think the interpretation of these numbers
can very well be ODM specific. We can try to keep only those types here that
are relevant for newer platforms but we intend to keep these attributes
nonetheless.
+
+static const char *const qrd_hw_platform_subtype[] = {
+ [0] = "QRD",
+ [1] = "SKUAA",
+ [2] = "SKUF",
+ [3] = "SKUAB",
+ [5] = "SKUG",
+ [6] = "INVALID",
+};
+
+static const char *const hw_platform_subtype[] = {
+ "Unknown", "charm", "strange", "strange_2a", "Invalid",
+};
>>>
>>> Same point here. Seems impossible to maintain this so please get
>>> rid of it and just output raw numbers if anything.
>
> And here the subtype becomes extremely complicated to parse.
> charm, strange, etc. are really old platform subtypes that I
> don't believe are used anymore but have stayed around in the code
> for unknown reasons. The subtype field is very large and is
> purely qcom specific.
>
Again we can keep here only relevant subtypes.
>>>
+
+static const char *const pmic_model[] = {
+ [0] = "Unknown PMIC model",
+ [13] =
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
Hi! > > - e1efa87241272104d6a12c8b9fcdc4f62634d447 > > Yep, a sync of the dma descriptors before the hardware gets ownership of the > tx tail > idx is missing in the stmmac, too. I can reproduce failure with 4.4 fairly easily. I tried with dma_ variant of barriers, and it failed, too [ 1018.410012] stmmac: early irq [ 1023.939702] fpga_cmd_read:wait_event timed out! [ 1033.128692] [ cut here ] [ 1033.133329] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x264/0x284() [ 1033.141748] NETDEV WATCHDOG: eth0 (socfpga-dwmac): transmit queue 0 timed out [ 1033.148861] Modules linked in: Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: ipc: BUG: sem_unlock unlocks non-locked lock
On 12/18/2016 05:29 PM, Davidlohr Bueso wrote: On Sun, 18 Dec 2016, Bueso wrote: On Fri, 16 Dec 2016, Dmitry Vyukov wrote: [ BUG: bad unlock balance detected! ] 4.9.0+ #89 Not tainted Thanks for the report, I can reproduce the issue as of (which I obviously should have tested with lockdep): 370b262c896 (ipc/sem: avoid idr tree lookup for interrupted semop) I need to think more about it this evening, but I believe the issue to be the potentially bogus locknum in the unlock path, as we are calling sem_lock without updating the variable. I'll send a patch after more testing. This fixes it for me: diff --git a/ipc/sem.c b/ipc/sem.c index e08b94851922..fba6139e7208 100644 --- a/ipc/sem.c +++ b/ipc/sem.c @@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf __user *, tsops, } rcu_read_lock(); -sem_lock(sma, sops, nsops); +sem_lock(sma, sops, nsops); *sigh*, that would be: locknum = sem_lock(sma, sops, nsops); Yes, I can confirm that this fixes the issue. Reproducing is simple: - task A: single semop semop(), sleeps - task B: multi semop semop(), sleeps - task A woken up by signal/timeout I'll send a patch. -- Manfred
[PATCH] ipc/sem.c: fix semop()/semop() locking failure
Based on the syzcaller test case from dvyukov:
https://gist.githubusercontent.com/dvyukov/d0e5efefe4d7d6daed829f5c3ca26a40/raw/08d0a261fe3c987bed04fbf267e08ba04bd533ea/gistfile1.txt
The slow (i.e.: failure to acquire) syscall exit from semtimedop()
incorrectly assumed that the the same lock is acquired as it was
at the initial syscall entry.
This is wrong:
- thread A: single semop semop(), sleeps
- thread B: multi semop semop(), sleeps
- thread A: woken up by signal/timeout
With this sequence, the initial sem_lock() call locks the
per-semaphore spinlock, the call at the syscall return locks
the global spinlock.
The fix is trivial: Use the return value from sem_lock.
Reported-by: dvyu...@google.com
Signed-off-by: Manfred Spraul
Fixes: 370b262c896e ("ipc/sem: avoid idr tree lookup for interrupted semop")
Cc: d...@stgolabs.net
---
ipc/sem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index e08b948..3ec5742 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -1977,7 +1977,7 @@ SYSCALL_DEFINE4(semtimedop, int, semid, struct sembuf
__user *, tsops,
}
rcu_read_lock();
- sem_lock(sma, sops, nsops);
+ locknum = sem_lock(sma, sops, nsops);
if (!ipc_valid_object(&sma->sem_perm))
goto out_unlock_free;
--
2.7.4
[PATCH] vfs: return EOPNOTSUPP when ioctl_fsthaw() is not supported
An attempt to freeze a filesystem that does not support such operation is reported as EOPNOTSUPP to user. Running unfreeze to the same filesystem returns EINVAL. Later is a little misleading, users can mix that message with return value from unfreezing when filesystem is not frozen. Signed-off-by: Sami Kerola --- fs/ioctl.c | 4 1 file changed, 4 insertions(+) diff --git a/fs/ioctl.c b/fs/ioctl.c index cb9b02940805..1d6372ef4008 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -566,6 +566,10 @@ static int ioctl_fsthaw(struct file *filp) if (!capable(CAP_SYS_ADMIN)) return -EPERM; + /* If filesystem doesn't support thaw feature, return. */ + if (!sb->s_op->unfreeze_fs) + return -EOPNOTSUPP; + /* Thaw */ if (sb->s_op->thaw_super) return sb->s_op->thaw_super(sb); -- 2.11.0
Re: [PATCH v10 3/3] fpga: Add support for Lattice iCE40 FPGAs
Hi Joel,
On 12/18/2016 07:33 AM, Joel Holdsworth wrote:
> This patch adds support to the FPGA manager for configuring the SRAM of
> iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> UltraPlus devices, through slave SPI.
>
> Signed-off-by: Joel Holdsworth
> Reviewed-by: Marek Vasut
> Reviewed-by: Moritz Fischer
> Acked-by: Alan Tull
> ---
[snip]
> +
> +static int ice40_fpga_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct device_node *np = spi->dev.of_node;
struct device_node *np = dev->of_node?
And actually I don't see why local variable 'np' is needed in the function,
see the next comment.
> + struct ice40_fpga_priv *priv;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No Device Tree entry\n");
> + return -EINVAL;
> + }
I would suggest to remove this check completely, I don't see a good
reason why it is needed.
> +
> + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = spi;
> +
> + /* Check board setup data. */
> + if (spi->max_speed_hz > ICE40_SPI_MAX_SPEED) {
> + dev_err(dev, "SPI speed is too high, maximum speed is "
> + __stringify(ICE40_SPI_MAX_SPEED) "\n");
> + return -EINVAL;
> + }
> +
> + if (spi->max_speed_hz < ICE40_SPI_MIN_SPEED) {
> + dev_err(dev, "SPI speed is too low, minimum speed is "
> + __stringify(ICE40_SPI_MIN_SPEED) "\n");
> + return -EINVAL;
> + }
> +
> + if (spi->mode & SPI_CPHA) {
> + dev_err(dev, "Bad SPI mode, CPHA not supported\n");
> + return -EINVAL;
> + }
> +
> + /* Set up the GPIOs */
> + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> + if (IS_ERR(priv->cdone)) {
> + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> + PTR_ERR(priv->cdone));
> + return -EINVAL;
You should do 'return PTR_ERR(priv->cdone)' here, this will allow
to handle at lease -EPROBE_DEFER correctly.
> + }
> +
> + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->reset)) {
> + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> + PTR_ERR(priv->reset));
> + return -EINVAL;
Same as above.
> + }
> +
> + /* Register with the FPGA manager */
> + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> + &ice40_fpga_ops, priv);
> + if (ret) {
> + dev_err(dev, "Unable to register FPGA manager");
> + return ret;
I would suggest to do just 'return fpga_mgr_register(dev, );' here,
if the driver is not registered, the core will let the user know about it.
> + }
> +
> + return 0;
> +}
> +
--
With best wishes,
Vladimir
Re: [PATCH v3 2/2] mfd: axp20x: Fix axp288 volatile ranges
Hi, On 17-12-16 16:12, Chen-Yu Tsai wrote: On Sat, Dec 17, 2016 at 4:09 AM, Hans de Goede wrote: The axp288 pmic has a lot more volatile registers then we were listing in axp288_volatile_ranges, fix this. Signed-off-by: Hans de Goede Acked-by: Chen-Yu Tsai Thank you. FYI, if you're going to add support for the battery charger detection module later, That driver is already in mainline, but like the other axp288 drivers it needs some love to actual successfully probe and work, I've a set of patches for ready for this, since I've been successfully testing them the last few days I guess I might as well send them now, so expect some patches for this soon :) you would need to add the remaining AXP288_BC_* registers to the writable table. The writeable table contains: regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE), Which already includes all of the BC registers. Regards, Hans
Re: [PATCH] staging: emxx_udc: Fix CamelCase styling issue
> Instead of merely converting Hungarian CamelCase to lowercase > with underscores where word transitions occurred, try reading > the code and making sense of what it does to perhaps find a > better variable name instead. Maybe eliminate the variable > altogether. > > iWordLength could be reads or numreads Ok! > btw: what happens if length is not a multiple of sizeof(u32)? Reading over the code (something I should have done the first time) it seems that it rounds down, not doing the full transfer, and EP0_out_OverBytes handles the remaining transfer. Since EP0_out_OverBytes is only called once and for this purpose would it be perferable to do that on EP0_out_PIO? > nret is more commonly ret > p_buf is also not common linux naming, buf is more common. Ok!
Re: [PATCH] printk: Remove no longer used second struct cont
On 12/15/2016 07:50 PM, Linus Torvalds wrote: On Thu, Dec 15, 2016 at 5:37 PM, Sergey Senozhatsky wrote: basically I'm talking about a bunch of 80-cols fixups. Please don't. Nobody uses a vt100 terminal any more. The 80-column wrapping is excessive, and makes things like "grep" not work as well. No, we still don't want excessively long lines, but that's generally mainly because (a) we don't want to have excessively _complicated_ lines (b) we don't want to have excessively deep indentation (so if line length is due to 4+ levels of indentation, that's usually the primary problem). (c) email quoting gets iffier and uglier, so short lines always are preferred if possible but in general, aside from those concerns, a long legible line is generally preferred over just adding line breaks for the very _occasional_ line. At the 100-column mark you almost have to break, because at that point people may start to be actually limited by their displays, but 80 columns generally isn't it. In fact, I thought we already upped the check-patch limit to 100? checkpatch.pl line 50 my $max_line_length = 80; Not changed as of yet. Linus
Re: [PATCH] fix code alignment with open parenthesis in drivers/staging/fbtft/fb_agm1264k-fl.c
I just read an email from Linus saying keep the line length shorter than 100, so my patch isn't necessary. I sent the v2 out today, but wasn't aware of 100 being the new limit checkpatch.pl still has 80 as the limit. Sorry to bother. Please disregard my patch. On 12/18/2016 11:43 AM, Scott Matheina wrote: On 12/18/2016 01:46 AM, Greg KH wrote: On Sat, Dec 17, 2016 at 08:42:53PM -0600, Scott Matheina wrote: Signed-off-by: Scott Matheina I can't take patches without any changelog text :( Yah. Forgot to add the description. Added for v2. --- drivers/staging/fbtft/fb_agm1264k-fl.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c b/drivers/staging/fbtft/fb_agm1264k-fl.c index a6e3af7..4e371ed 100644 --- a/drivers/staging/fbtft/fb_agm1264k-fl.c +++ b/drivers/staging/fbtft/fb_agm1264k-fl.c @@ -186,8 +186,9 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...) va_end(args); fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, -par->info->device, u8, buf, len, "%s: ", __func__); -} + par->info->device, u8, buf, len, + "%s: ", __func__); +} I don't think you did this correctly, do you? I looked at this, and made a change to the line break, but if you're talking about the code itself then I'll have to dig into the books to figure that out. Starting small and learn from reading the code and making some small changes while I figure it out.
Re: thermal zones break with patch "Reimplement IDR and IDA using the radix tree" (mainline+next)
On Fri, Dec 16, 2016 at 11:19 PM, Matthew Wilcox wrote:
> From: Heiko Stuebner [mailto:he...@sntech.de]
>> commit b05bbe3ea2db ("Reimplement IDR and IDA using the radix tree")
>> seems to
>> break thermal zone allocation. This happens both on todays mainline and
>> linux-next-20161216 and produces errors like:
>
>> While I haven't looked to deeply into what idr exactly does, some findings:
>> - thermal_zone0 and thermal_zone1 are allocated correctly
>> - every further thermal_zone always gets allocated the number "1"
>> - thermal core calls idr_alloc with 0 for both start and end
>> - the rewrite-patch seems to change the semantics of idr_alloc
>> where it orignally said "@end: the maximum id (exclusive, <= 0 for max)"
>> the "<= 0" part is gone now, but I checked, simply setting INT_MAX
>> as end in the thermal_core does not help
>
> Hi Heiko,
>
> Thanks for the report! The problem is because the thermal subsystem calls
> idr_alloc() passing a NULL pointer for the data. I have fixed this problem
> in my git tree but haven't sent the patch to Andrew yet. This patch should
> fix the problem for you:
>
> http://git.infradead.org/users/willy/linux-dax.git/commitdiff/c52eeed7b759c3fefe9b7f1b0a17a438df6950f3
>
> Now ... thermal is actually using an IDR when it could save memory by using
> an IDA. Are you interested in doing that conversion?
+Cc: Mika, Vinod
Same here for at least DMA Engine (and perhaps another place in
thermal subsystem).
For DMA Engine case
Tested-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
[PATCH v3 1/1] x86, relocs: add printf attribute to die()
Adding such an attribute helps to detect errors in the format string at
build time. After doing this, the compiler complains about such issues:
arch/x86/tools/relocs.c:460:5: error: format specifies type 'int'
but the argument has type 'Elf64_Xword' (aka 'unsigned long')
[-Werror,-Wformat]
sec->shdr.sh_size);
^
arch/x86/tools/relocs.c:464:5: error: format specifies type 'int'
but the argument has type 'Elf64_Off' (aka 'unsigned long')
[-Werror,-Wformat]
sec->shdr.sh_offset, strerror(errno));
^~~
When relocs.c is included by relocs_32.c, sec->shdr.sh_size and
sec->shdr.sh_offset are 32-bit unsigned integers. When the file is
included by relocs_64.c, these expressions are 64-bit unsigned integers.
Introduce a PRIuELF macro to define the right format to use when
printing sh_size and sh_offset values.
While at it, constify the format attribute of die().
Signed-off-by: Nicolas Iooss
---
I sent the first versions of this patch in September (cf.
https://patchwork.kernel.org/patch/9312665/) but it has not been
applied.
As commit adee8705d251 ("x86/build: Annotate die() with noreturn to fix
build warning on clang") introduced the noreturn attribute to die(),
this patch now only adds the printf attribute.
arch/x86/tools/relocs.c| 14 +++---
arch/x86/tools/relocs.h| 3 ++-
arch/x86/tools/relocs_32.c | 3 +++
arch/x86/tools/relocs_64.c | 3 +++
arch/x86/tools/relocs_common.c | 2 +-
5 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 0c2fae8d929d..4cad603b8d58 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -397,7 +397,7 @@ static void read_shdrs(FILE *fp)
ehdr.e_shnum);
}
if (fseek(fp, ehdr.e_shoff, SEEK_SET) < 0) {
- die("Seek to %d failed: %s\n",
+ die("Seek to %"PRIuELF" failed: %s\n",
ehdr.e_shoff, strerror(errno));
}
for (i = 0; i < ehdr.e_shnum; i++) {
@@ -431,11 +431,11 @@ static void read_strtabs(FILE *fp)
}
sec->strtab = malloc(sec->shdr.sh_size);
if (!sec->strtab) {
- die("malloc of %d bytes for strtab failed\n",
+ die("malloc of %"PRIuELF" bytes for strtab failed\n",
sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
- die("Seek to %d failed: %s\n",
+ die("Seek to %"PRIuELF" failed: %s\n",
sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->strtab, 1, sec->shdr.sh_size, fp)
@@ -456,11 +456,11 @@ static void read_symtabs(FILE *fp)
}
sec->symtab = malloc(sec->shdr.sh_size);
if (!sec->symtab) {
- die("malloc of %d bytes for symtab failed\n",
+ die("malloc of %"PRIuELF" bytes for symtab failed\n",
sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
- die("Seek to %d failed: %s\n",
+ die("Seek to %"PRIuELF" failed: %s\n",
sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->symtab, 1, sec->shdr.sh_size, fp)
@@ -489,11 +489,11 @@ static void read_relocs(FILE *fp)
}
sec->reltab = malloc(sec->shdr.sh_size);
if (!sec->reltab) {
- die("malloc of %d bytes for relocs failed\n",
+ die("malloc of %"PRIuELF" bytes for relocs failed\n",
sec->shdr.sh_size);
}
if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
- die("Seek to %d failed: %s\n",
+ die("Seek to %"PRIuELF" failed: %s\n",
sec->shdr.sh_offset, strerror(errno));
}
if (fread(sec->reltab, 1, sec->shdr.sh_size, fp)
diff --git a/arch/x86/tools/relocs.h b/arch/x86/tools/relocs.h
index 1d23bf953a4a..f41416c31608 100644
--- a/arch/x86/tools/relocs.h
+++ b/arch/x86/tools/relocs.h
@@ -16,7 +16,8 @@
#include
#include
-void die(char *fmt, ...) __attribute__((noreturn));
+void die(const char *fmt, ...) __attribute__((noreturn))
+ __attribute__((format(printf, 1, 2)));
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
diff --git a/arch/x86/tools/relocs_32.c b/arch/x86/tools/relocs_32.c
index b2ade2bb4162..8024ec473e6a 100644
--- a/arch/x86/tools/relocs_32.c
+++ b/arch/x86/tools/relocs_32.c
@@ -14,4 +1
Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
Tobias Klausmann writes: > A patch for this is already floating on the ML for a while now latest: > (ath9k: do not return early to fix rcu unlocking) It's here: https://patchwork.kernel.org/patch/9472709/ > Hopefully Kalle will include it in one of his upcoming pull requests. Yes, I'll try to get it to 4.10-rc2. -- Kalle Valo
Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
On 18.12.2016 20:57, Valo, Kalle wrote: Tobias Klausmann writes: A patch for this is already floating on the ML for a while now latest: (ath9k: do not return early to fix rcu unlocking) It's here: https://patchwork.kernel.org/patch/9472709/ Good to know! Hopefully Kalle will include it in one of his upcoming pull requests. Yes, I'll try to get it to 4.10-rc2. Thanks for the update!
Re: wl1251 & mac address & calibration data
On 18-12-2016 13:09, Pali Rohár wrote:
> On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
>> On 18-12-2016 12:04, Pali Rohár wrote:
>>> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from
>>> the existing mess. A solution to help both the old API and new
>>> API is possible for the "fallback mechanism" though -- but for
>>> that I can only refer you at this point to some of Daniel
>>> Wagner and Tom Gunderson's firmwared deamon prospect. It
>>> should help pave the way for a clean solution and help address
>>> other stupid issues.
>>
>> The firmwared project is hosted here
>>
>> https://github.com/teg/firmwared
>>
>> As Luis pointed out, firmwared relies on
>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>
> I know. But it does not mean that I cannot enable this option at
> kernel compile time.
>
> Bigger problem is that currently request_firmware() first try to
> load firmware directly from VFS and after that (if fails)
> fallback to user helper.
>
> So I would need to extend kernel firmware code with new function
> (or flag) to not use VFS and try only user mode helper.
Why do you need the user-mode helper anyway. This is all static
data, right?
>>>
>>> Those are static data, but device specific!
>>
>> So what?
>>
So why not cook up a firmware file in user-space once and put
it in /lib/firmware for the driver to request directly.
>>>
>>> 1. Violates FHS
>>
>> How?
>>
>>> 2. Does not work for readonly /, readonly /lib, readonly
>>> /lib/firmware
>>
>> Que?
>>
>>> 3. Backup & restore of rootfs between same devices does not work
>>> (as rootfs now contains device specific data).
>>
>> True.
>>
>>> 4. Sharing one rootfs (either via nfs or other technology) does not
>>> work for more devices (even in state when rootfs is used only by
>>> one device at one time).
>>
>> Indeed.
>>
>>> And it is common that N900 developers have rootfs in laptop and via
>>> usb (cdc_ether) exports it over nfs to N900 device and boot
>>> system. It basically break booting from one nfs-exported rootfs,
>>> as that export become model specific...
>>
>> These are all you choices and more a logistic issue. If your take is
>> that udev is the way to solve those, fine by me.
>>
Seems a bit
overkill to have a {e,}udev or whatever daemon running if the
result is always the same. Just my 2 cents.
>>>
>>> No it is not. It will break couple of other things in Linux and
>>> device
>>
>> Now I am curious. What "couple of other things" will be broken.
>>
>>> and model specific calibration data should not be in /lib/firmware!
>>> That directory is used for firmware files, not calibration.
>>
>> What is "firmware"? Really. These are binary blobs required to make
>> the device work. And guess what, your device needs calibration data.
>> Why make the distinction.
>>
>> Regards,
>> Arend
>
> File wl1251-nvs.bin is provided by linux-firmware package and contains
> default data which should be overriden by model specific calibrated
> data.
Ah. Someone thought it was a good idea to provide the "one ring to rule
them all". Nice.
> But overwriting that one file is not possible as it next update of
> linux-firmware package will overwrite it back. It break any normal usage
> of package management.
>
> Also it is ridiculously broken by design if some "boot" files needs to
> be overwritten to initialize hardware properly. To not break booting you
> need to overwrite that file before first boot. But without booting
> device you cannot read calibration data. So some hack with autoreboot
> after boot is needed. And how to detect that we have real overwritten
> calibration data and not default one from linux-firmware? Any heuristic
> or checks will be broken here. And no, nothing like you need to reboot
> your device now (and similar concept) from windows world is not
> accepted.
Well. After reading and creating calibration data you could just rebind
the driver to the device to have it probed again. But yeah, the default
one from linux-firmware should never have been there in the first place.
> "firmware" is one for chip. Any N900 device with wl1251 chip needs
> exactly same firmware "wl1251-fw.bin". But every N900 needs different
> calibration data which is not firmware.
Ok. This is exactly why Luis is giving the new API different name just
calling it "data".
Regards,
Arend
[GIT pull] x86/timers for 4.10
Linus,
please pull the latest x86-timers-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-timers-for-linus
This is the last functional update from the tip tree for 4.10. It got
delayed due to a newly reported and anlyzed variant of BIOS bug and the
resulting wreckage:
- Seperation of TSC being marked realiable and the fact that the platform
provides the TSC frequency via CPUID/MSRs and making use for it for
GOLDMONT.
- TSC adjust MSR validation and sanitizing:
The TSC adjust MSR contains the offset to the hardware counter. The sum
of the adjust MSR and the counter is the TSC value which is read via
RDTSC.
On at least two machines from different vendors the BIOS sets the TSC
adjust MSR to negative values. This happens on cold and warm boot. While
on cold boot the offset is a few milliseconds, on warm boot it basically
compensates the power on time of the system. The BIOSes are not even
using the adjust MSR to set all CPUs in the package to the same
offset. The offsets are different which renders the TSC unusable,
What's worse is that the TSC deadline timer has a HW feature^Wbug. It
malfunctions when the TSC adjust value is negative or greater equal
0x8000 resulting in silent boot failures, hard lockups or non firing
timers. This looks like some hardware internal 32/64bit issue with a
sign extension problem. Intel has been silent so far on the issue.
The update contains sanity checks and keeps the adjust register within
working limits and in sync on the package.
As it looks like this disease is spreading via BIOS crapware, we need to
address this urgently as the boot failures are hard to debug for users.
Thanks,
tglx
-->
Bin Gao (4):
x86/tsc: Add X86_FEATURE_TSC_KNOWN_FREQ flag
x86/tsc: Mark TSC frequency determined by CPUID as known
x86/tsc: Mark Intel ATOM_GOLDMONT TSC reliable
x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on Intel Atom SoCs
Thomas Gleixner (15):
x86/tsc: Finalize the split of the TSC_RELIABLE flag
x86/tsc: Use X86_FEATURE_TSC_ADJUST in detect_art()
x86/tsc: Detect random warps
x86/tsc: Store and check TSC ADJUST MSR
x86/tsc: Verify TSC_ADJUST from idle
x86/tsc: Sync test only for the first cpu in a package
x86/tsc: Move sync cleanup to a safe place
x86/tsc: Prepare warp test for TSC adjustment
x86/tsc: Try to adjust TSC if sync test fails
x86/tsc: Fix broken CONFIG_X86_TSC=n build
x86/tsc: Validate cpumask pointer before accessing it
x86/tsc: Validate TSC_ADJUST after resume
x86/tsc: Force TSC_ADJUST register to value >= zero
x86/tsc: Annotate printouts as firmware bug
x86/tsc: Limit the adjust value further
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/tsc.h | 9 ++
arch/x86/kernel/Makefile| 2 +-
arch/x86/kernel/process.c | 1 +
arch/x86/kernel/tsc.c | 42 --
arch/x86/kernel/tsc_msr.c | 19 +++
arch/x86/kernel/tsc_sync.c | 290 ++--
arch/x86/platform/intel-mid/mfld.c | 9 +-
arch/x86/platform/intel-mid/mrfld.c | 8 +-
arch/x86/power/cpu.c| 1 +
10 files changed, 355 insertions(+), 27 deletions(-)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
index a39629206864..7f6a5f88d5ae 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -106,6 +106,7 @@
#define X86_FEATURE_APERFMPERF ( 3*32+28) /* APERFMPERF */
#define X86_FEATURE_EAGER_FPU ( 3*32+29) /* "eagerfpu" Non lazy FPU restore */
#define X86_FEATURE_NONSTOP_TSC_S3 ( 3*32+30) /* TSC doesn't stop in S3 state
*/
+#define X86_FEATURE_TSC_KNOWN_FREQ ( 3*32+31) /* TSC has known frequency */
/* Intel-defined CPU features, CPUID level 0x0001 (ecx), word 4 */
#define X86_FEATURE_XMM3 ( 4*32+ 0) /* "pni" SSE-3 */
diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index 33b6365c22fe..abb1fdcc545a 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -45,8 +45,17 @@ extern int tsc_clocksource_reliable;
* Boot-time check whether the TSCs are synchronized across
* all CPUs/cores:
*/
+#ifdef CONFIG_X86_TSC
+extern bool tsc_store_and_check_tsc_adjust(bool bootcpu);
+extern void tsc_verify_tsc_adjust(bool resume);
extern void check_tsc_sync_source(int cpu);
extern void check_tsc_sync_target(void);
+#else
+static inline bool tsc_store_and_check_tsc_adjust(bool bootcpu) { return
false; }
+static inline void tsc_verify_tsc_adjust(bool resume) { }
+static inline void check_tsc_sync_source(int cpu) { }
+static inline void check_tsc_sync_target(void) { }
+#endif
extern int notsc_setup(char *);
extern void tsc_save_sched_clock_state(void);
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefi
Re: regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
On Sun, Dec 18, 2016 at 07:57:42PM +, Valo, Kalle wrote: > Tobias Klausmann writes: > > > A patch for this is already floating on the ML for a while now latest: > > (ath9k: do not return early to fix rcu unlocking) > > It's here: > > https://patchwork.kernel.org/patch/9472709/ Feel free to add: Acked-by: Paul E. McKenney Thanx, Paul > > Hopefully Kalle will include it in one of his upcoming pull requests. > > Yes, I'll try to get it to 4.10-rc2. > > -- > Kalle Valo
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock
Hi! > > For the same reason it's broken if it races with the transmit path: it > > can release driver resources while the transmit path uses these. > > > > Btw the points below may not matter/hurt much for a proof a concept > > but they would need to be addressed as well: > > 1) unchecked (and avoidable) extra error paths due to stmmac_release() > > 2) racy cancel_work_sync. Low probability as it is, an irq + error could > >take place right after cancel_work_sync > > It was indeed only meant as a proof of concept. Nevertheless the race is not > good, since one can run into it when faking the tx error for testings > purposes. > So below is a slightly improved version of the restart handling. > Its not meant as a final version either. But maybe we can use it as a starting > point. Certainly works better than version we currently have in tree. I'm running it in a loop, and it survived 10 minutes of testing so far. (Previous version killed the hardware at first iteration.) > Again the patch is only compile tested. Tested-by: Pavel Machek Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH v4 1/2] FPGA: Add TS-7300 FPGA manager
Add support for loading bitstreams on the Altera Cyclone II FPGA
populated on the TS-7300 board. This is done through the configuration
and data registers offered through a memory interface between the EP93xx
SoC and the FPGA via an intermediate CPLD device.
The EP93xx SoC on the TS-7300 does not have direct means of configuring
the on-board FPGA other than by using the special memory mapped
interface to the CPLD. No other entity on the system can control the
FPGA bitstream.
Signed-off-by: Florian Fainelli
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/ts73xx-fpga.c | 163 +
3 files changed, 171 insertions(+)
create mode 100644 drivers/fpga/ts73xx-fpga.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2853a4..d9cbef60db80 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -33,6 +33,13 @@ config FPGA_MGR_SOCFPGA_A10
help
FPGA manager driver support for Altera Arria10 SoCFPGA.
+config FPGA_MGR_TS73XX
+ tristate "Technologic Systems TS-73xx SBC FPGA Manager"
+ depends on ARCH_EP93XX && MACH_TS72XX
+ help
+ FPGA manager driver support for the Altera Cyclone II FPGA
+ present on the TS-73xx SBC boards.
+
config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bcf42a6..a1160169e6d9 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
+obj-$(CONFIG_FPGA_MGR_TS73XX) += ts73xx-fpga.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
# FPGA Bridge Drivers
diff --git a/drivers/fpga/ts73xx-fpga.c b/drivers/fpga/ts73xx-fpga.c
new file mode 100644
index ..5acdbcfe447b
--- /dev/null
+++ b/drivers/fpga/ts73xx-fpga.c
@@ -0,0 +1,163 @@
+/*
+ * Technologic Systems TS-73xx SBC FPGA loader
+ *
+ * Copyright (C) 2016 Florian Fainelli
+ *
+ * FPGA Manager Driver for the on-board Altera Cyclone II FPGA found on
+ * TS-7300, heavily based on load_fpga.c in their vendor tree.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TS73XX_FPGA_DATA_REG 0
+#define TS73XX_FPGA_CONFIG_REG 1
+
+#define TS73XX_FPGA_WRITE_DONE 0x1
+#define TS73XX_FPGA_WRITE_DONE_TIMEOUT 1000/* us */
+#define TS73XX_FPGA_RESET 0x2
+#define TS73XX_FPGA_RESET_LOW_DELAY30 /* us */
+#define TS73XX_FPGA_RESET_HIGH_DELAY 80 /* us */
+#define TS73XX_FPGA_LOAD_OK0x4
+#define TS73XX_FPGA_CONFIG_LOAD0x8
+
+struct ts73xx_fpga_priv {
+ void __iomem*io_base;
+ struct device *dev;
+};
+
+static enum fpga_mgr_states ts73xx_fpga_state(struct fpga_manager *mgr)
+{
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int ts73xx_fpga_write_init(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
+ const char *buf, size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+
+ /* Reset the FPGA */
+ writeb(0, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(TS73XX_FPGA_RESET_LOW_DELAY);
+ writeb(TS73XX_FPGA_RESET, priv->io_base + TS73XX_FPGA_CONFIG_REG);
+ udelay(TS73XX_FPGA_RESET_HIGH_DELAY);
+
+ return 0;
+}
+
+static int ts73xx_fpga_write(struct fpga_manager *mgr, const char *buf,
+size_t count)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ size_t i = 0;
+ int ret;
+ u8 reg;
+
+ while (count--) {
+ ret = readb_poll_timeout(priv->io_base + TS73XX_FPGA_CONFIG_REG,
+reg, !(reg & TS73XX_FPGA_WRITE_DONE),
+1, TS73XX_FPGA_WRITE_DONE_TIMEOUT);
+ if (ret < 0)
+ return ret;
+
+ writeb(buf[i], priv->io_base + TS73XX_FPGA_DATA_REG);
+ i++;
+ }
+
+ return 0;
+}
+
+static int ts73xx_fpga_write_complete(struct fpga_manager *mgr,
+ struct fpga_image_info *info)
+{
+ struct ts73xx_fpga_priv *priv = mgr->priv;
+ u8 reg;
+
+ usleep_range(1000, 2000);
+ reg = r
[PATCH v4 2/2] ARM: ep93xx: Register ts73xx-fpga manager driver for TS-7300
Register the TS-7300 FPGA manager device drivers which allows us to load
bitstreams into the on-board Altera Cyclone II FPGA.
Acked-by: H Hartley Sweeten
Signed-off-by: Florian Fainelli
---
arch/arm/mach-ep93xx/ts72xx.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 3b39ea353d30..acf72ea670ef 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -230,6 +230,28 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data =
{
.phy_id = 1,
};
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+
+/* Relative to EP93XX_CS1_PHYS_BASE */
+#define TS73XX_FPGA_LOADER_BASE0x03c0
+
+static struct resource ts73xx_fpga_resources[] = {
+ {
+ .start = EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE,
+ .end= EP93XX_CS1_PHYS_BASE + TS73XX_FPGA_LOADER_BASE + 1,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device ts73xx_fpga_device = {
+ .name = "ts73xx-fpga-mgr",
+ .id = -1,
+ .resource = ts73xx_fpga_resources,
+ .num_resources = ARRAY_SIZE(ts73xx_fpga_resources),
+};
+
+#endif
+
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
@@ -238,6 +260,10 @@ static void __init ts72xx_init_machine(void)
platform_device_register(&ts72xx_wdt_device);
ep93xx_register_eth(&ts72xx_eth_data, 1);
+#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
+ if (board_is_ts7300())
+ platform_device_register(&ts73xx_fpga_device);
+#endif
}
MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
--
2.9.3
