[PATCH] fs.h: Remove comment referring to removed inode-operation
struct inode_operations has a comment that used to refer to the removed
operation dentry_open, add in commit 4aa7c6346be3 ("vfs: add
i_op->dentry_open()"), mentioning that it was going to be removed soon.
The comment was not removed when the dentry_open operation was removed
in commit 4bacc9c9234c ("overlayfs: Make f_path always point to the
overlay and f_inode to the underlay").
Signed-off-by: Matt Kilgore
---
include/linux/fs.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 72d8a84..e495b3e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1678,8 +1678,6 @@ struct inode_operations {
umode_t create_mode, int *opened);
int (*tmpfile) (struct inode *, struct dentry *, umode_t);
int (*set_acl)(struct inode *, struct posix_acl *, int);
-
- /* WARNING: probably going away soon, do not use! */
} cacheline_aligned;
ssize_t rw_copy_check_uvector(int type, const struct iovec __user * uvector,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Revert locking changes in DAX for v4.3
On Fri, Oct 02, 2015 at 06:01:32PM -0600, Ross Zwisler wrote:
> This series reverts some recent changes to the locking scheme in DAX
> introduced
> by these two commits:
>
> commit 843172978bb9 ("dax: fix race between simultaneous faults")
> commit 46c043ede471 ("mm: take i_mmap_lock in unmap_mapping_range() for DAX")
>
> Changes from v1:
> - Squashed patches 1 and 2 from the first series into a single patch to
> avoid
> adding another spot in the git history where we could end up referencing
> an
> uninitialized pointer.
>
> Ross Zwisler (2):
> Revert "mm: take i_mmap_lock in unmap_mapping_range() for DAX"
> Revert "dax: fix race between simultaneous faults"
>
> fs/dax.c| 83
> +
> mm/memory.c | 2 ++
> 2 files changed, 36 insertions(+), 49 deletions(-)
>
> --
> 2.1.0
*sigh* - even after these reverts we can deadlock on in the DAX PMD code with
its original locking scheme. I can hit them 100% of the time with either
generic/074 or generic/198 using either XFS or ext4. I'll debug exactly
what's going on on Monday.
The quick and easy workaround for this is to do a "return VM_FAULT_FALLBACK;"
at the beginning of __dax_pmd_fault() to just turn off PMD faults while we
rework the locking for v4.4. This saves us reverting and re-adding all the
PMD code, and will let us ship v4.3 without known deadlocks.
Other better ideas?
- Ross
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mmap.c: Remove redundant vma looping
On 10/4/15 04:09, Richard Weinberger wrote:
> With that change you're reintroducing an issue.
> Please see:
> commit 7cd5a02f54f4c9d16cf7fdffa2122bc73bb09b43
> Author: Peter Zijlstra
> Date: Mon Aug 11 09:30:25 2008 +0200
>
> mm: fix mm_take_all_locks() locking order
>
> Lockdep spotted:
>
> ===
> [ INFO: possible circular locking dependency detected ]
> 2.6.27-rc1 #270
> ---
> qemu-kvm/2033 is trying to acquire lock:
> (>i_data.i_mmap_lock){}, at: []
> mm_take_all_locks+0xc2/0xea
>
> but task is already holding lock:
> (_vma->lock){}, at: []
> mm_take_all_locks+0x70/0xea
>
> which lock already depends on the new lock.
>
Oh, really. Thanks.
>
> git blame often explains funky code. :-)
>
Next, I shall check the git log before make patches, each time. :-)
Theoretically, the lock and unlock need to be symmetric, if we have to
lock f_mapping all firstly, then lock all anon_vma, probably, we also
need to unlock anon_vma all, then unlock all f_mapping.
Thanks.
--
Chen Gang (陈刚)
Open, share, and attitude like air, water, and life which God blessed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] 3.4.109 - unable to handle kernel NULL pointer dereference at (null)
On Thu, 1 Oct 2015, Steven Rostedt wrote: > > I merged 3.4.109 into 3.4-rt, and it bugged. I then booted 3.4.109 > vanilla and it bugged too. 3.4.108 is fine. > I'm getting a similar type bug here. I've bisected it down to this commit: commit 961bd13539b9e7ca5d2e667668141496b7a1d6bc Author: Michel Dänzer Date: Thu Apr 16 11:17:27 2015 +0900 drm/radeon: Use drm_calloc_ab for CS relocs commit b421ed15d2c3039eb724680e4de1e4b2bd196a9a upstream. The number of relocs is passed in by userspace and can be large. It has been observed to cause kcalloc failures in the wild. Backing it out of vanilla 3.4.109 has so far eliminated the problem. Steven, you look to be using i915 graphics instead of radeon, so it seems unlikely to me that we're hitting the same problem. Here's my oops for comparison though: BUG: unable to handle kernel NULL pointer dereference at 02f1 IP: [] evdev_poll+0x2a/0x70 [evdev] PGD 211441067 PUD 213771067 PMD 0 Oops: [#1] SMP CPU 0 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 iptable_nat nf_nat bridge stp llc nfs auth_rpcgss lockd ntfs cifs udf crypto_hash sunrpc crypto_algapi isofs crc_itu_t vfat msdos fat nls_cp437 nls_utf8 nls_iso8859_1 nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack_tftp nf_defrag_ipv4 nf_conntrack xt_LOG ipt_REJECT xt_tcpudp iptable_filter kvm_amd ip_tables kvm x_tables f71882fg af_packet edac_core msr pcspkr cpuid edac_mce_amd mousedev usbhid hid snd_hda_codec_hdmi snd_hda_codec_realtek usb_storage snd_hda_intel snd_hda_codec radeon sr_mod cdrom ttm drm_kms_helper ohci_hcd powernow_k8 freq_table psmouse evdev snd_pcm mperf snd_timer k10temp e1000 sata_sil drm snd 8250_pnp serio_raw 8250 serial_core floppy ehci_hcd microcode soundcore snd_page_alloc pata_atiixp backlight i2c_piix4 usbcore i2c_algo_bit processor i2c_core sg thermal_sys usb_common button power_supply r8169 hwmon firmware_class mii loop! ext4 bd2 crc16 raid1 dm_mod raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx md_mod ahci libahci libata sd_mod scsi_mod Pid: 1862, comm: X Not tainted 3.4.108-00059-g961bd13 #7 MICRO-STAR INTERNATIONAL CO.,LTD MS-7551/KA780G (MS-7551) RIP: 0010:[] [] evdev_poll+0x2a/0x70 [evdev] RSP: 0018:880211dd79f8 EFLAGS: 00010246 RAX: RBX: 8802106b6800 RCX: 0069 RDX: 88021184f800 RSI: 880211dd7ad8 RDI: 88021184f800 RBP: 0019 R08: 880211dd7f48 R09: 880211dd7de0 R10: R11: 3246 R12: 0001 R13: 0007e000 R14: 88021184f800 R15: 0040 FS: 7f649ddd08a0() GS:88021fc0() knlGS:f70486d0 CS: 0010 DS: ES: CR0: 8005003b CR2: 02f1 CR3: 000212ac6000 CR4: 07f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process X (pid: 1862, threadinfo 880211dd6000, task 8802135e62d0) Stack: 0001 0013 0010 810d4b93 880211f9c700 a03d90b2 880211dd7cc8 0007e000 000111dd7cc8 Call Trace: [] ? do_select+0x333/0x5f0 [] ? r600_cs_packet_parse+0x42/0x140 [radeon] [] ? __pollwait+0x110/0x110 Oct 3 23:24:38 lancer last message repeated 7 times [] ? kmem_cache_free+0x86/0x90 [] ? __dequeue_signal+0x102/0x190 [] ? core_sys_select+0x20c/0x380 [] ? set_current_blocked+0x38/0x60 [] ? block_sigmask+0x3c/0x50 [] ? do_signal+0x1d4/0x620 [] ? ktime_get_ts+0x6d/0xe0 [] ? sys_select+0x42/0x110 [] ? system_call_fastpath+0x16/0x1b Code: <80> bd d8 02 00 00 01 8b 4b 04 48 8b 6c 24 10 19 c0 24 14 05 04 01 RIP [] evdev_poll+0x2a/0x70 [evdev] RSP CR2: 02f1 ---[ end trace 369d4585fbe82a04 ]--- BUG: unable to handle kernel NULL pointer dereference at 00a1 IP: [] mutex_lock_interruptible+0xe/0x40 PGD 0 Oops: 0002 [#2] SMP CPU 0 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ipv6 iptable_nat nf_nat bridge stp llc nfs auth_rpcgss lockd ntfs cifs udf crypto_hash sunrpc crypto_algapi isofs crc_itu_t vfat msdos fat nls_cp437 nls_utf8 nls_iso8859_1 nf_conntrack_ftp nf_conntrack_ipv4 xt_state nf_conntrack_tftp nf_defrag_ipv4 nf_conntrack xt_LOG ipt_REJECT xt_tcpudp iptable_filter kvm_amd ip_tables kvm x_tables f71882fg af_packet edac_core msr pcspkr cpuid edac_mce_amd mousedev usbhid hid snd_hda_codec_hdmi snd_hda_codec_realtek usb_storage snd_hda_intel snd_hda_codec radeon sr_mod cdrom ttm drm_kms_helper ohci_hcd powernow_k8 freq_table psmouse evdev snd_pcm mperf snd_timer k10temp e1000 sata_sil drm snd 8250_pnp serio_raw 8250 serial_core floppy ehci_hcd microcode soundcore snd_page_alloc pata_atiixp backlight i2c_piix4
[PATCH] Staging: iio: meter: Use devm functions
Introduce use of managed resource function devm_iio_trigger_alloc
instead of iio_trigger_alloc and devm_request_irq instead of request_irq
Remove corresponding calls to iio_trigger_free and free_irq in the probe
and remove functions.
The now unnecessary labels error_free_trig and err_free_irq are dropped.
Signed-off-by: Shraddha Barke
---
drivers/staging/iio/meter/ade7758_trigger.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/iio/meter/ade7758_trigger.c
b/drivers/staging/iio/meter/ade7758_trigger.c
index 5b35a7f..e313b37 100644
--- a/drivers/staging/iio/meter/ade7758_trigger.c
+++ b/drivers/staging/iio/meter/ade7758_trigger.c
@@ -63,21 +63,21 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
struct ade7758_state *st = iio_priv(indio_dev);
int ret;
- st->trig = iio_trigger_alloc("%s-dev%d",
- spi_get_device_id(st->us)->name,
- indio_dev->id);
+ st->trig = devm_iio_trigger_alloc(_dev->id, "%s-dev%d",
+ spi_get_device_id(st->us)->name,
+ indio_dev->id);
if (!st->trig) {
ret = -ENOMEM;
goto error_ret;
}
- ret = request_irq(st->us->irq,
- ade7758_data_rdy_trig_poll,
- IRQF_TRIGGER_LOW,
- spi_get_device_id(st->us)->name,
- st->trig);
+ ret = devm_request_irq(_dev->dev, st->us->irq,
+ ade7758_data_rdy_trig_poll,
+ IRQF_TRIGGER_LOW,
+ spi_get_device_id(st->us)->name,
+ st->trig);
if (ret)
- goto error_free_trig;
+ goto error_ret
st->trig->dev.parent = >us->dev;
st->trig->ops = _trigger_ops;
@@ -87,14 +87,10 @@ int ade7758_probe_trigger(struct iio_dev *indio_dev)
/* select default trigger */
indio_dev->trig = iio_trigger_get(st->trig);
if (ret)
- goto error_free_irq;
+ goto error_ret;
return 0;
-error_free_irq:
- free_irq(st->us->irq, st->trig);
-error_free_trig:
- iio_trigger_free(st->trig);
error_ret:
return ret;
}
@@ -104,6 +100,4 @@ void ade7758_remove_trigger(struct iio_dev *indio_dev)
struct ade7758_state *st = iio_priv(indio_dev);
iio_trigger_unregister(st->trig);
- free_irq(st->us->irq, st->trig);
- iio_trigger_free(st->trig);
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] crypto/nx842: Add CRC and validation support
This patch adds CRC generation and validation support for nx-842.
Add CRC flag so that nx842 coprocessor includes CRC during compression
and validates during decompression.
Also changes in 842 SW compression to append CRC value at the end
of template and checks during decompression.
Signed-off-by: Haren Myneni
---
Changes in V2:
Added CRC and validation support in 842 SW compression/ decompression
drivers/crypto/nx/nx-842-powernv.c |4 ++--
drivers/crypto/nx/nx-842-pseries.c |8 ++--
lib/842/842.h |2 ++
lib/842/842_compress.c | 13 +
lib/842/842_decompress.c | 17 +
5 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/nx/nx-842-powernv.c
b/drivers/crypto/nx/nx-842-powernv.c
index 3750e13..9ef51fa 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -491,7 +491,7 @@ static int nx842_powernv_compress(const unsigned
char *in, unsigned int inlen,
void *wmem)
{
return nx842_powernv_function(in, inlen, out, outlenp,
- wmem, CCW_FC_842_COMP_NOCRC);
+ wmem, CCW_FC_842_COMP_CRC);
}
/**
@@ -519,7 +519,7 @@ static int nx842_powernv_decompress(const unsigned
char *in, unsigned int inlen,
void *wmem)
{
return nx842_powernv_function(in, inlen, out, outlenp,
- wmem, CCW_FC_842_DECOMP_NOCRC);
+ wmem, CCW_FC_842_DECOMP_CRC);
}
static int __init nx842_powernv_probe(struct device_node *dn)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index f4cbde0..df1b76c 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -234,6 +234,10 @@ static int nx842_validate_result(struct device
*dev,
dev_dbg(dev, "%s: Out of space in output buffer\n",
__func__);
return -ENOSPC;
+ case 65: /* Calculated CRC doesn't match the passed value */
+ dev_dbg(dev, "%s: CRC mismatch for decompression\n",
+ __func__);
+ return -EINVAL;
case 66: /* Input data contains an illegal template field */
case 67: /* Template indicates data past the end of the input stream
*/
dev_dbg(dev, "%s: Bad data for decompression (code:%d)\n",
@@ -324,7 +328,7 @@ static int nx842_pseries_compress(const unsigned
char *in, unsigned int inlen,
slout.entries = (struct nx842_slentry *)workmem->slout;
/* Init operation */
- op.flags = NX842_OP_COMPRESS;
+ op.flags = NX842_OP_COMPRESS_CRC;
csbcpb = >csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
@@ -457,7 +461,7 @@ static int nx842_pseries_decompress(const unsigned
char *in, unsigned int inlen,
slout.entries = (struct nx842_slentry *)workmem->slout;
/* Init operation */
- op.flags = NX842_OP_DECOMPRESS;
+ op.flags = NX842_OP_DECOMPRESS_CRC;
csbcpb = >csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
diff --git a/lib/842/842.h b/lib/842/842.h
index 7c20003..e0a122b 100644
--- a/lib/842/842.h
+++ b/lib/842/842.h
@@ -76,6 +76,7 @@
#include
#include
#include
+#include
#include
#include
@@ -98,6 +99,7 @@
#define I2_BITS(8)
#define I4_BITS(9)
#define I8_BITS(8)
+#define CRC_BITS (32)
#define REPEAT_BITS_MAX(0x3f)
#define SHORT_DATA_BITS_MAX(0x7)
diff --git a/lib/842/842_compress.c b/lib/842/842_compress.c
index 7ce6894..d33cac9 100644
--- a/lib/842/842_compress.c
+++ b/lib/842/842_compress.c
@@ -490,6 +490,7 @@ int sw842_compress(const u8 *in, unsigned int ilen,
int ret;
u64 last, next, pad, total;
u8 repeat_count = 0;
+ u32 crc;
BUILD_BUG_ON(sizeof(*p) > SW842_MEM_COMPRESS);
@@ -580,6 +581,18 @@ skip_comp:
if (ret)
return ret;
+ /*
+* crc(0:31) is appended to target data starting with the next
+* bit after End of stream template.
+* nx842 calculates CRC for data in big-endian format. So doing
+* same here so that sw842 decompression can be used for both
+* compressed data.
+*/
+ crc = crc32_be(0, in, ilen);
+ ret = add_bits(p, crc, CRC_BITS);
+ if (ret)
+ return ret;
+
if (p->bit) {
p->out++;
p->olen--;
diff --git a/lib/842/842_decompress.c b/lib/842/842_decompress.c
index 5446ff0..b0db568 100644
--- a/lib/842/842_decompress.c
+++ b/lib/842/842_decompress.c
@@ -285,6 +285,7 @@ int sw842_decompress(const u8 *in, unsigned int
ilen,
[PATCH] extcon: Modify the id and name of external connector
This patch modifies the id and name of external connector with the additional
prefix to clarify both attribute and meaning of external connector as following:
- EXTCON_CHG_* mean the charger connector.
- EXTCON_JACK_* mean the jack connector.
- EXTCON_DISP_* mean the display port connector.
Following table show the new name of external connector with old name:
-
Old extcon name | New extcon name |
-
EXTCON_TA | EXTCON_CHG_USB_DCP|
EXTCON_FAST_CHARGER | EXTCON_CHG_USB_FAST |
EXTCON_SLOW_CHARGER | EXTCON_CHG_USB_SLOW |
EXTCON_CHARGE_DOWNSTREAM| EXTCON_CHG_USB_CDP|
-
EXTCON_MICROPHONE | EXTCON_JACK_MICROPHONE|
EXTCON_HEADPHONE| EXTCON_JACK_HEADPHONE |
EXTCON_LINE_IN | EXTCON_JACK_LINE_IN |
EXTCON_LINE_OUT | EXTCON_JACK_LINE_OUT |
EXTCON_VIDEO_IN | EXTCON_JACK_VIDEO_IN |
EXTCON_VIDEO_OUT| EXTCON_JACK_VIDEO_OUT |
EXTCON_SPDIF_IN | EXTCON_JACK_SPDIF_IN |
EXTCON_SPDIF_OUT| EXTCON_JACK_SPDIF_OUT |
-
EXTCON_HMDI | EXTCON_DISP_HDMI |
EXTCON_MHL | EXTCON_DISP_MHL |
EXTCON_DVI | EXTCON_DISP_DVI |
EXTCON_VGA | EXTCON_DISP_VGA |
-
And, when altering the name of USB charger connector, EXTCON refers to the
"USB battery charging specification"[1] to use the standard name of USB
charging port as following. Following name of USB charging port are already used
in power_supply subsystem. We chan check it on patch[2].
- EXTCON_CHG_USB/* Standard Downstream Port */
- EXTCON_CHG_USB_DCP/* Dedicated Charging Port */
- EXTCON_CHG_USB_CDP/* Charging Downstream Port */
- EXTCON_CHG_USB_ACA/* Accessory Charging Adapter */
[1]
http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf
[2] commit 85efc8a18ce ("[PATCH] power_supply: Add types for USB chargers")
Signed-off-by: Chanwoo Choi
---
drivers/extcon/extcon-arizona.c | 18 ++--
drivers/extcon/extcon-axp288.c | 12
drivers/extcon/extcon-max14577.c | 18 ++--
drivers/extcon/extcon-max77693.c | 32 +++--
drivers/extcon/extcon-max77843.c | 27 ++
drivers/extcon/extcon-max8997.c | 21 +++---
drivers/extcon/extcon-rt8973a.c | 4 +--
drivers/extcon/extcon-sm5502.c | 4 +--
drivers/extcon/extcon.c | 60 ---
include/linux/extcon.h | 61 +++-
10 files changed, 138 insertions(+), 119 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index a1ab0a5..e4890dd 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -137,9 +137,9 @@ static const int arizona_micd_levels[] = {
static const unsigned int arizona_cable[] = {
EXTCON_MECHANICAL,
- EXTCON_MICROPHONE,
- EXTCON_HEADPHONE,
- EXTCON_LINE_OUT,
+ EXTCON_JACK_MICROPHONE,
+ EXTCON_JACK_HEADPHONE,
+ EXTCON_JACK_LINE_OUT,
EXTCON_NONE,
};
@@ -600,7 +600,7 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
struct arizona_extcon_info *info = data;
struct arizona *arizona = info->arizona;
int id_gpio = arizona->pdata.hpdet_id_gpio;
- unsigned int report = EXTCON_HEADPHONE;
+ unsigned int report = EXTCON_JACK_HEADPHONE;
int ret, reading;
bool mic = false;
@@ -645,9 +645,9 @@ static irqreturn_t arizona_hpdet_irq(int irq, void *data)
/* Report high impedence cables as line outputs */
if (reading >= 5000)
- report = EXTCON_LINE_OUT;
+ report = EXTCON_JACK_LINE_OUT;
else
- report = EXTCON_HEADPHONE;
+ report = EXTCON_JACK_HEADPHONE;
ret = extcon_set_cable_state_(info->edev, report, true);
if (ret != 0)
@@ -732,7 +732,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_set_cable_state_(info->edev, EXTCON_HEADPHONE, true);
+ ret = extcon_set_cable_state_(info->edev, EXTCON_JACK_HEADPHONE, true);
if (ret != 0)
dev_err(arizona->dev, "Failed to report headphone: %d\n", ret);
@@ -789,7 +789,7 @@ err:
ARIZONA_ACCDET_MODE_MASK, ARIZONA_ACCDET_MODE_MIC);
/* Just report headphone */
- ret = extcon_set_cable_state_(info->edev, EXTCON_HEADPHONE, true);
+ ret = extcon_set_cable_state_(info->edev, EXTCON_JACK_HEADPHONE, true);
if (ret != 0)
dev_err(arizona->dev, "Failed to report headphone: %d\n", ret);
@@ -915,7 +915,7 @@ static void
Re: [PATCH 8/24] ver_linux: e2fsprogs.patch
On Sat, Oct 03, 2015 at 04:23:02PM +0300, Alexander Kapshuk wrote: > 'tune2fs' is located in varying places depending on the distro. > Current implementation output on distros where 'tune2fs' is found at > a location that is not available in the PATH for the regular user, > e.g. '/sbin', will have nothing to display. > While running 'ver_linux' as user 'root' should be OK. Instead of making all of these changes, why not just add PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin to the beginning of ver_linux? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
Hi Gabriel,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
drivers/firmware/qemu_fw_cfg.c:66:25: sparse: constant 0xd0510 is so big
it is long
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:111:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
drivers/firmware/qemu_fw_cfg.c:367:25: sparse: cast to restricted __be32
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:368:27: sparse: cast to restricted __be16
>> drivers/firmware/qemu_fw_cfg.c:95:39: sparse: restricted __be16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:95:58: sparse: restricted __le16 degrades to
>> integer
>> drivers/firmware/qemu_fw_cfg.c:420:22: sparse: cast to restricted __le32
vim +95 drivers/firmware/qemu_fw_cfg.c
60 .size = 0x0a,
61 .ctrl_offset = 0x08,
62 .data_offset = 0x00,
63 .is_mmio = true,
64 }, {
65 .name = "fw_cfg MMIO on sun4m",
> 66 .base = 0xd0510,
67 .size = 0x03,
68 .ctrl_offset = 0x00,
69 .data_offset = 0x02,
70 .is_mmio = true,
71 }, {
72 .name = "fw_cfg MMIO on ppc/mac",
73 .base = 0xf510,
74 .size = 0x03,
75 .ctrl_offset = 0x00,
76 .data_offset = 0x02,
77 .is_mmio = true,
78 }, { } /* END */
79 };
80
81 /* fw_cfg device i/o currently selected option set */
82 static struct fw_cfg_access *fw_cfg_mode;
83
84 /* fw_cfg device i/o register addresses */
85 static void __iomem *fw_cfg_dev_base;
86 static void __iomem *fw_cfg_reg_ctrl;
87 static void __iomem *fw_cfg_reg_data;
88
89 /* atomic access to fw_cfg device (potentially slow i/o, so using
mutex) */
90 static DEFINE_MUTEX(fw_cfg_dev_lock);
91
92 /* pick appropriate endianness for selector key */
93 static inline u16 fw_cfg_sel_endianness(u16 key)
94 {
> 95 return fw_cfg_mode->is_mmio ? cpu_to_be16(key) :
cpu_to_le16(key);
96 }
97
98 /* type for fw_cfg "directory scan" visitor/callback function */
99 typedef int (*fw_cfg_file_callback)(const struct fw_cfg_file *f);
100
101 /* run a given callback on each fw_cfg directory entry */
102 static int fw_cfg_scan_dir(fw_cfg_file_callback callback)
103 {
104 int ret = 0;
105 u32 count, i;
106 struct fw_cfg_file f;
107
108 mutex_lock(_cfg_dev_lock);
109 iowrite16(fw_cfg_sel_endianness(FW_CFG_FILE_DIR),
fw_cfg_reg_ctrl);
110 ioread8_rep(fw_cfg_reg_data, , sizeof(count));
> 111 for (i = 0; i < be32_to_cpu(count); i++) {
112 ioread8_rep(fw_cfg_reg_data, , sizeof(f));
113 ret = callback();
114 if (ret)
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [RFC PATCHv2] x86/pci: Initial commit for new VMD device driver
Hi Keith,
[auto build test results on v4.3-rc3 -- if it's inappropriate base, please
ignore]
config: i386-randconfig-h1-10040721 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
In file included from arch/x86/pci/vmd.c:25:0:
>> arch/x86/include/asm/vmd.h:34:13: warning: 'vmd_add_dma_device' defined but
>> not used [-Wunused-function]
static void vmd_add_dma_device(struct vmd_dev *vmd) {}
^
>> arch/x86/include/asm/vmd.h:35:13: warning: 'vmd_del_dma_device' defined but
>> not used [-Wunused-function]
static void vmd_del_dma_device(struct vmd_dev *vmd) {}
^
vim +/vmd_add_dma_device +34 arch/x86/include/asm/vmd.h
28 struct irq_domain *arch_create_vmd_msi_irq_domain(struct pci_dev *dev,
29 const struct irq_domain_ops
*domain_ops);
30 #ifdef CONFIG_X86_DEV_DMA_OPS
31 void vmd_add_dma_device(struct vmd_dev *vmd);
32 void vmd_del_dma_device(struct vmd_dev *vmd);
33 #else
> 34 static void vmd_add_dma_device(struct vmd_dev *vmd) {}
> 35 static void vmd_del_dma_device(struct vmd_dev *vmd) {}
36 #endif
37
38 #endif
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags
On 10/3/15 4:44 PM, Nishanth Menon wrote: On 10/02/2015 11:09 AM, santosh shilimkar wrote: Nishant, On 9/25/2015 10:38 AM, Nishanth Menon wrote: On 09/25/2015 11:15 AM, santosh shilimkar wrote: 9/25/2015 9:01 AM, Nishanth Menon wrote: [..] Please refresh the series commit messages based on the discussion so far and repost. Will pick it up then. Thanks. I will do so (probably early next week).. Just want to check if you have series ready. I was planning to make queue ready over the weekend for upcoming merge window. I can hold that for another week though so let me know. Apologies on the delay. Update series was send: https://patchwork.kernel.org/patch/7322821/ https://patchwork.kernel.org/patch/7322831/ https://patchwork.kernel.org/patch/7322841/ No worries. Should show up in linux-next soon. I will let it sit there along with other patches for few more days and then send it up. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 0/3] ARM: dts/keystone: Introduce SoC specific compatible matches
On 10/3/15 4:38 PM, Nishanth Menon wrote: Hi, Round 2 of the series with updated patch #1. This series introduces SoC specific dt compatible property to allow for future SoCs to be handled and for userspace applications that can introduce features based on SoC they are functioning on. V1 of the series: http://marc.info/?l=devicetree=144309031109988=2 V2 of the series has the following changes: - updated commit message in patch #1 - picked up acked-by for patch #1 Series based on v4.3-rc1 Queued up for 4.4. Thanks !! Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] asm-generic/pci_iomap.h: make custom PCI BAR requirements explicit
On 10/02/15 16:17, Luis R. Rodriguez wrote: > On Fri, Aug 28, 2015 at 07:13:08PM -0700, Randy Dunlap wrote: >> On 08/28/15 17:17, Luis R. Rodriguez wrote: >>> >>> arch/s390/Kconfig | 8 + >>> arch/s390/include/asm/io.h| 11 --- >>> arch/s390/include/asm/pci.h | 2 -- >>> arch/s390/include/asm/pci_iomap.h | 33 + >>> arch/s390/pci/pci.c | 2 ++ >>> include/asm-generic/io.h | 12 >>> include/asm-generic/iomap.h | 10 --- >>> include/asm-generic/pci_iomap.h | 62 >>> +++ >>> lib/Kconfig | 1 + >>> lib/pci_iomap.c | 5 >>> 10 files changed, 105 insertions(+), 41 deletions(-) >>> create mode 100644 arch/s390/include/asm/pci_iomap.h >>> >>> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig >>> index 1d57000b1b24..1217b7db4265 100644 >>> --- a/arch/s390/Kconfig >>> +++ b/arch/s390/Kconfig >>> @@ -614,6 +614,14 @@ endif # PCI >>> config PCI_DOMAINS >>> def_bool PCI >>> >>> +config ARCH_PCI_NON_DISJUNCTIVE >>> + def_bool PCI >>> + help >>> + On the S390 architecture PCI BAR spaces are not disjunctive, as such >> >> are not disjoint? may be overlapping? >> >>> + the PCI bar is required on a series of otherwise asm generic PCI >>> + routines, as such S390 requires itw own implemention for these >> >>its own implementation > > Thanks, I've re-written this as: > > mcgrof@ergon ~/linux-next (git::(no branch, rebasing 20150805-pend-all))$ git > diff > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index f4725d1af438..8ba5826ed13b 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -618,10 +618,10 @@ config PCI_DOMAINS > config ARCH_PCI_NON_DISJUNCTIVE > def_bool PCI > help > - On the S390 architecture PCI BAR spaces are not disjunctive, as such > - the PCI bar is required on a series of otherwise asm generic PCI > - routines, as such S390 requires itw own implemention for these > - routines. > + On the S390 architecture PCI BAR spaces may overlap with each other, That "other," should not end with a comma. Either use a semi-colon or use a period and begin the next sentence with Because. > + because of this the PCI bar is required on a series of otherwise asm > + generic PCI routines and this in turn requires S390 to provide its > + own implementation for these routines. > > config HAS_IOMEM > def_bool PCI >> -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing operand for tlbie instruction on Power7
On Fri, Oct 02, 2015 at 09:24:46PM -0500, Peter Bergner wrote: > > > Ok, than we can just zero out r5 for example and use it in tlbie as RS, > > > right? > > > > That won't assemble _unless_ your assembler is in POWER7 mode. It also > > won't do the right thing at run time on older machines. > > Correct, getting this to work on both pre-power7 and power7 and later > is tricky. One really horrible hack would be to do: > > li r0,0 > tlbie r4,0 > > On pre-power7, the "0" will be taken as a zero L operand and on > power7 and later, it'll be r0, but with a zero value we loaded in > the insn before. I know, really ugly. :-) Hide the "li 0,0" somewhere earlier, and write it as "tlbie 4,0", and don't write a comment -- we *like* tricky! It should really be a separate macro define for power7 and 4xx etc.; and the macro should not be called "tlbia", but something that makes it obvious at the usage sites that it is in fact a macro; and why a macro anyway, a function call might be better here? Segher -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags
On 10/02/2015 11:09 AM, santosh shilimkar wrote: > Nishant, > > On 9/25/2015 10:38 AM, Nishanth Menon wrote: >> On 09/25/2015 11:15 AM, santosh shilimkar wrote: >>> 9/25/2015 9:01 AM, Nishanth Menon wrote: > > [..] > >>> Please refresh the series commit messages based on the >>> discussion so far and repost. Will pick it up then. >>> >> Thanks. I will do so (probably early next week).. >> > Just want to check if you have series ready. I was planning > to make queue ready over the weekend for upcoming merge > window. I can hold that for another week though so let > me know. Apologies on the delay. Update series was send: https://patchwork.kernel.org/patch/7322821/ https://patchwork.kernel.org/patch/7322831/ https://patchwork.kernel.org/patch/7322841/ -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 3/3] ARM: dts: keystone: Update SoC specific compatible flags
Update the compatible flags to allow specific SoC identification.
Signed-off-by: Nishanth Menon
---
V2: No change
V1: https://patchwork.kernel.org/patch/7240911/
arch/arm/boot/dts/k2e-evm.dts | 2 +-
arch/arm/boot/dts/k2e.dtsi | 3 +++
arch/arm/boot/dts/k2hk-evm.dts | 2 +-
arch/arm/boot/dts/k2hk.dtsi | 3 +++
arch/arm/boot/dts/k2l-evm.dts | 2 +-
arch/arm/boot/dts/k2l.dtsi | 3 +++
arch/arm/boot/dts/keystone.dtsi | 1 +
7 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/k2e-evm.dts b/arch/arm/boot/dts/k2e-evm.dts
index 50c83c21d911..b7e99807f5c2 100644
--- a/arch/arm/boot/dts/k2e-evm.dts
+++ b/arch/arm/boot/dts/k2e-evm.dts
@@ -13,7 +13,7 @@
#include "k2e.dtsi"
/ {
- compatible = "ti,k2e-evm","ti,keystone";
+ compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone";
model = "Texas Instruments Keystone 2 Edison EVM";
soc {
diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 675fb8e492c6..1097dada56d2 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -9,6 +9,9 @@
*/
/ {
+ compatible = "ti,k2e", "ti,keystone";
+ model = "Texas Instruments Keystone 2 Edison SoC";
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/k2hk-evm.dts b/arch/arm/boot/dts/k2hk-evm.dts
index 660ebf58d547..8161bf53271b 100644
--- a/arch/arm/boot/dts/k2hk-evm.dts
+++ b/arch/arm/boot/dts/k2hk-evm.dts
@@ -13,7 +13,7 @@
#include "k2hk.dtsi"
/ {
- compatible = "ti,k2hk-evm","ti,keystone";
+ compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking EVM";
soc {
diff --git a/arch/arm/boot/dts/k2hk.dtsi b/arch/arm/boot/dts/k2hk.dtsi
index d0810a5f2968..ada4c7ac96e7 100644
--- a/arch/arm/boot/dts/k2hk.dtsi
+++ b/arch/arm/boot/dts/k2hk.dtsi
@@ -9,6 +9,9 @@
*/
/ {
+ compatible = "ti,k2hk", "ti,keystone";
+ model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/k2l-evm.dts b/arch/arm/boot/dts/k2l-evm.dts
index 9a69a6b55374..00861244d788 100644
--- a/arch/arm/boot/dts/k2l-evm.dts
+++ b/arch/arm/boot/dts/k2l-evm.dts
@@ -13,7 +13,7 @@
#include "k2l.dtsi"
/ {
- compatible = "ti,k2l-evm","ti,keystone";
+ compatible = "ti,k2l-evm", "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr EVM";
soc {
diff --git a/arch/arm/boot/dts/k2l.dtsi b/arch/arm/boot/dts/k2l.dtsi
index 49fd414f680c..4446da72b0ae 100644
--- a/arch/arm/boot/dts/k2l.dtsi
+++ b/arch/arm/boot/dts/k2l.dtsi
@@ -9,6 +9,9 @@
*/
/ {
+ compatible = "ti,k2l", "ti,keystone";
+ model = "Texas Instruments Keystone 2 Lamarr SoC";
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 72816d65f7ec..ff91f703d371 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -12,6 +12,7 @@
#include "skeleton.dtsi"
/ {
+ compatible = "ti,keystone";
model = "Texas Instruments Keystone 2 SoC";
#address-cells = <2>;
#size-cells = <2>;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 0/3] ARM: dts/keystone: Introduce SoC specific compatible matches
Hi, Round 2 of the series with updated patch #1. This series introduces SoC specific dt compatible property to allow for future SoCs to be handled and for userspace applications that can introduce features based on SoC they are functioning on. V1 of the series: http://marc.info/?l=devicetree=144309031109988=2 V2 of the series has the following changes: - updated commit message in patch #1 - picked up acked-by for patch #1 Series based on v4.3-rc1 Tested on v4.3-rc3: http://pastebin.ubuntu.com/12659000/ Nishanth Menon (3): Documentation: dt: keystone: provide SoC specific compatible flags ARM: keystone: Update compatible to have SoC specific matches ARM: dts: keystone: Update SoC specific compatible flags .../devicetree/bindings/arm/keystone/keystone.txt| 20 +--- arch/arm/boot/dts/k2e-evm.dts| 2 +- arch/arm/boot/dts/k2e.dtsi | 3 +++ arch/arm/boot/dts/k2hk-evm.dts | 2 +- arch/arm/boot/dts/k2hk.dtsi | 3 +++ arch/arm/boot/dts/k2l-evm.dts| 2 +- arch/arm/boot/dts/k2l.dtsi | 3 +++ arch/arm/boot/dts/keystone.dtsi | 1 + arch/arm/mach-keystone/keystone.c| 3 +++ 9 files changed, 33 insertions(+), 6 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 1/3] Documentation: dt: keystone: provide SoC specific compatible flags
Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms for the
following reasons:
a) Userspace applications have no way of knowing which SoC they are
functioning, providing the compatible matches provide a mechanism for
them to enable SoC specific functionality. Such userspace applications
are typically automated test framework or SoC custom hardware
acceleration entitlement from a common file system.
b) Provides an accurate hardware description. This allows
SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.
Hence, provide compatible matches for each SoC in the Keystone family.
Acked-By: Murali Karicheri
Signed-off-by: Nishanth Menon
---
Changes since V2:
- elaborated reasoning why this change is useful - highlighted
potential userspace usage as well.
- picked up Acked-by from Murali
V1: https://patchwork.kernel.org/patch/7240891/
.../devicetree/bindings/arm/keystone/keystone.txt| 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 59d7a46f85eb..800d2d02e27b 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -9,12 +9,26 @@ Required properties:
the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
type UART should use the specified compatible for those devices.
+SoC families:
+
+- Keystone 2 generic SoC:
+ compatible = "ti,keystone"
+
+SoCs:
+
+- Keystone 2 Hawking/Kepler
+ compatible = ti,k2hk", "ti,keystone"
+- Keystone 2 Lamarr
+ compatible = ti,k2l", "ti,keystone"
+- Keystone 2 Edison
+ compatible = ti,k2e", "ti,keystone"
+
Boards:
- Keystone 2 Hawking/Kepler EVM
- compatible = "ti,k2hk-evm","ti,keystone"
+ compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
- Keystone 2 Lamarr EVM
- compatible = "ti,k2l-evm","ti,keystone"
+ compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
- Keystone 2 Edison EVM
- compatible = "ti,k2e-evm","ti,keystone"
+ compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
From: Gabriel Somlo
Instead of blindly probing fw_cfg registers at known IOport and MMIO
locations, use the ACPI subsystem to determine whether a QEMU fw_cfg
device is present, and, if found, to initialize it.
This limits portability to architectures which support ACPI (x86 and
UEFI-enabled aarch64), but avoids touching hardware registers before
being certain that our device is present.
NOTE: The standard way to verify the presence of fw_cfg on arm VMs
would have been to use the device tree, but that would have left out
x86, which is the primary architecture targeted by this patch.
Signed-off-by: Gabriel Somlo
---
.../ABI/testing/sysfs-firmware-qemu_fw_cfg | 4 +
drivers/firmware/Kconfig | 2 +-
drivers/firmware/qemu_fw_cfg.c | 201 +++--
3 files changed, 113 insertions(+), 94 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
index f1ef44e..e9761bf 100644
--- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
+++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
@@ -76,6 +76,10 @@ Description:
the port number of the control register. I.e., the two ports
are overlapping, and can not be mapped separately.
+ NOTE 2. QEMU publishes the register details in the device tree
+ on arm guests, and in ACPI (under _HID "QEMU0002") on x86 and
+ select arm (aarch64) VM types.
+
=== Firmware Configuration Items of Interest ===
Originally, the index key, size, and formatting of blobs in
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 0466e80..bc12d31 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -137,7 +137,7 @@ config ISCSI_IBFT
config FW_CFG_SYSFS
tristate "QEMU fw_cfg device support in sysfs"
- depends on SYSFS
+ depends on SYSFS && ACPI
default n
help
Say Y or M here to enable the exporting of the QEMU firmware
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 3a67a16..f935afb 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
#include
@@ -35,53 +36,10 @@ struct fw_cfg_file {
char name[FW_CFG_MAX_FILE_PATH];
};
-/* fw_cfg device i/o access options type */
-struct fw_cfg_access {
- const char *name;
- phys_addr_t base;
- u8 size;
- u8 ctrl_offset;
- u8 data_offset;
- bool is_mmio;
-};
-
-/* table of fw_cfg device i/o access options for known architectures */
-static struct fw_cfg_access fw_cfg_modes[] = {
- {
- .name = "fw_cfg IOport on i386, sun4u",
- .base = 0x510,
- .size = 0x02,
- .ctrl_offset = 0x00,
- .data_offset = 0x01,
- .is_mmio = false,
- }, {
- .name = "fw_cfg MMIO on arm",
- .base = 0x902,
- .size = 0x0a,
- .ctrl_offset = 0x08,
- .data_offset = 0x00,
- .is_mmio = true,
- }, {
- .name = "fw_cfg MMIO on sun4m",
- .base = 0xd0510,
- .size = 0x03,
- .ctrl_offset = 0x00,
- .data_offset = 0x02,
- .is_mmio = true,
- }, {
- .name = "fw_cfg MMIO on ppc/mac",
- .base = 0xf510,
- .size = 0x03,
- .ctrl_offset = 0x00,
- .data_offset = 0x02,
- .is_mmio = true,
- }, { } /* END */
-};
-
-/* fw_cfg device i/o currently selected option set */
-static struct fw_cfg_access *fw_cfg_mode;
-
/* fw_cfg device i/o register addresses */
+static bool fw_cfg_is_mmio;
+static phys_addr_t fw_cfg_phys_base;
+static u32 fw_cfg_phys_size;
static void __iomem *fw_cfg_dev_base;
static void __iomem *fw_cfg_reg_ctrl;
static void __iomem *fw_cfg_reg_data;
@@ -92,7 +50,7 @@ static DEFINE_MUTEX(fw_cfg_dev_lock);
/* pick appropriate endianness for selector key */
static inline u16 fw_cfg_sel_endianness(u16 key)
{
- return fw_cfg_mode->is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
+ return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key);
}
/* type for fw_cfg "directory scan" visitor/callback function */
@@ -133,60 +91,100 @@ static inline void fw_cfg_read_blob(u16 key,
/* clean up fw_cfg device i/o */
static void fw_cfg_io_cleanup(void)
{
- if (fw_cfg_mode->is_mmio) {
+ if (fw_cfg_is_mmio) {
iounmap(fw_cfg_dev_base);
- release_mem_region(fw_cfg_mode->base, fw_cfg_mode->size);
+ release_mem_region(fw_cfg_phys_base, fw_cfg_phys_size);
} else {
ioport_unmap(fw_cfg_dev_base);
-
[PATCH v3 3/4] kobject: export kset_find_obj() for module use
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 3e3a5c3..bea2c9b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -842,6 +842,7 @@ struct kobject *kset_find_obj(struct kset *kset, const char
*name)
spin_unlock(>list_lock);
return ret;
}
+EXPORT_SYMBOL(kset_find_obj);
static void kset_release(struct kobject *kobj)
{
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on overall similarity to the type of information
exposed under /sys/firmware/dmi/entries/...
NEW (since v2): Using ACPI to detect the presence and details of the
fw_cfg virtual hardware device.
Device Tree has been suggested by Ard as a comment on v2 of this
patch, but after some deliberation I decided to go with ACPI,
since it's supported on both x86 and some (uefi-enabled) versions
of aarch64. I really don't see how I'd reasonably use *both* DT (on
ARM) *and* ACPI (on x86), and after all I'm mostly concerned with
x86, but originally wanted to maximize portability (which is where
the register probing in earlier versions came from).
A patch set generating an ACPI device node for qemu's fw_cfg is
currently under review on the qemu-devel list:
http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg06946.html
(sorry, gmane appears down at the moment...)
In consequence:
- Patch 1/4 is mostly the same as in v2;
- Patch 2/4 switches device initialization from register
probing to using ACPI; this is a separate patch only to
illustrate the transition from probing to ACPI, and I'm
assuming it will end up squashed on top of patch 1/4 in
the final version.
- Patches 3/4 and 4/4 add a "human-readable" directory
hierarchy built from tokenizing fw_cfg blob names into
'/'-separated components, with symlinks to each 'by_key'
blob folder (same as in earlier versions). At Greg's
suggestion I tried to build this folder hierarchy and
leaf symlinks using udev rules, but so far I haven't been
successful in figuring that out. If udev turns out to
be applicable after all, these two patches can be dropped
from this series.
In other words, patches 1 and 2 give us the following "by_key" listing
of blobs contained in the qemu fw_cfg device (example pulled from a PC
qemu guest running Fedora 22), with the value of each "name" attribute
shown on the right:
$ tree /sys/firmware/qemu_fw_cfg/
/sys/firmware/qemu_fw_cfg/
|-- by_key
| |-- 32
| | |-- key
| | |-- name("etc/boot-fail-wait")
| | |-- raw
| | `-- size
| |-- 33
| | |-- key
| | |-- name("etc/smbios/smbios-tables")
| | |-- raw
| | `-- size
| |-- 34
| | |-- key
| | |-- name("etc/smbios/smbios-anchor")
| | |-- raw
| | `-- size
| |-- 35
| | |-- key
| | |-- name("etc/e820")
| | |-- raw
| | `-- size
| |-- 36
| | |-- key
| | |-- name("genroms/kvmvapic.bin")
| | |-- raw
| | `-- size
| |-- 37
| | |-- key
| | |-- name("etc/system-states")
| | |-- raw
| | `-- size
| |-- 38
| | |-- key
| | |-- name("etc/acpi/tables")
| | |-- raw
| | `-- size
| |-- 39
| | |-- key
| | |-- name("etc/table-loader")
| | |-- raw
| | `-- size
| |-- 40
| | |-- key
| | |-- name("etc/tpm/log")
| | |-- raw
| | `-- size
| |-- 41
| | |-- key
| | |-- name("etc/acpi/rsdp")
| | |-- raw
| | `-- size
| `-- 42
| |-- key
| |-- name("bootorder")
| |-- raw
| `-- size
|
...
Additionally, patches 3 and 4 (mostly 4) give us the following
"user friendly" directory hierarchy as a complement to the above,
based on tokenizing each blob name into symlink-tipped (sub)directories:
...
|-- by_name
| |-- bootorder -> ../by_key/42
| |-- etc
| | |-- acpi
| | | |-- rsdp -> ../../../by_key/41
| | | `-- tables -> ../../../by_key/38
| | |-- boot-fail-wait -> ../../by_key/32
| | |-- e820 -> ../../by_key/35
| | |-- smbios
| | | |-- smbios-anchor -> ../../../by_key/34
| | | `-- smbios-tables -> ../../../by_key/33
| | |-- system-states -> ../../by_key/37
| | |-- table-loader -> ../../by_key/39
| | `-- tpm
| | `-- log -> ../../../by_key/40
| `-- genroms
| `-- kvmvapic.bin -> ../../by_key/36
`-- rev
The trick is to figure out how to replace patches 3 and 4 with a
udev rule that would read the contents of each "name" attribute,
and build the "by_name" hierarchy and symlinks in userspace.
I tried:
$ udevadm info -a -p /sys/firmware/qemu_fw_cfg/by_key/33
looking at device '/firmware/qemu_fw_cfg/by_key/33':
KERNEL=="33"
SUBSYSTEM==""
DRIVER==""
ATTR{key}=="33"
[PATCH v3 1/4] firmware: introduce sysfs driver for QEMU's fw_cfg device
From: Gabriel Somlo Make fw_cfg entries of type "file" available via sysfs. Entries are listed under /sys/firmware/qemu_fw_cfg/by_key, in folders named after each entry's selector key. Filename, selector value, and size read-only attributes are included for each entry. Also, a "raw" attribute allows retrieval of the full binary content of each entry. This patch also provides a documentation file outlining the guest-side "hardware" interface exposed by the QEMU fw_cfg device. Signed-off-by: Gabriel Somlo --- .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 167 drivers/firmware/Kconfig | 10 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 456 + 4 files changed, 634 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg new file mode 100644 index 000..f1ef44e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg @@ -0,0 +1,167 @@ +What: /sys/firmware/qemu_fw_cfg/ +Date: August 2015 +Contact: Gabriel Somlo +Description: + Several different architectures supported by QEMU (x86, arm, + sun4*, ppc/mac) are provisioned with a firmware configuration + (fw_cfg) device, used by the host to provide configuration data + to the starting guest. While most of this data is meant for use + by the guest firmware, starting with QEMU v2.4, guest VMs may + be given arbitrary fw_cfg entries supplied directly on the + command line, which therefore may be of interest to userspace. + + === Guest-side Hardware Interface === + + The fw_cfg device is available to guest VMs as a register pair + (control and data), accessible as either a IO ports or as MMIO + addresses, depending on the architecture. + + --- Control Register --- + + Width: 16-bit + Access: Write-Only + Endianness: LE (if IOport) or BE (if MMIO) + + A write to the control register selects the index for one of + the firmware configuration items (or "blobs") available on the + fw_cfg device, which can subsequently be read from the data + register. + + Each time the control register is written, an data offset + internal to the fw_cfg device will be set to zero. This data + offset impacts which portion of the selected fw_cfg blob is + accessed by reading the data register, as explained below. + + --- Data Register --- + + Width: 8-bit (if IOport), or 8/16/32/64-bit (if MMIO) + Access: Read-Only + Endianness: string preserving + + The data register allows access to an array of bytes which + represent the fw_cfg blob last selected by a write to the + control register. + + Immediately following a write to the control register, the data + offset will be set to zero. Each successful read access to the + data register will increment the data offset by the appropriate + access width. + + Each fw_cfg blob has a maximum associated data length. Once the + data offset exceeds this maximum length, any subsequent reads + via the data register will return 0x00. + + An N-byte wide read of the data register will return the next + available N bytes of the selected fw_cfg blob, as a substring, + in increasing address order, similar to memcpy(), zero-padded + if necessary should the maximum data length of the selected + item be reached, as described above. + + --- Per-arch Register Details --- + + - + archaccess base ctrlctrldatamax. + modeaddress offset endian offset data + (bytes) (bytes) + - + x86*IOport0x510 0 LE 1 1 + arm MMIO 0x902 8 BE 0 8 + sun4u IOport0x510 0 LE 1 1 + sun4m MMIO0xd0510 0 BE 2 1 + ppc/mac MMIO 0xf510 0 BE 2 1 + - + +
[PATCH v3 4/4] firmware: create directory hierarchy for sysfs fw_cfg entries
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") to descriptively name the
various fw_cfg "blobs" passed into the guest.
This patch attempts, on a best effort basis, to create a
directory hierarchy representing the content of fw_cfg file
names, under /sys/firmware/qemu_fw_cfg/by_name.
Upon successful creation of all directories representing the
"dirname" portion of a fw_cfg file, a symlink will be created
to represent the "basename", pointing at the appropriate
/sys/firmware/qemu_fw_cfg/by_key entry. If a file name is not
suitable for this procedure (e.g., if its basename or dirname
components collide with an already existing dirname component
or basename, respectively) the corresponding fw_cfg blob is
skipped and will remain available in sysfs only by its selector
key value.
Signed-off-by: Gabriel Somlo
---
.../ABI/testing/sysfs-firmware-qemu_fw_cfg | 42 +
drivers/firmware/qemu_fw_cfg.c | 104 +
2 files changed, 146 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
index e9761bf..2e3eaba 100644
--- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
+++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg
@@ -169,3 +169,45 @@ Description:
entry via the control register, and reading a number
of bytes equal to the blob size from the data
register.
+
+ --- Listing fw_cfg blobs by file name ---
+
+ While the fw_cfg device does not impose any specific naming
+ convention on the blobs registered in the file directory,
+ QEMU developers have traditionally used path name semantics
+ to give each blob a descriptive name. For example:
+
+ "bootorder"
+ "genroms/kvmvapic.bin"
+ "etc/e820"
+ "etc/boot-fail-wait"
+ "etc/system-states"
+ "etc/table-loader"
+ "etc/acpi/rsdp"
+ "etc/acpi/tables"
+ "etc/smbios/smbios-tables"
+ "etc/smbios/smbios-anchor"
+ ...
+
+ In addition to the listing by unique selector key described
+ above, the fw_cfg sysfs driver also attempts to build a tree
+ of directories matching the path name components of fw_cfg
+ blob names, ending in symlinks to the by_key entry for each
+ "basename", as illustrated below (assume current directory is
+ /sys/firmware):
+
+ qemu_fw_cfg/by_name/bootorder -> ../by_key/38
+ qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
+ qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
+ ...
+
+ Construction of the directory tree and symlinks is done on a
+ "best-effort" basis, as there is no guarantee that components
+ of fw_cfg blob names are always "well behaved". I.e., there is
+ the possibility that a symlink (basename) will conflict with
+ a dirname component of another fw_cfg blob, in which case the
+ creation of the offending /sys/firmware/qemu_fw_cfg/by_name
+ entry will be skipped.
+
+ The authoritative list of entries will continue to be found
+ under the /sys/firmware/qemu_fw_cfg/by_key directory.
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index f935afb..880f8ff 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -346,9 +346,104 @@ static struct bin_attribute fw_cfg_sysfs_attr_raw = {
.read = fw_cfg_sysfs_read_raw,
};
+/*
+ * Create a kset subdirectory matching each '/' delimited dirname token
+ * in 'name', starting with sysfs kset/folder 'dir'; At the end, create
+ * a symlink directed at the given 'target'.
+ * NOTE: We do this on a best-effort basis, since 'name' is not guaranteed
+ * to be a well-behaved path name. Whenever a symlink vs. kset directory
+ * name collision occurs, the kernel will issue big scary warnings while
+ * refusing to add the offending link or directory. We follow up with our
+ * own, slightly less scary error messages explaining the situation :)
+ */
+static int __init fw_cfg_build_symlink(struct kset *dir,
+ struct kobject *target,
+ const char *name)
+{
+ int ret;
+ struct kset *subdir;
+ struct kobject
[PATCH V2 2/3] ARM: keystone: Update compatible to have SoC specific matches
With future SoCs of keystone2 family, the generic compatible match
may not be sufficient to handle SoC specific handling. So introduce
matches based on SoC compatiblity.
Signed-off-by: Nishanth Menon
---
Changes in V2:
- reformatting of commit message. no functional change
V1: https://patchwork.kernel.org/patch/7240901/
arch/arm/mach-keystone/keystone.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index e288010522f9..c279293f084c 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -97,6 +97,9 @@ static long long __init keystone_pv_fixup(void)
}
static const char *const keystone_match[] __initconst = {
+ "ti,k2hk",
+ "ti,k2e",
+ "ti,k2l",
"ti,keystone",
NULL,
};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.
On Sun, Oct 4, 2015 at 3:33 AM, Meelis Roos wrote: >> This is 4.3.0-rc1 on Sun E220R (dual-CPU sparc64). Sometimes it boots, >> sometimes it fails to boot with looping errors and finally a watchdog >> timeout. This console log from a failure. Config is below. > > I noticed blk-mq related changes in todays git. Retested, loop_init > still causes the same blk-mq problem. > [ 100.063323] blk_mq_sysfs_init: init hctx_kobj f800ad8b95f8 0 > [ 100.135151] blk_mq_sysfs_init: init ctx_kobj f800af80cdd8 0 > [ 100.205952] blk_mq_sysfs_init: init ctx_kobj 009f2dd8 1 > [ 100.276785] kobject (009f2dd8): tried to init an initialized > object, something is seriously wrong. >From the debug log, the issue happened on ctx_kobj which is one percpu variable, and looks it can't be initialized by blk-mq more than one time. I suspect it may be one memory issue, especiall in percpu allocation. The percpu variable's address for the offline CPU1 is a bit special, not like the other two online CPUs. And it might be helpful to enalbe 'Per cpu operations test' in' Kernel hacking --->'/'Runtime Testing' of Kconfig to see if it can pass the test. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] scsi: dpt: remove i2o header in uapi
The i2o subsystem was removed by
commit 4a72a7af462d ("staging: remove i2o subsystem") but the header was
still used by drivers/scsi/dpt_i2o.c driver.
This patch moves the structures used from the header into dpti_i2o.h.
CC: Arnd Bergmann
CC: Greg Kroah-Hartman
Signed-off-by: Gabriel Laskar
---
drivers/scsi/dpt/dpti_i2o.h | 134 +-
include/uapi/linux/Kbuild| 1 -
include/uapi/linux/i2o-dev.h | 421 ---
3 files changed, 132 insertions(+), 424 deletions(-)
delete mode 100644 include/uapi/linux/i2o-dev.h
diff --git a/drivers/scsi/dpt/dpti_i2o.h b/drivers/scsi/dpt/dpti_i2o.h
index bd9e31e..50515d3 100644
--- a/drivers/scsi/dpt/dpti_i2o.h
+++ b/drivers/scsi/dpt/dpti_i2o.h
@@ -19,8 +19,6 @@
#ifdef __KERNEL__ /* This file to be included by kernel only */
-#include
-
#include
#include
@@ -41,6 +39,137 @@
#define I2O_MAX_MANAGERS 4
+#define I2O_BUS_LOCAL 0
+#define I2O_BUS_ISA1
+#define I2O_BUS_EISA 2
+/* was I2O_BUS_MCA3 */
+#define I2O_BUS_PCI4
+#define I2O_BUS_PCMCIA 5
+#define I2O_BUS_NUBUS 6
+#define I2O_BUS_CARDBUS 7
+#define I2O_BUS_UNKNOWN 0x80
+
+typedef struct _i2o_pci_bus {
+ __u8 PciFunctionNumber;
+ __u8 PciDeviceNumber;
+ __u8 PciBusNumber;
+ __u8 reserved;
+ __u16 PciVendorID;
+ __u16 PciDeviceID;
+} i2o_pci_bus;
+
+typedef struct _i2o_local_bus {
+ __u16 LbBaseIOPort;
+ __u16 reserved;
+ __u32 LbBaseMemoryAddress;
+} i2o_local_bus;
+
+typedef struct _i2o_isa_bus {
+ __u16 IsaBaseIOPort;
+ __u8 CSN;
+ __u8 reserved;
+ __u32 IsaBaseMemoryAddress;
+} i2o_isa_bus;
+
+typedef struct _i2o_eisa_bus_info {
+ __u16 EisaBaseIOPort;
+ __u8 reserved;
+ __u8 EisaSlotNumber;
+ __u32 EisaBaseMemoryAddress;
+} i2o_eisa_bus;
+
+typedef struct _i2o_mca_bus {
+ __u16 McaBaseIOPort;
+ __u8 reserved;
+ __u8 McaSlotNumber;
+ __u32 McaBaseMemoryAddress;
+} i2o_mca_bus;
+
+typedef struct _i2o_other_bus {
+ __u16 BaseIOPort;
+ __u16 reserved;
+ __u32 BaseMemoryAddress;
+} i2o_other_bus;
+
+typedef struct _i2o_hrt_entry {
+ __u32 adapter_id;
+ __u32 parent_tid:12;
+ __u32 state:4;
+ __u32 bus_num:8;
+ __u32 bus_type:8;
+ union {
+ i2o_pci_bus pci_bus;
+ i2o_local_bus local_bus;
+ i2o_isa_bus isa_bus;
+ i2o_eisa_bus eisa_bus;
+ i2o_mca_bus mca_bus;
+ i2o_other_bus other_bus;
+ } bus;
+} i2o_hrt_entry;
+
+typedef struct _i2o_hrt {
+ __u16 num_entries;
+ __u8 entry_len;
+ __u8 hrt_version;
+ __u32 change_ind;
+ i2o_hrt_entry hrt_entry[1];
+} i2o_hrt;
+
+typedef struct _i2o_lct_entry {
+ __u32 entry_size:16;
+ __u32 tid:12;
+ __u32 reserved:4;
+ __u32 change_ind;
+ __u32 device_flags;
+ __u32 class_id:12;
+ __u32 version:4;
+ __u32 vendor_id:16;
+ __u32 sub_class;
+ __u32 user_tid:12;
+ __u32 parent_tid:12;
+ __u32 bios_info:8;
+ __u8 identity_tag[8];
+ __u32 event_capabilities;
+} i2o_lct_entry;
+
+typedef struct _i2o_lct {
+ __u32 table_size:16;
+ __u32 boot_tid:12;
+ __u32 lct_ver:4;
+ __u32 iop_flags;
+ __u32 change_ind;
+ i2o_lct_entry lct_entry[1];
+} i2o_lct;
+
+typedef struct _i2o_status_block {
+ __u16 org_id;
+ __u16 reserved;
+ __u16 iop_id:12;
+ __u16 reserved1:4;
+ __u16 host_unit_id;
+ __u16 segment_number:12;
+ __u16 i2o_version:4;
+ __u8 iop_state;
+ __u8 msg_type;
+ __u16 inbound_frame_size;
+ __u8 init_code;
+ __u8 reserved2;
+ __u32 max_inbound_frames;
+ __u32 cur_inbound_frames;
+ __u32 max_outbound_frames;
+ char product_id[24];
+ __u32 expected_lct_size;
+ __u32 iop_capabilities;
+ __u32 desired_mem_size;
+ __u32 current_mem_size;
+ __u32 current_mem_base;
+ __u32 desired_io_size;
+ __u32 current_io_size;
+ __u32 current_io_base;
+ __u32 reserved3:24;
+ __u32 cmd_status:8;
+} i2o_status_block;
+
/*
* I2O Interface Objects
*/
@@ -131,6 +260,7 @@ struct i2o_sys_tbl
struct i2o_sys_tbl_entry iops[0];
};
+
/*
* I2O classes / subclasses
*/
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index f7b2db4..38f6e50 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -151,7 +151,6 @@ header-y += hyperv.h
header-y += hysdn_if.h
header-y += i2c-dev.h
header-y += i2c.h
-header-y += i2o-dev.h
header-y += i8k.h
header-y += icmp.h
header-y += icmpv6.h
diff --git a/include/uapi/linux/i2o-dev.h b/include/uapi/linux/i2o-dev.h
deleted file mode 100644
index a8093bf..000
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Re: [PATCH v6 2/2] efi: a misc char interface for user to update efi firmware
On Thu, Oct 1, 2015 at 2:05 PM, Kweh, Hock Leong
wrote:
> From: "Kweh, Hock Leong"
>
> Introducing a kernel module to expose capsule loader interface
> (misc char device file note) for user to upload capsule binaries.
>
> Example method to load the capsule binary:
> cat firmware.bin > /dev/efi_capsule_loader
>
> Cc: Matt Fleming
> Signed-off-by: Kweh, Hock Leong
> ---
> drivers/firmware/efi/Kconfig | 10 ++
> drivers/firmware/efi/Makefile |1 +
> drivers/firmware/efi/efi-capsule-loader.c | 246
> +
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/firmware/efi/efi-capsule-loader.c
>
> diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> index f712d47..0be8ee3 100644
> --- a/drivers/firmware/efi/Kconfig
> +++ b/drivers/firmware/efi/Kconfig
> @@ -60,6 +60,16 @@ config EFI_RUNTIME_WRAPPERS
> config EFI_ARMSTUB
> bool
>
> +config EFI_CAPSULE_LOADER
> + tristate "EFI capsule loader"
> + depends on EFI
> + help
> + This option exposes a loader interface "/dev/efi_capsule_loader" for
> + user to load EFI capsule binary and update the EFI firmware through
> + system reboot.
> +
> + If unsure, say N.
> +
> endmenu
>
> config UEFI_CPER
> diff --git a/drivers/firmware/efi/Makefile b/drivers/firmware/efi/Makefile
> index 698846e..5ab031a 100644
> --- a/drivers/firmware/efi/Makefile
> +++ b/drivers/firmware/efi/Makefile
> @@ -8,3 +8,4 @@ obj-$(CONFIG_UEFI_CPER) += cper.o
> obj-$(CONFIG_EFI_RUNTIME_MAP) += runtime-map.o
> obj-$(CONFIG_EFI_RUNTIME_WRAPPERS) += runtime-wrappers.o
> obj-$(CONFIG_EFI_STUB) += libstub/
> +obj-$(CONFIG_EFI_CAPSULE_LOADER) += efi-capsule-loader.o
> diff --git a/drivers/firmware/efi/efi-capsule-loader.c
> b/drivers/firmware/efi/efi-capsule-loader.c
> new file mode 100644
> index 000..571e0c8
> --- /dev/null
> +++ b/drivers/firmware/efi/efi-capsule-loader.c
> @@ -0,0 +1,246 @@
> +/*
> + * EFI capsule loader driver.
> + *
> + * Copyright 2015 Intel Corporation
> + *
> + * This file is part of the Linux kernel, and is made available under
> + * the terms of the GNU General Public License version 2.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEV_NAME "efi_capsule_loader"
> +
> +static struct capsule_info {
> + charheader_obtained;
> + longindex;
> + unsigned long count;
> + unsigned long total_size;
> + struct page **pages;
> + unsigned long page_count_remain;
> +} cap_info;
> +
Why is this static?
> +static DEFINE_MUTEX(capsule_loader_lock);
> +
> +/*
> + * This function will free the current & all previous allocated buffer pages.
> + * The input parameter is the allocated buffer page for current execution
> which
> + * has not yet assigned to pages array. The input param can be NULL if the
> + * current execution has not allocated any buffer page.
> + */
> +static void efi_free_all_buff_pages(struct page *kbuff_page)
> +{
> + if (!kbuff_page)
> + __free_page(kbuff_page);
> +
> + if (cap_info.index > 0)
> + while (cap_info.index > 0)
> + __free_page(cap_info.pages[--cap_info.index]);
> +
> + if (cap_info.header_obtained)
> + kfree(cap_info.pages);
> +
> + /* indicate to the next that error had occurred */
> + cap_info.index = -2;
This -2 to too magical.
> +}
> +
> +/*
> + * This function will store the capsule binary and pass it to
> + * efi_capsule_update() API in capsule.c.
> + *
> + * Expectation:
> + * - userspace tool should start at the beginning of capsule binary and pass
> + * data in sequential.
> + * - user should close and re-open this file note in order to upload more
> + * capsules.
> + * - any error occurred, user should close the file and restart the operation
> + * for the next try otherwise -EIO will be returned until the file is
> closed.
> + */
> +static ssize_t efi_capsule_write(struct file *file, const char __user *buff,
> +size_t count, loff_t *offp)
> +{
> + int ret = 0;
> + struct page *kbuff_page;
> + void *kbuff;
> + size_t write_byte;
> +
> + pr_debug("%s: Entering Write()\n", __func__);
Unnecessary.
> + if (count == 0)
> + return 0;
> +
> + /* return error while error had occurred or capsule uploading is done
> */
> + if (cap_info.index < 0)
> + return -EIO;
> +
> + /* only alloc a new page when the current page is full */
> + if (!cap_info.page_count_remain) {
> + kbuff_page = alloc_page(GFP_KERNEL);
> + if (!kbuff_page) {
> + pr_debug("%s: alloc_page() failed\n", __func__);
> +
Re: linux-next: Tree for Sep 18 (build failures, up to 10/02)
On Fri, 02 Oct, at 09:16:37AM, Guenter Roeck wrote:
> On Fri, Sep 18, 2015 at 07:22:04AM -0700, Guenter Roeck wrote:
> > On Fri, Sep 18, 2015 at 02:08:10PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20150917:
> > >
> > > I used the h8300 tree from next-20150828 since the current tree has been
> > > rebased onto something very old :-(
> > >
> > > The bluetooth tree still had its build failure.
> > >
> > > The tip tree gained a conflict against Linus' tree.
> > >
> > > The akpm-current tree lost its build failure.
> > >
> > > Non-merge commits (relative to Linus' tree): 1938
> > > 1581 files changed, 83940 insertions(+), 23948 deletions(-)
> > >
> >
> > Build failures:
> >
> > ia64:defconfig
> > ia64:allnoconfig
> >
> > drivers/built-in.o: In function `efi_mem_attributes':
> > (.text+0xde962): undefined reference to `memmap'
> > drivers/built-in.o: In function `efi_mem_attributes':
> > (.text+0xde971): undefined reference to `memmap'
> >
> > Bisect points to 'efi, x86: Rearrange efi_mem_attributes()'.
> > On a side note, 'memmap' is really a bad name for a global variable,
> > As the patch description suggests, the variable does not exist for ia64,
> > so the build failure is not entirely unexpected.
> >
> The build for ia64 still fails in next-20151002. Maybe it is time
> to revert the offending commit ? After all, the commit was supposed
> to _fix_ a problem associated with ia64, not to make it completely
> non-buildable.
Urgh, sorry about this slipping through the cracks Guenter!
What about fixing it up with this patch?
---
>From 85ae872eafef767cf37a0a305266522a62b43fc2 Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Sat, 3 Oct 2015 20:44:52 +0100
Subject: [PATCH] efi: Use the generic efi.memmap instead of 'memmap'
Guenter reports that commit 7bf793115dd9 ("efi, x86: Rearrange
efi_mem_attributes()") breaks ia64 compilation with the following
error,
drivers/built-in.o: In function `efi_mem_attributes':
(.text+0xde962): undefined reference to `memmap'
drivers/built-in.o: In function `efi_mem_attributes':
(.text+0xde971): undefined reference to `memmap'
Instead of using the (rather poorly named) global variable 'memmap'
which doesn't exist on ia64, use efi.memmap which points to the
'memmap' object on x86 and arm64 and which is NULL for ia64.
The fact that efi.memmap is NULL for ia64 is OK because ia64 provides
its own implementation of efi_mem_attributes().
Reported-by: Guenter Roeck
Cc: Jonathan Zhang
Cc: Ingo Molnar
Cc: Tony Luck
Cc: Ard Biesheuvel
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/efi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index dd153be03f56..335f4c1a1504 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -647,13 +647,15 @@ char * __init efi_md_typeattr_format(char *buf, size_t
size,
*/
u64 __weak efi_mem_attributes(unsigned long phys_addr)
{
+ struct efi_memory_map *map;
efi_memory_desc_t *md;
void *p;
if (!efi_enabled(EFI_MEMMAP))
return 0;
- for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+ map = efi.memmap;
+ for (p = map->map; p < map->map_end; p += map->desc_size) {
md = p;
if ((md->phys_addr <= phys_addr) &&
(phys_addr < (md->phys_addr +
--
2.1.0
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: reduce CONFIG_SCSI_CONSTANTS impact by 4k
On Sat, Oct 03 2015, Christoph Hellwig wrote:
> Hi Rasmus,
>
> I like this idea. But maybe it's also time to just move the constants
> to a plain text file and auto-generate C headers from them? That way
> the format in which they can be edited is decoupled from the
> representation in the kernel image.
Well, I don't really have an opinion on that part.
In the meantime, I got another idea for doubling the saving to 8k. It
requires a few more code changes and is perhaps also more hacky. 2/2
would be something like below. Please let me know which version you'd
prefer, and I'll send both patches properly.
Thanks,
Rasmus
Subject: [PATCH 2/2] scsi: reduce CONFIG_SCSI_CONSTANTS=y impact by 8k
On 64 bit, struct error_info has 6 bytes of padding, which amounts to
over 4k of wasted space in the additional[] array. We could easily get
rid of that by instead using separate arrays for the codes and the
pointers. However, we can do even better than that and save an
additional 6 bytes per entry: In the table, just store the sizeof()
the corresponding string literal. The cumulative sum of these is then
the appropriate offset into additional_text, which is built from the
concatenation (with '\0's inbetween) of the strings.
$ scripts/bloat-o-meter /tmp/vmlinux vmlinux
add/remove: 0/0 grow/shrink: 1/1 up/down: 24/-8488 (-8464)
function old new delta
scsi_extd_sense_format 136 160 +24
additional 113122824 -8488
Signed-off-by: Rasmus Villemoes
---
drivers/scsi/constants.c | 25 +
drivers/scsi/sense_codes.h | 2 --
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 47aaccd5e68e..ccd34b0481cd 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -292,17 +292,31 @@ bool scsi_opcode_sa_name(int opcode, int service_action,
struct error_info {
unsigned short code12; /* 0x0302 looks better than 0x03,0x02 */
- const char * text;
+ unsigned short size;
};
+/*
+ * There are 700+ entries in this table. To save space, we don't store
+ * (code, pointer) pairs, which would make sizeof(struct
+ * error_info)==16 on 64 bits. Rather, the second element just stores
+ * the size (including \0) of the corresponding string, and we use the
+ * sum of these to get the appropriate offset into additional_text
+ * defined below. This approach saves 12 bytes per entry.
+ */
static const struct error_info additional[] =
{
-#define SENSE_CODE(c, s) {c, s},
+#define SENSE_CODE(c, s) {c, sizeof(s)},
#include "sense_codes.h"
#undef SENSE_CODE
};
+static const char *additional_text =
+#define SENSE_CODE(c, s) s "\0"
+#include "sense_codes.h"
+#undef SENSE_CODE
+ ;
+
struct error_info2 {
unsigned char code1, code2_min, code2_max;
const char * str;
@@ -364,11 +378,14 @@ scsi_extd_sense_format(unsigned char asc, unsigned char
ascq, const char **fmt)
{
int i;
unsigned short code = ((asc << 8) | ascq);
+ unsigned offset = 0;
*fmt = NULL;
- for (i = 0; additional[i].text; i++)
+ for (i = 0; i < ARRAY_SIZE(additional); i++) {
if (additional[i].code12 == code)
- return additional[i].text;
+ return additional_text + offset;
+ offset += additional[i].size;
+ }
for (i = 0; additional2[i].fmt; i++) {
if (additional2[i].code1 == asc &&
ascq >= additional2[i].code2_min &&
diff --git a/drivers/scsi/sense_codes.h b/drivers/scsi/sense_codes.h
index 54b3939d6309..da84d53b3379 100644
--- a/drivers/scsi/sense_codes.h
+++ b/drivers/scsi/sense_codes.h
@@ -833,5 +833,3 @@ SENSE_CODE(0x746E, "External data encryption control
timeout")
SENSE_CODE(0x746F, "External data encryption control error")
SENSE_CODE(0x7471, "Logical unit access not authorized")
SENSE_CODE(0x7479, "Security conflict in translated device")
-
-SENSE_CODE(0, NULL)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] net: dsa: add missing kfree on remove
On 10/3/2015 6:20 PM, Neil Armstrong wrote:
On 10/3/2015 5:25 PM, Neil Armstrong wrote:
To prevent memory leakage on unbinding, add missing kfree calls.
Signed-off-by: Neil Armstrong
---
net/dsa/dsa.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index c59fa5d..12cec40 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -914,8 +914,10 @@ static void dsa_remove_dst(struct dsa_switch_tree *dst)
for (i = 0; i < dst->pd->nr_chips; i++) {
struct dsa_switch *ds = dst->ds[i];
-if (ds != NULL)
+if (ds != NULL) {
Didn;t scripts/checkpatch.pl complain here? just if (ds) is preferred in
the networking code.
MBR, Sergei
Yes,
But I considered the cosmetic changes are not the subject of this serie.
Formally, all the patches should be checkpatch-clean...
Neil
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: via-rhine: fix VLAN receive handling error in 4.2.x
Andrej :
[...]
> Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from
> skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(),
> I chose the latter.
Can you send a patch with a proper Signed-off-by and a single line
'Fixes: 810f19bcb862 ("via-rhine: add consistent memory barrier in vlan
receive code.")' or do you want me to do that ?
The patch ought to be based against davem's net but it wouldn't make
any noticeable difference.
--
Ueimor
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HID: hiddev: fix returned errno code in hiddev_connect()
On 30/09/15 20:40, Jiri Kosina wrote: > On Wed, 30 Sep 2015, Luis de Bethencourt wrote: > >> The driver is using -1 instead of the -ENOMEM defined macro to specify >> that a buffer allocation failed. Since the error number is propagated, >> the caller will get a -EPERM which is the wrong error condition. > > Generally I agree that the more specific errno, the better. > > But I am not really sure where you are seeing the bug (mapping to -EPERM) > in this case? I think the only caller of hiddev_connect() should be > hid_connect(), and the only thing that guy cares about whether individual > callbacks succeed or fail, so that it sets hdev->clamed flags accordingly. > > Could you please be more specific about the -EPERM mapping you are talking > about? > > Thanks, > I agree with you. The only caller of hiddev_connect() only checks if the callback succeded. It checks if the return < 0. What I meant is that -1 means -EPERM. [0] This patch is purely about the correctness of using -ENOMEM. The word "propagated" was not the best way to describe this problem. I could edit the commit message if you would like. Thanks for the review, Luis [0] http://lxr.free-electrons.com/source/include/uapi/asm-generic/errno-base.h#L15 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ubi: fastmap: Implement produce_free_peb()
Am 11.08.2015 um 23:27 schrieb Richard Weinberger: > If fastmap requests a free PEB for a pool and UBI is busy > with erasing PEBs we need to offer a function to wait for one. > We can reuse produce_free_peb() from the non-fastmap WL code > but with different locking semantics. > > Reported-and-tested-by: Jörg Krause > Signed-off-by: Richard Weinberger Applied. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb-host: Remove fusbh200 driver
Peter Senna Tschudin writes: > On Fri, Oct 2, 2015 at 7:39 PM, Felipe Balbi wrote: >> On Fri, Oct 02, 2015 at 01:18:27PM +0200, Peter Senna Tschudin wrote: >>> fusbh200 and fotg210 are very similar. The initial idea was to consolidate >>> both drivers but I'm afraid fusbh200 is not being used. >>> >>> This patch remove the fusbh200 source code, update Kconfig and two >>> Makefiles. >>> >>> Signed-off-by: Peter Senna Tschudin >> >> after all this work on these previous patches, you just remove fusbh200 ? >> >> that's a bit odd. Are you sure there are no users for this driver ? It has >> been >> in tree since 2013. > I don't know about users, but I could not find devices using fusbh200. > The closest I got was: > > http://www.ebay.fr/itm/Digital-Video-Langzeit-Recorder-H264-DVR-3G-4-Kanal-/370525106495 > > But it only says: Main Processor: Faraday. I don't know which usb host > controller it uses. > > The idea of deleting fusbh200 came from contacting the driver authors. > I was asking where to find hw for testing, and I was told that the > fusbh200 driver can be deleted. Also at least Fedora and Ubuntu build > modules for these host controllers by default. If fusbh200 and fotg210 > are only available integrated into SOCs, maybe building the modules by > default for x86 is not a good idea. But if there are users I'll be > happy to continue the integration work, even better if I find hardware > for testing. fair enough, if can be deleted it's fine... > John Feng-Hsin Chiang, can you confirm that from your side the > fusbh200 driver can be deleted? ... but let's get this confirmation. > For the patches I sent, 10 of 14 are for fotg210 which I'll fix and resend. cool, thanks -- balbi signature.asc Description: PGP signature
Re: [PATCH] usbhid: Fix for the WiiU adapter from Mayflash
Oliver Schmitt writes:
Hi,
> The WiiU adapter from Mayflash (see
> http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not working
> correctly.
>
> The "XInput" mode works fine, the controller is recognized as a xbox
> controller. But it is only possible to connect one controller with this
> method.
>
> In "DInput" mode the device is recognized as some kind of mouse input but no
> joystick is created. This commit will change this behavior with
> HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that it
> will also create joysticks in /dev/input/js*.
>
Please split your commit log so that sentences don't go over 72
characters.
Other than that:
Reviewed-by: Felipe Balbi
> Signed-off-by: Oliver Schmitt
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/usbhid/hid-quirks.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f769208..cfb317e 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -288,6 +288,7 @@
> #define USB_DEVICE_ID_DMI_ENC0x5fab
>
> #define USB_VENDOR_ID_DRAGONRISE 0x0079
> +#define USB_DEVICE_ID_DRAGONRISE_WIIU0x1800
>
> #define USB_VENDOR_ID_DWAV 0x0eef
> #define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER 0x0001
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 1dff8f0..26d2f83 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -71,6 +71,7 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_CHICONY,
> USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
> + { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU,
> HID_QUIRK_MULTI_INPUT },
> { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
> HID_QUIRK_ALWAYS_POLL },
> { USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_0103,
> HID_QUIRK_ALWAYS_POLL },
> --
> 2.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: PGP signature
[PATCH] staging: rdma: Fix braces around if/else
Get rid of all ELSE_AFTER_BRACE type errors reported by checkpatch.pl.
Signed-off-by: Martin Kletzander
---
There is one warning reported in this patch though. That's because of
the multiline string and it's pre-existing. Feel free to let me know
if that should be fixed too, I'd also remove the pointless '#' then.
On the other hand, it'll create more-than-80-columns long line.
drivers/staging/rdma/ipath/ipath_driver.c| 19 ---
drivers/staging/rdma/ipath/ipath_file_ops.c | 12 ++--
drivers/staging/rdma/ipath/ipath_iba6110.c | 7 +++
drivers/staging/rdma/ipath/ipath_init_chip.c | 10 +-
drivers/staging/rdma/ipath/ipath_intr.c | 7 +++
drivers/staging/rdma/ipath/ipath_sysfs.c | 7 +++
drivers/staging/rdma/ipath/ipath_verbs.c | 4 ++--
7 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/rdma/ipath/ipath_driver.c
b/drivers/staging/rdma/ipath/ipath_driver.c
index 871dbe56216a..46d98980d66a 100644
--- a/drivers/staging/rdma/ipath/ipath_driver.c
+++ b/drivers/staging/rdma/ipath/ipath_driver.c
@@ -490,8 +490,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
"Unable to set DMA mask for unit %u: %d\n",
dd->ipath_unit, ret);
goto bail_regions;
- }
- else {
+ } else {
ipath_dbg("No 64bit DMA mask, used 32 bit mask\n");
ret = pci_set_consistent_dma_mask(pdev,
DMA_BIT_MASK(32));
if (ret)
@@ -501,8 +500,7 @@ static int ipath_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
dd->ipath_unit, ret);
}
- }
- else {
+ } else {
ret = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
if (ret)
dev_info(>dev,
@@ -1229,11 +1227,10 @@ reloop:
ipath_cdbg(PKT, "typ %x, opcode %x (eager, "
"qp=%x), len %x; ignored\n",
etype, opcode, qp, tlen);
- }
- else if (etype == RCVHQ_RCV_TYPE_EXPECTED)
+ } else if (etype == RCVHQ_RCV_TYPE_EXPECTED) {
ipath_dbg("Bug: Expected TID, opcode %x; ignored\n",
be32_to_cpu(hdr->bth[0]) >> 24);
- else {
+ } else {
/*
* error packet, type of error unknown.
* Probably type 3, but we don't know, so don't
@@ -1270,8 +1267,9 @@ reloop:
pd->port_seq_cnt = 1;
if (seq != pd->port_seq_cnt)
last = 1;
- } else if (l == hdrqtail)
+ } else if (l == hdrqtail) {
last = 1;
+ }
/*
* update head regs on last packet, and every 16 packets.
* Reduce bus traffic, while still trying to prevent
@@ -1821,15 +1819,14 @@ int ipath_create_rcvhdrq(struct ipath_devdata *dd,
(unsigned long) pd->port_rcvhdrq_phys,
(unsigned long) pd->port_rcvhdrq_size,
pd->port_port);
- }
- else
+ } else {
ipath_cdbg(VERBOSE, "reuse port %d rcvhdrq @%p %llx phys; "
"hdrtailaddr@%p %llx physical\n",
pd->port_port, pd->port_rcvhdrq,
(unsigned long long) pd->port_rcvhdrq_phys,
pd->port_rcvhdrtail_kvaddr, (unsigned long long)
pd->port_rcvhdrqtailaddr_phys);
-
+ }
/* clear for security and sanity on each use */
memset(pd->port_rcvhdrq, 0, pd->port_rcvhdrq_size);
if (pd->port_rcvhdrtail_kvaddr)
diff --git a/drivers/staging/rdma/ipath/ipath_file_ops.c
b/drivers/staging/rdma/ipath/ipath_file_ops.c
index c11f6c58ce53..04fe2dc51fe2 100644
--- a/drivers/staging/rdma/ipath/ipath_file_ops.c
+++ b/drivers/staging/rdma/ipath/ipath_file_ops.c
@@ -825,13 +825,13 @@ static void ipath_clean_part_key(struct ipath_portdata
*pd,
ipath_stats.sps_pkeys[j] =
dd->ipath_pkeys[j] = 0;
pchanged++;
+ } else {
+ ipath_cdbg(VERBOSE, "p%u key %x matches #%d, "
+ "but ref still %d\n", pd->port_port,
+ pd->port_pkeys[i], j,
+ atomic_read(>ipath_pkeyrefs[j]));
+ break;
}
- else ipath_cdbg(
-
[PATCH 1/3] Staging: rtl8192u: remove ieee80211_tkip_null()
This is a patch to remove the function ieee80211_tkip_null().
This function does nothing, and can therefore be safely removed.
Signed-off-by: Mike Dupuis
---
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 6 --
drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 1 -
2 files changed, 7 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
index 1f80c52..72d4fc6 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c
@@ -769,9 +769,3 @@ void __exit ieee80211_crypto_tkip_exit(void)
{
ieee80211_unregister_crypto_ops(_crypt_tkip);
}
-
-void ieee80211_tkip_null(void)
-{
-//printk(">%s()\n", __func__);
- return;
-}
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index 425b2dd..d5faf2f 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -176,7 +176,6 @@ struct net_device *alloc_ieee80211(int sizeof_priv)
}
/* These function were added to load crypte module autoly */
- ieee80211_tkip_null();
ieee80211_wep_null();
ieee80211_ccmp_null();
--
2.1.4
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Staging: rtl8192u: remove ieee80211_ccmp_null()
This is a patch to remove the function ieee80211_ccmp_null(). This function does nothing and can therefore be safely removed. Signed-off-by: Mike Dupuis --- drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c index 61edd57..af22ee5 100644 --- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c +++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c @@ -175,9 +175,6 @@ struct net_device *alloc_ieee80211(int sizeof_priv) ieee->last_packet_time[i] = 0; } -/* These function were added to load crypte module autoly */ - ieee80211_ccmp_null(); - return dev; failed: -- 2.1.4 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Staging: rtl8192u: remove ieee80211_wep_null()
This is a patch to remove the function ieee80211_wep_null().
This function does nothing and can therefore be safely removed.
Signed-off-by: Mike Dupuis
---
drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 4
drivers/staging/rtl8192u/ieee80211/ieee80211_module.c| 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
index 681611d..4c2fb84 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c
@@ -273,7 +273,3 @@ void __exit ieee80211_crypto_wep_exit(void)
{
ieee80211_unregister_crypto_ops(_crypt_wep);
}
-
-void ieee80211_wep_null(void)
-{
-}
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index d5faf2f..61edd57 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -176,7 +176,6 @@ struct net_device *alloc_ieee80211(int sizeof_priv)
}
/* These function were added to load crypte module autoly */
- ieee80211_wep_null();
ieee80211_ccmp_null();
return dev;
--
2.1.4
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Staging: rtl8192u: Remove do-nothing functions
This is a series of patches to remove three functions that do no processing in staging/rtl8192u/ieee80211/. Before: drivers/staging/rtl8192u/$ grep _null\( *.c drivers/staging/rtl8192u/$ drivers/staging/rtl8192u/ieee80211/$ grep _null\( *.c ieee80211_crypt_ccmp.c:void ieee80211_ccmp_null(void) ieee80211_crypt_tkip.c:void ieee80211_tkip_null(void) ieee80211_crypt_wep.c:void ieee80211_wep_null(void) ieee80211_module.c: ieee80211_tkip_null(); ieee80211_module.c: ieee80211_wep_null(); ieee80211_module.c: ieee80211_ccmp_null(); drivers/staging/rtl8192u/ieee80211/$ After: drivers/staging/rtl8192u/$ grep _null\( *.c drivers/staging/rtl8192u/$ drivers/staging/rtl8192u/ieee80211/$ grep _null\( *.c drivers/staging/rtl8192u/ieee80211/$ Mike Dupuis (3): Staging: rtl8192u: remove ieee80211_tkip_null() Staging: rtl8192u: remove ieee80211_wep_null() Staging: rtl8192u: remove ieee80211_ccmp_null() drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_tkip.c | 6 -- drivers/staging/rtl8192u/ieee80211/ieee80211_crypt_wep.c | 4 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 5 - 3 files changed, 15 deletions(-) -- 2.1.4 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hwrng: fix simple_return.cocci warnings
drivers/char/hw_random/stm32-rng.c:164:1-4: WARNING: end returns can be
simpified
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Daniel Thompson
Signed-off-by: Fengguang Wu
---
stm32-rng.c |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -161,11 +161,7 @@ static int stm32_rng_probe(struct platfo
priv->rng.read = stm32_rng_read,
priv->rng.priv = (unsigned long) dev;
- err = hwrng_register(>rng);
- if (err)
- return err;
-
- return 0;
+ return hwrng_register(>rng);
}
static const struct of_device_id stm32_rng_match[] = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] hwrng: stm32 - add support for STM32 HW RNG
Hi Daniel, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] coccinelle warnings: (new ones prefixed by >>) >> drivers/char/hw_random/stm32-rng.c:164:1-4: WARNING: end returns can be >> simpified Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h
If the host toolchain is not glibc based then the arm kernel build
fails with
HOSTCC arch/arm/vdso/vdsomunge
arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or
directory
Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF
cross-compiler.
Reason: byteswap.h is a glibc only header.
Solution: replace by private byte-swapping macros (taken from
arch/mips/boot/elf2ecoff.c)
Tested to compile on Mac OS X 10.9.5 host.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/vdso/vdsomunge.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
index aedec81..27a9a0b 100644
--- a/arch/arm/vdso/vdsomunge.c
+++ b/arch/arm/vdso/vdsomunge.c
@@ -45,7 +45,18 @@
* it does.
*/
-#include
+#define swab16(x) \
+ ((unsigned short)( \
+ (((unsigned short)(x) & (unsigned short)0x00ffU) << 8) | \
+ (((unsigned short)(x) & (unsigned short)0xff00U) >> 8) ))
+
+#define swab32(x) \
+ ((unsigned int)( \
+ (((unsigned int)(x) & (unsigned int)0x00ffUL) << 24) | \
+ (((unsigned int)(x) & (unsigned int)0xff00UL) << 8) | \
+ (((unsigned int)(x) & (unsigned int)0x00ffUL) >> 8) | \
+ (((unsigned int)(x) & (unsigned int)0xff00UL) >> 24) ))
+
#include
#include
#include
@@ -104,17 +115,17 @@ static void cleanup(void)
static Elf32_Word read_elf_word(Elf32_Word word, bool swap)
{
- return swap ? bswap_32(word) : word;
+ return swap ? swab32(word) : word;
}
static Elf32_Half read_elf_half(Elf32_Half half, bool swap)
{
- return swap ? bswap_16(half) : half;
+ return swap ? swab16(half) : half;
}
static void write_elf_word(Elf32_Word val, Elf32_Word *dst, bool swap)
{
- *dst = swap ? bswap_32(val) : val;
+ *dst = swap ? swab32(val) : val;
}
int main(int argc, char **argv)
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] hwrng: stm32 - add support for STM32 HW RNG
Add support for STMicroelectronics STM32 random number generator.
The config value defaults to N, reflecting the fact that STM32 is a
very low resource microcontroller platform and unlikely to be targeted
by any "grown up" defconfigs.
Signed-off-by: Daniel Thompson
---
drivers/char/hw_random/Kconfig | 12 +++
drivers/char/hw_random/Makefile| 1 +
drivers/char/hw_random/stm32-rng.c | 192 +
3 files changed, 205 insertions(+)
create mode 100644 drivers/char/hw_random/stm32-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index f48cf11c655e..7930cc9b719c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -359,6 +359,18 @@ config HW_RANDOM_XGENE
If unsure, say Y.
+config HW_RANDOM_STM32
+ tristate "STMicroelectronics STM32 random number generator"
+ depends on HW_RANDOM && (ARCH_STM32 || COMPILE_TEST)
+ help
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on STM32 microcontrollers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stm32-rng.
+
+ If unsure, say N.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 055bb01510ad..8b49c0f7abb1 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
+obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
diff --git a/drivers/char/hw_random/stm32-rng.c
b/drivers/char/hw_random/stm32-rng.c
new file mode 100644
index ..37dfa5fca105
--- /dev/null
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -0,0 +1,192 @@
+/*
+ * Copyright (c) 2015, Daniel Thompson
+ *
+ * This file 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; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This file 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
+#include
+#include
+
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+
+#define RNG_SR 0x04
+#define RNG_SR_SEIS BIT(6)
+#define RNG_SR_CEIS BIT(5)
+#define RNG_SR_DRDY BIT(0)
+
+#define RNG_DR 0x08
+
+/*
+ * It takes 40 cycles @ 48MHz to generate each random number (e.g. <1us).
+ * At the time of writing STM32 parts max out at ~200MHz meaning a timeout
+ * of 500 leaves us a very comfortable margin for error. The loop to which
+ * the timeout applies takes at least 4 instructions per cycle so the
+ * timeout is enough to take us up to multi-GHz parts!
+ */
+#define RNG_TIMEOUT 500
+
+struct stm32_rng_private {
+ struct hwrng rng;
+ void __iomem *base;
+ struct clk *clk;
+};
+
+static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+ struct stm32_rng_private *priv =
+ container_of(rng, struct stm32_rng_private, rng);
+ u32 cr, sr;
+ int retval = 0;
+
+ /* enable random number generation */
+ clk_enable(priv->clk);
+ cr = readl(priv->base + RNG_CR);
+ writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
+
+ while (max > sizeof(u32)) {
+ sr = readl(priv->base + RNG_SR);
+ if (!sr && wait) {
+ unsigned int timeout = RNG_TIMEOUT;
+
+ do {
+ cpu_relax();
+ sr = readl(priv->base + RNG_SR);
+ } while (!sr && --timeout);
+ }
+
+ /* Has h/ware error dection been triggered? */
+ if (WARN_ON(sr & (RNG_SR_SEIS | RNG_SR_CEIS)))
+ break;
+
+ /* No data ready... */
+ if (!sr)
+ break;
+
+ *(u32 *)data = readl(priv->base + RNG_DR);
+
+ retval += sizeof(u32);
+ data += sizeof(u32);
+ max -= sizeof(u32);
+ }
+
+ /* disable the generator */
+ writel(cr, priv->base + RNG_CR);
+ clk_disable(priv->clk);
+
+ return retval || !wait ? retval : -EIO;
+}
+
+static int stm32_rng_init(struct hwrng *rng)
+{
+ struct stm32_rng_private *priv =
+ container_of(rng, struct stm32_rng_private, rng);
+ int err;
+ u32 sr;
+
+ err = clk_prepare(priv->clk);
+ if (err)
+ return err;
+
+ /* clear error
[PATCH] [SMB3] Do not fall back to SMBWriteX in set_file_size error cases
The error paths in set_file_size for cifs and smb3 are incorrect.
In the unlikely event that a server did not support set file info
of the file size, the code incorrectly falls back to trying SMBWriteX
(note that only the original core SMB Write, used for example by DOS,
can set the file size this way - this actually does not work for the more
recent SMBWriteX). The idea was since the old DOS SMB Write could set
the file size if you write zero bytes at that offset then use that if
server rejects the normal set file info call.
Fortunately the SMBWriteX will never be sent on the wire (except when
file size is zero) since the length and offset fields were reversed
in the two places in this function that call SMBWriteX causing
the fall back path to return an error. It is also important to never call
an SMB request from an SMB2/sMB3 session (which theoretically would
be possible, and can cause a brief session drop, although the client
recovers) so this should be fixed. In practice this path does not happen
with modern servers but the error fall back to SMBWriteX is clearly wrong.
Removing the calls to SMBWriteX in the error paths in cifs_set_file_size
Pointed out by PaX/grsecurity team
Signed-off-by: Steve French
Reported-by: PaX Team
CC: Emese Revfy
CC: Brad Spengler
CC: Stable
---
fs/cifs/inode.c | 34 --
1 file changed, 34 deletions(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index f621b44..6b66dd5 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -2034,7 +2034,6 @@ cifs_set_file_size(struct inode *inode, struct iattr
*attrs,
struct tcon_link *tlink = NULL;
struct cifs_tcon *tcon = NULL;
struct TCP_Server_Info *server;
- struct cifs_io_parms io_parms;
/*
* To avoid spurious oplock breaks from server, in the case of
@@ -2056,18 +2055,6 @@ cifs_set_file_size(struct inode *inode, struct iattr
*attrs,
rc = -ENOSYS;
cifsFileInfo_put(open_file);
cifs_dbg(FYI, "SetFSize for attrs rc = %d\n", rc);
- if ((rc == -EINVAL) || (rc == -EOPNOTSUPP)) {
- unsigned int bytes_written;
-
- io_parms.netfid = open_file->fid.netfid;
- io_parms.pid = open_file->pid;
- io_parms.tcon = tcon;
- io_parms.offset = 0;
- io_parms.length = attrs->ia_size;
- rc = CIFSSMBWrite(xid, _parms, _written,
- NULL, NULL, 1);
- cifs_dbg(FYI, "Wrt seteof rc %d\n", rc);
- }
} else
rc = -EINVAL;
@@ -2093,28 +2080,7 @@ cifs_set_file_size(struct inode *inode, struct iattr
*attrs,
else
rc = -ENOSYS;
cifs_dbg(FYI, "SetEOF by path (setattrs) rc = %d\n", rc);
- if ((rc == -EINVAL) || (rc == -EOPNOTSUPP)) {
- __u16 netfid;
- int oplock = 0;
- rc = SMBLegacyOpen(xid, tcon, full_path, FILE_OPEN,
- GENERIC_WRITE, CREATE_NOT_DIR, ,
- , NULL, cifs_sb->local_nls,
- cifs_remap(cifs_sb));
- if (rc == 0) {
- unsigned int bytes_written;
-
- io_parms.netfid = netfid;
- io_parms.pid = current->tgid;
- io_parms.tcon = tcon;
- io_parms.offset = 0;
- io_parms.length = attrs->ia_size;
- rc = CIFSSMBWrite(xid, _parms, _written, NULL,
- NULL, 1);
- cifs_dbg(FYI, "wrt seteof rc %d\n", rc);
- CIFSSMBClose(xid, tcon, netfid);
- }
- }
if (tlink)
cifs_put_tlink(tlink);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: dts: stm32f429: Adopt STM32 RNG driver
New bindings and driver have been created for STM32 series parts. This
patch integrates this changes.
Signed-off-by: Daniel Thompson
---
arch/arm/boot/dts/stm32f429.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index cb0613090243..90081fc22c6c 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -175,6 +175,13 @@
reg = <0x40023800 0x400>;
clocks = <_hse>;
};
+
+ rng: rng@50060800 {
+ compatible = "st,stm32-rng";
+ reg = <0x50060800 0x400>;
+ interrupts = <80>;
+ clocks = < 0 38>;
+ };
};
};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] dt-bindings: Document the STM32 HW RNG bindings
This adds documenttaion of device tree binds for the STM32 hardware
random number generator.
Signed-off-by: Daniel Thompson
---
.../devicetree/bindings/hwrng/stm32-rng.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwrng/stm32-rng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/stm32-rng.txt
b/Documentation/devicetree/bindings/hwrng/stm32-rng.txt
new file mode 100644
index ..47f04176f93b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/stm32-rng.txt
@@ -0,0 +1,21 @@
+STMicroelectronics STM32 HW RNG
+===
+
+The STM32 hardware random number generator is a simple fixed purpose IP and
+is fully separated from other crypto functions.
+
+Required properties:
+
+- compatible : Should be "st,stm32-rng"
+- reg : Should be register base and length as documented in the datasheet
+- interrupts : The designated IRQ line for the RNG
+- clocks : The clock needed to enable the RNG
+
+Example:
+
+ rng: rng@50060800 {
+ compatible = "st,stm32-rng";
+ reg = <0x50060800 0x400>;
+ interrupts = <80>;
+ clocks = < 0 38>;
+ };
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] hwrng: stm32 - add support for STM32 HW RNG
This patchset introduces a driver for the STM32 hardware random number generator. Daniel Thompson (3): dt-bindings: Document the STM32 HW RNG bindings hwrng: stm32 - add support for STM32 HW RNG ARM: dts: stm32f429: Adopt STM32 RNG driver .../devicetree/bindings/hwrng/stm32-rng.txt| 21 +++ arch/arm/boot/dts/stm32f429.dtsi | 7 + drivers/char/hw_random/Kconfig | 12 ++ drivers/char/hw_random/Makefile| 1 + drivers/char/hw_random/stm32-rng.c | 192 + 5 files changed, 233 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwrng/stm32-rng.txt create mode 100644 drivers/char/hw_random/stm32-rng.c -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/5] net: dsa: switch to devm_ calls and remove kfree calls
Le 03/10/2015 07:26, Neil Armstrong a écrit : > Now the kfree calls exists in the the remove functions, remove them in all > places except the of_probe functions and replace allocation calls > with their devm_ counterparts. > > Signed-off-by: Neil Armstrong Reviewed-by: Florian Fainelli -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/5] net: dsa: exit probe if no switch were found
Le 03/10/2015 07:26, Neil Armstrong a écrit : > If no switch were found in dsa_setup_dst, return -ENODEV and > exit the dsa_probe cleanly. > > Tested-by: Andrew Lunn > Tested-by: Florian Fainelli > Signed-off-by: Neil Armstrong > --- [snip] > static int dsa_probe(struct platform_device *pdev) > @@ -926,9 +937,9 @@ static int dsa_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, dst); > > - dsa_setup_dst(dst, dev, >dev, pd); > - > - return 0; > + ret = dsa_setup_dst(dst, dev, >dev, pd); > + if (!ret) > + return 0; That logic is a little weird, I would just go with something like this: ret = dsa_setup_dst(ds, dev, >dev, pd); if (ret) goto out; return 0; -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] x86/apic: Use smaller array for __apicid_to_node[] mapping
On 10/03/2015 09:44 AM, Ingo Molnar wrote:
>
> * Denys Vlasenko wrote:
>
>> @@ -56,16 +56,34 @@ early_param("numa", numa_setup);
>> /*
>> * apicid, cpu, node mappings
>> */
>> -s16 __apicid_to_node[MAX_LOCAL_APICID] = {
>> -[0 ... MAX_LOCAL_APICID-1] = NUMA_NO_NODE
>> +
>> +struct apicid_to_node __apicid_to_node[NR_CPUS] = {
>> +[0 ... NR_CPUS-1] = {-1, NUMA_NO_NODE}
>> };
>>
>> +void set_apicid_to_node(int apicid, s16 node)
>> +{
>> +static int ent;
>
> having such statics inside functions is really obscure and makes review
> harder.
> I had to look twice to see it. Please move it outside and also name it
> appropriately.
Just to confirm: you want it to be a static data, but not inside a function?
>> +/* Protect against small kernel on large system */
>> +if (ent >= NR_CPUS)
>> +return;
>> +
>> +__apicid_to_node[ent].apicid = apicid;
>> +__apicid_to_node[ent].node = node;
>> +ent++;
>> +}
>
> So what happens if we run a small kernel and run out of entries? We just
> silently
> seem to return, no warning, no nothing - the system will likely fail to boot
> in
> myserious ways, right?
Good question.
I tested this.
I built a NR_CPUS=8 kernel and booted it on 144 cpu and 240 cpu machines.
Both booted fine:
[0.00] ACPI: Local APIC address 0xfee0
[0.00] ACPI: NR_CPUS/possible_cpus limit of 8 reached. Processor
8/0x16 ignored.
...
[0.00] ACPI: NR_CPUS/possible_cpus limit of 8 reached. Processor
143/0xf7 ignored.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/5] net: dsa: complete dsa_switch_destroy
Le 03/10/2015 07:26, Neil Armstrong a écrit :
> When unbinding dsa, complete the dsa_switch_destroy to unregister the
> fixed link phy then cleanly unregister and destroy the net devices.
>
> Signed-off-by: Neil Armstrong
> ---
[snip]
> + port_dn = cd->port_dn[port];
> + if (of_phy_is_fixed_link(port_dn)) {
> + phydev = of_phy_find_device(port_dn);
> + if (phydev) {
> + int addr = phydev->addr;
> + phy_device_free(phydev);
> + of_node_put(port_dn);
> + fixed_phy_del(addr);
fixed_phy_del() removes the fixed PHY from the platform fixed MDIO bus
list of PHYs, so we should be okay even with switch drivers which
register a link_update callback via fixed_phy_set_link_update(), but I
have not checked that. The sequence of call looks (phy_device_free then
fixed_phy_del) looks sane though.
Eventually this logic might be better moved into net/dsa/slave.c such
that it is easy to see how it balances dsa_slave_phy_setup().
Reviewed-by: Florian Fainelli
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/5] net: dsa: add missing dsa_switch mdiobus remove
Le 03/10/2015 07:26, Neil Armstrong a écrit : > To prevent memory leakage on unbinding, add missing mdiobus unregister > and free calls. > > Signed-off-by: Neil Armstrong Reviewed-by: Florian Fainelli -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/mmap.c: Remove redundant vma looping
On Sat, Oct 3, 2015 at 9:38 PM, Chen Gang wrote:
> From 36dbcc145819655682f80efd49e72b01515b4e9a Mon Sep 17 00:00:00 2001
> From: Chen Gang
> Date: Sun, 4 Oct 2015 03:22:41 +0800
> Subject: [PATCH] mm/mmap.c: Remove redundant vma looping
>
> vma->vm_file->f_mapping and vma->anon_vma are shared with the same vma
> looping, so merge them.
>
> Signed-off-by: Chen Gang
> ---
> mm/mmap.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 8393580..f7c1631 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3201,9 +3201,7 @@ int mm_take_all_locks(struct mm_struct *mm)
> goto out_unlock;
> if (vma->vm_file && vma->vm_file->f_mapping)
> vm_lock_mapping(mm, vma->vm_file->f_mapping);
> - }
>
> - for (vma = mm->mmap; vma; vma = vma->vm_next) {
> if (signal_pending(current))
> goto out_unlock;
> if (vma->anon_vma)
With that change you're reintroducing an issue.
Please see:
commit 7cd5a02f54f4c9d16cf7fdffa2122bc73bb09b43
Author: Peter Zijlstra
Date: Mon Aug 11 09:30:25 2008 +0200
mm: fix mm_take_all_locks() locking order
Lockdep spotted:
===
[ INFO: possible circular locking dependency detected ]
2.6.27-rc1 #270
---
qemu-kvm/2033 is trying to acquire lock:
(>i_data.i_mmap_lock){}, at: []
mm_take_all_locks+0xc2/0xea
but task is already holding lock:
(_vma->lock){}, at: []
mm_take_all_locks+0x70/0xea
which lock already depends on the new lock.
git blame often explains funky code. :-)
--
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/mmap.c: Change static function __install_special_mapping args' order
>From 5a6ffe3515c21d1152586e484c29fed91d2b0b6f Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 03:47:24 +0800
Subject: [PATCH] mm/mmap.c: Change static function __install_special_mapping
args' order
Let __install_special_mapping() args order match the caller, so the
caller can pass their register args directly to callee with no touch.
For most of architectures, args (at least the first 5th args) are in
registers, so this change will have effect on most of architectures.
For -O2, __install_special_mapping() may be inlined under most of
architectures, but for -Os, it should not. So this change can get a
little better performance for -Os, at least.
Signed-off-by: Chen Gang
---
mm/mmap.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index f7c1631..98ff62d 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3048,8 +3048,8 @@ static int special_mapping_fault(struct vm_area_struct
*vma,
static struct vm_area_struct *__install_special_mapping(
struct mm_struct *mm,
unsigned long addr, unsigned long len,
- unsigned long vm_flags, const struct vm_operations_struct *ops,
- void *priv)
+ unsigned long vm_flags, void *priv,
+ const struct vm_operations_struct *ops)
{
int ret;
struct vm_area_struct *vma;
@@ -3098,8 +3098,8 @@ struct vm_area_struct *_install_special_mapping(
unsigned long addr, unsigned long len,
unsigned long vm_flags, const struct vm_special_mapping *spec)
{
- return __install_special_mapping(mm, addr, len, vm_flags,
-_mapping_vmops, (void *)spec);
+ return __install_special_mapping(mm, addr, len, vm_flags, (void *)spec,
+ _mapping_vmops);
}
int install_special_mapping(struct mm_struct *mm,
@@ -3107,8 +3107,8 @@ int install_special_mapping(struct mm_struct *mm,
unsigned long vm_flags, struct page **pages)
{
struct vm_area_struct *vma = __install_special_mapping(
- mm, addr, len, vm_flags, _special_mapping_vmops,
- (void *)pages);
+ mm, addr, len, vm_flags, (void *)pages,
+ _special_mapping_vmops);
return PTR_ERR_OR_ZERO(vma);
}
--
1.9.3
0001-mm-mmap.c-Change-static-function-__install_special_m.patch
Description: Binary data
[GIT pull] irq fixes for 4.3
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
This update contains:
- Fix for a long standing race affecting /proc/irq/NNN
- One line fix for ARM GICV3-ITS counting the wrong data
- Warning silencing in ARM GICV3-ITS. Another GCC trying to be
overly clever issue.
Thanks,
tglx
-->
Ben Hutchings (1):
genirq: Fix race in register_irq_proc()
Marc Zyngier (2):
irqchip/gic-v3-its: Silence warning when its_lpi_alloc_chunks gets inlined
irqchip/gic-v3-its: Count additional LPIs for the aliased devices
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 2 +-
drivers/irqchip/irq-gic-v3-its.c | 3 +++
kernel/irq/proc.c| 19 +--
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cf351c637464..a7c8c9ffbafd 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -62,7 +62,7 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16 alias,
void *data)
dev_alias->dev_id = alias;
if (pdev != dev_alias->pdev)
- dev_alias->count += its_pci_msi_vec_count(dev_alias->pdev);
+ dev_alias->count += its_pci_msi_vec_count(pdev);
return 0;
}
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index ac7ae2b3cb83..25ceae9f7348 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -719,6 +719,9 @@ static unsigned long *its_lpi_alloc_chunks(int nr_irqs, int
*base, int *nr_ids)
out:
spin_unlock(_lock);
+ if (!bitmap)
+ *base = *nr_ids = 0;
+
return bitmap;
}
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index e3a8c9577ba6..a50ddc9417ff 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "internals.h"
@@ -323,18 +324,29 @@ void register_handler_proc(unsigned int irq, struct
irqaction *action)
void register_irq_proc(unsigned int irq, struct irq_desc *desc)
{
+ static DEFINE_MUTEX(register_lock);
char name [MAX_NAMELEN];
- if (!root_irq_dir || (desc->irq_data.chip == _irq_chip) || desc->dir)
+ if (!root_irq_dir || (desc->irq_data.chip == _irq_chip))
return;
+ /*
+* irq directories are registered only when a handler is
+* added, not when the descriptor is created, so multiple
+* tasks might try to register at the same time.
+*/
+ mutex_lock(_lock);
+
+ if (desc->dir)
+ goto out_unlock;
+
memset(name, 0, MAX_NAMELEN);
sprintf(name, "%d", irq);
/* create /proc/irq/1234 */
desc->dir = proc_mkdir(name, root_irq_dir);
if (!desc->dir)
- return;
+ goto out_unlock;
#ifdef CONFIG_SMP
/* create /proc/irq//smp_affinity */
@@ -355,6 +367,9 @@ void register_irq_proc(unsigned int irq, struct irq_desc
*desc)
proc_create_data("spurious", 0444, desc->dir,
_spurious_proc_fops, (void *)(long)irq);
+
+out_unlock:
+ mutex_unlock(_lock);
}
void unregister_irq_proc(unsigned int irq, struct irq_desc *desc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 fixes
On Sat, 3 Oct 2015, Ingo Molnar wrote: > > 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 > > > ># HEAD: f4b4aae1828855db761bf998ce37d3062b1d6446 x86/headers/uapi: Fix > > __BITS_PER_LONG value for x32 builds > > > > Fixes all around the map: W+X kernel mapping fix, WCHAN fixes, two build > > failure > > fixes for corner case configs, x32 header fix and a speling fix. > > Sorry, please don't pull this tree: Thomas tells me that the two WCHAN fixes > trigger some sort of badness in Sasha's testing: > > > Thomas Gleixner (2): > > x86/process: Add proper bound checks in 64bit get_wchan() > > x86/process: Unify 32bit and 64bit implementations of get_wchan() > > I don't know any details yet. Andrey Ryabinin explained it here: http://marc.info/?l=linux-kernel=144387188203639=2 So it's a false positive and the patches are good to go. I rechecked as well another five times that the bound check is correct. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/mmap.c: Remove redundant vma looping
>From 36dbcc145819655682f80efd49e72b01515b4e9a Mon Sep 17 00:00:00 2001
From: Chen Gang
Date: Sun, 4 Oct 2015 03:22:41 +0800
Subject: [PATCH] mm/mmap.c: Remove redundant vma looping
vma->vm_file->f_mapping and vma->anon_vma are shared with the same vma
looping, so merge them.
Signed-off-by: Chen Gang
---
mm/mmap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 8393580..f7c1631 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3201,9 +3201,7 @@ int mm_take_all_locks(struct mm_struct *mm)
goto out_unlock;
if (vma->vm_file && vma->vm_file->f_mapping)
vm_lock_mapping(mm, vma->vm_file->f_mapping);
- }
- for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (signal_pending(current))
goto out_unlock;
if (vma->anon_vma)
--
1.9.3
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
0001-mm-mmap.c-Remove-redundant-vma-looping.patch
Description: Binary data
Congratulation !!!!
Congratulation,You have been selected to receive the sum of $2 Million Donation from my won Lottery Money, Kindly get back to me now and Claim your Cash. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: blk_mq_register_disk: kobject (00000000009f2dd8): tried to init an initialized object, something is seriously wrong.
> This is 4.3.0-rc1 on Sun E220R (dual-CPU sparc64). Sometimes it boots,
> sometimes it fails to boot with looping errors and finally a watchdog
> timeout. This console log from a failure. Config is below.
I noticed blk-mq related changes in todays git. Retested, loop_init
still causes the same blk-mq problem.
[...]
> [] Cleaning up temporary files... /tmp[ ok .
> [ 106.370834] kobject (009f2dd8): tried to init an initialized
> object, something is seriously wrong.
> [ 106.485668] CPU: 2 PID: 1155 Comm: modprobe Not tainted 4.3.0-rc1 #65
> [ 106.562646] Call Trace:
> [ 106.591812] [00654560] kobject_init+0x80/0xa0
> [ 106.653285] [00640cc0] blk_mq_register_disk+0xa0/0x180
> [ 106.724089] [00636550] blk_register_queue+0x70/0x120
> [ 106.792840] [00643b5c] add_disk+0x19c/0x460
> [ 106.852197] [10033800] loop_add+0x1a0/0x240 [loop]
> [ 106.918853] [1003a168] loop_init+0x168/0x1b0 [loop]
> [ 106.986531] [00426c00] do_one_initcall+0x80/0x1c0
> [ 107.052155] [004de3c4] do_init_module+0x48/0x1e4
> [ 107.116740] [004c7654] load_module+0xf14/0x11e0
> [ 107.180265] [004c7ab4] SyS_finit_module+0x74/0xa0
> [ 107.245874] [004061d4] linux_sparc_syscall32+0x34/0x60
> [ 107.317210] Unable to handle kernel paging request at virtual address
> 00018f09
> [ 107.411482] tsk->{mm,active_mm}->context = 03c4
> [ 107.478123] tsk->{mm,active_mm}->pgd = f800ada7
> [ 107.540600] \|/ \|/
> [ 107.540600] "@'/ .. \`@"
> [ 107.540600] /_| \__/ |_\
> [ 107.540600] \__U_/
> [ 107.716705] modprobe(1155): Oops [#1]
> [ 107.760362] CPU: 2 PID: 1155 Comm: modprobe Not tainted 4.3.0-rc1 #65
> [ 107.837442] task: f800af25ba80 ti: f800adcec000 task.ti:
> f800adcec000
> [ 107.927040] TSTATE: 004411001607 TPC: 00481384 TNPC:
> 00481388 Y: Not tainted
> [ 108.044741] TPC:
> [ 108.094698] g0: 00908ad2 g1: g2:
> g3: 009f2c00
> [ 108.198866] g4: f800af25ba80 g5: f800af01a000 g6: f800adcec000
> g7: f800ad373f68
> [ 108.303025] o0: 00919000 o1: 0040 o2: 00919000
> o3: 00d0
> [ 108.407184] o4: 0097ea00 o5: 0040 sp: f800adceecd1
> ret_pc: 005288a8
> [ 108.515510] RPC:
> [ 108.568576] l0: f800af3a6db8 l1: 343c l2: f800af3a6db8
> l3: 0001
> [ 108.672759] l4: 016e l5: 0001 l6: 3000
> l7: 0002
> [ 108.776902] i0: 00018f090680 i1: 0097ea00 i2: 0097ea00
> i3: 00479530
> [ 108.881062] i4: 0096d800 i5: f800af005bc0 i6: f800adceed81
> i7: 0047958c
> [ 108.985223] I7:
> [ 109.043505] Call Trace:
> [ 109.072666] [0047958c] kthread_create_on_node+0x8c/0x140
> [ 109.145580] [00476874] __alloc_workqueue_key+0x274/0x460
> [ 109.218497] [0062d68c] __bioset_create+0x20c/0x2a0
> [ 109.285154] [00631830] blk_alloc_queue_node+0x50/0x1e0
> [ 109.355987] [0063e54c] blk_mq_init_queue+0xc/0x60
> [ 109.421594] [10033710] loop_add+0xb0/0x240 [loop]
> [ 109.487212] [1003a168] loop_init+0x168/0x1b0 [loop]
> [ 109.554889] [00426c00] do_one_initcall+0x80/0x1c0
> [ 109.620516] [004de3c4] do_init_module+0x48/0x1e4
> [ 109.685081] [004c7654] load_module+0xf14/0x11e0
> [ 109.748623] [004c7ab4] SyS_finit_module+0x74/0xa0
> [ 109.814238] [004061d4] linux_sparc_syscall32+0x34/0x60
> [ 109.885052] Disabling lock debugging due to kernel taint
> [ 109.948585] Caller[0047958c]: kthread_create_on_node+0x8c/0x140
> [ 110.027749] Caller[00476874]: __alloc_workqueue_key+0x274/0x460
> [ 110.106902] Caller[0062d68c]: __bioset_create+0x20c/0x2a0
> [ 110.179816] Caller[00631830]: blk_alloc_queue_node+0x50/0x1e0
> [ 110.256877] Caller[0063e54c]: blk_mq_init_queue+0xc/0x60
> [ 110.328760] Caller[10033710]: loop_add+0xb0/0x240 [loop]
> [ 110.400607] Caller[1003a168]: loop_init+0x168/0x1b0 [loop]
> [ 110.474553] Caller[00426c00]: do_one_initcall+0x80/0x1c0
> [ 110.546406] Caller[004de3c4]: do_init_module+0x48/0x1e4
> [ 110.617242] Caller[004c7654]: load_module+0xf14/0x11e0
> [ 110.687015] Caller[004c7ab4]: SyS_finit_module+0x74/0xa0
> [ 110.758889] Caller[004061d4]: linux_sparc_syscall32+0x34/0x60
> [ 110.835949] Caller[70015738]: 0x70015738
> [ 110.891141] Instruction DUMP: 0100 0100 9de3bf50
> 8208600c 0ac04005 11002409 b2102003 106fff12
>
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Re: Soft lockup issue in Linux 4.1.9
Hi, Holger Hoffstätte wrote: > Greg, any chance you can drop this into the pending 4.1.10? Otherwise people > will get another broken release. For me it looks like the request was too late, the patch is not included in 4.1.10. So don't forget to re-apply the patch when doing the upgrade. Greg, do you need a dedicated inclusion request for http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af in 4.1.x or is it already on your list? -Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 23/39] UBI: drop null test before destroy functions
Am 13.09.2015 um 14:15 schrieb Julia Lawall: > Remove unneeded NULL test. > > The semantic patch that makes this change is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ expression x; @@ > -if (x != NULL) > \(kmem_cache_destroy\|mempool_destroy\|dma_pool_destroy\)(x); > // > > Signed-off-by: Julia Lawall > > --- > drivers/mtd/ubi/attach.c |4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/mtd/ubi/attach.c b/drivers/mtd/ubi/attach.c > index 68eea5b..c1aaf03 100644 > --- a/drivers/mtd/ubi/attach.c > +++ b/drivers/mtd/ubi/attach.c > @@ -1209,9 +1209,7 @@ static void destroy_ai(struct ubi_attach_info *ai) > } > } > > - if (ai->aeb_slab_cache) > - kmem_cache_destroy(ai->aeb_slab_cache); > - > + kmem_cache_destroy(ai->aeb_slab_cache); > kfree(ai); > } Applied! Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread()
jffs2_garbage_collect_thread() can race with SIGCONT and sleep in
TASK_STOPPED state after it was already sent. Add the new helper,
kernel_signal_stop(), which does this correctly.
Signed-off-by: Oleg Nesterov
---
fs/jffs2/background.c | 3 +--
include/linux/sched.h | 10 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index f3145fd..53cc735 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -132,8 +132,7 @@ static int jffs2_garbage_collect_thread(void *_c)
case SIGSTOP:
jffs2_dbg(1, "%s(): SIGSTOP received\n",
__func__);
- set_current_state(TASK_STOPPED);
- schedule();
+ kernel_signal_stop();
break;
case SIGKILL:
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e714539..56e688c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2477,6 +2477,16 @@ static inline int kernel_dequeue_signal(siginfo_t *info)
return ret;
}
+static inline void kernel_signal_stop(void)
+{
+ spin_lock_irq(>sighand->siglock);
+ if (current->jobctl & JOBCTL_STOP_DEQUEUED)
+ __set_current_state(TASK_STOPPED);
+ spin_unlock_irq(>sighand->siglock);
+
+ schedule();
+}
+
extern void release_task(struct task_struct * p);
extern int send_sig_info(int, struct siginfo *, struct task_struct *);
extern int force_sigsegv(int, struct task_struct *);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
1. Rename dequeue_signal_lock() to kernel_dequeue_signal(). This
matches another "for kthreads only" kernel_sigaction() helper.
2. Remove the "tsk" and "mask" arguments, they are always current
and current->blocked. And it is simply wrong if tsk != current.
3. We could also remove the 3rd "siginfo_t *info" arg but it looks
potentially useful. However we can simplify the callers if we
change kernel_dequeue_signal() to accept info => NULL.
4. Remove _irqsave, it is never called from atomic context.
Signed-off-by: Oleg Nesterov
---
drivers/block/nbd.c | 9 ++---
drivers/usb/gadget/function/f_mass_storage.c | 4 +---
fs/jffs2/background.c| 3 +--
include/linux/sched.h| 11 ++-
4 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 293495a..214de17 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -432,9 +432,7 @@ static int nbd_thread_recv(struct nbd_device *nbd)
nbd->task_recv = NULL;
if (signal_pending(current)) {
- siginfo_t info;
-
- ret = dequeue_signal_lock(current, >blocked, );
+ ret = kernel_dequeue_signal(NULL);
dev_warn(nbd_to_dev(nbd), "pid %d, %s, got signal %d\n",
task_pid_nr(current), current->comm, ret);
mutex_lock(>tx_lock);
@@ -545,11 +543,8 @@ static int nbd_thread_send(void *data)
!list_empty(>waiting_queue));
if (signal_pending(current)) {
- siginfo_t info;
- int ret;
+ int ret = kernel_dequeue_signal(NULL);
- ret = dequeue_signal_lock(current, >blocked,
- );
dev_warn(nbd_to_dev(nbd), "pid %d, %s, got signal %d\n",
task_pid_nr(current), current->comm, ret);
mutex_lock(>tx_lock);
diff --git a/drivers/usb/gadget/function/f_mass_storage.c
b/drivers/usb/gadget/function/f_mass_storage.c
index a6eb537..9d1e3b3 100644
--- a/drivers/usb/gadget/function/f_mass_storage.c
+++ b/drivers/usb/gadget/function/f_mass_storage.c
@@ -2347,7 +2347,6 @@ static void fsg_disable(struct usb_function *f)
static void handle_exception(struct fsg_common *common)
{
- siginfo_t info;
int i;
struct fsg_buffhd *bh;
enum fsg_state old_state;
@@ -2359,8 +2358,7 @@ static void handle_exception(struct fsg_common *common)
* into a high-priority EXIT exception.
*/
for (;;) {
- int sig =
- dequeue_signal_lock(current, >blocked, );
+ int sig = kernel_dequeue_signal(NULL);
if (!sig)
break;
if (sig != SIGUSR1) {
diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c
index bb9cebc..f3145fd 100644
--- a/fs/jffs2/background.c
+++ b/fs/jffs2/background.c
@@ -121,13 +121,12 @@ static int jffs2_garbage_collect_thread(void *_c)
/* Put_super will send a SIGKILL and then wait on the sem.
*/
while (signal_pending(current) || freezing(current)) {
- siginfo_t info;
unsigned long signr;
if (try_to_freeze())
goto again;
- signr = dequeue_signal_lock(current, >blocked,
);
+ signr = kernel_dequeue_signal(NULL);
switch(signr) {
case SIGSTOP:
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8c3fa80..e714539 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -2464,14 +2464,15 @@ extern void ignore_signals(struct task_struct *);
extern void flush_signal_handlers(struct task_struct *, int force_default);
extern int dequeue_signal(struct task_struct *tsk, sigset_t *mask, siginfo_t
*info);
-static inline int dequeue_signal_lock(struct task_struct *tsk, sigset_t *mask,
siginfo_t *info)
+static inline int kernel_dequeue_signal(siginfo_t *info)
{
- unsigned long flags;
+ struct task_struct *tsk = current;
+ siginfo_t __info;
int ret;
- spin_lock_irqsave(>sighand->siglock, flags);
- ret = dequeue_signal(tsk, mask, info);
- spin_unlock_irqrestore(>sighand->siglock, flags);
+ spin_lock_irq(>sighand->siglock);
+ ret = dequeue_signal(tsk, >blocked, info ?: &__info);
+ spin_unlock_irq(>sighand->siglock);
return ret;
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
[PATCH 3/3] signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT)
jffs2_garbage_collect_thread() does allow_signal(SIGCONT) for no reason, SIGCONT will wake a stopped task up even if it is ignored. Signed-off-by: Oleg Nesterov --- fs/jffs2/background.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/jffs2/background.c b/fs/jffs2/background.c index 53cc735..e5c1783 100644 --- a/fs/jffs2/background.c +++ b/fs/jffs2/background.c @@ -80,7 +80,6 @@ static int jffs2_garbage_collect_thread(void *_c) siginitset(, sigmask(SIGHUP)); allow_signal(SIGKILL); allow_signal(SIGSTOP); - allow_signal(SIGCONT); allow_signal(SIGHUP); c->gc_task = current; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH -mm 0/3] minor kthread/signals cleanups and fix
On top of signals-kill-block_all_signals-and-unblock_all_signals.patch Simple but untested, hopefully maintainers can ack or nack 1/3 at least. Oleg. drivers/block/nbd.c |9 ++--- drivers/usb/gadget/function/f_mass_storage.c |4 +--- fs/jffs2/background.c|7 ++- include/linux/sched.h| 21 - 4 files changed, 21 insertions(+), 20 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: add Marvell PXA framebuffer binding
Am Samstag, den 03.10.2015, 19:23 +0200 schrieb Robert Jarzmik:
[...]
> a/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> > > b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> > > new file mode 100644
> > > index ..489055bf3c57
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> > > @@ -0,0 +1,75 @@
> > > +PXA LCDC Framebuffer
> > > +-
> > > +
> > > +Required properties:
> > > +- compatible :
> > > + "marvell,pxa2xx-fb",
> >
> > Should be "marvell,pxa2xx-lcd-controller", "marvell,pxa2xx-lcdc" or
> > something like this.
> Whichever you see fit.
Personally, I like the lcdc one better, even though it is an arbitrary
abbreviation of the text found in the manual.
> > > +- reg : Should contain 1 register ranges(address and length).
> > > + Can contain an additional register range(address and
> > > length)
> > > + for fixed framebuffer memory. Useful for dedicated
> > > memories.
> > > +- interrupts : framebuffer controller interrupt
> > > +- display: a phandle pointing to the display node
> > > +
> > > +Required nodes:
> > > +- display: a display node is required to initialize the lcd
> > > panel
> > > + This should be in the board dts.
> >
> > I'd prefer to use an of-graph link to a panel node with a proper
> > compatible value for the panel, instead of this custom display
> > property.
> > That way, if somebody ever decides convert the fbdev driver to a
> > drm
> > driver, we don't have to change the device tree and can directly
> > use
> > drm_panel.
> Ok, if you give me an example it would be easier for me.
Have a look at the of-graph connection between capture interface and
sensor (QCI and MT9M111) in your example below. The connection between
LCD controller and panel should look similar:
pxabus {
lcd-controller@4050 {
compatible = "marvell,pxa2xx-lcdc";
/* ... */
port {
lcdc_out: endpoint {
remote-endpoint = <_in>;
bus-width = <16>;
};
};
};
};
panel {
compatible = "toshiba,ltm0305a776";
lcd-type = "color-tft";
power-supply = <_supply>;
backlight = <_backlight>;
port {
panel_in: endpoint {
remote-endpoint = <_out>;
};
};
}
The bus-width could be made a property of the lcdc_out endpoint for
symmetry with the QCI binding, and as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
If you later bind a drm_panel driver to the panel node, it can look up
that information (and the timings) just from the compatible string.
[...]
> > > +Optional properties:
> > > +- lcd-supply: Regulator for LCD supply voltage.
> >
> > How does this differ from the regulator below?
> Ah yes, good point. In the end I couldn't decide which one was the
> correct one
> ... My feeling is that it's the display's one, as hardware wise the
> power is
> necessary for the display, not the framebuffer.
Then I'd suggest a power-supply property in the panel node, as is
already documented for simple panels:
Documentation/devicetree/bindings/panel/simple-panel.txt
> > > +PXA LCDC Display
> > > +-
> > > +Required properties (as per of_videomode_helper):
> > > + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color
> > > -dstn",
> > > + "color-tft", "smart-panel"
> > > + - bits-per-pixel: LCD data bus width
> >
> > This is already found in the lcd controller node above.
> I think the bus-width should be here. It represents the number of
> data lines
> between the SoC and the panel.
With the of-graph, it can be argued that this is a property of both
endpoints of the bus (imagine an 18-bit panel driven by a 16-bit LCD
controller with some funny wiring).
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] video: fbdev: pxafb: initial devicetree conversion
Am Samstag, den 03.10.2015, 19:08 +0200 schrieb Robert Jarzmik: > > Thanks a lot for working on this! Out of interest, do you plan to > > convert MIOA701 to DT? > Actually, I already had. If you take all the pending patches > scattered across > all the subsystems (around 40 by my last count), then mioa701 is > converted, see > in [1]. If we take -next tree, I think the count will be closer to 20 > or so. This is amazing. I'm looking forward to follow your good example with magician and hx4700 once that hits mainline. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kselftest: replace $(RM) with rm -f command
- On Oct 3, 2015, at 1:55 PM, Josh Triplett j...@joshtriplett.org wrote: > On Sat, Oct 03, 2015 at 02:11:57PM +, Mathieu Desnoyers wrote: >> - On Oct 3, 2015, at 12:38 AM, dvhart dvh...@infradead.org wrote: >> >> > On Mon, Sep 28, 2015 at 03:16:53AM +, Mathieu Desnoyers wrote: >> >> - On Sep 27, 2015, at 10:10 PM, Wang Long long.wangl...@huawei.com >> >> wrote: >> >> >> >> > Some test's Makefile using "$(RM)" while the other's >> >> > using "rm -f". It is better to use one of them in all >> >> > tests. >> >> >> >> I agree that this disparity appears to be unwanted. We >> >> should settle on one or the other. >> >> >> >> > >> >> > "rm -f" is better, because it is less magic, and everyone >> >> > konws what is does. >> >> >> >> "$(RM)" is clearly defined as a Makefile implicit variable >> >> which defaults to "rm -f". >> >> Ref. >> >> https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html >> >> >> >> Leaving it as a variable is more flexible because then the >> >> default behavior can be overridden if need be, which is >> >> not the case of a hardcoded "rm -f". >> >> >> >> Following your line of argumentation, we should then >> >> invoke "gcc" directly in every Makefile because it is >> >> less magic than "$(CC)". This makes no sense. >> > >> > I don't think they can be compared so simply. Specifying a compiler is a >> > common >> > use case. Customizing the rm command is not, in my experience anyway, and >> > like >> > Michael, I would definately have to look up what RM means. >> > >> > That said, I care more about consistency than which is used. Both are >> > valid, but >> > $(RM), while more flexible, will cost more people time to look up what it >> > does >> > as it isn't commonly used than any benefit we're likely to see from its >> > use. >> > >> > Meh. :-) >> >> An example is "grm" when you install the opencsw repository >> packages on Solaris. In the unlikely example where someone >> would have a Solaris machine to build Linux, overriding >> various command names, including "rm", can be useful. This >> is just one example, there are probably others. > > Does Solaris rm not support -f? Yes, it does. I was merely showing this as an example where it can be useful to override the command name, although I don't expect anyone to have to use "grm" rather than "rm" on that specific platform. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kselftest: replace $(RM) with rm -f command
On Sat, Oct 03, 2015 at 02:11:57PM +, Mathieu Desnoyers wrote: > - On Oct 3, 2015, at 12:38 AM, dvhart dvh...@infradead.org wrote: > > > On Mon, Sep 28, 2015 at 03:16:53AM +, Mathieu Desnoyers wrote: > >> - On Sep 27, 2015, at 10:10 PM, Wang Long long.wangl...@huawei.com > >> wrote: > >> > >> > Some test's Makefile using "$(RM)" while the other's > >> > using "rm -f". It is better to use one of them in all > >> > tests. > >> > >> I agree that this disparity appears to be unwanted. We > >> should settle on one or the other. > >> > >> > > >> > "rm -f" is better, because it is less magic, and everyone > >> > konws what is does. > >> > >> "$(RM)" is clearly defined as a Makefile implicit variable > >> which defaults to "rm -f". > >> Ref. > >> https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html > >> > >> Leaving it as a variable is more flexible because then the > >> default behavior can be overridden if need be, which is > >> not the case of a hardcoded "rm -f". > >> > >> Following your line of argumentation, we should then > >> invoke "gcc" directly in every Makefile because it is > >> less magic than "$(CC)". This makes no sense. > > > > I don't think they can be compared so simply. Specifying a compiler is a > > common > > use case. Customizing the rm command is not, in my experience anyway, and > > like > > Michael, I would definately have to look up what RM means. > > > > That said, I care more about consistency than which is used. Both are > > valid, but > > $(RM), while more flexible, will cost more people time to look up what it > > does > > as it isn't commonly used than any benefit we're likely to see from its use. > > > > Meh. :-) > > An example is "grm" when you install the opencsw repository > packages on Solaris. In the unlikely example where someone > would have a Solaris machine to build Linux, overriding > various command names, including "rm", can be useful. This > is just one example, there are probably others. Does Solaris rm not support -f? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
via-rhine: fix VLAN receive handling error in 4.2.x
Hi, via-rhine driver in 4.2.x kernels doesn’t correctly parse VLAN ID on receive. A bug was introduced in the commit 810f19bcb862f8889b27e0c9d9eceac9593925dd. All 4.2.x kernels are affected. 4.1.x and older kernels are not affected. During code refactoring, the sequence of calls changed which introduced a regression. Original sequence was: 1) Read TCI from skb->data 2) Determine eth protocol using eth_type_trans (which calls skb_pull_inline) 3) Write TCI to skb->vlan_tci After the change, the sequence is: 1) Determine protocol using eth_type_trans (which calls skb_pull_inline) 2) Read TCI from skb->data 3) Write TCI to skb->vlan_tci Because eth_type_trans consumes ethernet header worth of bytes, a call to read TCI from packet no longer works as expected as it’s reading from invalid offset. Choosing between changing rhine_get_vlan_tci(), which retrieves TCI from skb->data, or moving eth_type_trans() invocation after rhine_rx_vlan_tag(), I chose the latter. Andrej. --- linux-4.2.2.orig/drivers/net/ethernet/via/via-rhine.c 2015-10-03 15:46:59.81700 +0200 +++ linux-4.2.2/drivers/net/ethernet/via/via-rhine.c2015-10-03 18:53:51.79900 +0200 @@ -2134,10 +2134,11 @@ } skb_put(skb, pkt_len); - skb->protocol = eth_type_trans(skb, dev); rhine_rx_vlan_tag(skb, desc, data_size); + skb->protocol = eth_type_trans(skb, dev); + netif_receive_skb(skb); u64_stats_update_begin(>rx_stats.syncp); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: add Marvell PXA framebuffer binding
Philipp Zabel writes: > On Sat, Oct 3, 2015 at 6:11 PM, Robert Jarzmik wrote: >> Add documentation for the PXA frambuffer devicetree binding. >> >> Signed-off-by: Robert Jarzmik >> Cc: Jean-Christophe Plagniol-Villard >> Cc: Tomi Valkeinen >> Cc: linux-fb...@vger.kernel.org >> >> --- >> .../devicetree/bindings/video/marvell,pxafb.txt| 75 >> ++ >> 1 file changed, 75 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt >> >> diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt >> b/Documentation/devicetree/bindings/video/marvell,pxafb.txt >> new file mode 100644 >> index ..489055bf3c57 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt >> @@ -0,0 +1,75 @@ >> +PXA LCDC Framebuffer >> +- >> + >> +Required properties: >> +- compatible : >> + "marvell,pxa2xx-fb", > > Should be "marvell,pxa2xx-lcd-controller", "marvell,pxa2xx-lcdc" or > something like this. Whichever you see fit. > >> +- reg : Should contain 1 register ranges(address and length). >> + Can contain an additional register range(address and length) >> + for fixed framebuffer memory. Useful for dedicated memories. >> +- interrupts : framebuffer controller interrupt >> +- display: a phandle pointing to the display node >> + >> +Required nodes: >> +- display: a display node is required to initialize the lcd panel >> + This should be in the board dts. > > I'd prefer to use an of-graph link to a panel node with a proper > compatible value for the panel, instead of this custom display > property. > That way, if somebody ever decides convert the fbdev driver to a drm > driver, we don't have to change the device tree and can directly use > drm_panel. Ok, if you give me an example it would be easier for me. >> +- default-mode: a videomode within the display with timing parameters >> + as specified below. >> +- bits-per-pixel: pixel data bus width of the LCD panel > > Would bus-width be better here? bus-width yes, but I think I should remove this property, and only keep the one in the panel/display. >> +Optional properties: >> +- lcd-supply: Regulator for LCD supply voltage. > > How does this differ from the regulator below? Ah yes, good point. In the end I couldn't decide which one was the correct one ... My feeling is that it's the display's one, as hardware wise the power is necessary for the display, not the framebuffer. > >> +- enable-transparency-bit: if framebuffer colorspace reserves a bit for >> + transparency > > That doesn't belong in the device tree. > >> +- enable-greyscale-cmap: true if palette is a grayscale based instead of >> color > > I suspect this doesn't belong in the device tree either. Does this > specify the pixel format of the memory framebuffer? Yes, both these values specify the pixel format. I was thinking this was a hardware capability of the IP, I was wrong, just cross-checked. I'll remove these 2 properties. >> + enable-transparency-bit = <0>; >> + enable-greyscale-cmap = <0>; >> + #address-cells = <1>; >> + #size-cells = <1>; > > What are the #address/size-cells needed for? Copy-paste from another binding, atmel's I think. Poor leftover obviously. >> + }; >> + >> +PXA LCDC Display >> +- >> +Required properties (as per of_videomode_helper): >> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn", >> + "color-tft", "smart-panel" >> + - bits-per-pixel: LCD data bus width > > This is already found in the lcd controller node above. I think the bus-width should be here. It represents the number of data lines between the SoC and the panel. Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: acer-wmi: update notice about deprecated user interface
On Tue, Sep 29, 2015 at 05:50:32PM +0800, joeyli wrote: > Hi Martin, > > On Tue, Sep 29, 2015 at 08:46:38AM +0200, Martin Kepplinger wrote: > > Signed-off-by: Martin Kepplinger > > --- > > This just looks odd in the logs. Feel free to ignore it or act on it > > differently ;) > > > > > > Thanks for your patch and it reminds me to remove those interfaces in > acer-wmi. > Please let me check and I am thinking direct remove those interfaces. Joey, I will wait to hear from you on this patch (or a replacement). Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] platform/x86: Toshiba WMI Hotkey Driver
On Mon, Sep 28, 2015 at 08:32:28PM -0600, Azael Avalos wrote:
> Toshiba laptops that feature WMI events for hotkeys were left unsupported
> by the toshiba_acpi driver, however, commit a88bc06e5aec ("toshiba_acpi:
> Avoid registering input device on WMI event laptops") added hardware
> support for such laptops, but the hotkeys are not handled there.
>
> This driver adds support for hotkey monitoring on certain Toshiba laptops
> that manage the hotkeys via WMI events instead of the Toshiba
> Configuration Interface (TCI).
>
> The toshiba_acpi driver and this one can co-exist, as this only takes
> care of hotkeys, while the proper takes care of hardware related stuff.
>
> Currently the driver is under the EXPERIMENTAL flag, as the keymap
> and the notify function are incomplete (due to lack of hardware to test).
>
> Signed-off-by: Azael Avalos
Queued to testing, thanks Azael.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] video: fbdev: add Marvell PXA framebuffer binding
On Sat, Oct 3, 2015 at 6:11 PM, Robert Jarzmik wrote:
> Add documentation for the PXA frambuffer devicetree binding.
>
> Signed-off-by: Robert Jarzmik
> Cc: Jean-Christophe Plagniol-Villard
> Cc: Tomi Valkeinen
> Cc: linux-fb...@vger.kernel.org
>
> ---
> .../devicetree/bindings/video/marvell,pxafb.txt| 75
> ++
> 1 file changed, 75 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> new file mode 100644
> index ..489055bf3c57
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> @@ -0,0 +1,75 @@
> +PXA LCDC Framebuffer
> +-
> +
> +Required properties:
> +- compatible :
> + "marvell,pxa2xx-fb",
Should be "marvell,pxa2xx-lcd-controller", "marvell,pxa2xx-lcdc" or
something like this.
> +- reg : Should contain 1 register ranges(address and length).
> + Can contain an additional register range(address and length)
> + for fixed framebuffer memory. Useful for dedicated memories.
> +- interrupts : framebuffer controller interrupt
> +- display: a phandle pointing to the display node
> +
> +Required nodes:
> +- display: a display node is required to initialize the lcd panel
> + This should be in the board dts.
I'd prefer to use an of-graph link to a panel node with a proper
compatible value for the panel, instead of this custom display
property.
That way, if somebody ever decides convert the fbdev driver to a drm
driver, we don't have to change the device tree and can directly use
drm_panel.
> +- default-mode: a videomode within the display with timing parameters
> + as specified below.
> +- bits-per-pixel: pixel data bus width of the LCD panel
Would bus-width be better here?
> +Optional properties:
> +- lcd-supply: Regulator for LCD supply voltage.
How does this differ from the regulator below?
> +- enable-transparency-bit: if framebuffer colorspace reserves a bit for
> + transparency
That doesn't belong in the device tree.
> +- enable-greyscale-cmap: true if palette is a grayscale based instead of
> color
I suspect this doesn't belong in the device tree either. Does this
specify the pixel format of the memory framebuffer?
> +Example:
> +
> + fb0: video@0x4400 {
> + compatible = "marvell,pxa2xx-fb";
> + reg = <0x4400 0x1>;
> + interrupts = <17>;
> + clocks = < CLK_LCD>;
> + interrupts = <23>;
> + display = <>;
> + status = "okay";
> +
> + enable-transparency-bit = <0>;
> + enable-greyscale-cmap = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
What are the #address/size-cells needed for?
> + };
> +
> +PXA LCDC Display
> +-
> +Required properties (as per of_videomode_helper):
> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
> + "color-tft", "smart-panel"
> + - bits-per-pixel: LCD data bus width
This is already found in the lcd controller node above.
> +Optional properties (as per of_videomode_helper):
> + - power-regulator: power supply regulator to the LCD to power it on or off
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: reduce CONFIG_SCSI_CONSTANTS impact by 4k
Hi Rasmus, I like this idea. But maybe it's also time to just move the constants to a plain text file and auto-generate C headers from them? That way the format in which they can be edited is decoupled from the representation in the kernel image. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] video: fbdev: pxafb: initial devicetree conversion
Philipp Zabel writes:
> Hi Robert,
>
> On Sat, Oct 3, 2015 at 6:11 PM, Robert Jarzmik wrote:
>> This patch brings a first support of pxa framebuffer devices to a
>> devicetree pxa platform, as was before platform data.
>>
>> There are restrictions with this port, the biggest one being the lack of
>> support of smart panels. Moreover the conversion doesn't provide a way
>> to declare multiple framebuffer configurations with different bits per
>> pixel, only the LCD hardware bus width is used.
>>
>> The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
>> lubbock, mainstone and zylonite).
>>
>> Signed-off-by: Robert Jarzmik
>
> Thanks a lot for working on this! Out of interest, do you plan to
> convert MIOA701 to DT?
Actually, I already had. If you take all the pending patches scattered across
all the subsystems (around 40 by my last count), then mioa701 is converted, see
in [1]. If we take -next tree, I think the count will be closer to 20 or so.
>> @@ -2313,11 +2461,19 @@ static int pxafb_remove(struct platform_device *dev)
>> return 0;
>> }
>>
>> +static const struct of_device_id pxafb_of_dev_id[] = {
>> + {
>> + .compatible = "marvell,pxa2xx-fb",
>
> At least in the old Intel manuals, this was called the LCD Controller,
> all register names are LCsomething.
> Please let's not just put the Linux driver name in the device tree and
> call this pxa2xx-lcd-controller or a shortened version thereof.
Ok, I'm very open for a name change, devicetree is not my speciality, so
basically I'll take any advice :)
Cheers.
--
Robert
[1] mioa701 dt
/*
* Copyright (C) Robert Jarzmik
*
* 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
* publishhed by the Free Software Foundation.
*/
/dts-v1/;
#include "pxa27x.dtsi"
#include "include/dt-bindings/gpio/gpio.h"
#include "include/dt-bindings/clock/pxa-clock.h"
/ {
model = "Mitac Mio A701 Board";
/* compatible = "mitac,mioa701"; */
compatible = "marvell,pxa270";
chosen {
bootargs =
"mtdparts=docg3.0:256k@3456k(barebox)ro,256k(barebox-logo),128k(barebox-env),4M(kernel),-(root)
ubi.mtd=4 rootfstype=ubifs root=ubi0:linux_root ro";
};
memory {
reg = <0xa000 0x0400>;
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
pstore_region:region@0xa200 {
compatible = "linux,contiguous-memory-region";
reg = <0xa200 1048576>;
};
};
};
cpus {
cpu {
cpu-supply = <_core>;
};
};
pxabus {
gpio: gpio@40e0 {
status = "okay";
};
ffuart: uart@4010 {
status = "okay";
};
btuart: uart@4020 {
status = "okay";
};
stuart: uart@4070 {
status = "okay";
};
usb2phy: gpio-vbus@13 {
compatible = "usb-nop-xceiv";
vbus-detect-gpio = < 13 GPIO_ACTIVE_LOW>;
wakeup;
};
pxa27x_udc: udc@4060 {
status = "okay";
gpios = < 22 0>;
phys = <>;
phys-names = "usb2phy";
};
pwri2c: i2c@40f000180 {
status = "okay";
max1586@14 {
compatible = "maxim,max1586";
reg = <0x14>;
v3-gain = <100>;
regulators {
vcc_core: v3 {
regulator-name = "vcc_core";
regulator-compatible =
"Output_V3";
regulator-min-microvolt =
<100>;
regulator-max-microvolt =
<1705000>;
regulator-always-on;
};
};
};
};
pxai2c1: i2c@40301680 {
mrvl,i2c-fast-mode;
status = "okay";
mt9m111: camera@5d {
compatible = "micron,mt9m111";
reg = <0x5d>;
gpios = < 56 GPIO_ACTIVE_HIGH>;
Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()
Mathias Krause writes: > On 2 October 2015 at 22:43, Jason Baron wrote: >> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait >> queue associated with the socket s that we are poll'ing against, but also >> calls [useless full-quote removed] > My reproducer runs on this patch for more than 3 days now without > triggering anything anymore. Since the behaviour of your program is random, using it to "test" anything doesn't really provide any insight: It could have been executing the same codepath which doesn't happen to trigger any problems for all of these three days. Nobody can tell. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] video: fbdev: pxafb: initial devicetree conversion
Hi Robert,
On Sat, Oct 3, 2015 at 6:11 PM, Robert Jarzmik wrote:
> This patch brings a first support of pxa framebuffer devices to a
> devicetree pxa platform, as was before platform data.
>
> There are restrictions with this port, the biggest one being the lack of
> support of smart panels. Moreover the conversion doesn't provide a way
> to declare multiple framebuffer configurations with different bits per
> pixel, only the LCD hardware bus width is used.
>
> The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
> lubbock, mainstone and zylonite).
>
> Signed-off-by: Robert Jarzmik
Thanks a lot for working on this! Out of interest, do you plan to
convert MIOA701 to DT?
[...]
> + of_property_read_u32(dev->of_node, "depth", );
[...]
> + of_property_read_u32(dev->of_node, "enable-transparency-bit",
[...]
> + display = of_parse_phandle(dev->of_node, "display", 0);
[...]
> + ret = of_property_read_u32(disp, "bits-per-pixel", );
[...]
> + ret = of_property_read_string(disp, "lcd-type", );
[...]
> + timings = of_get_display_timings(disp);
These DT properties need some kind of binding documentation.
[...]
> @@ -2313,11 +2461,19 @@ static int pxafb_remove(struct platform_device *dev)
> return 0;
> }
>
> +static const struct of_device_id pxafb_of_dev_id[] = {
> + {
> + .compatible = "marvell,pxa2xx-fb",
At least in the old Intel manuals, this was called the LCD Controller,
all register names are LCsomething.
Please let's not just put the Linux driver name in the device tree and
call this pxa2xx-lcd-controller or a shortened version thereof.
best regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] ARM: at91/dt: shdwc binding: add new shutdown controller documentation
On 30/09/2015 at 18:22:00 +0200, Nicolas Ferre wrote : > +SHDWC Shutdown Controller (Alternative) > + > +1) shdwc node > + > +required properties: > +- compatible: should be "atmel,sama5d2-shdwc". > +- reg: should contain registers location and length > +- clocks: phandle to input clock. > +- #address-cells: should be one. The cell is the wake-up input index. > +- #size-cells: should be zero. > + > +optional properties: > + > +- atmel,wakeup-debouncer: minimum wake-up inputs debouncer period in Shouldn't that property be called atmel,wakeup-debouncer-ms ? > + > +2) input nodes > + > +Wake-up input nodes are usually described in the "board" part of the Device > +Tree. Note also that input 0 is linked to the wake-up pin and is frequently > +used. > + > +Required properties: > +- reg: should contain the wake-up input index [0 - 15]. > + > +Optional properties: > +- atmel,wakeup-type: string, operation mode of the input described by the > child > + node. Supported values are: "high" or "low". > + Maybe we could avoid parsing string and use an integer with a few defines -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] platform: x86: PMC IPC depends on ACPI
On Fri, Sep 25, 2015 at 06:53:56PM -0700, Randy Dunlap wrote: > On 09/25/15 09:38, Lee Jones wrote: > > This patch solves: > > > > on x86_64: > > > > when CONFIG_ACPI is not enabled: > > > > ../drivers/mfd/intel_soc_pmic_bxtwc.c: In function 'bxtwc_probe': > > ../drivers/mfd/intel_soc_pmic_bxtwc.c:342:2: > > error: implicit declaration of function 'acpi_evaluate_integer' > > [-Werror=implicit-function-declaration] > > status = acpi_evaluate_integer(handle, "_HRV", NULL, ); > > ^ > > > > Reported-by: Randy Dunlap > > Signed-off-by: Lee Jones > > Works for me. Thanks. > > Acked-by: Randy Dunlap Lee, Since this appears to be the result of a patch applied to the mfd tree, would you like to pick up this patch? Acked-by: Darren Hart -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/15] cx88: use pci_set_dma_mask insted of pci_dma_supported
Hi Christoph,
Em Sat, 3 Oct 2015 17:19:29 +0200
Christoph Hellwig escreveu:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
For this and the other patches touching at drivers/media:
Acked-by: Mauro Carvalho Chehab
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/media/pci/cx88/cx88-alsa.c | 2 +-
> drivers/media/pci/cx88/cx88-mpeg.c | 2 +-
> drivers/media/pci/cx88/cx88-video.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/pci/cx88/cx88-alsa.c
> b/drivers/media/pci/cx88/cx88-alsa.c
> index 7f8dc60..0703a81 100644
> --- a/drivers/media/pci/cx88/cx88-alsa.c
> +++ b/drivers/media/pci/cx88/cx88-alsa.c
> @@ -890,7 +890,7 @@ static int snd_cx88_create(struct snd_card *card, struct
> pci_dev *pci,
> return err;
> }
>
> - if (!pci_dma_supported(pci,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(pci,DMA_BIT_MASK(32))) {
> dprintk(0, "%s/1: Oops: no 32bit PCI DMA ???\n",core->name);
> err = -EIO;
> cx88_core_put(core, pci);
> diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
> b/drivers/media/pci/cx88/cx88-mpeg.c
> index 34f5057..9b3b565 100644
> --- a/drivers/media/pci/cx88/cx88-mpeg.c
> +++ b/drivers/media/pci/cx88/cx88-mpeg.c
> @@ -393,7 +393,7 @@ static int cx8802_init_common(struct cx8802_dev *dev)
> if (pci_enable_device(dev->pci))
> return -EIO;
> pci_set_master(dev->pci);
> - if (!pci_dma_supported(dev->pci,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(dev->pci,DMA_BIT_MASK(32))) {
> printk("%s/2: Oops: no 32bit PCI DMA ???\n",dev->core->name);
> return -EIO;
> }
> diff --git a/drivers/media/pci/cx88/cx88-video.c
> b/drivers/media/pci/cx88/cx88-video.c
> index 400e5ca..f12af31 100644
> --- a/drivers/media/pci/cx88/cx88-video.c
> +++ b/drivers/media/pci/cx88/cx88-video.c
> @@ -1311,7 +1311,7 @@ static int cx8800_initdev(struct pci_dev *pci_dev,
> dev->pci_lat,(unsigned long long)pci_resource_start(pci_dev,0));
>
> pci_set_master(pci_dev);
> - if (!pci_dma_supported(pci_dev,DMA_BIT_MASK(32))) {
> + if (!pci_set_dma_mask(pci_dev,DMA_BIT_MASK(32))) {
> printk("%s/0: Oops: no 32bit PCI DMA ???\n",core->name);
> err = -EIO;
> goto fail_core;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Bluetooth: hci_smd: Qualcomm WCNSS HCI driver
Hi Bjorn,
>>> The Qualcomm WCNSS chip provides two SMD channels to the BT core; one
>>> for command and one for event packets. This driver exposes the two
>>> channels as a hci device.
>>>
> [..]
>>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>>> index 07c9cf381e5a..43c7dc8641ff 100644
>>> --- a/drivers/bluetooth/Makefile
>>> +++ b/drivers/bluetooth/Makefile
>>> @@ -14,6 +14,7 @@ obj-$(CONFIG_BT_HCIBTUART)+= btuart_cs.o
>>>
>>> obj-$(CONFIG_BT_HCIBTUSB) += btusb.o
>>> obj-$(CONFIG_BT_HCIBTSDIO) += btsdio.o
>>> +obj-$(CONFIG_BT_HCISMD)+= hci_smd.o
>>
>> I wonder if choosing a name like btqcomsmd.ko would not be better
>> here. For now I am fine with keeping hci_smd.ko since there are other
>> issues here to be fixed first.
>
> I had some problems figuring out the naming scheme here, but btqcomsmd
> does seem reasonable, I'll update it in the next set.
>
>> Especially the kbuild test robot complained loudly.
>>
>
> Sorry, I forgot to mention in the patch that the patch depends on the
> qcom_smd_id patch - that's available in linux-next. I will take another
> look, but I think that was the cause of all the issues.
which means, I can only merge this driver when this other patch has hit
net-next tree. Unless I take the qcom_smd_id through bluetooth-next tree which
doesn't look like a good idea.
>>> obj-$(CONFIG_BT_INTEL) += btintel.o
>>> obj-$(CONFIG_BT_ATH3K) += ath3k.o
>>> diff --git a/drivers/bluetooth/hci_smd.c b/drivers/bluetooth/hci_smd.c
> [..]
>>> +#include
>>
>> The hci.h include is not needed. If you do, then you are doing
>> something fishy.
>>
>
> Nothing fishy going on here, so I'll drop it.
>
>>> +
>>> +static struct {
>>> + struct qcom_smd_channel *acl_channel;
>>> + struct qcom_smd_channel *cmd_channel;
>>> +
>>> + struct hci_dev *hci;
>>> +} smd_hci;
>>
>> A driver that only supports a single instance of a device and uses a
>> global variable to do so is not a good idea. There should be no reason
>> for this. Why is this done this way.
>>
>
> There's two channels coming up, each probing the associated driver that
> combines these into 1 hci device.
>
> So I have two options;
>
> * the original idea was to implement multi-channel-per-device support in
> SMD, but as this is the only known case where that's needed I really
> don't want to add all the extra complexity to SMD.
>
> * I can accept the fact that this is silicon inside the MSM SoC and
> should never exist in more than one instance and make this hack. The
> first version I implemented had this structure allocated on the first
> probe, but that didn't really add any value to the static struct.
>
> I picked the second option due to the fact that the patch to SMD was way
> bigger then this patch, and full of nasty logic.
Writing a driver that assume it is a single instance of a given device is never
a good idea. While you might find some instances in the kernel if you look hard
enough, but that doesn't mean we should keep doing this. So this needs
addressing.
>
>>> +
>>> +static int smd_hci_recv(unsigned type, const void *data, size_t count)
>>> +{
>>> + struct sk_buff *skb;
>>> + void *buf;
>>> + int ret;
>>> +
>>> + skb = bt_skb_alloc(count, GFP_ATOMIC);
>>
>> Is it required that this is GFP_ATOMIC or can this actually be
>> GFP_KERNEL?
>>
>
> This is being called from IRQ context upon receiving data on the
> channels.
I wonder why that is needed, but seems an issue in the SMD subsystem. So this
is fine, might want to add a comment above the bt_skb_alloc to remind us.
>
>>> + if (!skb)
>>> + return -ENOMEM;
>>> +
>>> + buf = skb_put(skb, count);
>>> + memcpy_fromio(buf, data, count);
>>
>> Why is this a memcpy_fromio here?
>>
>
> A memcpy here doesn't seem to work on ARM64, probably because the
> pointer references ioremapped memory. We are discussing either marking
> the data __iomem or perhaps using memremap rather then ioremap.
I would add a comment here as well to remind everybody why this is used. And
marking up the pointers is a good idea as well.
>>> +
>>> + skb->dev = (void *)smd_hci.hci;
>>
>> This is no longer needed.
>>
>
> Thanks
>
>>> + bt_cb(skb)->pkt_type = type;
>>> + skb_orphan(skb);
>>> +
>>> + ret = hci_recv_frame(smd_hci.hci, skb);
>>> + if (ret < 0)
>>> + kfree_skb(skb);
>>
>> This is a double kfree_skb here. The hci_recv_frame will consume the
>> skb no matter what.
>>
>
> Thanks
>
>>> +
>>> + return ret;
>>> +}
>>> +
> [..]
>>> +
>>> +static int smd_hci_send(struct hci_dev *hdev, struct sk_buff *skb)
>>> +{
>>> + int ret;
>>> +
>>> + switch (bt_cb(skb)->pkt_type) {
>>> + case HCI_ACLDATA_PKT:
>>> + case HCI_SCODATA_PKT:
>>> + ret = qcom_smd_send(smd_hci.acl_channel, skb->data, skb->len);
>>> + break;
>>> + case HCI_COMMAND_PKT:
>>> + ret = qcom_smd_send(smd_hci.cmd_channel, skb->data, skb->len);
Re: [PATCH 14/19] sony-laptop: fix handling sony_nc_hotkeys_decode result
On Thu, Sep 24, 2015 at 04:00:22PM +0200, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
> Signed-off-by: Andrzej Hajda
Sorry for the delay Andrsej, and thank you for your patch. Given my delay, I've
made a couple of changes myself rather than asking you to resubmit. Please
review and let me know if you have any concerns.
First, The description above is incomplete and relies on context from the URL
to fully explain the problem you are fixing. In the future, please ensure the
commit message is self-sufficient.
I have changed the message to read:
sony-laptop: Fix handling sony_nc_hotkeys_decode result
sony_nv_hotkeys_decode can return a negative value. real_ev is a u32
variable.
The check for real_ev > 0 is incorrect.
Use an intermediate ret variable.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
Signed-off-by: Andrzej Hajda
[dvhart: clarify commit msg, drop superfluous else block]
Signed-off-by: Darren Hart
See below for an additional change.
> ---
> Hi,
>
> To avoid problems with too many mail recipients I have sent whole
> patchset only to LKML. Anyway patches have no dependencies.
>
> Regards
> Andrzej
> ---
> drivers/platform/x86/sony-laptop.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/platform/x86/sony-laptop.c
> b/drivers/platform/x86/sony-laptop.c
> index aeb80d1..d8a2115 100644
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1204,6 +1204,8 @@ static void sony_nc_notify(struct acpi_device *device,
> u32 event)
> {
> u32 real_ev = event;
> u8 ev_type = 0;
> + int ret;
> +
> dprintk("sony_nc_notify, event: 0x%.2x\n", event);
>
> if (event >= 0x90) {
> @@ -1225,13 +1227,15 @@ static void sony_nc_notify(struct acpi_device
> *device, u32 event)
> case 0x0100:
> case 0x0127:
> ev_type = HOTKEY;
> - real_ev = sony_nc_hotkeys_decode(event, handle);
> + ret = sony_nc_hotkeys_decode(event, handle);
>
> - if (real_ev > 0)
> - sony_laptop_report_input_event(real_ev);
> - else
> + if (ret > 0) {
> + sony_laptop_report_input_event(ret);
> + real_ev = ret;
> + } else {
> /* restore the original event for reporting */
> real_ev = event;
> + }
This 4 line else block is superfluous. real_ev is initialized to event and only
changed here if ret > 0. Therefore, there is no need to set real_ev to event
again. I have simply dropped the else block
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: iio: adc: fix comment block coding style issue
This patch to ad7746.c makes the comment block end with a */ on a separate line. Signed-off-by: Hugo Camboulive --- drivers/staging/iio/cdc/ad7746.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c index 10fa372..8445ddd 100644 --- a/drivers/staging/iio/cdc/ad7746.c +++ b/drivers/staging/iio/cdc/ad7746.c @@ -531,7 +531,7 @@ static int ad7746_write_raw(struct iio_dev *indio_dev, /* CAPDAC Scale = 21pF_typ / 127 * CIN Scale = 8.192pF / 2^24 * Offset Scale = CAPDAC Scale / CIN Scale = 338646 -* */ +*/ val /= 338646; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: simple_return: fix typos in messages
On Fri, 2 Oct 2015, Javier Martinez Canillas wrote: > All messages have a typo that misspells the word simplified. Thanks for your contribution, but in another thread it has been proposed to drop the semantic patch completely. julia > > Signed-off-by: Javier Martinez Canillas > > --- > > scripts/coccinelle/misc/simple_return.cocci | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/scripts/coccinelle/misc/simple_return.cocci > b/scripts/coccinelle/misc/simple_return.cocci > index e8b6313b116f..ad22c5236ff6 100644 > --- a/scripts/coccinelle/misc/simple_return.cocci > +++ b/scripts/coccinelle/misc/simple_return.cocci > @@ -134,7 +134,7 @@ p1 << s1.p1; > q << s2.q; > @@ > > -msg = "WARNING: end returns can be simpified and declaration on line %s can > be dropped" % (q[0].line) > +msg = "WARNING: end returns can be simplified and declaration on line %s can > be dropped" % (q[0].line) > coccilib.report.print_report(p[0],msg) > cocci.include_match(False) > > @@ -145,7 +145,7 @@ q << s2.q > ; > @@ > > -msg = "WARNING: end returns may be simpified if negative or 0 value and > declaration on line %s can be dropped" % (q[0].line) > +msg = "WARNING: end returns may be simplified if negative or 0 value and > declaration on line %s can be dropped" % (q[0].line) > coccilib.report.print_report(p[0],msg) > cocci.include_match(False) > > @@ -154,7 +154,7 @@ p << s1.p; > p1 << s1.p1; > @@ > > -msg = "WARNING: end returns can be simpified" > +msg = "WARNING: end returns can be simplified" > coccilib.report.print_report(p[0],msg) > > @script:python depends on report@ > @@ -162,19 +162,19 @@ p << s1.p; > p2 << s1.p2; > @@ > > -msg = "WARNING: end returns can be simpified if negative or 0 value" > +msg = "WARNING: end returns can be simplified if negative or 0 value" > coccilib.report.print_report(p[0],msg) > > @script:python depends on report@ > p << s3.p1; > @@ > > -msg = "WARNING: end returns can be simpified" > +msg = "WARNING: end returns can be simplified" > coccilib.report.print_report(p[0],msg) > > @script:python depends on report@ > p << s3.p2; > @@ > > -msg = "WARNING: end returns can be simpified if tested value is negative or > 0" > +msg = "WARNING: end returns can be simplified if tested value is negative or > 0" > coccilib.report.print_report(p[0],msg) > -- > 2.4.3 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: misc: remove "complex return code" warnings
Should have acked this message...
Acked-by: Julia Lawall
On Wed, 30 Sep 2015, Johan Hovold wrote:
> This effectively reverts 932058a5d5f9 ("coccinelle: misc: semantic patch
> to delete overly complex return code processing").
>
> There can be both symmetry and readability reasons for not wanting to do
> the final function call as part of the return statement and to maintain
> a clear separation of success and error paths.
>
> Since this is in no way mandated by the coding standard, let's just
> remove this semantic patch to avoid having "clean up" patches being
> posted over and over in response to these Coccinelle warnings.
>
> Signed-off-by: Johan Hovold
> ---
> scripts/coccinelle/misc/simple_return.cocci | 180
>
> 1 file changed, 180 deletions(-)
> delete mode 100644 scripts/coccinelle/misc/simple_return.cocci
>
> diff --git a/scripts/coccinelle/misc/simple_return.cocci
> b/scripts/coccinelle/misc/simple_return.cocci
> deleted file mode 100644
> index e8b6313b116f..
> --- a/scripts/coccinelle/misc/simple_return.cocci
> +++ /dev/null
> @@ -1,180 +0,0 @@
> -/// Simplify a trivial if-return sequence. Possibly combine with a
> -/// preceding function call.
> -///
> -// Confidence: High
> -// Copyright: (C) 2014 Julia Lawall, INRIA/LIP6. GPLv2.
> -// Copyright: (C) 2014 Gilles Muller, INRIA/LiP6. GPLv2.
> -// URL: http://coccinelle.lip6.fr/
> -// Comments:
> -// Options: --no-includes --include-headers
> -
> -virtual patch
> -virtual context
> -virtual org
> -virtual report
> -
> -@r depends on patch@
> -local idexpression e;
> -identifier i,f,fn;
> -@@
> -
> -fn(...) { <...
> -- e@i =
> -+ return
> -f(...);
> --if (i != 0) return i;
> --return 0;
> -...> }
> -
> -@depends on patch@
> -identifier r.i;
> -type t;
> -@@
> -
> --t i;
> - ... when != i
> -
> -@depends on patch@
> -expression e;
> -@@
> -
> --if (e != 0)
> - return e;
> --return 0;
> -
> -// ---
> -
> -@s1 depends on context || org || report@
> -local idexpression e;
> -identifier i,f,fn;
> -position p,p1,p2;
> -@@
> -
> -fn(...) { <...
> -* e@i@p = f(...);
> - if (\(i@p1 != 0\|i@p2 < 0\))
> - return i;
> - return 0;
> -...> }
> -
> -@s2 depends on context || org || report forall@
> -identifier s1.i;
> -type t;
> -position q,s1.p;
> -expression e,f;
> -@@
> -
> -* t i@q;
> - ... when != i
> - e@p = f(...);
> -
> -@s3 depends on context || org || report@
> -expression e;
> -position p1!=s1.p1;
> -position p2!=s1.p2;
> -@@
> -
> -*if (\(e@p1 != 0\|e@p2 < 0\))
> - return e;
> - return 0;
> -
> -// ---
> -
> -@script:python depends on org@
> -p << s1.p;
> -p1 << s1.p1;
> -q << s2.q;
> -@@
> -
> -cocci.print_main("decl",q)
> -cocci.print_secs("use",p)
> -cocci.include_match(False)
> -
> -@script:python depends on org@
> -p << s1.p;
> -p2 << s1.p2;
> -q << s2.q;
> -@@
> -
> -cocci.print_main("decl",q)
> -cocci.print_secs("use with questionable test",p)
> -cocci.include_match(False)
> -
> -@script:python depends on org@
> -p << s1.p;
> -p1 << s1.p1;
> -@@
> -
> -cocci.print_main("use",p)
> -
> -@script:python depends on org@
> -p << s1.p;
> -p2 << s1.p2;
> -@@
> -
> -cocci.print_main("use with questionable test",p)
> -
> -@script:python depends on org@
> -p << s3.p1;
> -@@
> -
> -cocci.print_main("test",p)
> -
> -@script:python depends on org@
> -p << s3.p2;
> -@@
> -
> -cocci.print_main("questionable test",p)
> -
> -// ---
> -
> -@script:python depends on report@
> -p << s1.p;
> -p1 << s1.p1;
> -q << s2.q;
> -@@
> -
> -msg = "WARNING: end returns can be simpified and declaration on line %s can
> be dropped" % (q[0].line)
> -coccilib.report.print_report(p[0],msg)
> -cocci.include_match(False)
> -
> -@script:python depends on report@
> -p << s1.p;
> -p1 << s1.p1;
> -q << s2.q
> -;
> -@@
> -
> -msg = "WARNING: end returns may be simpified if negative or 0 value and
> declaration on line %s can be dropped" % (q[0].line)
> -coccilib.report.print_report(p[0],msg)
> -cocci.include_match(False)
> -
> -@script:python depends on report@
> -p << s1.p;
> -p1 << s1.p1;
> -@@
> -
> -msg = "WARNING: end returns can be simpified"
> -coccilib.report.print_report(p[0],msg)
> -
> -@script:python depends on report@
> -p << s1.p;
> -p2 << s1.p2;
> -@@
> -
> -msg = "WARNING: end returns can be simpified if negative or 0 value"
> -coccilib.report.print_report(p[0],msg)
> -
> -@script:python depends on report@
> -p << s3.p1;
> -@@
> -
> -msg = "WARNING: end returns can be simpified"
> -coccilib.report.print_report(p[0],msg)
> -
> -@script:python depends on report@
> -p << s3.p2;
> -@@
> -
> -msg = "WARNING: end returns can be simpified if tested value is negative or
> 0"
> -coccilib.report.print_report(p[0],msg)
> --
> 2.4.9
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Re: [PATCH] coccinelle: misc: remove "complex return code" warnings
Acked-by: Julia Lawall
Perhaps there is a more restricted version that can be acceptable, but I'm
OK with dropping the current version.
julia
On Thu, 1 Oct 2015, Johan Hovold wrote:
> On Thu, Oct 01, 2015 at 07:20:10AM +0200, Julia Lawall wrote:
> > On Wed, 30 Sep 2015, Johan Hovold wrote:
> >
> > > This effectively reverts 932058a5d5f9 ("coccinelle: misc: semantic patch
> > > to delete overly complex return code processing").
> > >
> > > There can be both symmetry and readability reasons for not wanting to do
> > > the final function call as part of the return statement and to maintain
> > > a clear separation of success and error paths.
> > >
> > > Since this is in no way mandated by the coding standard, let's just
> > > remove this semantic patch to avoid having "clean up" patches being
> > > posted over and over in response to these Coccinelle warnings.
> >
> > What do you mean by "posted"? Are you referring to 0-day build testing
> > or individual usage of make coccicheck? Maybe it would make sense to
> > remove the semantic patch from 0-day build testing but leave it in the
> > kernel, perhaps removing the < 0 case because that one in practice doesn't
> > seem to turn up much that is useful?
>
> Individuals running coccicheck on in-kernel code and posting patches to
> "fix warnings", where the end result is not necessarily an improvement.
>
> But I don't think these warnings should be enabled for 0-day build
> testing either as it is should be up to the author to decide what style
> to prefer in each case.
>
> > Perhaps it could also be improved to detect a previous != 0 case and then
> > not return a warning. On some functions, this change can make some nice
> > simplifications.
>
> Yes, that would at least improve things.
>
> I don't think warnings should be generated at all for the following
> code:
>
> {
> int ret;
>
> ret = init_a(...);
> if (ret)
> return ret;
>
> ret = init_b(...);
> if (ret)
> return ret;
>
> return 0;
> }
>
> as it is (at least to me) preferred over:
>
> {
> int ret;
>
> ret = init_a(...);
> if (ret)
> return ret;
>
> return init_b(...);
> }
>
> for symmetry and readability reasons (e.g. I don't have to look at
> init_b to figure out what the functions returns). And with a long
> parameter list to init_b with line breaks, this would look even worse.
>
> But either way, it should be up to the author of the code to decide what
> style to use.
>
> Thanks,
> Johan
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/24] ver_linux: gcc.patch
Am 03.10.2015 um 18:07 schrieb Alexander Kapshuk:
> The main objective I endeavoured to attain was to come up with an
> algorithm that would possibly result in a uniform output that would
> work across as many distros as possbile. The current implementation
> seems to struggle with that.
What that? The output if ver_linux is designed for humans.
It is not JSON, ASN.1 or XML.
> In my experience, 'sed' enables handling situations where the data
> being looked for is located in varying places more gracefully.
>
> For example, 'gcc -dumpversion', outputs its version in a
> dot-separated numerical format. Thankfully, this format seems to be
> uniform across all the distros I have been able to test it on. So in
> this particular case, the original implementation works as expected.
> However, should 'gcc -dumpversion' change its output in the future,
> with some distros further modifying this output, so that the version
> ends up in different fields, the original awk implementation would no
> longer work. Of course, perhaps a more complex awk script could be
> written to handle this. It just that with 'sed', in my view, it would
> be a matter of adding/modifying the current patterns in a way that
> would be accommodating to the changed format.
>
> E.g.
> 'ld -v 2>&1' output on
> Debian is:
> GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303
>
> Oracle Linux:
> GNU ld version 2.23.52.0.1-30.el7_1.2 20130226
>
> Gentoo:
> GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
I don't see a problem with these three different outputs.
Everyone can read it.
> The binutils patch:
> ld -v 2>&1 |
> sed '
> /[0-9]$/!d# applies to all 3 cases;
> s/-.*// # applies to Debian/Oracle, but doesn't affect Gentoo;
> s/.*[ \t]// # applies to all 3 cases;
> s/^/binutils\t\t/
> '
Seems horrible over engineered to me.
> So far, I have not been able to come up with an awk solution that
> would work equally well across all three distros. My best take so far
> has been:
> Debian:
> ld -v 2>&1 | awk -F'[ \t\-]+' '{print $(NF-1)}'
> 2.20.1
>
> Oracle Linux:
> ld -v 2>&1 | awk -F'[ \t\-]+' '{print $(NF-2)}'
> 2.23.52.0.1
>
> Gentoo:
> ld -v 2>&1 | awk '{print $NF}'
> 2.25.1
>
> Which is far from being a uniform implementation.
Why do you focus on that so much?
> I hope I am making sense here.
I fear your patch is a solution for a non-existing problem.
> I have found the proposed implementation to work well in all the
> distros I have had access to, so I thought I would share it with the
> community. If the folk here have some suggestions to make, I am
> willing to do my best to work in with them.
>
> At the same time, I do understand that 'ver_linux' is not a tool that
> is crucial to kernel development. On this token, I do not expect, nor
> insist on the proposed implementation to be accepted. I leave it to
> the discretion of the maintainers whether or not to accept any of the
> patches.
That said, the decision is not up to me.
As I said, let's try to keep things simple unless we really need to
complicate them.
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usbhid: Fix for the WiiU adapter from Mayflash
The WiiU adapter from Mayflash (see
http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not working
correctly.
The "XInput" mode works fine, the controller is recognized as a xbox
controller. But it is only possible to connect one controller with this method.
In "DInput" mode the device is recognized as some kind of mouse input but no
joystick is created. This commit will change this behavior with
HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that it will
also create joysticks in /dev/input/js*.
Signed-off-by: Oliver Schmitt
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/usbhid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f769208..cfb317e 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -288,6 +288,7 @@
#define USB_DEVICE_ID_DMI_ENC 0x5fab
#define USB_VENDOR_ID_DRAGONRISE 0x0079
+#define USB_DEVICE_ID_DRAGONRISE_WIIU 0x1800
#define USB_VENDOR_ID_DWAV 0x0eef
#define USB_DEVICE_ID_EGALAX_TOUCHCONTROLLER 0x0001
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 1dff8f0..26d2f83 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -71,6 +71,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
{ USB_VENDOR_ID_CHICONY,
USB_DEVICE_ID_CHICONY_PIXART_USB_OPTICAL_MOUSE, HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_WIIU,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_009B,
HID_QUIRK_ALWAYS_POLL },
{ USB_VENDOR_ID_ELAN, USB_DEVICE_ID_ELAN_TOUCHSCREEN_0103,
HID_QUIRK_ALWAYS_POLL },
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] video: fbdev: pxafb: devicetree conversion
This patchset aims at bringing support for the pxa framebuffer driver to a devicetree pxa platform. This was tested on a pxa27x platform, in both a devicetree build and a classic platform data one. Robert Jarzmik (2): video: fbdev: pxafb: loosen the platform data bond video: fbdev: pxafb: initial devicetree conversion drivers/video/fbdev/Kconfig | 2 + drivers/video/fbdev/pxafb.c | 212 +++- drivers/video/fbdev/pxafb.h | 2 + 3 files changed, 195 insertions(+), 21 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] video: fbdev: pxafb: loosen the platform data bond
In order to prepare the transition to a mixed platform data and
device-tree initialization, remove all the platform data references all
over the driver.
Copy the platform data into the internal structure of the pxafb, and
only use this afterward.
Signed-off-by: Robert Jarzmik
---
drivers/video/fbdev/pxafb.c | 54 -
drivers/video/fbdev/pxafb.h | 2 ++
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index 94813af97f09..ed4b1a5dc306 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -457,7 +457,7 @@ static int pxafb_adjust_timing(struct pxafb_info *fbi,
static int pxafb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
struct pxafb_info *fbi = container_of(info, struct pxafb_info, fb);
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
int err;
if (inf->fixed_modes) {
@@ -1230,7 +1230,7 @@ static unsigned int __smart_timing(unsigned time_ns,
unsigned long lcd_clk)
static void setup_smart_timing(struct pxafb_info *fbi,
struct fb_var_screeninfo *var)
{
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
struct pxafb_mode_info *mode = >modes[0];
unsigned long lclk = clk_get_rate(fbi->clk);
unsigned t1, t2, t3, t4;
@@ -1258,14 +1258,13 @@ static void setup_smart_timing(struct pxafb_info *fbi,
static int pxafb_smart_thread(void *arg)
{
struct pxafb_info *fbi = arg;
- struct pxafb_mach_info *inf = dev_get_platdata(fbi->dev);
+ struct pxafb_mach_info *inf = fbi->inf;
if (!inf->smart_update) {
pr_err("%s: not properly initialized, thread terminated\n",
__func__);
return -EINVAL;
}
- inf = dev_get_platdata(fbi->dev);
pr_debug("%s(): task starting\n", __func__);
@@ -1788,11 +1787,11 @@ decode_mode:
fbi->video_mem_size = video_mem_size;
}
-static struct pxafb_info *pxafb_init_fbinfo(struct device *dev)
+static struct pxafb_info *pxafb_init_fbinfo(struct device *dev,
+ struct pxafb_mach_info *inf)
{
struct pxafb_info *fbi;
void *addr;
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
/* Alloc the pxafb_info and pseudo_palette in one step */
fbi = kmalloc(sizeof(struct pxafb_info) + sizeof(u32) * 16, GFP_KERNEL);
@@ -1801,6 +1800,7 @@ static struct pxafb_info *pxafb_init_fbinfo(struct device
*dev)
memset(fbi, 0, sizeof(struct pxafb_info));
fbi->dev = dev;
+ fbi->inf = inf;
fbi->clk = clk_get(dev, NULL);
if (IS_ERR(fbi->clk)) {
@@ -1852,10 +1852,9 @@ static struct pxafb_info *pxafb_init_fbinfo(struct
device *dev)
}
#ifdef CONFIG_FB_PXA_PARAMETERS
-static int parse_opt_mode(struct device *dev, const char *this_opt)
+static int parse_opt_mode(struct device *dev, const char *this_opt,
+ struct pxafb_mach_info *inf)
{
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
-
const char *name = this_opt+5;
unsigned int namelen = strlen(name);
int res_specified = 0, bpp_specified = 0;
@@ -1911,9 +1910,9 @@ done:
return 0;
}
-static int parse_opt(struct device *dev, char *this_opt)
+static int parse_opt(struct device *dev, char *this_opt,
+struct pxafb_mach_info *inf)
{
- struct pxafb_mach_info *inf = dev_get_platdata(dev);
struct pxafb_mode_info *mode = >modes[0];
char s[64];
@@ -1922,7 +1921,7 @@ static int parse_opt(struct device *dev, char *this_opt)
if (!strncmp(this_opt, "vmem:", 5)) {
video_mem_size = memparse(this_opt + 5, NULL);
} else if (!strncmp(this_opt, "mode:", 5)) {
- return parse_opt_mode(dev, this_opt);
+ return parse_opt_mode(dev, this_opt, inf);
} else if (!strncmp(this_opt, "pixclock:", 9)) {
mode->pixclock = simple_strtoul(this_opt+9, NULL, 0);
sprintf(s, "pixclock: %ld\n", mode->pixclock);
@@ -2011,7 +2010,8 @@ static int parse_opt(struct device *dev, char *this_opt)
return 0;
}
-static int pxafb_parse_options(struct device *dev, char *options)
+static int pxafb_parse_options(struct device *dev, char *options,
+ struct pxafb_mach_info *inf)
{
char *this_opt;
int ret;
@@ -2023,7 +2023,7 @@ static int pxafb_parse_options(struct device *dev, char
*options)
/* could be made table driven or similar?... */
while ((this_opt = strsep(, ",")) != NULL) {
- ret = parse_opt(dev, this_opt);
+ ret = parse_opt(dev, this_opt, inf);
if (ret)
[PATCH 2/2] video: fbdev: pxafb: initial devicetree conversion
This patch brings a first support of pxa framebuffer devices to a
devicetree pxa platform, as was before platform data.
There are restrictions with this port, the biggest one being the lack of
support of smart panels. Moreover the conversion doesn't provide a way
to declare multiple framebuffer configurations with different bits per
pixel, only the LCD hardware bus width is used.
The patch was tested on both pxa25x, pxa27x and pxa3xx platform (namely
lubbock, mainstone and zylonite).
Signed-off-by: Robert Jarzmik
---
drivers/video/fbdev/Kconfig | 2 +
drivers/video/fbdev/pxafb.c | 162 +++-
2 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 8b1d371b5404..1a24ca5a0624 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1878,6 +1878,8 @@ config FB_PXA
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
+ select VIDEOMODE_HELPERS if OF
+ select FB_MODE_HELPERS if OF
---help---
Frame buffer driver for the built-in LCD controller in the Intel
PXA2x0 processor.
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index ed4b1a5dc306..602622c56186 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -55,6 +55,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -2092,6 +2094,152 @@ static void pxafb_check_options(struct device *dev,
struct pxafb_mach_info *inf)
#define pxafb_check_options(...) do {} while (0)
#endif
+#if defined(CONFIG_OF)
+static const char * const lcd_types[] = {
+ "unknown", "mono-stn", "mono-dstn", "color-stn", "color-dstn",
+ "color-tft", "smart-panel", NULL
+};
+
+static int of_get_pxafb_display(struct device *dev, struct device_node *disp,
+ struct pxafb_mach_info *info)
+{
+ struct display_timings *timings;
+ struct videomode vm;
+ int i, ret = -EINVAL;
+ u32 bpp;
+ const char *s;
+
+ ret = of_property_read_u32(disp, "bits-per-pixel", );
+ if (ret) {
+ dev_err(dev, "no bits per pixel specified: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_read_string(disp, "lcd-type", );
+ if (ret) {
+ dev_err(dev, "no lcd type: %d\n", ret);
+ return ret;
+ }
+
+ for (i = 0; lcd_types[i]; i++)
+ if (!strcmp(s, lcd_types[i]))
+ break;
+ if (!i || !lcd_types[i]) {
+ dev_err(dev, "lcd-type %s is unknown\n", s);
+ return -EINVAL;
+ }
+ info->lcd_conn |= LCD_CONN_TYPE(i);
+ info->lcd_conn |= LCD_CONN_WIDTH(bpp);
+
+ timings = of_get_display_timings(disp);
+ if (!timings)
+ goto out;
+
+ ret = -ENOMEM;
+ info->modes = kmalloc_array(timings->num_timings,
+ sizeof(info->modes[0]), GFP_KERNEL);
+ if (!info->modes)
+ goto out;
+ info->num_modes = timings->num_timings;
+
+ for (i = 0; i < timings->num_timings; i++) {
+ ret = videomode_from_timings(timings, , i);
+ if (ret) {
+ dev_err(dev, "videomode_from_timings %d failed: %d\n",
+ i, ret);
+ goto out;
+ }
+ if (vm.flags & DISPLAY_FLAGS_PIXDATA_POSEDGE)
+ info->lcd_conn |= LCD_PCLK_EDGE_RISE;
+ if (vm.flags & DISPLAY_FLAGS_PIXDATA_NEGEDGE)
+ info->lcd_conn |= LCD_PCLK_EDGE_FALL;
+ if (vm.flags & DISPLAY_FLAGS_DE_HIGH)
+ info->lcd_conn |= LCD_BIAS_ACTIVE_HIGH;
+ if (vm.flags & DISPLAY_FLAGS_DE_LOW)
+ info->lcd_conn |= LCD_BIAS_ACTIVE_LOW;
+ if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH)
+ info->modes[i].sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm.flags & DISPLAY_FLAGS_VSYNC_HIGH)
+ info->modes[i].sync |= FB_SYNC_VERT_HIGH_ACT;
+
+ info->modes[i].pixclock = 10UL / (vm.pixelclock / 1000);
+ info->modes[i].xres = vm.hactive;
+ info->modes[i].yres = vm.vactive;
+ info->modes[i].hsync_len = vm.hsync_len;
+ info->modes[i].left_margin = vm.hback_porch;
+ info->modes[i].right_margin = vm.hfront_porch;
+ info->modes[i].vsync_len = vm.vsync_len;
+ info->modes[i].upper_margin = vm.vback_porch;
+ info->modes[i].lower_margin = vm.vfront_porch;
+ info->modes[i].bpp = bpp;
+ }
+ ret = 0;
+
+out:
+ display_timings_release(timings);
+ return ret;
+}
+
+static int of_get_pxafb_mode_info(struct device *dev,
+
[PATCH] video: fbdev: add Marvell PXA framebuffer binding
Add documentation for the PXA frambuffer devicetree binding.
Signed-off-by: Robert Jarzmik
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen
Cc: linux-fb...@vger.kernel.org
---
.../devicetree/bindings/video/marvell,pxafb.txt| 75 ++
1 file changed, 75 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt
b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
new file mode 100644
index ..489055bf3c57
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
@@ -0,0 +1,75 @@
+PXA LCDC Framebuffer
+-
+
+Required properties:
+- compatible :
+ "marvell,pxa2xx-fb",
+- reg : Should contain 1 register ranges(address and length).
+ Can contain an additional register range(address and length)
+ for fixed framebuffer memory. Useful for dedicated memories.
+- interrupts : framebuffer controller interrupt
+- display: a phandle pointing to the display node
+
+Required nodes:
+- display: a display node is required to initialize the lcd panel
+ This should be in the board dts.
+- default-mode: a videomode within the display with timing parameters
+ as specified below.
+- bits-per-pixel: pixel data bus width of the LCD panel
+
+Optional properties:
+- lcd-supply: Regulator for LCD supply voltage.
+- enable-transparency-bit: if framebuffer colorspace reserves a bit for
+ transparency
+- enable-greyscale-cmap: true if palette is a grayscale based instead of color
+
+Example:
+
+ fb0: video@0x4400 {
+ compatible = "marvell,pxa2xx-fb";
+ reg = <0x4400 0x1>;
+ interrupts = <17>;
+ clocks = < CLK_LCD>;
+ interrupts = <23>;
+ display = <>;
+ status = "okay";
+
+ enable-transparency-bit = <0>;
+ enable-greyscale-cmap = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
+PXA LCDC Display
+-
+Required properties (as per of_videomode_helper):
+ - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
+ "color-tft", "smart-panel"
+ - bits-per-pixel: LCD data bus width
+
+Optional properties (as per of_videomode_helper):
+ - power-regulator: power supply regulator to the LCD to power it on or off
+
+Example:
+ display0: display {
+ lcd-type = "color-tft";
+ bits-per-pixel = <16>;
+
+ display-timings {
+ native-mode = <>;
+ timing0: 240p {
+ /* 240x320p24 */
+ clock-frequency = <4545000>;
+ hactive = <240>;
+ vactive = <320>;
+ hfront-porch = <4>;
+ hback-porch = <6>;
+ hsync-len = <4>;
+ vback-porch = <5>;
+ vfront-porch = <3>;
+ vsync-len = <2>;
+ pixelclk-active = <0>;
+ de-active = <1>;
+ };
+ };
+ };
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/17] platform: x86: remove misuse of IRQF_NO_SUSPEND flag
On Mon, Sep 21, 2015 at 04:47:01PM +0100, Sudeep Holla wrote:
> The IRQF_NO_SUSPEND flag is used to identify the interrupts that should
> be left enabled so as to allow them to work as expected during the
> suspend-resume cycle, but doesn't guarantee that it will wake the system
> from a suspended state, enable_irq_wake is recommended to be used for
> the wakeup.
>
> This patch removes the use of IRQF_NO_SUSPEND flags and uses newly
> introduce PM wakeup APIs dev_pm_{set,clear}_wake_irq.
>
> Cc: Darren Hart
> Cc: platform-driver-...@vger.kernel.org
> Signed-off-by: Sudeep Holla
Queued to testing, thanks Sudeep.
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/24] ver_linux: gcc.patch
On Sat, Oct 3, 2015 at 6:07 PM, Richard Weinberger
wrote:
> On Sat, Oct 3, 2015 at 3:07 PM, Alexander Kapshuk
> wrote:
>> Using 'awk' here is a bit of an overkill. Should the output of 'gcc
>> -dumpversion' vary on another disto, or change overtime, it may no longer
>> be available at field 1, as relied on by the current implementation.
>> I believe 'sed' offers greater flexibility here in terms of processing
>> varying output as well as being more light-weight.
>>
>> Tested on:
>> Gentoo Linux
>> Debian 6.0.10
>> Oracle Linux Server release 7.1
>> Arch Linux
>> openSuSE 13.2
>>
>> Signed-off-by: Alexander Kapshuk
>> ---
>> --- linux/scripts/ver_linux.orig2015-10-03 13:41:57.118790241 +0300
>> +++ linux/scripts/ver_linux2015-10-03 13:48:49.277622632 +0300
>> @@ -11,8 +11,12 @@
>> uname -a
>> echo ' '
>>
>> -gcc -dumpversion 2>&1| awk \
>> -'NR==1{print "Gnu C ", $1}'
>> +test -x "$gcc" &&
>> +$gcc -dumpversion 2>&1 |
>> +sed '
>> +/^[0-9\.]*$/!d
>> +s/^/GNU C\t\t\t/
>> +'
>
> I'm not sure whether replacing a bog standard idiom with a non-trivial
> sed expression
> is a good idea.
> Your argument that currently the version has to be the first field is weak,
> your script has a even stronger assumption, it assumes that the
> version is field 1
> _and_ has too be numeric.
> But maybe I'm misinterpreting your regex, regex is hard to read for a human.
> :)
>
> IMHO we should keep things simple. It's not that ver_linux (and other
> scripts you patch) are hot paths
> in the kernel build process.
>
> --
> Thanks,
> //richard
Thanks for your feedback.
The main objective I endeavoured to attain was to come up with an
algorithm that would possibly result in a uniform output that would
work across as many distros as possbile. The current implementation
seems to struggle with that.
In my experience, 'sed' enables handling situations where the data
being looked for is located in varying places more gracefully.
For example, 'gcc -dumpversion', outputs its version in a
dot-separated numerical format. Thankfully, this format seems to be
uniform across all the distros I have been able to test it on. So in
this particular case, the original implementation works as expected.
However, should 'gcc -dumpversion' change its output in the future,
with some distros further modifying this output, so that the version
ends up in different fields, the original awk implementation would no
longer work. Of course, perhaps a more complex awk script could be
written to handle this. It just that with 'sed', in my view, it would
be a matter of adding/modifying the current patterns in a way that
would be accommodating to the changed format.
E.g.
'ld -v 2>&1' output on
Debian is:
GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303
Oracle Linux:
GNU ld version 2.23.52.0.1-30.el7_1.2 20130226
Gentoo:
GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
The binutils patch:
ld -v 2>&1 |
sed '
/[0-9]$/!d# applies to all 3 cases;
s/-.*// # applies to Debian/Oracle, but doesn't affect Gentoo;
s/.*[ \t]// # applies to all 3 cases;
s/^/binutils\t\t/
'
So far, I have not been able to come up with an awk solution that
would work equally well across all three distros. My best take so far
has been:
Debian:
ld -v 2>&1 | awk -F'[ \t\-]+' '{print $(NF-1)}'
2.20.1
Oracle Linux:
ld -v 2>&1 | awk -F'[ \t\-]+' '{print $(NF-2)}'
2.23.52.0.1
Gentoo:
ld -v 2>&1 | awk '{print $NF}'
2.25.1
Which is far from being a uniform implementation.
I hope I am making sense here.
I have found the proposed implementation to work well in all the
distros I have had access to, so I thought I would share it with the
community. If the folk here have some suggestions to make, I am
willing to do my best to work in with them.
At the same time, I do understand that 'ver_linux' is not a tool that
is crucial to kernel development. On this token, I do not expect, nor
insist on the proposed implementation to be accepted. I leave it to
the discretion of the maintainers whether or not to accept any of the
patches.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: lustre: llite: Added a blank line
On Oct 3, 2015, at 7:39 AM, Anjali Menon wrote:
> Added a blank line after declaration to fix the coding
> style warning detected by checkpatch.pl
>
> WARNING: Missing a blank line after declarations
>
> Signed-off-by: Anjali Menon
> ---
> drivers/staging/lustre/lustre/llite/llite_capa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/lustre/lustre/llite/llite_capa.c
> b/drivers/staging/lustre/lustre/llite/llite_capa.c
> index aec9a44..a626871 100644
> --- a/drivers/staging/lustre/lustre/llite/llite_capa.c
> +++ b/drivers/staging/lustre/lustre/llite/llite_capa.c
> @@ -140,6 +140,7 @@ static void sort_add_capa(struct obd_capa *ocapa, struct
> list_head *head)
> static inline int obd_capa_open_count(struct obd_capa *oc)
This whole file has been recently removed.
In general at least with Lustre (and probably with other staging code) it's
best to
base your work on Greg's staging-next (or even staging-testing) tree because
this
is where the most up to date code is (And this is where Greg tries to apply it
anyway).
> {
> struct ll_inode_info *lli = ll_i2info(oc->u.cli.inode);
> +
> return atomic_read(>lli_open_count);
> }
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Doc:kvm: Fix typo in Doc/virtual/kvm
This patch fix spelling typos in Documentation/virtual/kvm.
Signed-off-by: Masanari Iida
---
Documentation/virtual/kvm/api.txt| 4 ++--
Documentation/virtual/kvm/devices/vm.txt | 2 +-
Documentation/virtual/kvm/ppc-pv.txt | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index d9eccee..29ece60 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1774,7 +1774,7 @@ has been called, this interface is completely emulated
within the kernel.
To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the
following algorithm:
- - pause the vpcu
+ - pause the vcpu
- read the local APIC's state (KVM_GET_LAPIC)
- check whether changing LINT1 will queue an NMI (see the LVT entry for
LINT1)
- if so, issue KVM_NMI
@@ -2798,7 +2798,7 @@ Returns: = 0 on success,
< 0 on generic error (e.g. -EFAULT or -ENOMEM),
> 0 if an exception occurred while walking the page tables
-Read or write data from/to the logical (virtual) memory of a VPCU.
+Read or write data from/to the logical (virtual) memory of a VCPU.
Parameters are specified via the following structure:
diff --git a/Documentation/virtual/kvm/devices/vm.txt
b/Documentation/virtual/kvm/devices/vm.txt
index 5542c46..2d09d1e 100644
--- a/Documentation/virtual/kvm/devices/vm.txt
+++ b/Documentation/virtual/kvm/devices/vm.txt
@@ -74,7 +74,7 @@ struct kvm_s390_vm_cpu_processor {
KVM does not enforce or limit the cpu model data in any form. Take the
information
retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable
configuration
-setups. Instruction interceptions triggered by additionally set facilitiy bits
that
+setups. Instruction interceptions triggered by additionally set facility bits
that
are not handled by KVM need to by imlemented in the VM driver code.
Parameters: address of buffer to store/set the processor related cpu
diff --git a/Documentation/virtual/kvm/ppc-pv.txt
b/Documentation/virtual/kvm/ppc-pv.txt
index 3195606..e26115c 100644
--- a/Documentation/virtual/kvm/ppc-pv.txt
+++ b/Documentation/virtual/kvm/ppc-pv.txt
@@ -110,7 +110,7 @@ Flags are passed to the host in the low 12 bits of the
Effective Address.
The following flags are currently available for a guest to expose:
- MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page
+ MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correctly wrt magic page
MSR bits
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: lustre: llite: Added const
Added const to the struct statement which fixed the coding
style warning detected by chekpatch.pl
WARNING: struct seq_operations should normally be const
Signed-off-by: Anjali Menon
---
drivers/staging/lustre/lustre/llite/vvp_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/llite/vvp_dev.c
b/drivers/staging/lustre/lustre/llite/vvp_dev.c
index fde41d7..742be5a 100644
--- a/drivers/staging/lustre/lustre/llite/vvp_dev.c
+++ b/drivers/staging/lustre/lustre/llite/vvp_dev.c
@@ -517,7 +517,7 @@ static void vvp_pgcache_stop(struct seq_file *f, void *v)
/* Nothing to do */
}
-static struct seq_operations vvp_pgcache_ops = {
+static const struct seq_operations vvp_pgcache_ops = {
.start = vvp_pgcache_start,
.next = vvp_pgcache_next,
.stop = vvp_pgcache_stop,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] arm: Fix backtrace generation when IPI is masked
On Tue, Sep 15, 2015 at 03:40:05PM +0100, Daniel Thompson wrote:
> Currently on ARM when is triggered from an interrupt handler
> (e.g. a SysRq issued using UART or kbd) the main CPU will wedge for ten
> seconds with interrupts masked before issuing a backtrace for every CPU
> except itself.
>
> The new backtrace code introduced by commit 96f0e00378d4 ("ARM: add
> basic support for on-demand backtrace of other CPUs") does not work
> correctly when run from an interrupt handler because IPI_CPU_BACKTRACE
> is used to generate the backtrace on all CPUs but cannot preempt the
> current calling context.
>
> This can be fixed by detecting that the calling context cannot be
> preempted and issuing the backtrace directly in this case. Issuing
> directly leaves us without any pt_regs to pass to nmi_cpu_backtrace()
> so we also modify the generic code to call dump_stack() when its
> argument is NULL.
>
> Signed-off-by: Daniel Thompson
When submitting a patch to the patch system, please ensure that you pick
up people's acks _before_ submitting it to there - don't expect me to
search the mailing list, identify which patch version is the one in the
patch system, and then read the entire thread finding all the acks, then
having to amend the commit to add them.
A patch in the patch system with no acks looks like a patch which hasn't
been sent to the mailing lists.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
