Re: [PATCH v2] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table
On Sun, Feb 1, 2015 at 12:11 PM, Jonathan Cameron wrote: > On 05/01/15 23:00, Hartmut Knaack wrote: >> Daniel Baluta schrieb am 05.01.2015 um 10:21: >>> odr_bits values are between 0 and 11, so we can use the index >>> in kmx61_samp_freq_table instead of odr_bits structure member. >>> >>> Signed-off-by: Daniel Baluta >> Reviewed-by: Hartmut Knaack > Applied to the togreg branch of iio.git - pushed out as testing. > > Sorry, I marked this to apply when there was a messup over my > first pull request then failed to actually pick it up once that > got resolved. Now unfortunately 3.21 material. > > Ah well, not a critical change anyway, more of a cleanup ;) 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/
[BUG]rmmod null_blk lead to general protection fault on 3.19.0-rc6
When rmmod null_blk lead to GPF below: [ 29.193712] IPv6: ADDRCONF(NETDEV_CHANGE): ib0: link becomes ready [ 62.216289] general protection fault: [#1] SMP DEBUG_PAGEALLOC [ 62.216586] Dumping ftrace buffer: [ 62.216660](ftrace buffer empty) [ 62.216730] Modules linked in: ib_ipoib ib_uverbs ib_umad mlx4_ib mlx4_en rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr null_blk(-) mlx4_core [ 62.217755] CPU: 1 PID: 3928 Comm: rmmod Not tainted 3.19.0-rc6debug #1 [ 62.217824] Hardware name: To be filled by O.E.M. To be filled by O.E.M./M5A97 R2.0, BIOS 2501 04/07/2014 [ 62.217900] task: 88023345 ti: 8802289a8000 task.ti: 8802289a8000 [ 62.217966] RIP: 0010:[] [] blk_mq_tag_wakeup_all+0x13/0x90 [ 62.218095] RSP: 0018:8802289abe68 EFLAGS: 00010202 [ 62.218170] RAX: 8800b534d480 RBX: RCX: 0001 [ 62.218247] RDX: 6b6b6b6b RSI: 0001 RDI: 6b6b6b6b6b6b6b6b [ 62.218316] RBP: 8802289abe88 R08: 0038 R09: [ 62.218969] R10: R11: R12: 0001 [ 62.219038] R13: 880232b20a20 R14: 7f7cad118090 R15: 0800 [ 62.219107] FS: 7f7cac1ac700() GS:88023520() knlGS: [ 62.219175] CS: 0010 DS: ES: CR0: 8005003b [ 62.219288] CR2: 7f11a69e4095 CR3: 000230d54000 CR4: 000407e0 [ 62.219401] Stack: [ 62.219514] 880232b2 880232b20a20 7f7cad118090 [ 62.219912] 8802289abea8 8138985e 880232b2 880232b2 [ 62.220333] 8802289abec8 8137cfd6 880232b2 880232b20730 [ 62.220724] Call Trace: [ 62.220834] [] blk_mq_wake_waiters+0x4e/0x80 [ 62.220952] [] blk_set_queue_dying+0x26/0x90 [ 62.221068] [] blk_cleanup_queue+0x35/0x2a0 [ 62.221187] [] null_exit+0x57/0x8c [null_blk] [ 62.221308] [] SyS_delete_module+0x1b8/0x220 [ 62.221456] [] system_call_fastpath+0x12/0x17 [ 62.221580] Code: 40 08 b8 01 00 00 00 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 56 41 55 41 54 53 41 89 f4 <44> 8b 6f 28 48 89 fb 41 be 08 00 00 00 49 63 c5 48 c1 e0 07 48 [ 62.227747] RIP [] blk_mq_tag_wakeup_all+0x13/0x90 [ 62.227917] RSP [ 62.228138] ---[ end trace 349782d190908f70 ]--- -- Best Regards, Jack Wang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] lib: rename lib/find_next_bit.c to lib/find_bit.c
On Sat, Jan 31 2015, yury.no...@gmail.com wrote: > From: Yury Norov > > This file contains implementation for: > - find_last_bit; > - find_first_zero_bit; > - find_first_bit; > - find_next_zero_bit; > - find_next_bit. > [and a few _le variants] > So giving more generic name looks reasonable. It does. But it is a little annoying that it is not shown as a pure rename. > Signed-off-by: Yury Norov > --- > lib/Makefile| 2 +- > lib/find_bit.c | 194 > > lib/find_next_bit.c | 192 --- > 3 files changed, 195 insertions(+), 193 deletions(-) > create mode 100644 lib/find_bit.c > delete mode 100644 lib/find_next_bit.c > > diff --git a/lib/Makefile b/lib/Makefile > index 13990aa..1cc93f4 100644 > --- a/lib/Makefile > +++ b/lib/Makefile > @@ -25,7 +25,7 @@ obj-y += lockref.o > obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \ >bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \ >gcd.o lcm.o list_sort.o uuid.o flex_array.o iovec.o clz_ctz.o \ > - bsearch.o find_next_bit.o llist.o memweight.o kfifo.o \ > + bsearch.o find_bit.o llist.o memweight.o kfifo.o \ >percpu-refcount.o percpu_ida.o rhashtable.o reciprocal_div.o > obj-y += string_helpers.o > obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o > diff --git a/lib/find_bit.c b/lib/find_bit.c > new file mode 100644 > index 000..236a850 > --- /dev/null > +++ b/lib/find_bit.c > @@ -0,0 +1,194 @@ > +/* find_bit.c: generic implementation fore: > + * find_last_bit; find_first_zero_bit; find_first_bit; > + * find_next_zero_bit; find_next_bit. > + * [trivial typo: s/fore/for/] I _think_ the cause of the 2-line descrepancy is this change in a comment, but it's hard to tell for sure. There's no simple way of telling whether the other 192 lines are actually the same or if subtle changes have been introduced. This is one reason hard-coding the name of a file inside the file is a bad idea. I'd suggest tweaking that comment in one of the earlier patches, for example the one moving find_last_bit to find_next_bit.c, making sure to remove the filename. Then this patch can be a simple 'git mv' and the same two-line change of the Makefile. Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] netlabel: Less function calls in netlbl_mgmt_add_common() after error detection
From: Markus Elfring
Date: Mon, 2 Feb 2015 11:00:24 +0100
The functions "cipso_v4_doi_putdef" and "kfree" could be called in some cases
by the netlbl_mgmt_add_common() function during error handling even if the
passed variables contained still a null pointer.
* This implementation detail could be improved by adjustments for jump labels.
* Let us return immediately after the first failed function call according to
the current Linux coding style convention.
* Let us delete also an unnecessary check for the variable "entry" there.
Signed-off-by: Markus Elfring
Acked-by: Paul Moore
---
net/netlabel/netlabel_mgmt.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c
index f5807f5..7044074 100644
--- a/net/netlabel/netlabel_mgmt.c
+++ b/net/netlabel/netlabel_mgmt.c
@@ -93,23 +93,20 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
struct netlbl_audit *audit_info)
{
int ret_val = -EINVAL;
- struct netlbl_dom_map *entry = NULL;
struct netlbl_domaddr_map *addrmap = NULL;
struct cipso_v4_doi *cipsov4 = NULL;
u32 tmp_val;
+ struct netlbl_dom_map *entry = kzalloc(sizeof(*entry), GFP_KERNEL);
- entry = kzalloc(sizeof(*entry), GFP_KERNEL);
- if (entry == NULL) {
- ret_val = -ENOMEM;
- goto add_failure;
- }
+ if (!entry)
+ return -ENOMEM;
entry->def.type = nla_get_u32(info->attrs[NLBL_MGMT_A_PROTOCOL]);
if (info->attrs[NLBL_MGMT_A_DOMAIN]) {
size_t tmp_size = nla_len(info->attrs[NLBL_MGMT_A_DOMAIN]);
entry->domain = kmalloc(tmp_size, GFP_KERNEL);
if (entry->domain == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_free_entry;
}
nla_strlcpy(entry->domain,
info->attrs[NLBL_MGMT_A_DOMAIN], tmp_size);
@@ -125,16 +122,16 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
break;
case NETLBL_NLTYPE_CIPSOV4:
if (!info->attrs[NLBL_MGMT_A_CV4DOI])
- goto add_failure;
+ goto add_free_domain;
tmp_val = nla_get_u32(info->attrs[NLBL_MGMT_A_CV4DOI]);
cipsov4 = cipso_v4_doi_getdef(tmp_val);
if (cipsov4 == NULL)
- goto add_failure;
+ goto add_free_domain;
entry->def.cipso = cipsov4;
break;
default:
- goto add_failure;
+ goto add_free_domain;
}
if (info->attrs[NLBL_MGMT_A_IPV4ADDR]) {
@@ -145,7 +142,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
addrmap = kzalloc(sizeof(*addrmap), GFP_KERNEL);
if (addrmap == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_doi_put_def;
}
INIT_LIST_HEAD(>list4);
INIT_LIST_HEAD(>list6);
@@ -153,12 +150,12 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
if (nla_len(info->attrs[NLBL_MGMT_A_IPV4ADDR]) !=
sizeof(struct in_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
if (nla_len(info->attrs[NLBL_MGMT_A_IPV4MASK]) !=
sizeof(struct in_addr)) {
ret_val = -EINVAL;
- goto add_failure;
+ goto add_free_addrmap;
}
addr = nla_data(info->attrs[NLBL_MGMT_A_IPV4ADDR]);
mask = nla_data(info->attrs[NLBL_MGMT_A_IPV4MASK]);
@@ -166,7 +163,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
map = kzalloc(sizeof(*map), GFP_KERNEL);
if (map == NULL) {
ret_val = -ENOMEM;
- goto add_failure;
+ goto add_free_addrmap;
}
map->list.addr = addr->s_addr & mask->s_addr;
map->list.mask = mask->s_addr;
@@ -178,7 +175,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
ret_val = netlbl_af4list_add(>list, >list4);
if (ret_val != 0) {
kfree(map);
- goto add_failure;
+ goto add_free_addrmap;
}
entry->def.type = NETLBL_NLTYPE_ADDRSELECT;
@@ -192,7 +189,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info,
addrmap = kzalloc(sizeof(*addrmap), GFP_KERNEL);
if (addrmap == NULL) {
Re: [PATCH] x86: mce: Avoid timer double-add during CMCI interrupt storms.
On Fri, Jan 23, 2015 at 12:03:35PM +0100, Borislav Petkov wrote: > I've uploaded it as a branch if you want to give it a run as there are > other changes to MCE pending for 3.20 which might cause merge conflicts: > > git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git, branch mce-fb > > Shout if there are some issues remaining not addressed. In the meantime, I've tested it successfully on an EINJ box too, will queue it for 3.21 for extra simmering time in linux-next et al. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/6] KVM: nVMX: Enable nested posted interrupt processing
On 28/01/2015 17:02, Wincy Van wrote:
> +static int vmx_deliver_nested_posted_interrupt(struct kvm_vcpu *vcpu,
> + int vector)
> +{
> + if (is_guest_mode(vcpu) &&
> + vector == to_vmx(vcpu)->nested.posted_intr_nv &&
> + vcpu->mode == IN_GUEST_MODE) {
> + /* the PIR and ON have been set by L1. */
What happens if there is a L2->L0->L2 exit on the target VCPU, and the
guest exits before apic->send_IPI_mask sends the IPI?
The L1 hypervisor might "know" somehow that there cannot be a concurrent
L2->L1->L2 exit, and not do the equivalent of KVM's
kvm_make_request(KVM_REQ_EVENT, vcpu);
after it sets ON.
So I think you have to do something like
static bool vmx_is_nested_posted_interrupt(struct kvm_vcpu *vcpu,
int vector)
{
return (is_guest_mode(vcpu) &&
vector == to_vmx(vcpu)->nested.posted_intr_nv);
}
and in vmx_deliver_posted_interrupt:
r = 0;
if (!vmx_is_nested_posted_interrupt(vcpu, vector)) {
if (pi_test_and_set_pir(vector, >pi_desc))
return;
r = pi_test_and_set_on(>pi_desc);
}
kvm_make_request(KVM_REQ_EVENT, vcpu);
#ifdef CONFIG_SMP
if (!r && (vcpu->mode == IN_GUEST_MODE))
apic->send_IPI_mask(get_cpu_mask(vcpu->cpu),
POSTED_INTR_VECTOR);
else
#endif
kvm_vcpu_kick(vcpu);
What do you think?
Paolo
> + apic->send_IPI_mask(get_cpu_mask(vcpu->cpu),
> + POSTED_INTR_VECTOR);
> + return 0;
> + }
> + return -1;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] lib/string_helpers.c: Change semantics of string_escape_mem
On Sat, 2015-01-31 at 00:39 +0100, Rasmus Villemoes wrote: > On Fri, Jan 30 2015, Andy Shevchenko > wrote: > >> >> * Return: > >> >> - * The amount of the characters processed to the destination buffer, or > >> >> - * %-ENOMEM if the size of buffer is not enough to put an escaped > >> >> character is > >> >> - * returned. > >> >> - * > >> >> - * Even in the case of error @dst pointer will be updated to point to > >> >> the byte > >> >> - * after the last processed character. > >> >> + * The total size of the escaped output that would be generated for > >> >> + * the given input and flags. To check whether the output was > >> >> + * truncated, compare the return value to osz. There is room left in > >> >> + * dst for a '\0' terminator if and only if ret < osz. > >> >> */ > >> >> -int string_escape_mem(const char *src, size_t isz, char **dst, size_t > >> >> osz, > >> >> - unsigned int flags, const char *esc) > >> >> +size_t string_escape_mem(const char *src, size_t isz, char *dst, > >> >> size_t osz, > >> >> +unsigned int flags, const char *esc) > >> > > >> > I prefer to leave the prototype the same. int for return is okay. dst > >> > should be updated accordingly. > >> > >> Please explain exactly what you think the return value should be, and > >> what *dst should be set to. > > > > Return value like you proposed, *dst is incremented by it. > > The more I think about it, the less I like having dst being char**. > > (1) It is unlike most other functions taking buffer+size arguments. > (2) It is inconvenient. Callers doing > > char escaped[SOME_SIZE]; > > or > > char *escaped = kmalloc(likely_big_enough); > > can't just pass they would need to use an extra dummy variable. > > (3) With the return value telling the size of the would-be generated > output, it is redundant. > > In fact, I dislike it so much that I'm not going to sign off on a patch > where dst is still char**. Fair enough, though there usual case when temporary variable is already present (at least current users). Let's proceed with char *dst. -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: gadget: nokia: Add mass storage driver to g_nokia
Hello Pali, W dniu 31.01.2015 o 10:53, Pali Rohár pisze: This patch adds removable mass storage support to g_nokia gadget (for N900). It means that at runtime block device can be exported or unexported. For a hint please see this thread: http://www.spinics.net/lists/linux-usb/msg119669.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 3.12.37
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm announcing the release of the 3.12.37 kernel. All users of the 3.12 kernel series must upgrade. The updated 3.12.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.12.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary - Ahmed S. Darwish (3): can: kvaser_usb: Don't free packets when tight on URBs can: kvaser_usb: Reset all URB tx contexts upon channel close can: kvaser_usb: Don't send a RESET_CHIP for non-existing channels Akash Goel (1): drm/i915: Resolving the memory region conflict for Stolen area Al Viro (2): move d_rcu from overlapping d_child to overlapping d_alias deal with deadlock in d_walk() Alan Stern (1): USB: EHCI: fix initialization bug in iso_stream_schedule() Alex Deucher (5): drm/radeon: fix typo in CI dpm disable drm/radeon: work around a hw bug in MGCG on CIK drm/radeon: check the right ring in radeon_evict_flags() drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hw drm/radeon: add si dpm quirk list Alex Williamson (1): driver core: Fix unbalanced device reference in drivers_probe Alexandre Demers (1): x86/tsc: Change Fast TSC calibration failed from error to info Amit Virdi (2): usb: dwc3: gadget: Fix TRB preparation during SG usb: dwc3: gadget: Stop TRB preparation after limit is reached Andrew Jackson (1): ASoC: dwc: Ensure FIFOs are flushed to prevent channel swap Andrew Lunn (1): bus: mvebu-mbus: fix support of MBus window 13 Andy Lutomirski (5): x86_64, vdso: Fix the vdso address randomization algorithm x86, vdso: Use asm volatile in __getcpu x86, tls, ldt: Stop checking lm in LDT_empty x86, tls: Interpret an all-zero struct user_desc as "no segment" x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs Andy Shevchenko (1): sata_dwc_460ex: fix resource leak on error path Anton Blanchard (1): powerpc: Fix bad NULL pointer check in udbg_uart_getc_poll() Arik Nemtsov (1): cfg80211: avoid mem leak on driver hint set Arseny Solokha (1): OHCI: add a quirk for ULi M5237 blocking on reset Benjamin Coddington (1): nfsd4: fix xdr4 inclusion of escaped char Brian King (1): ipr: wait for aborted command responses Brian Norris (1): mtd: tests: abort torturetest on erase errors Bryan O'Donoghue (1): x86/apic: Re-enable PCI_MSI support for non-SMP X86_32 Chris Wilson (3): drm/i915: Invalidate media caches on gen7 drm/i915: Force the CS stall for invalidate flushes drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES Christian Riesch (1): n_tty: Fix read_buf race condition, increment read_head after pushing data Dan Carpenter (7): HID: roccat: potential out of bounds in pyra_sysfs_write_settings() ALSA: hda - using uninitialized data ceph: do_sync is never initialized netfilter: ipset: small potential read beyond the end of buffer decompress_bunzip2: off by one in get_next_block() ipvs: uninitialized data with IP_VS_IPV6 USB: adutux: NULL dereferences on disconnect Daniel Borkmann (1): x86, um: actually mark system call tables readonly Daniel Mack (1): ALSA: snd-usb: re-order some quirk entries Daniel Vetter (1): drm/i915: Don't complain about stolen conflicts on gen3 David Jeffery (1): libata: prevent HSM state change race between ISR and PIO David Miller (1): netlink: Always copy on mmap TX. David Peterson (1): USB: cp210x: add IDs for CEL USB sticks and MeshWorks devices Dmitry Torokhov (1): Input: I8042 - add Acer Aspire 7738 to the nomux list Dmitry Voytik (1): ARM: imx6q: drop unnecessary semicolon Dominique Leuenberger (1): hp_accel: Add support for HP ZBook 15 Eduard Gilmutdinov (1): ALSA: usb-audio: Add support for Focusrite Saffire 6 USB Eric Dumazet (1): alx: fix alx_poll() Fabio Estevam (2): ARM: dts: imx25: Fix the SPI1 clocks ARM: dts: imx25: Fix PWM "per" clocks Felipe Balbi (1): net: ethernet: cpsw: fix hangs with interrupts Felix Fietkau (3): ath9k_hw: fix hardware queue allocation ath9k: fix BE/BK queue order ath5k: fix hardware queue index assignment Frank Schaefer (1): af9005: fix kernel panic on init if compiled without IR Gary Bisson (1): ARM: clk-imx6q: fix video divider for rev T0 1.0 Geert Uytterhoeven (1): ARM: shmobile: sh73a0 legacy: Set .control_parent for all irqpin instances Giedrius Statkevičius (1): HID: Add a new id 0x501a for Genius MousePen i608X Govindarajulu Varadarajan (1): enic: fix rx skb checksum Greg Kroah-Hartman (1):
Re: [PATCH 2/2] tty: serial: 8250_core: Check that port->line is >=0
On Mon, 2015-02-02 at 09:09 +0100, Michal Simek wrote: > On 01/31/2015 12:23 AM, Greg Kroah-Hartman wrote: > > On Thu, Jan 15, 2015 at 03:55:08PM +0100, Michal Simek wrote: > >> This patch should be the part of: > >> "tty: serial: 8250_core: use the ->line argument as a hint in > >> serial8250_find_match_or_unused()" > >> (sha1: 59b3e898ddfc81a65975043b5eb44103cc29ff6e) > >> > > > > How can I go back in time and add a patch to another one? > > ok. Let me rewrite it to make more sense. Definitely not asking > you to squash that to the patch. It is just pointer to origin > patch which added this code and which should be extended with this one. I guess you can use Fixes tag for that, though it doesn't sound like a fix. > > Thanks, > Michal > -- Andy Shevchenko Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: i2c: ADV7604: Migrate to regmap
Hi Pablo, Jean-Michel,
On 02/01/2015 11:08 AM, Jean-Michel Hautbois wrote:
> This is a preliminary patch in order to add support for ALSA.
> It replaces all current i2c access with regmap.
> Add the registers which will then be used too, as these are declared at init.
>
> Signed-off-by: Pablo Anton
> Signed-off-by: Jean-Michel Hautbois
> ---
> drivers/media/i2c/adv7604.c | 428
> +---
> include/media/adv7604.h | 129 +
> 2 files changed, 455 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index e43dd2e..af19544 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -43,6 +43,8 @@
> #include
> #include
>
> +#include
> +
> static int debug;
> module_param(debug, int, 0644);
> MODULE_PARM_DESC(debug, "debug level (0-2)");
> @@ -165,6 +167,9 @@ struct adv7604_state {
> /* i2c clients */
> struct i2c_client *i2c_clients[ADV7604_PAGE_MAX];
>
> + /* Regmaps */
> + struct regmap *regmap[ADV7604_PAGE_MAX];
> +
> /* controls */
> struct v4l2_ctrl *detect_tx_5v_ctrl;
> struct v4l2_ctrl *analog_sampling_phase_ctrl;
> @@ -353,84 +358,53 @@ static inline unsigned vtotal(const struct
> v4l2_bt_timings *t)
> return V4L2_DV_BT_FRAME_HEIGHT(t);
> }
>
> -/* --- */
> -
> -static s32 adv_smbus_read_byte_data_check(struct i2c_client *client,
> - u8 command, bool check)
> -{
> - union i2c_smbus_data data;
> -
> - if (!i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> - I2C_SMBUS_READ, command,
> - I2C_SMBUS_BYTE_DATA, ))
> - return data.byte;
> - if (check)
> - v4l_err(client, "error reading %02x, %02x\n",
> - client->addr, command);
> - return -EIO;
> -}
> -
> -static s32 adv_smbus_read_byte_data(struct adv7604_state *state,
> - enum adv7604_page page, u8 command)
> -{
> - return adv_smbus_read_byte_data_check(state->i2c_clients[page],
> - command, true);
> -}
> -
> -static s32 adv_smbus_write_byte_data(struct adv7604_state *state,
> - enum adv7604_page page, u8 command,
> - u8 value)
> +static int regmap_read_check(struct adv7604_state *state,
> + int client_page, u8 reg)
> {
> - struct i2c_client *client = state->i2c_clients[page];
> - union i2c_smbus_data data;
> + struct i2c_client *client = state->i2c_clients[client_page];
> int err;
> - int i;
> + unsigned int val;
>
> - data.byte = value;
> - for (i = 0; i < 3; i++) {
> - err = i2c_smbus_xfer(client->adapter, client->addr,
> - client->flags,
> - I2C_SMBUS_WRITE, command,
> - I2C_SMBUS_BYTE_DATA, );
> - if (!err)
> - break;
> + err = regmap_read(state->regmap[client_page], reg, );
> +
> + if (err) {
> + v4l_err(client, "error reading %02x, %02x\n",
> + client->addr, reg);
> + return err;
> }
> - if (err < 0)
> - v4l_err(client, "error writing %02x, %02x, %02x\n",
> - client->addr, command, value);
> - return err;
> + return val;
> }
>
> -static s32 adv_smbus_write_i2c_block_data(struct adv7604_state *state,
> - enum adv7604_page page, u8 command,
> - unsigned length, const u8 *values)
> +/* regmap_write_block(): Write raw data with a maximum of I2C_SMBUS_BLOCK_MAX
> + * size to one or more registers.
> + *
> + * A value of zero will be returned on success, a negative errno will
> + * be returned in error cases.
> + */
> +static int regmap_write_block(struct adv7604_state *state, int client_page,
> + unsigned int init_reg, const void *val,
> + size_t val_len)
> {
> - struct i2c_client *client = state->i2c_clients[page];
> - union i2c_smbus_data data;
> + struct regmap *regmap = state->regmap[client_page];
>
> - if (length > I2C_SMBUS_BLOCK_MAX)
> - length = I2C_SMBUS_BLOCK_MAX;
> - data.block[0] = length;
> - memcpy(data.block + 1, values, length);
> - return i2c_smbus_xfer(client->adapter, client->addr, client->flags,
> - I2C_SMBUS_WRITE, command,
> - I2C_SMBUS_I2C_BLOCK_DATA, );
> -}
> + if (val_len > I2C_SMBUS_BLOCK_MAX)
> + val_len = I2C_SMBUS_BLOCK_MAX;
>
> -/* --- */
> + return regmap_raw_write(regmap,
Re: [PATCH v2 1/3] lib: find_*_bit reimplementation
On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
> From: Yury Norov
>
> New implementations takes less space in source file (see diffstat)
> and in object. For me it's 710 vs 453 bytes of text.
>
New version generally looks good. Please include a summary of the
changes between the versions either below the --- line or in a 0/n cover
letter, especially since you've now expanded the scope of the series.
Comments below.
>
> Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
> Performance tests were ran on userspace with code like this:
>
> /* addr[] is filled from /dev/urandom */
> start = clock();
> while (ret < nbits)
> ret = find_next_bit(addr, nbits, ret + 1);
>
> end = clock();
> printf("%ld\t", (unsigned long) end - start);
>
> On Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz rezults are next:
> (for find_next_bit, nbits is 8M, for find_first_bit - 80K)
>
> find_next_bit: find_first_bit:
> new current new current
> 26932 43151 14777 14925
> 26947 43182 14521 15423
> 26507 43824 15053 14705
> 27329 43759 14473 14777
> 26895 43367 14847 15023
> 26990 43693 15103 15163
> 26775 43299 15067 15232
> 27282 42752 14544 15121
> 27504 43088 14644 14858
> 26761 43856 14699 15193
> 26692 43075 14781 14681
> 27137 42969 14451 15061
> ... ...
>
> find_next_bit performance gain is 35-40%;
> find_first_bit - no measurable difference.
>
> Signed-off-by: Yury Norov
> ---
> lib/find_last_bit.c | 31 ++-
> lib/find_next_bit.c | 254
> +++-
> 2 files changed, 79 insertions(+), 206 deletions(-)
>
> diff --git a/lib/find_last_bit.c b/lib/find_last_bit.c
> index 91ca09f..e67e970 100644
> --- a/lib/find_last_bit.c
> +++ b/lib/find_last_bit.c
> @@ -4,44 +4,29 @@
> * Written by Rusty Russell
> * (Inspired by David Howell's find_next_bit implementation)
> *
> + * Rewritten by Yury Norov to decrease
> + * size and improve performance, 2015.
> + *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> * as published by the Free Software Foundation; either version
> * 2 of the License, or (at your option) any later version.
> */
>
> -#include
Why do you remove that #include? It is rather important that the header
and implementation don't get out of sync. I know that kernel.h includes
bitops.h, but please don't rely on such things. Quoting SubmitChecklist:
1: If you use a facility then #include the file that defines/declares
that facility. Don't depend on other header files pulling in ones
that you use.
> #include
> -#include
> -#include
However, getting rid of includes that are no longer needed is certainly
a good thing.
> +#include
>
> #ifndef find_last_bit
>
> unsigned long find_last_bit(const unsigned long *addr, unsigned long size)
> {
> - unsigned long words;
> - unsigned long tmp;
> -
> - /* Start at final word. */
> - words = size / BITS_PER_LONG;
> -
> - /* Partial final word? */
> - if (size & (BITS_PER_LONG-1)) {
> - tmp = (addr[words] & (~0UL >> (BITS_PER_LONG
> - - (size & (BITS_PER_LONG-1);
> - if (tmp)
> - goto found;
> - }
> + unsigned long idx = DIV_ROUND_UP(size, BITS_PER_LONG);
>
> - while (words) {
> - tmp = addr[--words];
> - if (tmp) {
> -found:
> - return words * BITS_PER_LONG + __fls(tmp);
> - }
> + while (idx--) {
> + if (addr[idx])
> + return min(idx * BITS_PER_LONG + __fls(addr[idx]),
> size);
> }
>
> - /* Not found */
> return size;
> }
> EXPORT_SYMBOL(find_last_bit);
> diff --git a/lib/find_next_bit.c b/lib/find_next_bit.c
> index 0cbfc0b..ebfb3dc 100644
> --- a/lib/find_next_bit.c
> +++ b/lib/find_next_bit.c
> @@ -3,18 +3,45 @@
> * Copyright (C) 2004 Red Hat, Inc. All Rights Reserved.
> * Written by David Howells (dhowe...@redhat.com)
> *
> + * Rewritten by Yury Norov to decrease
> + * size and improve performance, 2015.
> + *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License
> * as published by the Free Software Foundation; either version
> * 2 of the License, or (at your option) any later version.
> */
>
> -#include
> #include
> -#include
> -#include
> +#include
Same as above.
> +#define HIGH_BITS_MASK(nr) (ULONG_MAX << (nr))
> +
> +#if !defined(find_next_bit) || !defined(find_next_zero_bit)
> +static unsigned long
Re: [PATCH 2/2] drivers: xen/block: add multi-page ring support
El 23/01/15 a les 10.14, Bob Liu ha escrit: > Extend xen/block to support multi-page ring. > * xen-blkback notify blkfront with feature-multi-ring-pages > * xen-blkfront write to xenstore about how many pages are used as the ring > > If using 4 pages as the ring, inflight requests inscreased from 32 to 128 and > IOPS improved nearly 400% on our system. > > Signed-off-by: Bob Liu > --- > drivers/block/xen-blkback/xenbus.c | 86 + > drivers/block/xen-blkfront.c | 94 > ++-- This requires a patch to xen/include/public/io/blkif.h in the Xen repository describing how this protocol extension is going to work before reviewing the Linux implementation. Roger. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] clocksource: mmp: add mmp timer driver
On Mon, Feb 02, 2015 at 08:31:36AM +, Chao Xie wrote:
> From: Chao Xie
>
> MMP timer is attached to APB bus, It has the following
> limitation.
> 1. When get count of timer counter, it need some delay
>to get a stable count.
> 2. When set match register, it need disable the counter
>first, and enable it after set the match register.
>The disabling need wait for 2 clock cycle to take
>effect.
>
> To improve above #1, shadow register for count is added.
> To improve above #2, CRSR register is added for quick updating.
>
> So there are three types of timer.
> timer1: old timer.
> timer2: old timer with shadow register.
> timer3: old timer with shadow and CRSR register.
>
> This timer driver will be used for many SOCes.
> 1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
> 2. pxa1L88, pxa1U88 have timer1 and timer3.
> 3. pxa1928 has timer 2.
>
> The driver supports DT and non-DT initialization.
> The driver supports UP/SMP SOCes and 64 bit core.
>
> Signed-off-by: Chao Xie
> ---
> .../devicetree/bindings/arm/mrvl/timer.txt | 61 +-
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-mmp.c| 837
> +
> include/linux/mmp_timer.h | 40 +
> 4 files changed, 933 insertions(+), 6 deletions(-)
> create mode 100644 drivers/clocksource/timer-mmp.c
> create mode 100644 include/linux/mmp_timer.h
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> index 9a6e251..b49cb3e 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> @@ -1,13 +1,62 @@
> * Marvell MMP Timer controller
>
> +Each timer have multiple counters, so the timer DT need include counter's
> +description.
> +
> +1. Timer
> +
> Required properties:
> -- compatible : Should be "mrvl,mmp-timer".
> +- compatible : Should be "marvell,mmp-timer".
> - reg : Address and length of the register set of timer controller.
> -- interrupts : Should be the interrupt number.
> +- clocks : The first clock is the fequency of the apb bus that the timer
> + attached to. The second clock is the fast clock frequency of the timer.
> + This frequency and fast clock are used to calculated delay
> + loops for clock operations.
It might be a good idea to use clock-names for "apb" and "fast" and use
them in the driver.
> +
> +Optional properties:
> +- marvell,timer-has-crsr : This timer has CRSR register.
> +- marvell,timer-has-shadow : This timer has shadow register.
> +
> +2. Counter
The coutner nodes appear to be sub-nodes of the timer. That should be
stated explicitly.
> +
> +Required properties:
> +- compatible : It can be
> + "marvell,timer-counter-clkevt" : The counter is used for clock event
> + device.
> + "marvell,timer-counter-clksrc" : The counter is used for clock source.
> + "marvell,timer-counter-delay" : The counter is used for delay timer.
These are all Linux-internal details. I don't see why we should need
separate strings; Linux should be able to allocate these as appropriate
(and a single timer should be able to be both a clocksource and a delay
timer).
Is there any reason you envisage for having separate strings here? It
douesn't make sense to me to do so.
> +- marvell,timer-counter-id : The counter index in this timer.
It sounds like you could use reg for this, unless you have other
sub-nodes you'll need to instantiate?
>
> -Example:
> - timer0: timer@d4014000 {
> - compatible = "mrvl,mmp-timer";
> - reg = <0xd4014000 0x100>;
> +Optional properties:
> +- marvell,fast-clock : whether the counter use the fast-clock for counting.
It looks below like this is a policy decision, rather than a description
of the HW. When would you select the fast clock and when would you not?
Why can't the driver figure this out?
> +- interrupts : The interrupt for clock event device.
> + Only valid for "marvell,timer-counter-clkevt".
> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
> + "marvell,timer-counter-clkevt".
This sounds like a policy decision, rather than a description of the HW.
Additionally, the number usage seems to be a Linux logical ID, rather
than a physical CPU ID. This is broken.
> +- marvell,timer-counter-broadcast : When this counter acts as clock event
> + device. It is broadcast clock event device.
> + Only valid for "marvell,timer-counter-clkevt".
This is a Linux-internal detail. There shouldn't be a binding for this.
> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
> + event device, it cannot switch the IRQ of broadcast clock event to any CPU.
> + Only valid for "marvell,timer-counter-clkevt".
Likewise. Why can't you change the affinity?
For all of the above properties, it sounds like what you
Re: [PATCHv4 00/36] perf tools: New build framework
On Mon, Jan 26, 2015 at 11:12:00AM +0100, Jiri Olsa wrote: > hi, > I'm following up on latest post from Alexis: > http://marc.info/?l=linux-kernel=141427580405357=2 > > thanks for feedback and testing! > > v4 changes: > - updated to the current Arnaldo's perf/core branch > - added Tested-by tags [Will, Sukadev] > - fixed common-cmds.h dependency [David] > - updated changelog for base arch patch 20/36 [David] > perf build: Add arch x86 objects building > - added Copyright header for build framework files hi, any more feedback? thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gfs2: use __vmalloc GFP_NOFS for fs-related allocations.
Hi,
On 02/02/15 08:11, Dave Chinner wrote:
On Mon, Feb 02, 2015 at 01:57:23AM -0500, Oleg Drokin wrote:
Hello!
On Feb 2, 2015, at 12:37 AM, Dave Chinner wrote:
On Sun, Feb 01, 2015 at 10:59:54PM -0500, gr...@linuxhacker.ru wrote:
From: Oleg Drokin
leaf_dealloc uses vzalloc as a fallback to kzalloc(GFP_NOFS), so
it clearly does not want any shrinker activity within the fs itself.
convert vzalloc into __vmalloc(GFP_NOFS|__GFP_ZERO) to better achieve
this goal.
Signed-off-by: Oleg Drokin
---
fs/gfs2/dir.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/gfs2/dir.c b/fs/gfs2/dir.c
index c5a34f0..6371192 100644
--- a/fs/gfs2/dir.c
+++ b/fs/gfs2/dir.c
@@ -1896,7 +1896,8 @@ static int leaf_dealloc(struct gfs2_inode *dip, u32
index, u32 len,
ht = kzalloc(size, GFP_NOFS | __GFP_NOWARN);
if (ht == NULL)
- ht = vzalloc(size);
+ ht = __vmalloc(size, GFP_NOFS | __GFP_NOWARN | __GFP_ZERO,
+ PAGE_KERNEL);
That, in the end, won't help as vmalloc still uses GFP_KERNEL
allocations deep down in the PTE allocation code. See the hacks in
the DM and XFS code to work around this. i.e. go look for callers of
memalloc_noio_save(). It's ugly and grotesque, but we've got no
other way to limit reclaim context because the MM devs won't pass
the vmalloc gfp context down the stack to the PTE allocations
Hm, interesting.
So all the other code in the kernel that does this sort of thing (and there's
quite a bit
outside of xfs and ocfs2) would not get the desired effect?
No. I expect, however, that very few people would ever see a
deadlock as a result - it's a pretty rare sort of kernel case to hit
in most cases. XFS does make extensive use of vm_map_ram() in
GFP_NOFS context, however, when large directory block sizes are in
use, and we also have a history of lockdep throwing warnings under
memory pressure. In the end, the memalloc_noio_save() changes were
made to stop the frequent lockdep reports rather than actual
deadlocks.
Indeed, I think the patch is still an improvement however, so I'm happy
to apply it while a better solution is found.
So, I did some digging in archives and found this thread from 2010 onward with
various
patches and rants.
Not sure how I missed that before.
Should we have another run at this I wonder?
By all means, but I don't think you'll have any more luck than
anyone else in the past. We've still got the problem of attitude
("vmalloc is not for general use") and making it actually work is
seen as "encouraging undesirable behaviour". If you can change
attitudes towards vmalloc first, then you'll be much more likely to
make progress in getting these problems solved
Well I don't know whether it has to be vmalloc that provides the
solution here... if memory fragmentation could be controlled then
kmalloc of larger contiguous chunks of memory could be done using that,
which might be a better solution overall. But I do agree that we need to
try and come to some kind of solution to this problem as it is one of
those things that has been rumbling on for a long time without a proper
solution.
I also wonder if vmalloc is still very slow? That was the case some time
ago when I noticed a problem in directory access times in gfs2, which
made us change to use kmalloc with a vmalloc fallback in the first place,
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: comedi: drivers: dyna_pci10xx: Removed variables that is never used
On 31/01/15 13:44, Rickard Strandqvist wrote: Variable was assigned a value that was never used. I have also removed all the code that thereby serves no purpose. This was found using a static code analysis program called cppcheck Signed-off-by: Rickard Strandqvist --- drivers/staging/comedi/drivers/dyna_pci10xx.c |4 1 file changed, 4 deletions(-) Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: comedi: drivers: jr3_pci: Removed variables that is never used
On 31/01/15 13:39, Rickard Strandqvist wrote: Variable was assigned a value that was never used. I have also removed all the code that thereby serves no purpose. This was found using a static code analysis program called cppcheck Signed-off-by: Rickard Strandqvist --- drivers/staging/comedi/drivers/jr3_pci.c | 16 1 file changed, 16 deletions(-) Reviewed-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Web: http://www.mev.co.uk/ )=- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v6] media: au0828 - convert to use videobuf2
On Thu, Jan 29, 2015 at 4:41 PM, Shuah Khan wrote: > Convert au0828 to use videobuf2. Tested with NTSC. > Tested video and vbi devices with xawtv, tvtime, > and vlc. Ran v4l2-compliance to ensure there are > no failures. > > Video compliance test results summary: > Total: 75, Succeeded: 75, Failed: 0, Warnings: 18 > > Vbi compliance test results summary: > Total: 75, Succeeded: 75, Failed: 0, Warnings: 0 > > Signed-off-by: Shuah Khan Reviewed-by: Lad, Prabhakar Regards, --Prabhakar Lad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] netlabel: Deletion of an unnecessary check before the function call "cipso_v4_doi_free"
From: Markus Elfring Date: Mon, 2 Feb 2015 10:40:30 +0100 The cipso_v4_doi_free() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Acked-by: Paul Moore --- net/netlabel/netlabel_cipso_v4.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/netlabel/netlabel_cipso_v4.c b/net/netlabel/netlabel_cipso_v4.c index 1796253..7fd1104 100644 --- a/net/netlabel/netlabel_cipso_v4.c +++ b/net/netlabel/netlabel_cipso_v4.c @@ -324,8 +324,7 @@ static int netlbl_cipsov4_add_std(struct genl_info *info, return 0; add_std_failure: - if (doi_def) - cipso_v4_doi_free(doi_def); + cipso_v4_doi_free(doi_def); return ret_val; } -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regmap: Fix i2c word access when using SMBus access functions
On 02/02/2015 12:48 AM, Guenter Roeck wrote:
[...]
static int regmap_i2c_write(void *context, const void *data, size_t count)
{
struct device *dev = context;
@@ -180,7 +216,10 @@ static const struct regmap_bus *regmap_get_i2c_bus(struct
i2c_client *i2c,
else if (config->val_bits == 16 && config->reg_bits == 8 &&
i2c_check_functionality(i2c->adapter,
I2C_FUNC_SMBUS_WORD_DATA))
- return _smbus_word;
+ if (config->val_format_endian == REGMAP_ENDIAN_LITTLE)
This should probably use regmap_get_val_endian() and maybe also handle
REGMAP_ENDIAN_NATIVE.
+ return _smbus_word;
+ else
+ return _smbus_word_swapped;
else if (config->val_bits == 8 && config->reg_bits == 8 &&
i2c_check_functionality(i2c->adapter,
I2C_FUNC_SMBUS_BYTE_DATA))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] media: adv7604: CP CSC uses a different register on adv7604 and adv7611
Hi Jean-Michel, On 01/26/2015 02:52 PM, Jean-Michel Hautbois wrote: > The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc. > When reading back the value in log_status, differentiate both. > > Signed-off-by: Jean-Michel Hautbois > --- > drivers/media/i2c/adv7604.c | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c > index e43dd2e..32e53e0 100644 > --- a/drivers/media/i2c/adv7604.c > +++ b/drivers/media/i2c/adv7604.c > @@ -2310,8 +2310,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd) > (reg_io_0x02 & 0x04) ? "(16-235)" : "(0-255)", > ((reg_io_0x02 & 0x04) ^ (reg_io_0x02 & 0x01)) ? > "enabled" : "disabled"); > - v4l2_info(sd, "Color space conversion: %s\n", > + if (state->info->type == ADV7604) > + v4l2_info(sd, "Color space conversion: %s\n", > csc_coeff_sel_rb[cp_read(sd, 0xfc) >> 4]); > + else > + v4l2_info(sd, "Color space conversion: %s\n", > + csc_coeff_sel_rb[cp_read(sd, 0xf4) >> 4]); > > if (!is_digital_input(sd)) > return 0; > You need to add this register to the adv7604_chip_info struct, just like is done for other registers that have this issue. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] netlabel: Deletion of an unnecessary check before the function call "cipso_v4_doi_putdef"
From: Markus Elfring Date: Mon, 2 Feb 2015 10:01:45 +0100 The cipso_v4_doi_putdef() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring Acked-by: Paul Moore --- net/netlabel/netlabel_mgmt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/netlabel/netlabel_mgmt.c b/net/netlabel/netlabel_mgmt.c index 8b3b789..f5807f5 100644 --- a/net/netlabel/netlabel_mgmt.c +++ b/net/netlabel/netlabel_mgmt.c @@ -242,8 +242,7 @@ static int netlbl_mgmt_add_common(struct genl_info *info, return 0; add_failure: - if (cipsov4) - cipso_v4_doi_putdef(cipsov4); + cipso_v4_doi_putdef(cipsov4); if (entry) kfree(entry->domain); kfree(addrmap); -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] netlabel: Deletion of a few unnecessary checks
From: Markus Elfring Date: Mon, 2 Feb 2015 11:15:56 +0100 Further update suggestions were taken into account after patches were applied from static source code analysis. Markus Elfring (3): Deletion of an unnecessary check before the function call "cipso_v4_doi_putdef" Deletion of an unnecessary check before the function call "cipso_v4_doi_free" Less function calls in netlbl_mgmt_add_common() after error detection net/netlabel/netlabel_cipso_v4.c | 3 +-- net/netlabel/netlabel_mgmt.c | 50 +++- 2 files changed, 25 insertions(+), 28 deletions(-) -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/1] extcon: usb-gpio: Introduce gpio usb extcon driver
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-HOST (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros
---
v4:
- got rid of id_irqwake flag. Fail if enable/disable_irq_wake() fails
- changed host cable name to "USB-HOST"
- use 'depends on' instead of 'select' GPIOLIB
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 237 +
4 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be "linux,extcon-usb-gpio"
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = < 1 GPIO_ACTIVE_HIGH>;
+ }
+
+ _dwc3_1 {
+ extcon = <_usb1>;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..e4c01ab 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate "USB GPIO extcon support"
+ depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..3f0bad3
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,237 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define USB_GPIO_DEBOUNCE_MS 20 /* ms */
+
+struct usb_extcon_info {
+ struct device *dev;
+ struct extcon_dev *edev;
+
+ struct gpio_desc *id_gpiod;
+ int id_irq;
+
+ unsigned long debounce_jiffies;
+ struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+ EXTCON_CABLE_USB = 0,
+ EXTCON_CABLE_USB_HOST,
+
+ EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+ [EXTCON_CABLE_USB] = "USB",
+ [EXTCON_CABLE_USB_HOST] = "USB-HOST",
+ NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+ int id;
+ struct usb_extcon_info *info = container_of(to_delayed_work(work),
+ struct usb_extcon_info,
+ wq_detcable);
+
+ /* check ID and update cable state */
+ id = gpiod_get_value_cansleep(info->id_gpiod);
+ if (id) {
+ /*
+* ID = 1 means USB HOST cable detached.
+* As we don't have event for USB peripheral cable attached,
+* we
Re: [PATCH] einj: Documentation text corrections and streamlining
On Fri, Jan 30, 2015 at 07:13:20PM +, Luck, Tony wrote: > >> How about a paragraph telling people how to check whether their platform > >> supports > > > > I took your text and massaged it into the doc, diff ontop: > > Acked-by: Tony Luck Queued for 3.21. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iommu: arm-smmu: avoid build warning
On Fri, Jan 30, 2015 at 09:55:55PM +, Arnd Bergmann wrote:
> ARM allmodconfig gained a new warning when dma_addr_t is 32-bit wide:
>
> drivers/iommu/arm-smmu.c: In function 'arm_smmu_iova_to_phys_hard':
> drivers/iommu/arm-smmu.c:1255:3: warning: right shift count >= width of type
>
> This changes the calculation so that the effective type is always
> 64-bit.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 859a732e4f713 ("iommu/arm-smmu: add support for iova_to_phys through
> ATS1PR")
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 1d6d43bb3395..fc13dd56953e 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1252,7 +1252,7 @@ static phys_addr_t arm_smmu_iova_to_phys_hard(struct
> iommu_domain *domain,
> } else {
> u32 reg = iova & ~0xfff;
> writel_relaxed(reg, cb_base + ARM_SMMU_CB_ATS1PR_LO);
> - reg = (iova & ~0xfff) >> 32;
> + reg = ((u64)iova & ~0xfff) >> 32;
> writel_relaxed(reg, cb_base + ARM_SMMU_CB_ATS1PR_HI);
> }
Thanks, Arnd.
Acked-by: Will Deacon
Joerg, could you pick this one up directly please? I don't have any other
ARM SMMU fixes queued at the moment.
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 3/3] mm/compaction: enhance compaction finish condition
On 02/02/2015 08:15 AM, Joonsoo Kim wrote:
> Compaction has anti fragmentation algorithm. It is that freepage
> should be more than pageblock order to finish the compaction if we don't
> find any freepage in requested migratetype buddy list. This is for
> mitigating fragmentation, but, there is a lack of migratetype
> consideration and it is too excessive compared to page allocator's anti
> fragmentation algorithm.
>
> Not considering migratetype would cause premature finish of compaction.
> For example, if allocation request is for unmovable migratetype,
> freepage with CMA migratetype doesn't help that allocation and
> compaction should not be stopped. But, current logic regards this
> situation as compaction is no longer needed, so finish the compaction.
This is only for order >= pageblock_order, right? Perhaps should be told
explicitly.
> Secondly, condition is too excessive compared to page allocator's logic.
> We can steal freepage from other migratetype and change pageblock
> migratetype on more relaxed conditions in page allocator. This is designed
> to prevent fragmentation and we can use it here. Imposing hard constraint
> only to the compaction doesn't help much in this case since page allocator
> would cause fragmentation again.
>
> To solve these problems, this patch borrows anti fragmentation logic from
> page allocator. It will reduce premature compaction finish in some cases
> and reduce excessive compaction work.
>
> stress-highalloc test in mmtests with non movable order 7 allocation shows
> considerable increase of compaction success rate.
>
> Compaction success rate (Compaction success * 100 / Compaction stalls, %)
> 31.82 : 42.20
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/compaction.c | 14 --
> mm/internal.h | 2 ++
> mm/page_alloc.c | 12
> 3 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/mm/compaction.c b/mm/compaction.c
> index 782772d..d40c426 100644
> --- a/mm/compaction.c
> +++ b/mm/compaction.c
> @@ -1170,13 +1170,23 @@ static int __compact_finished(struct zone *zone,
> struct compact_control *cc,
> /* Direct compactor: Is a suitable page free? */
> for (order = cc->order; order < MAX_ORDER; order++) {
> struct free_area *area = >free_area[order];
> + bool can_steal;
>
> /* Job done if page is free of the right migratetype */
> if (!list_empty(>free_list[migratetype]))
> return COMPACT_PARTIAL;
>
> - /* Job done if allocation would set block type */
> - if (order >= pageblock_order && area->nr_free)
> + /* MIGRATE_MOVABLE can fallback on MIGRATE_CMA */
> + if (migratetype == MIGRATE_MOVABLE &&
> + !list_empty(>free_list[MIGRATE_CMA]))
> + return COMPACT_PARTIAL;
The above AFAICS needs #ifdef CMA otherwise won't compile without CMA.
> +
> + /*
> + * Job done if allocation would steal freepages from
> + * other migratetype buddy lists.
> + */
> + if (find_suitable_fallback(area, order, migratetype,
> + true, _steal) != -1)
> return COMPACT_PARTIAL;
> }
>
> diff --git a/mm/internal.h b/mm/internal.h
> index c4d6c9b..9640650 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -200,6 +200,8 @@ isolate_freepages_range(struct compact_control *cc,
> unsigned long
> isolate_migratepages_range(struct compact_control *cc,
> unsigned long low_pfn, unsigned long end_pfn);
> +int find_suitable_fallback(struct free_area *area, unsigned int order,
> + int migratetype, bool only_stealable, bool *can_steal);
>
> #endif
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 6cb18f8..0a150f1 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1177,8 +1177,8 @@ static void steal_suitable_fallback(struct zone *zone,
> struct page *page,
> set_pageblock_migratetype(page, start_type);
> }
>
> -static int find_suitable_fallback(struct free_area *area, unsigned int order,
> - int migratetype, bool *can_steal)
> +int find_suitable_fallback(struct free_area *area, unsigned int order,
> + int migratetype, bool only_stealable, bool *can_steal)
> {
> int i;
> int fallback_mt;
> @@ -1198,7 +1198,11 @@ static int find_suitable_fallback(struct free_area
> *area, unsigned int order,
> if (can_steal_fallback(order, migratetype))
> *can_steal = true;
>
> - return i;
> + if (!only_stealable)
> + return i;
> +
> + if (*can_steal)
> + return i;
So I've realized that this problaby won't always work as intended :/ Because we
still differ from what page allocator does.
Consider we
[PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.
>From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
From: Ken Xue
Date: Mon, 2 Feb 2015 17:32:24 +0800
Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART found on AMD CZ and later chipsets. It
based on example INTEL LPSS. Now, it can support AMD I2C & UART.
Signed-off-by: Ken Xue
---
arch/x86/Kconfig| 11 +++
drivers/acpi/Makefile | 2 +-
drivers/acpi/acpi_apd.c | 208
drivers/acpi/internal.h | 2 +
drivers/acpi/scan.c | 1 +
5 files changed, 223 insertions(+), 1 deletion(-)
create mode 100644 drivers/acpi/acpi_apd.c
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0dc9d01..ddf8d42 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -496,6 +496,17 @@ config X86_INTEL_LPSS
things like clock tree (common clock framework) and pincontrol
which are needed by the LPSS peripheral drivers.
+config X86_AMD_PLATFORM_DEVICE
+ bool "AMD ACPI2Platform devices support"
+ depends on ACPI
+ select COMMON_CLK
+ select PINCTRL
+ ---help---
+ Select to interpret AMD specific ACPI device to platform device
+ such as I2C, UART found on AMD Carrizo and later chipsets. Selecting
+ this option enables things like clock tree (common clock framework)
+ and pinctrl.
+
config IOSF_MBI
tristate "Intel SoC IOSF Sideband support for SoC platforms"
depends on PCI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index f74317c..0071141 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -40,7 +40,7 @@ acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o
-acpi-y += acpi_lpss.o
+acpi-y += acpi_lpss.o acpi_apd.o
acpi-y += acpi_platform.o
acpi-y += acpi_pnp.o
acpi-y += int340x_thermal.o
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
new file mode 100644
index 000..b875ef6
--- /dev/null
+++ b/drivers/acpi/acpi_apd.c
@@ -0,0 +1,208 @@
+/*
+ * AMD ACPI support for ACPI2platform device.
+ *
+ * Copyright (c) 2014,2015 AMD Corporation.
+ * Authors: Ken Xue
+ * Wu, Jeff
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "internal.h"
+
+
+ACPI_MODULE_NAME("acpi_apd");
+struct apd_private_data;
+
+/**
+ * device flags of acpi_apd_dev_desc.
+ * ACPI_APD_SYSFS : add device attributes in sysfs
+ * ACPI_APD_PM : attach power domain to device
+ * ACPI_APD_PM_ON : power on device when attach power domain
+ */
+#define ACPI_APD_SYSFS BIT(0)
+#define ACPI_APD_PMBIT(1)
+#define ACPI_APD_PM_ON BIT(2)
+
+/**
+ * struct apd_device_desc - a descriptor for apd device
+ * @flags: device flags like ACPI_APD_SYSFS ACPI_APD_PM ACPI_APD_PM_ON
+ * @fixed_clk_rate: fixed rate input clock source for acpi device;
+ * 0 means no fixed rate input clock source
+ * @setup: a hook routine to set device resource during create platform device
+ *
+ * device description defined as acpi_device_id.driver_data
+ */
+struct apd_device_desc {
+ unsigned int flags;
+ unsigned int fixed_clk_rate;
+ int (*setup)(struct apd_private_data *pdata);
+};
+
+struct apd_private_data {
+ struct clk *clk;
+ struct acpi_device *adev;
+ struct apd_device_desc *dev_desc;
+};
+
+
+#ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
+#define APD_ADDR(desc) ((unsigned long))
+
+static int acpi_apd_setup(struct apd_private_data *pdata)
+{
+ struct apd_device_desc *dev_desc = pdata->dev_desc;
+ struct clk *clk = ERR_PTR(-ENODEV);
+
+ if (dev_desc->fixed_clk_rate) {
+ clk = clk_register_fixed_rate(>adev->dev,
+ dev_name(>adev->dev),
+ NULL, CLK_IS_ROOT,
+ dev_desc->fixed_clk_rate);
+ clk_register_clkdev(clk, NULL, dev_name(>adev->dev));
+ pdata->clk = clk;
+ }
+
+ return 0;
+}
+
+static struct apd_device_desc cz_i2c_desc = {
+ .setup = acpi_apd_setup,
+ .fixed_clk_rate = 13300,
+};
+
+static struct apd_device_desc cz_uart_desc = {
+ .setup = acpi_apd_setup,
+ .fixed_clk_rate = 4800,
+};
+
+#else
+
+#define APD_ADDR(desc) (0UL)
+
+#endif /* CONFIG_X86_AMD_PLATFORM_DEVICE */
+
+static int acpi_apd_create_device(struct acpi_device *adev,
+ const struct acpi_device_id *id)
+{
+ struct
RE: [PATCH v2 2/3] hv: vmbus_post_msg: retry the hypercall on some transient errors
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, February 2, 2015 17:41 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> Subject: Re: [PATCH v2 2/3] hv: vmbus_post_msg: retry the hypercall on some
> transient errors
>
> On Mon, Feb 2, 2015 at 12:36 PM, Dexuan Cui wrote:
> > I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when
> keeping
> > running
> > "rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe
> > hv_utils"
> > in a Linux guest. Looks the host has some kind of throttling
> > mechanism if
> > some kinds of hypercalls are sent too frequently.
>
> Better to clarify this kind of throttling. Looks like it only affects
> HVCALL_POST_MESSAGE. Other looks good.
I'm not sure about the details either.
And it may be pretty host-specific, e.g., I can only get the error code on
Hyper-V 2008 R2, but can't get it on 2012 R2.
> Reviewed-by: Jason Wang
Thanks!
> >
> > Without the patch, the driver can occasionally fail to load.
> >
> > Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get
> > it
> > before.
> >
> > Removed 'case -ENOMEM', since the hypervisor doesn't return this.
> >
> > CC: "K. Y. Srinivasan"
> > Signed-off-by: Dexuan Cui
> > ---
> >
> > v2:
> > updated the subject and changelog
> > on HV_STATUS_INVALID_CONNECTION_ID: ret = -EAGAIN;
> > added HV_STATUS_INSUFFICIENT_MEMORY
> > removed unreachable -ENOMEM
> > changed the delay from 100ms to 1000ms
> >
> > arch/x86/include/uapi/asm/hyperv.h | 2 ++
> > drivers/hv/connection.c| 11 +--
> > 2 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> > b/arch/x86/include/uapi/asm/hyperv.h
> > index 90c458e..ce6068d 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -225,6 +225,8 @@
> > #define HV_STATUS_INVALID_HYPERCALL_CODE 2
> > #define HV_STATUS_INVALID_HYPERCALL_INPUT 3
> > #define HV_STATUS_INVALID_ALIGNMENT4
> > +#define HV_STATUS_INSUFFICIENT_MEMORY 11
> > +#define HV_STATUS_INVALID_CONNECTION_ID18
> > #define HV_STATUS_INSUFFICIENT_BUFFERS 19
> >
> > typedef struct _HV_REFERENCE_TSC_PAGE {
> > diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> > index c4acd1c..af2388f 100644
> > --- a/drivers/hv/connection.c
> > +++ b/drivers/hv/connection.c
> > @@ -440,9 +440,16 @@ int vmbus_post_msg(void *buffer, size_t buflen)
> > ret = hv_post_message(conn_id, 1, buffer, buflen);
> >
> > switch (ret) {
> > + case HV_STATUS_INVALID_CONNECTION_ID:
> > + /*
> > +* We could get this if we send messages too
> > +* frequently.
> > +*/
> > + ret = -EAGAIN;
> > + break;
> > + case HV_STATUS_INSUFFICIENT_MEMORY:
> > case HV_STATUS_INSUFFICIENT_BUFFERS:
> > ret = -ENOMEM;
> > - case -ENOMEM:
> > break;
> > case HV_STATUS_SUCCESS:
> > return ret;
> > @@ -452,7 +459,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
> > }
> >
> > retries++;
> > - msleep(100);
> > + msleep(1000);
> > }
> > return ret;
> > }
> > --
> > 1.9.1
> >
Re: Linux 3.19-rc7
On Mon, Feb 2, 2015 at 6:16 AM, Linus Torvalds
wrote:
> Jan Kara (2):
> quota: Switch ->get_dqblk() and ->set_dqblk() to use bytes as space
> units
Can't copy_to_xfs_dqblk/copy_from_xfs_dqblk be done in XFS instead?
function old new delta
sys_quotactl23804082 +1702
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ad_sigma_delta: cleanup wait_for_completion return handling
On 02/02/2015 10:50 AM, Nicholas Mc Guire wrote:
On Mon, 02 Feb 2015, Lars-Peter Clausen wrote:
On 02/02/2015 09:37 AM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int, rather
than introducing a new variable the wait_for_completion_timeout is moved
into the if condition as the return value is only used to detect timeout.
But the return value is bound by the timeout parameter and we know that
fits into a int. And I really dont like moving the function call into the
if condition, so unless there is some additional explanation why this is
necessary and should be done I'm inclined to nack this.
well having correct types is important for all static code chekcers
and I did not want to add a new variable just for this case
simply because the result is only relevant in the == 0 case
anyway.
I do think that the types being assigned should correct with respect
to the API definition even if it fits in this case.
Signed-off-by: Nicholas Mc Guire
---
Aside from the fixup of the wait_for_completion_timeout handling
a minor coding style issue in the else branch was fixed - the {} is
not needed for the one-line body.
If one of the branches of a conditional statement has braces the other
branches should also have braces. This is documented in
Documentation/CodingStyle.
my bad - it is not uncommon to be asymetric - but you are right that Chapter 3
states it should not be asymetric in this case - will remove that.
given the botched braces this needs to be redone - let me know if moving
it into the condition is ok (its not uncommon) or if an additional variable
of type unsigned long is the prefered solution.
I prefer the extra variable, but that's personal taste. And maybe add the
stuff about the static code checker etc to the commit message.
Thanks,
- Lars
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] hv: hv_util: move vmbus_open() to a later place
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Monday, February 2, 2015 17:36 PM
> To: Dexuan Cui
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; KY
> Srinivasan; vkuzn...@redhat.com; Haiyang Zhang
> Subject: Re: [PATCH v2 1/3] hv: hv_util: move vmbus_open() to a later place
>
>
>
> On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui wrote:
> > Before the line vmbus_open() returns, srv->util_cb can be already
> > running
> > and the variables, like util_fw_version, are needed by the
> > srv->util_cb.
>
> A questions is why we do this for util only? Can callbacks of other
> devices be called before vmbus_open() returns?
The variables are used in vmbus_prep_negotiate_resp(), which is only for
the util devices.
I think the other devices should already handle the similar issue properly.
If this is not the case, we need to fix them too.
>
> >
> > So we have to make sure the variables are initialized before the
> > vmbus_open().
> >
> > CC: "K. Y. Srinivasan"
> > Reviewed-by: Vitaly Kuznetsov
> > Signed-off-by: Dexuan Cui
> > ---
> >
> > v2:
> > This is a RESEND.
> > I just added Vitaly's Reviewed-by.
> >
> > drivers/hv/hv_util.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> > index 3b9c9ef..c5be773 100644
> > --- a/drivers/hv/hv_util.c
> > +++ b/drivers/hv/hv_util.c
> > @@ -340,12 +340,8 @@ static int util_probe(struct hv_device *dev,
> >
> > set_channel_read_state(dev->channel, false);
> >
> > - ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL,
> > 0,
> > - srv->util_cb, dev->channel);
> > - if (ret)
> > - goto error;
> > -
> > hv_set_drvdata(dev, srv);
> > +
>
> This seems unnecessary.
Yeah, it's an empty line, splitting the line and the below comment.
I'm Ok to not have it.
> > /*
> > * Based on the host; initialize the framework and
> > * service version numbers we will negotiate.
> > @@ -365,6 +361,11 @@ static int util_probe(struct hv_device *dev,
> > hb_srv_version = HB_VERSION;
> > }
> >
> > + ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL,
> > 0,
> > + srv->util_cb, dev->channel);
> > + if (ret)
> > + goto error;
> > +
> > return 0;
> >
> > error:
> > --
> > 1.9.1
> >
-- Dexuan
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] regmap: Fix i2c word access when using SMBus access functions
Hi Guenter,
On Sun, 1 Feb 2015 15:48:01 -0800, Guenter Roeck wrote:
> SMBUs access functions assume that 16 bit values are formatted as
Correct spelling is SMBus (lowercase U.) Also I think "16 bit" is
better spelled "16-bit" (more occurrences below.)
> little endian numbers. The direct i2c access functions in regmap,
> however, assume that 16 bit values are formatted as big endian numbers.
> As a result, the current code returns different values if an i2c chip's
> 16 bit registers are accessed through i2c access functions vs. SMBus
> access functions.
>
> Use regmap_smbus_read_word_swapped and regmap_smbus_write_word_swapped
> for 16 bit SMBus accesses unless a chip is registered with val_format_endian
> set to REGMAP_ENDIAN_LITTLE. In the latter case, keep using
> regmap_smbus_write_word_data and regmap_smbus_read_word_data.
>
> Cc: Jean Delvare
> Signed-off-by: Guenter Roeck
> ---
> Might be a candidate for -stable, though as far as I can see there is
> currently
> no driver in the upstream kernel using regmap for 16-bit i2c accesses.
>
> drivers/base/regmap/regmap-i2c.c | 41
> +++-
> 1 file changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/regmap/regmap-i2c.c
> b/drivers/base/regmap/regmap-i2c.c
> index 053150a..865f4f8 100644
> --- a/drivers/base/regmap/regmap-i2c.c
> +++ b/drivers/base/regmap/regmap-i2c.c
> @@ -87,6 +87,42 @@ static struct regmap_bus regmap_smbus_word = {
> .reg_read = regmap_smbus_word_reg_read,
> };
>
> +static int regmap_smbus_word_read_swapped(void *context, unsigned int reg,
> + unsigned int *val)
> +{
> + struct device *dev = context;
> + struct i2c_client *i2c = to_i2c_client(dev);
> + int ret;
> +
> + if (reg > 0xff)
> + return -EINVAL;
> +
> + ret = i2c_smbus_read_word_swapped(i2c, reg);
> + if (ret < 0)
> + return ret;
> +
> + *val = ret;
> +
> + return 0;
> +}
> +
> +static int regmap_smbus_word_write_swapped(void *context, unsigned int reg,
> +unsigned int val)
> +{
> + struct device *dev = context;
> + struct i2c_client *i2c = to_i2c_client(dev);
> +
> + if (val > 0x || reg > 0xff)
> + return -EINVAL;
> +
> + return i2c_smbus_write_word_swapped(i2c, reg, val);
> +}
> +
> +static struct regmap_bus regmap_smbus_word_swapped = {
> + .reg_write = regmap_smbus_word_write_swapped,
> + .reg_read = regmap_smbus_word_read_swapped,
> +};
> +
> static int regmap_i2c_write(void *context, const void *data, size_t count)
> {
> struct device *dev = context;
> @@ -180,7 +216,10 @@ static const struct regmap_bus
> *regmap_get_i2c_bus(struct i2c_client *i2c,
> else if (config->val_bits == 16 && config->reg_bits == 8 &&
>i2c_check_functionality(i2c->adapter,
>I2C_FUNC_SMBUS_WORD_DATA))
> - return _smbus_word;
> + if (config->val_format_endian == REGMAP_ENDIAN_LITTLE)
> + return _smbus_word;
> + else
> + return _smbus_word_swapped;
Indentation looks wrong.
> else if (config->val_bits == 8 && config->reg_bits == 8 &&
>i2c_check_functionality(i2c->adapter,
>I2C_FUNC_SMBUS_BYTE_DATA))
The code itself looks sane, although I am not a regmap expert.
Reviewed-by: Jean Delvare
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi/xilinx: Fix access invalid memory on xilinx_spi_tx
On 1 and 2 bytes per word, the transfer of the 3 last bytes will access
memory outside tx_ptr.
Although this has not trigger any error on real hardware, we should
better fix this.
Fixes: 24ba5e593f391507 Remove rx_fn and tx_fn pointer
Signed-off-by: Ricardo Ribalda Delgado
---
v2:
v1 was completely wrong, sorry about that :(. This v2 has been tested on x86
1 byte per word
drivers/spi/spi-xilinx.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-xilinx.c b/drivers/spi/spi-xilinx.c
index d1901d5..133f53a 100644
--- a/drivers/spi/spi-xilinx.c
+++ b/drivers/spi/spi-xilinx.c
@@ -117,11 +117,26 @@ static unsigned int xspi_read32_be(void __iomem *addr)
static void xilinx_spi_tx(struct xilinx_spi *xspi)
{
+ u32 data = 0;
+
if (!xspi->tx_ptr) {
xspi->write_fn(0, xspi->regs + XSPI_TXD_OFFSET);
return;
}
- xspi->write_fn(*(u32 *)(xspi->tx_ptr), xspi->regs + XSPI_TXD_OFFSET);
+
+ switch (xspi->bytes_per_word) {
+ case 1:
+ data = *(u8 *)(xspi->tx_ptr);
+ break;
+ case 2:
+ data = *(u16 *)(xspi->tx_ptr);
+ break;
+ case 4:
+ data = *(u32 *)(xspi->tx_ptr);
+ break;
+ }
+
+ xspi->write_fn(data, xspi->regs + XSPI_TXD_OFFSET);
xspi->tx_ptr += xspi->bytes_per_word;
}
--
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 v2 2/7] usb: extcon: Fix USB-Host cable name
On 02/02/2015 07:01 PM, Roger Quadros wrote: > On 02/02/15 11:55, Chanwoo Choi wrote: >> Hi Roger, >> >> On 02/02/2015 06:09 PM, Roger Quadros wrote: >>> Chanwoo, >>> >>> On 02/02/15 07:04, Chanwoo Choi wrote: Hi Roger, On 01/30/2015 11:05 PM, Roger Quadros wrote: > Hi, > > On 30/01/15 13:04, Roger Quadros wrote: >> Felipe & Chanwoo, >> >> On 26/01/15 14:15, Roger Quadros wrote: >>> The recommended name for USB-Host cable state is "USB-Host" and not >>> "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name. >>> >>> Change all instances of "USB-HOST" to "USB-Host". >>> >>> Signed-off-by: Roger Quadros >>> Reviewed-by: Felipe Balbi >>> Acked-by: Felipe Balbi >> >> This patch has no dependency to the rest so can be picked up as soon as >> possible. >> >> Do you think it is better to go via the USB tree? >> If yes then Chanwoo, can you please Ack this one? Thanks. >> >> This would mean that only the first patch needs to go through extcon >> tree as Tony >> will pick the rest. > > Hold on. Let's first decide what we really want to go ahead with > "USB-Host" or "USB-HOST". Currently, extcon driver have used the specific cable name(USB-Host or USB-HOST) without any standard way. So, I have plan to define common cable name in extcon header file by using capital letter. >>> >>> OK. In that case, this patch is not required. >>> I will resend patch 1 with cable name corrected to "USB-HOST". >> >> If you possbile, I want to use 'USB-HOST' cable name in drivers related to >> extcon. >> If we use different cable name, this cause the confusion to control cable. >> > > Kernel tree shows following users of "USB-Host" that will have to be changed > to > "USB-HOST". You're right. I'll modify all cable name of 'USB-HOST'. Also, I have plan to use only capital letter for cable name. > > extcon-class.c: [EXTCON_USB_HOST] = "USB-Host", > extcon-max77693.c:[EXTCON_CABLE_USB_HOST] = "USB-Host", > extcon-max77693.c:extcon_set_cable_state(info->edev, "USB-Host", > attached); > extcon-max8997.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", > extcon-max8997.c: extcon_set_cable_state(info->edev, "USB-Host", > attached); > extcon-rt8973a.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", > extcon-sm5502.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", > > I'm not aware if any user space programs depend on this name. Do you know of > any? As I knew, released samsung smart-phone used the cable name to detect the cable state becaues extcon send the uevent with both cable name and cable state. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/42] perf record: Add --index option for building index table
On Mon, Feb 02, 2015 at 11:52:26AM +0200, Adrian Hunter wrote:
> On 02/02/15 11:15, Jiri Olsa wrote:
> > On Mon, Feb 02, 2015 at 10:34:50AM +0200, Adrian Hunter wrote:
> >
> > SNIP
> >
> >>> but how about bump up the header version for this feature? ;-)
> >>>
> >>> currently it's:
> >>>
> >>> struct perf_file_header {
> >>> u64 magic;
> >>> u64 size;
> >>> u64 attr_size;
> >>> struct perf_file_sectionattrs;
> >>> struct perf_file_sectiondata;
> >>> /* event_types is ignored */
> >>> struct perf_file_sectionevent_types;
> >>> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> >>> };
> >>>
> >>>
> >>> - we already store attrs as a FEATURE so we could omit that
> >>> - your patch stores only synthesized data into 'data' section (-1 idx)
> >>> this could be stored into separate file and get merged with the rest
> >>> - new header version would have 'features' section, so the features
> >>> position wouldnt depend on the 'data' end as of now and we could
> >>> easily store after all data is merged:
> >>>
> >>> struct perf_file_header {
> >>> u64 magic;
> >>> u64 size;
> >>> u64 attr_size;
> >>> struct perf_file_sectionfeatures;
> >>> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> >>> };
> >>>
> >>>
> >>> thoughts?
> >>
> >> How come the features are being written before the sample data anyway?
> >> I would have expected:
> >>- write the data (update the index in memory)
> >>- write the features (including index)
> >>
> >
> > I think the problem is that the only way how to get features offset
> > right now is via perf_file_header::data.offset + perf_file_headerdata.size,
> > and we still use this section to carry 'sythesized' data, so it needs
> > to have correct size.
>
> Why not make it the same as all the other data. i.e. find the start and size
> via the index? And then just lump all the data together?
thats what I suggested
>
> > I guess we could workaround that by storing the 'perf_file_header::data'
> > as the last data section. That would require to treat it the same way as
> > all other data sections, but we could keep current header layout.
>
> Would it need to be last? Logically it should precede the data that depends
> on it.
i suggested this as a workaround for having features at the end of the file
while keeping the current perf data header
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[3.16.y-ckt stable] Linux 3.16.7-ckt5
I am announcing the release of the Linux 3.16.7-ckt5 kernel. The updated 3.16.y-ckt tree can be found at: git://kernel.ubuntu.com/ubuntu/linux.git linux-3.16.y and can be browsed at: http://kernel.ubuntu.com/git?p=ubuntu/linux.git;h=refs/heads/linux-3.16.y;a=shortlog The diff from v3.16.7-ckt4 is posted as a follow-up to this email. The 3.16.y-ckt extended stable tree is maintained by the Canonical Kernel Team. For more info, see https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable -Luis -- Makefile | 2 +- arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 2 + arch/arm/boot/dts/berlin2q.dtsi | 63 - arch/arm/boot/dts/dra7-evm.dts | 10 +-- arch/arm/boot/dts/dra7.dtsi | 2 +- arch/arm/boot/dts/imx25.dtsi | 2 +- arch/arm/boot/dts/imx51-babbage.dts | 22 ++ arch/arm/boot/dts/s3c6410-mini6410.dts | 4 -- arch/arm/boot/dts/s3c64xx.dtsi | 1 - arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/include/asm/xen/page.h | 4 ++ arch/arm/kernel/setup.c | 9 +++ arch/arm/kernel/smp.c| 13 +++- arch/arm/mach-imx/clk-imx6q.c| 4 +- arch/arm/mach-imx/clk-imx6sx.c | 3 + arch/arm/mach-omap2/common.h | 1 + arch/arm/mach-omap2/omap-headsmp.S | 21 ++ arch/arm/mach-omap2/omap-smp.c | 13 +++- arch/arm/mach-omap2/pm44xx.c | 29 +++- arch/arm/mach-omap2/timer.c | 8 +-- arch/arm/mach-shmobile/setup-sh73a0.c| 3 + arch/arm/xen/mm.c| 7 ++ arch/arm64/kernel/efi.c | 2 +- arch/arm64/kernel/setup.c| 1 + arch/powerpc/kernel/udbg_16550.c | 6 +- arch/x86/include/asm/vsyscall.h | 2 +- arch/x86/include/asm/xen/page.h | 7 ++ arch/x86/kernel/kprobes/core.c | 20 -- arch/x86/vdso/vma.c | 45 +++- drivers/acpi/acpica/evxfgpe.c| 47 + drivers/acpi/device_pm.c | 2 +- drivers/acpi/scan.c | 42 ++- drivers/clk/at91/clk-slow.c | 27 +++ drivers/clk/berlin/bg2q.c| 1 - drivers/clk/clk.c| 5 +- drivers/gpu/drm/i915/i915_irq.c | 6 +- drivers/gpu/drm/i915/i915_reg.h | 12 ++-- drivers/gpu/drm/i915/intel_ringbuffer.c | 66 +++--- drivers/gpu/drm/nouveau/core/subdev/mc/nv4c.c| 8 --- drivers/gpu/drm/radeon/atombios_crtc.c | 8 +-- drivers/gpu/drm/radeon/atombios_dp.c | 4 ++ drivers/gpu/drm/radeon/dce3_1_afmt.c | 2 +- drivers/gpu/drm/radeon/kv_dpm.c | 10 ++- drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h| 1 + drivers/hid/hid-input.c | 3 + drivers/hid/hid-kye.c| 4 ++ drivers/hid/hid-roccat-pyra.c| 8 ++- drivers/hid/i2c-hid/i2c-hid.c| 5 -- drivers/hid/usbhid/hid-quirks.c | 1 + drivers/md/bcache/btree.c| 2 +- drivers/misc/mei/hw-me.c | 12 drivers/mmc/host/sdhci-pxav3.c | 19 +++-- drivers/mmc/host/sdhci.c | 8 ++- drivers/mtd/nand/omap2.c | 7 -- drivers/net/ethernet/atheros/alx/main.c | 24 --- drivers/net/ethernet/broadcom/tg3.c | 34 - drivers/net/ethernet/cisco/enic/enic_main.c | 12 ++-- drivers/net/ethernet/ti/cpsw.c | 30 drivers/net/ethernet/ti/cpsw_ale.c | 10 ++- drivers/net/ethernet/ti/cpsw_ale.h | 2 +- drivers/net/team/team.c | 16 - drivers/net/wireless/iwlwifi/mvm/utils.c | 2 +- drivers/net/xen-netback/xenbus.c | 1 + drivers/net/xen-netfront.c | 10 ++- drivers/reset/reset-sunxi.c | 4 ++ drivers/rtc/rtc-isl12057.c | 4 +- drivers/scsi/scsi_error.c| 4 +- drivers/spi/spi-sh-msiof.c | 5 ++ drivers/target/loopback/tcm_loop.c | 23 +++--- drivers/target/target_core_device.c | 8 +-- drivers/target/target_core_file.c| 11 ++- drivers/target/target_core_iblock.c | 2 +- drivers/target/target_core_sbc.c | 15 drivers/target/target_core_spc.c | 5 +-
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
On 02/02/15 11:55, Chanwoo Choi wrote: > Hi Roger, > > On 02/02/2015 06:09 PM, Roger Quadros wrote: >> Chanwoo, >> >> On 02/02/15 07:04, Chanwoo Choi wrote: >>> Hi Roger, >>> >>> On 01/30/2015 11:05 PM, Roger Quadros wrote: Hi, On 30/01/15 13:04, Roger Quadros wrote: > Felipe & Chanwoo, > > On 26/01/15 14:15, Roger Quadros wrote: >> The recommended name for USB-Host cable state is "USB-Host" and not >> "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name. >> >> Change all instances of "USB-HOST" to "USB-Host". >> >> Signed-off-by: Roger Quadros >> Reviewed-by: Felipe Balbi >> Acked-by: Felipe Balbi > > This patch has no dependency to the rest so can be picked up as soon as > possible. > > Do you think it is better to go via the USB tree? > If yes then Chanwoo, can you please Ack this one? Thanks. > > This would mean that only the first patch needs to go through extcon tree > as Tony > will pick the rest. Hold on. Let's first decide what we really want to go ahead with "USB-Host" or "USB-HOST". >>> >>> Currently, extcon driver have used the specific cable name(USB-Host or >>> USB-HOST) >>> without any standard way. So, I have plan to define common cable name in >>> extcon >>> header file by using capital letter. >> >> OK. In that case, this patch is not required. >> I will resend patch 1 with cable name corrected to "USB-HOST". > > If you possbile, I want to use 'USB-HOST' cable name in drivers related to > extcon. > If we use different cable name, this cause the confusion to control cable. > Kernel tree shows following users of "USB-Host" that will have to be changed to "USB-HOST". extcon-class.c: [EXTCON_USB_HOST] = "USB-Host", extcon-max77693.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", extcon-max77693.c: extcon_set_cable_state(info->edev, "USB-Host", attached); extcon-max8997.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", extcon-max8997.c: extcon_set_cable_state(info->edev, "USB-Host", attached); extcon-rt8973a.c: [EXTCON_CABLE_USB_HOST] = "USB-Host", extcon-sm5502.c:[EXTCON_CABLE_USB_HOST] = "USB-Host", I'm not aware if any user space programs depend on this name. Do you know of any? cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: block layer copying user io vectors
On Fri, Jan 30, 2015 at 05:43:04PM +, Andy Falanga (afalanga) wrote: > > > This function does something that seems rather strange. On line 859, > > > a for loop determines the number of pages needed for the copying of > > > the user data to kernel space. Then the memory is allocated (line > > > 886 bio_kmalloc()). Then, strangely, on line 895, there is this > > > conditional: > > > > This is because the function can also be used with preallocated pages, > > a feature only used by the sg and tape drivers. > > > > Make sure your user memory is 4k aligned, and you should be able to > > avoid the copy entirely (1). > > Where is this 4k alignment being enforced? When sg_start_req calls to > blk_rq_map_user_iov, the only check for alignment is that the data buffers > are 4-byte aligned (q->dma_alignment == 3). I have verified that they are. Indeed, I though we had the more strict direct I/O alignment. Still doesn't help because the sg driver refuses to directly map user pages for vectored I/O. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v3 2/3] mm/page_alloc: factor out fallback freepage checking
On 02/02/2015 08:15 AM, Joonsoo Kim wrote:
> This is preparation step to use page allocator's anti fragmentation logic
> in compaction. This patch just separates fallback freepage checking part
> from fallback freepage management part. Therefore, there is no functional
> change.
>
> Signed-off-by: Joonsoo Kim
> ---
> mm/page_alloc.c | 128
> +---
> 1 file changed, 76 insertions(+), 52 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index e64b260..6cb18f8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1142,14 +1142,26 @@ static void change_pageblock_range(struct page
> *pageblock_page,
> * as fragmentation caused by those allocations polluting movable pageblocks
> * is worse than movable allocations stealing from unmovable and reclaimable
> * pageblocks.
> - *
> - * If we claim more than half of the pageblock, change pageblock's
> migratetype
> - * as well.
> */
> -static void try_to_steal_freepages(struct zone *zone, struct page *page,
> - int start_type, int fallback_type)
> +static bool can_steal_fallback(unsigned int order, int start_mt)
> +{
> + if (order >= pageblock_order)
> + return true;
> +
> + if (order >= pageblock_order / 2 ||
> + start_mt == MIGRATE_RECLAIMABLE ||
> + start_mt == MIGRATE_UNMOVABLE ||
> + page_group_by_mobility_disabled)
> + return true;
> +
> + return false;
> +}
> +
> +static void steal_suitable_fallback(struct zone *zone, struct page *page,
> + int start_type)
Some comment about the function please?
> {
> int current_order = page_order(page);
> + int pages;
>
> /* Take ownership for orders >= pageblock_order */
> if (current_order >= pageblock_order) {
> @@ -1157,19 +1169,39 @@ static void try_to_steal_freepages(struct zone *zone,
> struct page *page,
> return;
> }
>
> - if (current_order >= pageblock_order / 2 ||
> - start_type == MIGRATE_RECLAIMABLE ||
> - start_type == MIGRATE_UNMOVABLE ||
> - page_group_by_mobility_disabled) {
> - int pages;
> + pages = move_freepages_block(zone, page, start_type);
>
> - pages = move_freepages_block(zone, page, start_type);
> + /* Claim the whole block if over half of it is free */
> + if (pages >= (1 << (pageblock_order-1)) ||
> + page_group_by_mobility_disabled)
> + set_pageblock_migratetype(page, start_type);
> +}
>
> - /* Claim the whole block if over half of it is free */
> - if (pages >= (1 << (pageblock_order-1)) ||
> - page_group_by_mobility_disabled)
> - set_pageblock_migratetype(page, start_type);
> +static int find_suitable_fallback(struct free_area *area, unsigned int order,
> + int migratetype, bool *can_steal)
Same here.
> +{
> + int i;
> + int fallback_mt;
> +
> + if (area->nr_free == 0)
> + return -1;
> +
> + *can_steal = false;
> + for (i = 0;; i++) {
> + fallback_mt = fallbacks[migratetype][i];
> + if (fallback_mt == MIGRATE_RESERVE)
> + break;
> +
> + if (list_empty(>free_list[fallback_mt]))
> + continue;
> +
> + if (can_steal_fallback(order, migratetype))
> + *can_steal = true;
> +
> + return i;
You want to return fallback_mt, not 'i', no?
> }
> +
> + return -1;
> }
>
> /* Remove an element from the buddy allocator from the fallback list */
> @@ -1179,53 +1211,45 @@ __rmqueue_fallback(struct zone *zone, unsigned int
> order, int start_migratetype)
> struct free_area *area;
> unsigned int current_order;
> struct page *page;
> + int fallback_mt;
> + bool can_steal;
>
> /* Find the largest possible block of pages in the other list */
> for (current_order = MAX_ORDER-1;
> current_order >= order && current_order <=
> MAX_ORDER-1;
> --current_order) {
> - int i;
> - for (i = 0;; i++) {
> - int migratetype = fallbacks[start_migratetype][i];
> - int buddy_type = start_migratetype;
> -
> - /* MIGRATE_RESERVE handled later if necessary */
> - if (migratetype == MIGRATE_RESERVE)
> - break;
> -
> - area = &(zone->free_area[current_order]);
> - if (list_empty(>free_list[migratetype]))
> - continue;
> -
> - page = list_entry(area->free_list[migratetype].next,
> - struct page, lru);
> -
[PATCH 1/2 v3] spi: tegra20-sflash: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already states "timeout" there
is little point in printing the 0 here.
Signed-off-by: Nicholas Mc Guire
---
v2: typo fixed as suggested by Laxman Dewangan
v3: merged dev_err into one line as suggested by Laxman Dewangan
This patch was only compile tested with tegra_defconfig
(implies CONFIG_SPI_TEGRA20_SFLASH=y)
Patch is against 3.19.0-rc6 -next-20150202
drivers/spi/spi-tegra20-sflash.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index b6558bb..c23d3d4 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -323,6 +323,7 @@ static int tegra_sflash_transfer_one_message(struct
spi_master *master,
struct spi_transfer *xfer;
struct spi_device *spi = msg->spi;
int ret;
+ unsigned long dma_timeout;
msg->status = 0;
msg->actual_length = 0;
@@ -337,11 +338,10 @@ static int tegra_sflash_transfer_one_message(struct
spi_master *master,
goto exit;
}
is_first_msg = false;
- ret = wait_for_completion_timeout(>xfer_completion,
+ dma_timeout = wait_for_completion_timeout(>xfer_completion,
SPI_DMA_TIMEOUT);
- if (WARN_ON(ret == 0)) {
- dev_err(tsd->dev,
- "spi trasfer timeout, err %d\n", ret);
+ if (WARN_ON(dma_timeout == 0)) {
+ dev_err(tsd->dev, "spi transfer timeout\n");
ret = -EIO;
goto exit;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Hi Roger, On 02/02/2015 06:09 PM, Roger Quadros wrote: > Chanwoo, > > On 02/02/15 07:04, Chanwoo Choi wrote: >> Hi Roger, >> >> On 01/30/2015 11:05 PM, Roger Quadros wrote: >>> Hi, >>> >>> On 30/01/15 13:04, Roger Quadros wrote: Felipe & Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: > The recommended name for USB-Host cable state is "USB-Host" and not > "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name. > > Change all instances of "USB-HOST" to "USB-Host". > > Signed-off-by: Roger Quadros > Reviewed-by: Felipe Balbi > Acked-by: Felipe Balbi This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. >>> >>> Hold on. Let's first decide what we really want to go ahead with >>> "USB-Host" or "USB-HOST". >> >> Currently, extcon driver have used the specific cable name(USB-Host or >> USB-HOST) >> without any standard way. So, I have plan to define common cable name in >> extcon >> header file by using capital letter. > > OK. In that case, this patch is not required. > I will resend patch 1 with cable name corrected to "USB-HOST". If you possbile, I want to use 'USB-HOST' cable name in drivers related to extcon. If we use different cable name, this cause the confusion to control cable. Thanks, Chanwoo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 14/42] perf record: Add --index option for building index table
On 02/02/15 11:15, Jiri Olsa wrote:
> On Mon, Feb 02, 2015 at 10:34:50AM +0200, Adrian Hunter wrote:
>
> SNIP
>
>>> but how about bump up the header version for this feature? ;-)
>>>
>>> currently it's:
>>>
>>> struct perf_file_header {
>>> u64 magic;
>>> u64 size;
>>> u64 attr_size;
>>> struct perf_file_sectionattrs;
>>> struct perf_file_sectiondata;
>>> /* event_types is ignored */
>>> struct perf_file_sectionevent_types;
>>> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
>>> };
>>>
>>>
>>> - we already store attrs as a FEATURE so we could omit that
>>> - your patch stores only synthesized data into 'data' section (-1 idx)
>>> this could be stored into separate file and get merged with the rest
>>> - new header version would have 'features' section, so the features
>>> position wouldnt depend on the 'data' end as of now and we could
>>> easily store after all data is merged:
>>>
>>> struct perf_file_header {
>>> u64 magic;
>>> u64 size;
>>> u64 attr_size;
>>> struct perf_file_sectionfeatures;
>>> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
>>> };
>>>
>>>
>>> thoughts?
>>
>> How come the features are being written before the sample data anyway?
>> I would have expected:
>> - write the data (update the index in memory)
>> - write the features (including index)
>>
>
> I think the problem is that the only way how to get features offset
> right now is via perf_file_header::data.offset + perf_file_headerdata.size,
> and we still use this section to carry 'sythesized' data, so it needs
> to have correct size.
Why not make it the same as all the other data. i.e. find the start and size
via the index? And then just lump all the data together?
> I guess we could workaround that by storing the 'perf_file_header::data'
> as the last data section. That would require to treat it the same way as
> all other data sections, but we could keep current header layout.
Would it need to be last? Logically it should precede the data that depends
on it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: ad_sigma_delta: cleanup wait_for_completion return handling
On Mon, 02 Feb 2015, Lars-Peter Clausen wrote:
> On 02/02/2015 09:37 AM, Nicholas Mc Guire wrote:
>> return type of wait_for_completion_timeout is unsigned long not int, rather
>> than introducing a new variable the wait_for_completion_timeout is moved
>> into the if condition as the return value is only used to detect timeout.
>
> But the return value is bound by the timeout parameter and we know that
> fits into a int. And I really dont like moving the function call into the
> if condition, so unless there is some additional explanation why this is
> necessary and should be done I'm inclined to nack this.
>
well having correct types is important for all static code chekcers
and I did not want to add a new variable just for this case
simply because the result is only relevant in the == 0 case
anyway.
I do think that the types being assigned should correct with respect
to the API definition even if it fits in this case.
>>
>> Signed-off-by: Nicholas Mc Guire
>> ---
>>
>> Aside from the fixup of the wait_for_completion_timeout handling
>> a minor coding style issue in the else branch was fixed - the {} is
>> not needed for the one-line body.
>
> If one of the branches of a conditional statement has braces the other
> branches should also have braces. This is documented in
> Documentation/CodingStyle.
my bad - it is not uncommon to be asymetric - but you are right that Chapter 3
states it should not be asymetric in this case - will remove that.
given the botched braces this needs to be redone - let me know if moving
it into the condition is ok (its not uncommon) or if an additional variable
of type unsigned long is the prefered solution.
thanks for your review !
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.19-rc5
Dne 30.1.2015 v 02:49 Rafael J. Wysocki napsal(a): On Thursday, January 29, 2015 05:12:11 PM Linus Torvalds wrote: On Thu, Jan 29, 2015 at 5:22 PM, Rafael J. Wysocki wrote: On Wednesday, January 21, 2015 05:54:00 PM Peter Hurley wrote: Yeah, but the debug check is triggering worse behavior, requiring bisecting back to the debug commit. Yes, it is. So I'm wondering is anyone is working on fixing this in any way? It kind of sucks when this is happening on an otherwise perfectly usable old(ish) machine ... The WARN() was already changed to a WARN_ONCE(). So that debug check doesn't cause problems any more. If somebody is bisecting something else, and the WARN() is a problem for those intermediate kernels, then just disabling CONFIG_DEBUG_ATOMIC_SLEEP should get you past that point. IOW, this really shouldn't be an issue. Does the pccard thing still not work? Interestingly enough, if the kernel is built with CONFIG_DEBUG_ATOMIC_SLEEP unset, the problem with 99+% CPU load from pccardd goes away, so thanks for the hint. Ok - I can now 'use' 3.19-rc7 on T61 (C2D) without having a single core occupied on 100% with pccardd, but I still get this one logged: [2.185320] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f: [2.185363] excluding 0xc-0xc 0xe-0xf [2.185526] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: [2.185559] excluding 0xa000-0xa0ff [2.185720] pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000-0x60ff: [2.185754] excluding 0x6000-0x60ff [2.297692] [ cut here ] [2.297698] WARNING: CPU: 1 PID: 185 at kernel/sched/core.c:7300 __might_sleep+0xae/0xc0() [2.297702] do not call blocking ops when !TASK_RUNNING; state=1 set at [] pccardd+0xe8/0x490 [2.297712] Modules linked in: uhci_hcd sr_mod cdrom ehci_pci ehci_hcd yenta_socket usbcore usb_common video backlight autofs4 [2.297715] CPU: 1 PID: 185 Comm: pccardd Not tainted 3.19.0-rc7-2-g9afdf96 #5 [2.297716] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011 [2.297719] 819e4d8a 8800b8bdbc58 8163926d 810a9e1e [2.297721] 8800b8bdbca8 8800b8bdbc98 810587ba 8800 [2.297724] 819e6073 026d 0080 [2.297725] Call Trace: [2.297729] [] dump_stack+0x4f/0x7b [2.297732] [] ? down_trylock+0x2e/0x40 [2.297736] [] warn_slowpath_common+0x8a/0xc0 [2.297738] [] warn_slowpath_fmt+0x46/0x50 [2.297741] [] ? pccardd+0xe8/0x490 [2.297742] [] ? pccardd+0xe8/0x490 [2.297744] [] __might_sleep+0xae/0xc0 [2.297747] [] mutex_lock_nested+0x2e/0x440 [2.297749] [] ? _raw_spin_unlock_irqrestore+0x5d/0x80 [2.297753] [] ? preempt_count_sub+0xab/0x100 [2.297755] [] pccardd+0x150/0x490 [2.297757] [] ? pcmcia_socket_dev_complete+0x40/0x40 [2.297760] [] kthread+0x11f/0x140 [2.297763] [] ? kthread_create_on_node+0x260/0x260 [2.297766] [] ret_from_fork+0x7c/0xb0 [2.297768] [] ? kthread_create_on_node+0x260/0x260 [2.297770] ---[ end trace ed9e591061d223e6 ]--- [2.464635] usb 3-1: new full-speed USB device number 2 using uhci_hcd and of course number of these: [ 29.660708] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 29.667061] i915 :00:02.0: registered panic notifier [ 30.314206] [ cut here ] [ 30.318866] WARNING: CPU: 0 PID: 1010 at drivers/gpu/drm/drm_irq.c:1121 drm_wait_one_vblank+0x180/0x190 [drm]() [ 30.329085] vblank not available on crtc 1, ret=-22 [ 30.334003] Modules linked in: i915 i2c_algo_bit drm_kms_helper drm xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun brid ge stp llc ipv6 ebtables ip6_tables iptable_filter ip_tables x_tables bnep iTCO_wdt hid_generic iTCO_vendor_support snd_hda_codec_analo g snd_hda_codec_generic coretemp kvm_intel kvm microcode usbhid psmouse serio_raw hid arc4 r852 sm_common nand i2c_i801 nand_ecc i2c_co re nand_ids mtd btusb bluetooth iwl3945 sdhci_pci r592 iwlegacy memstick pcmcia snd_hda_intel sdhci mac80211 snd_hda_controller mmc_cor e snd_hda_codec snd_hwdep lpc_ich snd_seq mfd_core snd_seq_device snd_pcm e1000e cfg80211 ptp thinkpad_acpi snd_timer pps_core wmi nvra m [ 30.406592] snd soundcore evdev nfsd auth_rpcgss oid_registry nfs_acl lockd grace binfmt_misc loop sunrpc uhci_hcd sr_mod cdrom ehc i_pci ehci_hcd yenta_socket usbcore usb_common video backlight autofs4 [ 30.424031] CPU: 1 PID: 1010 Comm: Xorg.bin Tainted: GW 3.19.0-rc7-2-g9afdf96 #5 [ 30.432930] Hardware name: LENOVO 6464CTO/6464CTO, BIOS 7LETC9WW (2.29 ) 03/18/2011 [ 30.440627] a0e1017f 880135a37a28 8163926d
Re: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension)
On Mon 2015-02-02 10:07:02, Jacek Anaszewski wrote: > On 01/30/2015 05:40 PM, Greg KH wrote: > >On Fri, Jan 30, 2015 at 09:55:30AM +0100, Jacek Anaszewski wrote: > >>Hi Pavel, > >> > >>On 01/29/2015 10:14 PM, Pavel Machek wrote: > >>>Hi! > >>> > >>+ - flash_fault - list of flash faults that may have occurred: > >>+ * led-over-voltage - flash controller voltage to the > >>flash LED > >>+ has exceededthe limit specific to the flash > >>controller > >>+ * flash-timeout-exceeded - the flash strobe was still > >>on when > >>+ the timeout set by the user has expired; not > >>all flash > >>+ controllers may set this in all such conditions > >>+ * controller-over-temperature - the flash controller has > >>+ overheated > >>+ * controller-short-circuit - the short circuit > >>protection > >>+ of the flash controller has been triggered > >>+ * led-power-supply-over-current - current in the LED > >>power > >>+ supply has exceeded the limit specific to the > >>flash > >>+ controller > >>+ * indicator-led-fault - the flash controller has > >>detected > >>+ a short or open circuit condition on the > >>indicator LED > >>+ * led-under-voltage - flash controller voltage to the > >>flash > >>+ LED has been below the minimum limit specific to > >>+ the flash > >>+ * controller-under-voltage - the input voltage of the > >>flash > >>+ controller is below the limit under which > >>strobing the > >>+ flash at full current will not be possible. The > >>condition > >>+ persists until this flag is no longer set > >>+ * led-over-temperature - the temperature of the LED has > >>exceeded > >>+ its allowed upper limit > >>+ > >>+ Flash faults are cleared, if possible, by reading the > >>attribute. > > > >That's bad. Now you can no longer present flash_fault file as readable > >to non-root users, and grep -ri foo /sys will interfere with your > >camera application. > > > >Bad interface, just fix it. > > In my opinion it isn't crucial for the user to be aware of the > fact that some non-persistent fault happened right after strobing the > flash (e.g. over temperature). > > I cannot see anything harmful in the situation when someone does grep > on /sys and clears non-persistent fault on a flash LED device. > >>> > >>>So why export the faults at all? > >> > >>Faults may prevent strobing the flash in case of some devices. > >>The example of such a device is ADP1663 (drivers/media/i2c/adp1653.c). > >>This driver reads the faults before strobing the flash and if a > >>fault preventing strobing has occurred it returns -EBUSY. > >> > >>If this driver was made a LED Flash class driver, then it would > >>expose flash_faults attribute. The driver would probably need > >>redesigning - checking the faults before strobing would have to be > >>avoided and it should be left to the userspace. > > > >That's fine, but Pavel's point is that you shouldn't "clear a fault" by > >reading a sysfs file as you don't control who reads all sysfs files > >(hint, libudev might cache all attributes when they are found / change, > >which could prevent anyone else from seeing that fault.) > > > >So please fix this, make a write to clear a fault or some other such > >explicit action, not a simple read. That's not an acceptable api. > > I am aware what Pavel'a point was, I just presented the arguments > justifying existence of the flash_faults attribute at all. Fine. Then, you should understand what you need to fix at this point. > In my opinion flash_faults attribute should report the current state of > the device. For the devices which clear the faults on I2C readout the > faults read would have to be cached in the driver, until they are > explicitly cleared, to keep the sysfs interface consistent. Yes, just do the caching. > Nonetheless, there can be also devices which don't require clearing the > faults - they are reported only when the actual condition occurs, > e.g. over temperature or under voltage. When the related value gets > back to the acceptable level the fault is no longer reported by the > device. > > In this case some faults will remain unnoticed by the user space. This > is the argument in favour of my statement that caching the faults does > not make a sense and is not crucial. The user's vital interest is to > know whether the flash LED is operational right before
Re: [PATCH v2 3/3] hv: vmbus_open(): reset the channel state on ENOMEM
On Mon, Feb 2, 2015 at 12:37 PM, Dexuan Cui wrote:
Without this patch, the state is put to CHANNEL_OPENING_STATE, and
when
the driver is loaded next time, vmbus_open() will fail immediately
due to
newchannel->state != CHANNEL_OPEN_STATE.
CC: "K. Y. Srinivasan"
Signed-off-by: Dexuan Cui
---
v2: this is a RESEND.
drivers/hv/channel.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 2978f5e..26dcf26 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -89,9 +89,10 @@ int vmbus_open(struct vmbus_channel *newchannel,
u32 send_ringbuffer_size,
out = (void *)__get_free_pages(GFP_KERNEL|__GFP_ZERO,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
- if (!out)
- return -ENOMEM;
-
+ if (!out) {
+ err = -ENOMEM;
+ goto error0;
+ }
in = (void *)((unsigned long)out + send_ringbuffer_size);
@@ -199,6 +200,7 @@ error0:
free_pages((unsigned long)out,
get_order(send_ringbuffer_size + recv_ringbuffer_size));
kfree(open_info);
+ newchannel->state = CHANNEL_OPEN_STATE;
return err;
}
EXPORT_SYMBOL_GPL(vmbus_open);
--
1.9.1
Reviewed-by: Jason Wang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/4] mtd: nand: atmel: Update DT documentation after splitting NFC and NAND
Hi Brian, On Sun, 1 Feb 2015 23:57:37 -0800 Brian Norris wrote: > Hi Boris, > > BTW, this series has a few conflicts with other things I have queued, so > you'll need to refresh. Yes, that's not a problem, but I'd like to be sure this is the way we want to go before rebasing this series. > > On Thu, Dec 04, 2014 at 11:30:12PM +0100, Boris Brezillon wrote: > > The NAND and NFC (NAND Flash Controller) were linked together with a > > parent <-> child relationship. > > > > This model has several drawbacks: > > - it does not allow for multiple NAND chip handling while the controller > > support multi-chip (even though the driver is not ready yet) > > - it mixes NAND partitions and NFC nodes at the same level (which is a bit > > disturbing) > > I agree that this is disturbing. (FWIW, it also seems a bit disturbing > that atmel_nand.c actually registers two different drivers and the tries > to synchronize them; this seems like it could be handled better, but I'm > not sure how at the moment.) Yep, that's my feeling too, but I'm not sure how this could/should be done. My problem here is that the pinmux should be requested by the EBI device because the EBI manages several type of devices and the data and address signals are shared by all the devices, hence the idea of defining the nand chip node under the EBI node. In the other hand, the NFC is not part of the EBI bus, and thus should not be defined under the EBI node. This might lead to the NFC device being probed before the NAND chip, hence the need for this synchronization. > > > - the introduction of the EBI bus implies defining NAND chips under the > > EBI node, and the ranges available under the EBI node should be > > restricted to EBI address space, while the NFC references several > > registers outside of these EBI ranges. > > That's an interesting bit. I've actually run across this sort of problem > on other SoCs, where we have a relationship between two pieces of > hardware--the NAND chip and the NAND controller--where the former might > be on one bus (like your EBI bus, with chip selects), and the latter is > part of the top-level MMIO register space. > > But can you elaborate here a bit more? Does the NAND chip actually need > to be represented under your EBI bus? Yes, as said above this is all about pinmux conflicts, the NAND controller has to request the appropriate pinmux for its NAND chips but it will conflict with the pinmux requested by the EBI bus (data and address signals are shared by all the devices connected on the EBI). > > > Move the NFC node outside of the NAND node, to get a more future-proof > > model. > > I'm curious if an alternative solution might work, maybe one like the > Allwiner NAND (sunxi-nand) DT, which just reverses the roles; the 'NFC' > is the parent of the NAND chip(s). We've seen this pattern in other > contexts too. I would have preferred this solution too, but the EBI/pinmux constraint explained above prevents this approach. What I can do though, is reverse the referencing: reference nand chips from the nand controller node. Josh, Brian, any idea to solve this EBI/nand-chip/nand-controller dependency problem is welcome. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel 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/
[PATCH] stagging: media: tlg2300: Fixes Checkpatch error
Error: Missing a blank line after declarations
Singed-off-by: pushpendra.si...@smartplayin.com
to: pramod.gu...@smartplayin.com
cc: kiran.pad...@smartplayin.com
cc: chowdegowda...@smartplayin.com
---
drivers/staging/media/tlg2300/pd-alsa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/media/tlg2300/pd-alsa.c
b/drivers/staging/media/tlg2300/pd-alsa.c
index 0b23395..f3b1ac8 100644
--- a/drivers/staging/media/tlg2300/pd-alsa.c
+++ b/drivers/staging/media/tlg2300/pd-alsa.c
@@ -255,6 +255,7 @@ snd_pd_capture_pointer(struct snd_pcm_substream *substream)
{
struct poseidon *p = snd_pcm_substream_chip(substream);
struct poseidon_audio *pa = >audio;
+
return pa->rcv_position;
}
@@ -262,6 +263,7 @@ static struct page *snd_pcm_pd_get_page(struct
snd_pcm_substream *subs,
unsigned long offset)
{
void *pageptr = subs->runtime->dma_area + offset;
+
return vmalloc_to_page(pageptr);
}
--
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 v2 2/3] hv: vmbus_post_msg: retry the hypercall on some transient errors
On Mon, Feb 2, 2015 at 12:36 PM, Dexuan Cui wrote:
I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping
running
"rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe
hv_utils"
in a Linux guest. Looks the host has some kind of throttling
mechanism if
some kinds of hypercalls are sent too frequently.
Better to clarify this kind of throttling. Looks like it only affects
HVCALL_POST_MESSAGE. Other looks good.
Reviewed-by: Jason Wang
Without the patch, the driver can occasionally fail to load.
Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get
it
before.
Removed 'case -ENOMEM', since the hypervisor doesn't return this.
CC: "K. Y. Srinivasan"
Signed-off-by: Dexuan Cui
---
v2:
updated the subject and changelog
on HV_STATUS_INVALID_CONNECTION_ID: ret = -EAGAIN;
added HV_STATUS_INSUFFICIENT_MEMORY
removed unreachable -ENOMEM
changed the delay from 100ms to 1000ms
arch/x86/include/uapi/asm/hyperv.h | 2 ++
drivers/hv/connection.c| 11 +--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/uapi/asm/hyperv.h
b/arch/x86/include/uapi/asm/hyperv.h
index 90c458e..ce6068d 100644
--- a/arch/x86/include/uapi/asm/hyperv.h
+++ b/arch/x86/include/uapi/asm/hyperv.h
@@ -225,6 +225,8 @@
#define HV_STATUS_INVALID_HYPERCALL_CODE 2
#define HV_STATUS_INVALID_HYPERCALL_INPUT 3
#define HV_STATUS_INVALID_ALIGNMENT4
+#define HV_STATUS_INSUFFICIENT_MEMORY 11
+#define HV_STATUS_INVALID_CONNECTION_ID18
#define HV_STATUS_INSUFFICIENT_BUFFERS 19
typedef struct _HV_REFERENCE_TSC_PAGE {
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index c4acd1c..af2388f 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -440,9 +440,16 @@ int vmbus_post_msg(void *buffer, size_t buflen)
ret = hv_post_message(conn_id, 1, buffer, buflen);
switch (ret) {
+ case HV_STATUS_INVALID_CONNECTION_ID:
+ /*
+* We could get this if we send messages too
+* frequently.
+*/
+ ret = -EAGAIN;
+ break;
+ case HV_STATUS_INSUFFICIENT_MEMORY:
case HV_STATUS_INSUFFICIENT_BUFFERS:
ret = -ENOMEM;
- case -ENOMEM:
break;
case HV_STATUS_SUCCESS:
return ret;
@@ -452,7 +459,7 @@ int vmbus_post_msg(void *buffer, size_t buflen)
}
retries++;
- msleep(100);
+ msleep(1000);
}
return ret;
}
--
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 3/3] iio: ad_sigma_delta: cleanup wait_for_completion return handling
On 02/02/2015 09:37 AM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int, rather
than introducing a new variable the wait_for_completion_timeout is moved
into the if condition as the return value is only used to detect timeout.
But the return value is bound by the timeout parameter and we know that fits
into a int. And I really dont like moving the function call into the if
condition, so unless there is some additional explanation why this is
necessary and should be done I'm inclined to nack this.
Signed-off-by: Nicholas Mc Guire
---
Aside from the fixup of the wait_for_completion_timeout handling
a minor coding style issue in the else branch was fixed - the {} is
not needed for the one-line body.
If one of the branches of a conditional statement has braces the other
branches should also have braces. This is documented in
Documentation/CodingStyle.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] hv: hv_util: move vmbus_open() to a later place
On Mon, Feb 2, 2015 at 12:35 PM, Dexuan Cui wrote: Before the line vmbus_open() returns, srv->util_cb can be already running and the variables, like util_fw_version, are needed by the srv->util_cb. A questions is why we do this for util only? Can callbacks of other devices be called before vmbus_open() returns? So we have to make sure the variables are initialized before the vmbus_open(). CC: "K. Y. Srinivasan" Reviewed-by: Vitaly Kuznetsov Signed-off-by: Dexuan Cui --- v2: This is a RESEND. I just added Vitaly's Reviewed-by. drivers/hv/hv_util.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c index 3b9c9ef..c5be773 100644 --- a/drivers/hv/hv_util.c +++ b/drivers/hv/hv_util.c @@ -340,12 +340,8 @@ static int util_probe(struct hv_device *dev, set_channel_read_state(dev->channel, false); - ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0, - srv->util_cb, dev->channel); - if (ret) - goto error; - hv_set_drvdata(dev, srv); + This seems unnecessary. /* * Based on the host; initialize the framework and * service version numbers we will negotiate. @@ -365,6 +361,11 @@ static int util_probe(struct hv_device *dev, hb_srv_version = HB_VERSION; } + ret = vmbus_open(dev->channel, 4 * PAGE_SIZE, 4 * PAGE_SIZE, NULL, 0, + srv->util_cb, dev->channel); + if (ret) + goto error; + return 0; error: -- 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 0/6] randomize kernel physical address and virtual address separately
On 02/01/15 at 05:13am, Andy Lutomirski wrote: > On Sun, Feb 1, 2015 at 12:10 AM, Baoquan He wrote: > > On 01/20/15 at 08:19pm, Andy Lutomirski wrote: > >> On 01/20/2015 07:37 PM, Baoquan He wrote: > >> > >> I have no idea what the #PF thing you're referring to is, but I have > >> code to implement a #PF handler in boot/compressed if it would be > >> helpful. It's two patches: > >> > >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed=89476ea6a2becbaee4f45c3b6689ff31b6aa959a > >> > >> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=sync_rand_seed=142d86921e6f271261584016fc8cfa5cdbf455ba > >> > >> You can't recover from a page fault in my version of this code, but that > >> would be straightforward to add. > >> > > Hi all, > > > > I used Andy's patch to setup idt and implement #PF handler before kernel > > decompression, and it works. Then a problem is encountered that when > > choose a position above 4G and decompress kernel there system will > > reboot to BIOS after kernel decompression. I use hlt command to position > > where the asm code will cause that reboot and found it happened after > > jumping when adjusted page table is loaded in arch/x86/kernel/head_64.S > > I applied this to Linus' tree today, and I get: > > early console in decompress_kernel > KASLR disabled by default... > > Decompressing Linux... > > XZ-compressed data is corrupt > > -- System halted > > If I comment out the output = 0x14000 line, then it boots. > > With gzip instead of XZ, it just gets stuck at Decompressing Linux... > > Presumably this is because 0x14000 is an invalid address in my VM. > I added more RAM, and I get a nice reboot loop. QEMU thinks that it's > a page fault causing a triple fault. Thanks a lot for help, Andy. Currently in boot/compressed/head_64.S, 6 page tables are used to build the identity mapping in 0~4G area, 1 page used for pgd table, 1 page used for pud table, and left 4 pgaes used for pmd table. So I added 4 more pages for pmd table, then it cover 0~8G area. So during kernel decompressing, if trying to reload kernel to be above 4G, physical memory have to be larger than 4G. So you can set output=0x1, then you only need 4.5G memory. Then if you add below 2 lines of code, you will see the output messgae from screen : "Booting the kernel." diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S index a468c0a..1c039a5 100644 --- a/arch/x86/kernel/head_64.S +++ b/arch/x86/kernel/head_64.S @@ -181,6 +181,10 @@ ENTRY(secondary_startup_64) movl$(X86_CR4_PAE | X86_CR4_PGE), %ecx movq%rcx, %cr4 +/*This is used to position where the kernel will reboot to bios*/ +1: hlt + jmp 1b + /* Setup early boot stage 4 level pagetables. */ addqphys_base(%rip), %rax movq%rax, %cr3 > > If I add in my IDT code and #PF handler, nothing changes. If I > re-enable relocations, I get: > > 32-bit relocation outside of kernel! Here is a code bug which is fixed by my posted patch 2/6: a bug that relocation can not be handled when kernel is loaded above 2G So now I use the debug patch in last mail to debug how to make kernel move to above 4G position and be decompressed there. So I just the comment out the handle_relocations() calling. Actually the debug patch can filter unncecessary interference. > > Can you post the whole set of patches you're using or a link to a git tree? I am creating a repo on git hub and push my patchset, then it can be got publicly. Will send it as soon as it's finished. Btw, I didn't try xz, just always bzImage. Thanks Baoquan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: PPC: Convert openpic lock to raw_spinlock
Ping?
On 22.01.2015 11:39, Bogdan Purcareata wrote:
This patch enables running intensive I/O workloads, e.g. netperf, in a guest
deployed on a RT host. It also enable guests to be SMP.
The openpic spinlock becomes a sleeping mutex on a RT system. This no longer
guarantees that EPR is atomic with exception delivery. The guest VCPU thread
fails due to a BUG_ON(preemptible()) when running netperf.
In order to make the kvmppc_mpic_set_epr() call safe on RT from non-atomic
context, convert the openpic lock to a raw_spinlock. A similar approach can
be seen for x86 platforms in the following commit [1].
Here are some comparative cyclitest measurements run inside a high priority RT
guest run on a RT host. The guest has 1 VCPU and the test has been run for 15
minutes. The guest runs ~750 hackbench processes as background stress.
spinlock raw_spinlock
Min latency (us) 4 4
Avg latency (us) 1519
Max latency (us) 7062
Due to the introduction of the raw_spinlock, guests with a high number of VCPUs
may induce great latencies on the underlying RT Linux system (e.g. cyclictest
reports latencies of ~15ms for guests with 24 VCPUs). This can be further
aggravated by sending a lot of external interrupts to the guest. A malicious app
can abuse this scenario, causing a DoS of the host Linux. Until the KVM openpic
code is refactored to use finer lock granularity, impose a limitation on the
number of VCPUs a guest can have when running on a PREEMPT_RT_FULL system with
KVM_MPIC emulation.
Sent against v3.14-rt branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
[1] https://lkml.org/lkml/2010/1/11/289
Signed-off-by: Bogdan Purcareata
[ add KVM_MAX_VCPUS limitation ]
Signed-off-by: Mihai Caraman
Reviewed-by: Scott Wood
---
arch/powerpc/include/asm/kvm_host.h | 6 +
arch/powerpc/kvm/mpic.c | 44 ++---
2 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 1eaea2d..5ae38c5 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -35,8 +35,14 @@
#include
#include
+#if defined(CONFIG_PREEMPT_RT_FULL) && defined(CONFIG_KVM_MPIC)
+/* Limit the number of vcpus due to in-kernel mpic concurrency */
+#define KVM_MAX_VCPUS 4
+#define KVM_MAX_VCORES 4
+#else
#define KVM_MAX_VCPUS NR_CPUS
#define KVM_MAX_VCORESNR_CPUS
+#endif
#define KVM_USER_MEM_SLOTS 32
#define KVM_MEM_SLOTS_NUM KVM_USER_MEM_SLOTS
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
index efbd996..b9802a3 100644
--- a/arch/powerpc/kvm/mpic.c
+++ b/arch/powerpc/kvm/mpic.c
@@ -194,7 +194,7 @@ struct openpic {
int num_mmio_regions;
gpa_t reg_base;
- spinlock_t lock;
+ raw_spinlock_t lock;
/* Behavior control */
struct fsl_mpic_info *fsl;
@@ -1105,9 +1105,9 @@ static int openpic_cpu_write_internal(void *opaque, gpa_t
addr,
mpic_irq_raise(opp, dst, ILR_INTTGT_INT);
}
- spin_unlock(>lock);
+ raw_spin_unlock(>lock);
kvm_notify_acked_irq(opp->kvm, 0, notify_eoi);
- spin_lock(>lock);
+ raw_spin_lock(>lock);
break;
}
@@ -1182,12 +1182,12 @@ void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu)
int cpu = vcpu->arch.irq_cpu_id;
unsigned long flags;
- spin_lock_irqsave(>lock, flags);
+ raw_spin_lock_irqsave(>lock, flags);
if ((opp->gcr & opp->mpic_mode_mask) == GCR_MODE_PROXY)
kvmppc_set_epr(vcpu, openpic_iack(opp, >dst[cpu], cpu));
- spin_unlock_irqrestore(>lock, flags);
+ raw_spin_unlock_irqrestore(>lock, flags);
}
static int openpic_cpu_read_internal(void *opaque, gpa_t addr,
@@ -1387,9 +1387,9 @@ static int kvm_mpic_read(struct kvm_io_device *this,
gpa_t addr,
return -EINVAL;
}
- spin_lock_irq(>lock);
+ raw_spin_lock_irq(>lock);
ret = kvm_mpic_read_internal(opp, addr - opp->reg_base, );
- spin_unlock_irq(>lock);
+ raw_spin_unlock_irq(>lock);
/*
* Technically only 32-bit accesses are allowed, but be nice to
@@ -1427,10 +1427,10 @@ static int kvm_mpic_write(struct kvm_io_device *this,
gpa_t addr,
return -EOPNOTSUPP;
}
- spin_lock_irq(>lock);
+ raw_spin_lock_irq(>lock);
ret = kvm_mpic_write_internal(opp, addr - opp->reg_base,
*(const u32 *)ptr);
- spin_unlock_irq(>lock);
+ raw_spin_unlock_irq(>lock);
pr_debug("%s: addr %llx ret %d val %x\n",
__func__, addr, ret, *(const u32 *)ptr);
@@ -1501,14 +1501,14 @@ static int access_reg(struct openpic *opp, gpa_t addr,
u32 *val, int type)
if (addr & 3)
Re: [PATCH 01/13] kdbus: add documentation
Hi Andy, On 01/29/2015 01:09 PM, Andy Lutomirski wrote: > On Jan 29, 2015 6:42 AM, "Daniel Mack" wrote: >> As we explained before, currently, D-Bus peers do collect the same >> information already if they need to have them, but they have to do deal >> with the inherit races in such cases. kdbus is closing the gap by >> optionally providing the same information along with each message, if >> requested. > > In all these discussions, no one ever gave a decent example use case. > If a process drops some privilege, it must close all fds it has that > captured its old privilege. This has nothing to do with kdbus. kdbus does not implement any new concept here but sticks to what SCM_CREDENTIALS does on SOL_SEQPACKET. An application can get a file-descriptor from socket() or socketpair() and freely pass it around between different tasks or threads, but messages will always have the credentials attached that are valid at *send* time. SO_PEERCREDS, however, still reports the connect-time credentials, and kdbus provides exactly the same semantics and both ways of retrieving information. > I agree that the design seems to have improved to a state of being at > least decent, One reason for that is your feedback. Thanks for that again! > It's an optional feature that will get used, non-optionally, thousands > of times on each boot, apparently. Keep in mind that it's also a > scalability problem because it takes locks. If it ever gets used > thousands of times per CPU on a big thousand-core machine, it's going > to suck, and you'll have backed yourself into a corner. That's right, but again - if an application wants to gather this kind of information about tasks it interacts with, it can do so today by looking at /proc or similar sources. Desktop machines do exactly that already, and the kernel code executed in such cases very much resembles that in metadata.c, and is certainly not cheaper. kdbus just makes such information more accessible when requested. Which information is collected is defined by bit-masks on both the sender and the receiver connection, and most applications will effectively only use a very limited set by default if they go through one of the more high-level libraries. Also, when metadata is collected, the code mostly takes temporary references on objects like PIDs, namespaces etc. Which operation would you consider particularly expensive? Thanks again, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [sched] [ INFO: suspicious RCU usage. ]
Hi, Fengguang, We already fixed that in f7b8a47da17c "sched: Remove lockdep check in sched_move_task()". В Вс, 01/02/2015 в 20:22 -0800, Fengguang Wu пишет: > Hi Kirill, > > FYI the RCU warning shows up since this commit, however there are > several other BUGs, so it's not necessarily a problem of this patch. > > commit eeb61e53ea19be0c4015b00b2e8b3b2185436f2b > Author: Kirill Tkhai > AuthorDate: Mon Oct 27 14:18:25 2014 +0400 > Commit: Ingo Molnar > CommitDate: Tue Oct 28 10:45:59 2014 +0100 > > sched: Fix race between task_group and sched_task_group > > The race may happen when somebody is changing task_group of a forking > task. > Child's cgroup is the same as parent's after dup_task_struct() (there just > memory copying). Also, cfs_rq and rt_rq are the same as parent's. > > But if parent changes its task_group before it's called > cgroup_post_fork(), > we do not reflect this situation on child. Child's cfs_rq and rt_rq remain > the same, while child's task_group changes in cgroup_post_fork(). > > To fix this we introduce fork() method, which calls sched_move_task() > directly. > This function changes sched_task_group on appropriate (also its logic has > no problem with freshly created tasks, so we shouldn't introduce something > special; we are able just to use it). > > Possibly, this decides the Burke Libbey's problem: > https://lkml.org/lkml/2014/10/24/456 > > Signed-off-by: Kirill Tkhai > Signed-off-by: Peter Zijlstra (Intel) > Cc: Linus Torvalds > Link: http://lkml.kernel.org/r/1414405105.19914.169.camel@tkhai > Signed-off-by: Ingo Molnar > > === > PARENT COMMIT NOT CLEAN. LOOK OUT FOR WRONG BISECT! > === > > Attached dmesg for the parent commit, too, to help confirm whether it is a > noise error. > > +++++ > || xfs-for-li | > eeb61e53ea | 28ff344e1d | > +++++ > | boot_successes | 0 | 0 > | 0 | > | boot_failures | 60 | 20 > | 11 | > | WARNING:at_include/linux/kref.h:#kobject_get() | 60 | 20 > | 11 | > | WARNING:at_fs/kernfs/dir.c:#kernfs_remove_by_name_ns() | 1 | 1 > | 1 | > | BUG:unable_to_handle_kernel| 59 | 20 > | 11 | > | Oops | 59 | 20 > | 11 | > | RIP:string | 1 | 1 > | 1 | > | Kernel_panic-not_syncing:Fatal_exception | 59 | 20 > | 11 | > | backtrace:platform_driver_unregister | 60 | 20 > | 11 | > | backtrace:init_mac80211_hwsim | 60 | 20 > | 11 | > | backtrace:kernel_init_freeable | 60 | 20 > | 11 | > | backtrace:bus_register | 1 | 1 > | 1 | > | backtrace:i2o_driver_init | 1 | 1 > | 1 | > | backtrace:i2o_iop_init | 1 | 1 > | 1 | > | INFO:trying_to_register_non-static_key | 59 | 18 > | 10 | > | RIP:mutex_lock_nested | 58 | 18 > | 10 | > | INFO:rcu_sched_detected_stalls_on_CPUs/tasks | 1 | > || > | INFO:task_blocked_for_more_than#seconds| 1 | > || > | INFO:lockdep_is_turned_off | 1 | > || > | RIP:native_apic_mem_write | 1 | > || > | RIP:rep_nop| 1 | > || > | Kernel_panic-not_syncing:hung_task:blocked_tasks | 1 | > || > | backtrace:ring_buffer_producer_thread | 1 | > || > | backtrace:watchdog | 1 | > || > | INFO:suspicious_RCU_usage | 0 | 20 > | 11 | > | WARNING:at_kernel/locking/lockdep.c:#__bfs() | 0 | 1 > || > | RIP:__bfs | 0
Re: [PATCH] can: janz-ican3: fix type missmatch in assignment
On 02/01/2015 09:34 AM, Nicholas Mc Guire wrote: > From: Nicholas Mc Guire > > return type of wait_for_completion_timeout is unsigned long not int, this > patch removes the type missmatch by moving the call into the condition. > > Signed-off-by: Nicholas Mc Guire Thanks, applied to can-next. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] mtd: avoid registering reboot notifier twice
On Mon, Feb 02, 2015 at 10:01:51AM +0100, Ricard Wanderlof wrote: > > > On 02/02/2015 12:07 AM, Brian Norris wrote: > > > > > > No driver should be calling mtd_device_parse_register() multiple times > > > on the same mtd_info. Under what context do you see this? What driver? > > arch/cris/arch-v32/drivers/axisflashmap.c > > Looking at it another way, why should it not be allowed, if the only > thing stopping it from working is Niklas' fix below? It severely breaks the way that normal MTD partition parsers work, for one. cmdlineparts could never be sanely applied here, for instance. > If there are multiple > ways a driver can acquire partitioning information, it is handy to be able > to do mtd_device_parse_register() several times, rather than collecting > all the partitioning information in one place and doing the call there, > which I suppose would be the alternative. It may be handy, but it breaks the abstraction that is established in most every other case, that partitions are determined by exactly one source: a single list from platform data, device tree, the kernel command line, or an on-flash parser (e.g., RedBoot, bcm47xxpart, etc.). > I've noted that mtd/nand/diskonchip.c does it too: > > mtd_device_register(mtd, NULL, 0); > if (!no_autopart) > mtd_device_register(mtd, parts, numparts); > > but this driver might be essentially deprecated, I don't know. Yeah, I just noticed that one too. TBH, I'm not sure the reboot notifier patch places that code in the best place anyway. There really is no central initialization code for the 'master' mtd_info struct, as this initialization is handled ad-hoc in every single MTD driver. It just happens that the partition parsing/registration function fit nicely as the one place that (almost) all MTD master devices got registered. But this just exposed yet another instance where my assumptions are challenged. There's so much legacy crap in MTD that sometimes I wonder why I even bother... Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] spi: tegra20-sflash: cleanup wait_for_completion return handling
On Monday 02 February 2015 02:38 PM, Nicholas Mc Guire wrote:
On Mon, 02 Feb 2015, Laxman Dewangan wrote:
+ if (WARN_ON(dma_timeout == 0)) {
dev_err(tsd->dev,
- "spi trasfer timeout, err %d\n", ret);
+ "spi trasfer timeout\n");
trasfer -> transfer.
overlooked that - sorry - will fix it up and resubmit.
Thanks, And possibly we will be able to merge two lines into single one
i.e. single line error message.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2 v2] spi: tegra20-slink: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already states "timeout" there is little point in
printing the 0 here as it just restates "timeout".
Signed-off-by: Nicholas Mc Guire
---
v2: typo fixed as suggested by Laxman Dewangan
This patch was only compile tested with tegra_defconfig
(implies CONFIG_SPI_TEGRA20_SLINK=y)
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-tegra20-slink.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 85c91f5..106afe1 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -811,6 +811,7 @@ static int tegra_slink_transfer_one(struct spi_master
*master,
{
struct tegra_slink_data *tspi = spi_master_get_devdata(master);
int ret;
+ unsigned long dma_timeout;
reinit_completion(>xfer_completion);
ret = tegra_slink_start_transfer_one(spi, xfer);
@@ -820,11 +821,10 @@ static int tegra_slink_transfer_one(struct spi_master
*master,
return ret;
}
- ret = wait_for_completion_timeout(>xfer_completion,
+ dma_timeout = wait_for_completion_timeout(>xfer_completion,
SLINK_DMA_TIMEOUT);
- if (WARN_ON(ret == 0)) {
- dev_err(tspi->dev,
- "spi trasfer timeout, err %d\n", ret);
+ if (WARN_ON(dma_timeout == 0)) {
+ dev_err(tspi->dev, "spi transfer timeout\n");
return -EIO;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2 v2] spi: tegra20-sflash: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already states "timeout" there
is little point in printing the 0 here.
Signed-off-by: Nicholas Mc Guire
---
v2: typo fixed as suggested by Laxman Dewangan
This patch was only compile tested with tegra_defconfig
(implies CONFIG_SPI_TEGRA20_SFLASH=y)
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-tegra20-sflash.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index b6558bb..48a7c74 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -323,6 +323,7 @@ static int tegra_sflash_transfer_one_message(struct
spi_master *master,
struct spi_transfer *xfer;
struct spi_device *spi = msg->spi;
int ret;
+ unsigned long dma_timeout;
msg->status = 0;
msg->actual_length = 0;
@@ -337,11 +338,11 @@ static int tegra_sflash_transfer_one_message(struct
spi_master *master,
goto exit;
}
is_first_msg = false;
- ret = wait_for_completion_timeout(>xfer_completion,
+ dma_timeout = wait_for_completion_timeout(>xfer_completion,
SPI_DMA_TIMEOUT);
- if (WARN_ON(ret == 0)) {
+ if (WARN_ON(dma_timeout == 0)) {
dev_err(tsd->dev,
- "spi trasfer timeout, err %d\n", ret);
+ "spi transfer timeout\n");
ret = -EIO;
goto exit;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/42] perf record: Add --index option for building index table
On Mon, Feb 02, 2015 at 10:34:50AM +0200, Adrian Hunter wrote:
SNIP
> > but how about bump up the header version for this feature? ;-)
> >
> > currently it's:
> >
> > struct perf_file_header {
> > u64 magic;
> > u64 size;
> > u64 attr_size;
> > struct perf_file_sectionattrs;
> > struct perf_file_sectiondata;
> > /* event_types is ignored */
> > struct perf_file_sectionevent_types;
> > DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> > };
> >
> >
> > - we already store attrs as a FEATURE so we could omit that
> > - your patch stores only synthesized data into 'data' section (-1 idx)
> > this could be stored into separate file and get merged with the rest
> > - new header version would have 'features' section, so the features
> > position wouldnt depend on the 'data' end as of now and we could
> > easily store after all data is merged:
> >
> > struct perf_file_header {
> > u64 magic;
> > u64 size;
> > u64 attr_size;
> > struct perf_file_sectionfeatures;
> > DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> > };
> >
> >
> > thoughts?
>
> How come the features are being written before the sample data anyway?
> I would have expected:
> - write the data (update the index in memory)
> - write the features (including index)
>
I think the problem is that the only way how to get features offset
right now is via perf_file_header::data.offset + perf_file_headerdata.size,
and we still use this section to carry 'sythesized' data, so it needs
to have correct size.
I guess we could workaround that by storing the 'perf_file_header::data'
as the last data section. That would require to treat it the same way as
all other data sections, but we could keep current header layout.
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] spi: tegra114: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already explicitly states "timeout" there
is little point in printing the 0 here which also just says "timeout".
Signed-off-by: Nicholas Mc Guire
---
v2: typo fixed as suggested by Laxman Dewangan
This patch was only compile tested with tegra_defconfig
(implies CONFIG_SPI_TEGRA114=y)
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-tegra114.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 73779ce..0dfb422 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -807,6 +807,7 @@ static int tegra_spi_transfer_one_message(struct spi_master
*master,
struct spi_transfer *xfer;
struct spi_device *spi = msg->spi;
int ret;
+ unsigned long dma_timeout;
bool skip = false;
msg->status = 0;
@@ -833,11 +834,10 @@ static int tegra_spi_transfer_one_message(struct
spi_master *master,
}
is_first_msg = false;
- ret = wait_for_completion_timeout(>xfer_completion,
- SPI_DMA_TIMEOUT);
- if (WARN_ON(ret == 0)) {
- dev_err(tspi->dev,
- "spi trasfer timeout, err %d\n", ret);
+ dma_timeout = wait_for_completion_timeout(
+ >xfer_completion, SPI_DMA_TIMEOUT);
+ if (WARN_ON(dma_timeout == 0)) {
+ dev_err(tspi->dev, "spi transfer timeout\n");
ret = -EIO;
goto complete_xfer;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Chanwoo, On 02/02/15 07:04, Chanwoo Choi wrote: > Hi Roger, > > On 01/30/2015 11:05 PM, Roger Quadros wrote: >> Hi, >> >> On 30/01/15 13:04, Roger Quadros wrote: >>> Felipe & Chanwoo, >>> >>> On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is "USB-Host" and not "USB-HOST" as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of "USB-HOST" to "USB-Host". Signed-off-by: Roger Quadros Reviewed-by: Felipe Balbi Acked-by: Felipe Balbi >>> >>> This patch has no dependency to the rest so can be picked up as soon as >>> possible. >>> >>> Do you think it is better to go via the USB tree? >>> If yes then Chanwoo, can you please Ack this one? Thanks. >>> >>> This would mean that only the first patch needs to go through extcon tree >>> as Tony >>> will pick the rest. >> >> Hold on. Let's first decide what we really want to go ahead with >> "USB-Host" or "USB-HOST". > > Currently, extcon driver have used the specific cable name(USB-Host or > USB-HOST) > without any standard way. So, I have plan to define common cable name in > extcon > header file by using capital letter. OK. In that case, this patch is not required. I will resend patch 1 with cable name corrected to "USB-HOST". cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the net-next tree with the net tree
Le 02/02/2015 03:33, Stephen Rothwell a écrit :
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/vxlan.c between commit 33564bbb2cf1 ("vxlan: setup the
right link netns in newlink hdlr") from the net tree and commit
ac5132d1a03f ("vxlan: Only bind to sockets with compatible flags
enabled") from the net-next tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Acked-by: Nicolas Dichtel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] spi: tegra20-sflash: cleanup wait_for_completion return handling
On Mon, 02 Feb 2015, Laxman Dewangan wrote:
> On Sunday 01 February 2015 06:30 PM, Nicholas Mc Guire wrote:
>> return type of wait_for_completion_timeout is unsigned long not int, this
>> patch adds an appropriate variable and fixes up the assignment.
>> As the string in dev_err already states "timeout" there
>> is little point in printing the 0 here.
>>
>> Signed-off-by: Nicholas Mc Guire
>
> Looks good to me. Thanks for fixing this.
> I think it is good if we fix the typo here also.
>
> Acked-by: Laxman Dewangan
>
>>
>> +if (WARN_ON(dma_timeout == 0)) {
>> dev_err(tsd->dev,
>> -"spi trasfer timeout, err %d\n", ret);
>> +"spi trasfer timeout\n");
>
> trasfer -> transfer.
>
>
overlooked that - sorry - will fix it up and resubmit.
thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension)
On 01/30/2015 05:40 PM, Greg KH wrote: On Fri, Jan 30, 2015 at 09:55:30AM +0100, Jacek Anaszewski wrote: Hi Pavel, On 01/29/2015 10:14 PM, Pavel Machek wrote: Hi! + - flash_fault - list of flash faults that may have occurred: + * led-over-voltage - flash controller voltage to the flash LED + has exceededthe limit specific to the flash controller + * flash-timeout-exceeded - the flash strobe was still on when + the timeout set by the user has expired; not all flash + controllers may set this in all such conditions + * controller-over-temperature - the flash controller has + overheated + * controller-short-circuit - the short circuit protection + of the flash controller has been triggered + * led-power-supply-over-current - current in the LED power + supply has exceeded the limit specific to the flash + controller + * indicator-led-fault - the flash controller has detected + a short or open circuit condition on the indicator LED + * led-under-voltage - flash controller voltage to the flash + LED has been below the minimum limit specific to + the flash + * controller-under-voltage - the input voltage of the flash + controller is below the limit under which strobing the + flash at full current will not be possible. The condition + persists until this flag is no longer set + * led-over-temperature - the temperature of the LED has exceeded + its allowed upper limit + + Flash faults are cleared, if possible, by reading the attribute. That's bad. Now you can no longer present flash_fault file as readable to non-root users, and grep -ri foo /sys will interfere with your camera application. Bad interface, just fix it. In my opinion it isn't crucial for the user to be aware of the fact that some non-persistent fault happened right after strobing the flash (e.g. over temperature). I cannot see anything harmful in the situation when someone does grep on /sys and clears non-persistent fault on a flash LED device. So why export the faults at all? Faults may prevent strobing the flash in case of some devices. The example of such a device is ADP1663 (drivers/media/i2c/adp1653.c). This driver reads the faults before strobing the flash and if a fault preventing strobing has occurred it returns -EBUSY. If this driver was made a LED Flash class driver, then it would expose flash_faults attribute. The driver would probably need redesigning - checking the faults before strobing would have to be avoided and it should be left to the userspace. That's fine, but Pavel's point is that you shouldn't "clear a fault" by reading a sysfs file as you don't control who reads all sysfs files (hint, libudev might cache all attributes when they are found / change, which could prevent anyone else from seeing that fault.) So please fix this, make a write to clear a fault or some other such explicit action, not a simple read. That's not an acceptable api. I am aware what Pavel'a point was, I just presented the arguments justifying existence of the flash_faults attribute at all. In my opinion flash_faults attribute should report the current state of the device. For the devices which clear the faults on I2C readout the faults read would have to be cached in the driver, until they are explicitly cleared, to keep the sysfs interface consistent. Nonetheless, there can be also devices which don't require clearing the faults - they are reported only when the actual condition occurs, e.g. over temperature or under voltage. When the related value gets back to the acceptable level the fault is no longer reported by the device. In this case some faults will remain unnoticed by the user space. This is the argument in favour of my statement that caching the faults does not make a sense and is not crucial. The user's vital interest is to know whether the flash LED is operational right before strobing. Since we cannot guarantee reporting all the faults that occurred for all possible flash LED devices, the only sensible solution is to report only the currently valid fault. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spi: tegra114: cleanup wait_for_completion return handling
On Sunday 01 February 2015 07:25 PM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already explicitly states "timeout" there
is little point in printing the 0 here which also just says "timeout".
Looks good to me. Thanks for fixing this.
I think it is good if we fix the typo here also.
Acked-by: Laxman Dewangan
+ if (WARN_ON(dma_timeout == 0)) {
+ dev_err(tspi->dev, "spi trasfer timeout\n");
trasfer->transfer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On Mon, Feb 02, 2015 at 09:59:16AM +0100, Paolo Bonzini wrote:
>
>
> On 02/02/2015 08:45, David Gibson wrote:
> > + case H_LOGICAL_CI_LOAD:
> > + ret = kvmppc_h_logical_ci_load(vcpu);
> > + if (ret == H_TOO_HARD) {
> > + printk("Punting H_LOGICAL_CI_LOAD\n");
> > + return RESUME_HOST;
> > + }
> > + break;
> > + case H_LOGICAL_CI_STORE:
> > + ret = kvmppc_h_logical_ci_store(vcpu);
> > + if (ret == H_TOO_HARD) {
> > + printk("Punting H_LOGICAL_CI_STORE\n");
> > + return RESUME_HOST;
> > + }
> > + break;
> > case H_SET_MODE:
> > ret = kvmppc_h_set_mode(vcpu, kvmppc_get_gpr(vcpu, 4),
> > kvmppc_get_gpr(vcpu, 5),
>
> KERN_DEBUG I guess? Or even no printk at all perhaps.
Oh, bugger, removed most of the debug code, but not all of it.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
pgpm80fmKY_Fo.pgp
Description: PGP signature
Re: [PATCH 2/2] spi: tegra20-slink: cleanup wait_for_completion return handling
On Sunday 01 February 2015 06:32 PM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already states "timeout" there is little point in
printing the 0 here as it just restates "timeout".
Looks good to me. Thanks for fixing this.
I think it is good if we fix the typo here also.
Acked-by: Laxman Dewangan
- if (WARN_ON(ret == 0)) {
- dev_err(tspi->dev,
- "spi trasfer timeout, err %d\n", ret);
+ if (WARN_ON(dma_timeout == 0)) {
+ dev_err(tspi->dev, "spi trasfer timeout\n");
trasfer->transfer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] spi: tegra20-sflash: cleanup wait_for_completion return handling
On Sunday 01 February 2015 06:30 PM, Nicholas Mc Guire wrote:
return type of wait_for_completion_timeout is unsigned long not int, this
patch adds an appropriate variable and fixes up the assignment.
As the string in dev_err already states "timeout" there
is little point in printing the 0 here.
Signed-off-by: Nicholas Mc Guire
Looks good to me. Thanks for fixing this.
I think it is good if we fix the typo here also.
Acked-by: Laxman Dewangan
+ if (WARN_ON(dma_timeout == 0)) {
dev_err(tsd->dev,
- "spi trasfer timeout, err %d\n", ret);
+ "spi trasfer timeout\n");
trasfer -> transfer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: avoid registering reboot notifier twice
> On 02/02/2015 12:07 AM, Brian Norris wrote:
> >
> > No driver should be calling mtd_device_parse_register() multiple times
> > on the same mtd_info. Under what context do you see this? What driver?
> arch/cris/arch-v32/drivers/axisflashmap.c
Looking at it another way, why should it not be allowed, if the only
thing stopping it from working is Niklas' fix below? If there are multiple
ways a driver can acquire partitioning information, it is handy to be able
to do mtd_device_parse_register() several times, rather than collecting
all the partitioning information in one place and doing the call there,
which I suppose would be the alternative.
I've noted that mtd/nand/diskonchip.c does it too:
mtd_device_register(mtd, NULL, 0);
if (!no_autopart)
mtd_device_register(mtd, parts, numparts);
but this driver might be essentially deprecated, I don't know.
> >> Signed-off-by: Niklas Cassel
> >> ---
> >> drivers/mtd/mtdcore.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> >> index de79576..98efc1e 100644
> >> --- a/drivers/mtd/mtdcore.c
> >> +++ b/drivers/mtd/mtdcore.c
> >> @@ -556,7 +556,7 @@ int mtd_device_parse_register(struct mtd_info *mtd,
> >> const char * const *types,
> >>err = -ENODEV;
> >>}
> >>
> >> - if (mtd->_reboot) {
> >> + if (mtd->_reboot && !mtd->reboot_notifier.notifier_call) {
> >>mtd->reboot_notifier.notifier_call = mtd_reboot_notifier;
> >>register_reboot_notifier(>reboot_notifier);
> >>}
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Swedenwww.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: avoid registering reboot notifier twice
On Mon, Feb 02, 2015 at 08:08:17AM +0100, Niklas Cassel wrote: > > On 02/02/2015 12:07 AM, Brian Norris wrote: > > On Sun, Feb 01, 2015 at 02:08:50AM +0100, Niklas Cassel wrote: > >> Calling mtd_device_parse_register with the same mtd_info > >> (e.g. registering several partitions on a single device) > >> would add the same reboot notifier twice, causing an > >> infinte loop in notifier_chain_register during boot up. > > No driver should be calling mtd_device_parse_register() multiple times > > on the same mtd_info. Under what context do you see this? What driver? > arch/cris/arch-v32/drivers/axisflashmap.c Yikes, that file is ugly! I am reminded of (one of the many reasons) why ARM ditched board files. > It calls mtd_device_register for different partitions on same device using > the same mtd_info. > > What do you suggest this driver should do instead? Well, it would be really great if it could aggregate the partitions it wants all into one list (array) and pass that to the MTD core all at once. It also looks like this should have all been written as an MTD partition parser (struct mtd_part_parser), and some additional platform data to select the default maps if they aren't found on the flash. But there are a lot of odd cases in that code that make it difficult to do now. I'm tempted to suggest just calling add_mtd_partitions() directly, since you couldn't possibly be making good use out of the "parse" part of the mtd_device_parse_register() function. If you were, you'd get a ton of duplicate partitions, since the parser (e.g., cmdlinepart) would get called a bunch of times, and it would add the same partitions for *every* time you're calling mtd_device_register(). [1] But (as noted in mtdcore.h) add_mtd_partitions() is really private to the core MTD files. So... any chance you can rewrite this as an MTD parser + platform data? Also, now that you point this issue out, I see that one other driver might have the same problem as you -- diskonchip.c. It has a dubiously-formed partition registration setup. I'm tempted to remove its first mtd_device_register() and drop its 'no_autopart' parameter and see if anyone complains. If we have enough problems with this code, though, I might rip out some of: 3efe41be224c mtd: implement common reboot notifier boilerplate until I can find a better way. Brian [1] This suggests that your code is quite broken already, but just happens to work for the particular cases that are hard-coded here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 00/20] power_supply: Allow safe usage of power supply
Am Freitag, 30. Januar 2015, 15:47:38 schrieb Krzysztof Kozlowski: > Hi, > > The patchset changes power supply API and drivers implementing > power supply class. > > > TLDR for driver and subsystem maintainers > = > Two patches of patchset change power_supply_register() function so in > the same time they touch all drivers. I am kindly asking for acks, > review and help in testing. > > Please look at: > - patch 2: power_supply: Move run-time configuration to separate structure > - patch 11: power_supply: Change ownership from driver to core > > These are huge. Patches 2 and 11 are Reviewed-By: Marc Dietrich # for the nvec part. Thanks! Marc signature.asc Description: This is a digitally signed message part.
man-pages-3.79 is released
Gidday, The Linux man-pages maintainer proudly announces: man-pages-3.79 - man pages for Linux Tarball download: http://www.kernel.org/doc/man-pages/download.html Git repository: https://git.kernel.org/cgit/docs/man-pages/man-pages.git/ Online changelog: http://man7.org/linux/man-pages/changelog.html#release_3.79 A short summary of the release is blogged at: http://linux-man-pages.blogspot.com/2015/09/man-pages-379-is-released.html A selection of changes in this release that may be interesting for readers of this list is shown below. Cheers, Michael Changes in man-pages-3.79 New and rewritten pages --- getrandom.2 Heinrich Schuchardt, Theodore T'so, Michael Kerrisk New page documenting getrandom(2) Kernel 3.17 introduces a new system call getrandom(2). kexec_load.2 Vivek Goyal, Michael Kerrisk Add documentation of kexec_file_load(2) Michael Kerrisk, Vivek Goyal Rewrite and extend documentation of kexec_load(). Changes to individual pages --- socket.2 Stephan Mueller document AF_ALG Add a reference to the AF_ALG protocol accessible via socket(2). signal.7 Michael Kerrisk Add getrandom(2) to list of restartable system calls Michael Kerrisk Add F_OFD_SETLKW to list of restartable operations -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvmppc: Implement H_LOGICAL_CI_{LOAD,STORE} in KVM
On 02/02/2015 08:45, David Gibson wrote:
> + case H_LOGICAL_CI_LOAD:
> + ret = kvmppc_h_logical_ci_load(vcpu);
> + if (ret == H_TOO_HARD) {
> + printk("Punting H_LOGICAL_CI_LOAD\n");
> + return RESUME_HOST;
> + }
> + break;
> + case H_LOGICAL_CI_STORE:
> + ret = kvmppc_h_logical_ci_store(vcpu);
> + if (ret == H_TOO_HARD) {
> + printk("Punting H_LOGICAL_CI_STORE\n");
> + return RESUME_HOST;
> + }
> + break;
> case H_SET_MODE:
> ret = kvmppc_h_set_mode(vcpu, kvmppc_get_gpr(vcpu, 4),
> kvmppc_get_gpr(vcpu, 5),
KERN_DEBUG I guess? Or even no printk at all perhaps.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] cpuidle/powernv: Read target_residency value of idle states from DT if available
On 02/02/2015 12:09 PM, Michael Ellerman wrote: > On Mon, 2015-02-02 at 10:40 +0530, Preeti U Murthy wrote: >> The device tree now exposes the residency values for different idle states. >> Read >> these values instead of calculating residency from the latency values. The >> values >> exposed in the DT are validated for optimal power efficiency. However to >> maintain >> compatibility with the older firmware code which does not expose residency >> values, use default values as a fallback mechanism. While at it, use better >> APIs to parse the powermgmt device tree node so as to avoid endianness >> transformation. >> >> Signed-off-by: Preeti U Murthy >> --- >> Changes from V2: https://lkml.org/lkml/2015/1/27/1054 >> 1. Used APIs to eliminate endianness transformation > > Hi Preeti, > > I thought I was pretty clear when I said you should do that as a follow-up > patch. > > This is now doing too many things, it's not a single logical change, and it's > touching code in arch/powerpc and the driver. Which means neither I nor Rafael > can easily merge it. > > So please go back to the v2 you had. And then do the > of_property_count_u32_elems() > changes as separate patches. Yeah I apologize for this; going back to the conversation we had, I realize that I completely overlooked the part where you suggested it as a second patch. Sorry for the inconvenience. Rafael, please ignore the versions sent so far. I shall send out two patches that are logically separated. V2 of this patch that you were requested to pick up needs some more fixes; the patch was not freeing the dynamically allocated data after populating the cpufreq table. Ill fix all of these in the next posting. Thanks Regards Preeti U Murthy > > cheers > > > ___ > Linuxppc-dev mailing list > linuxppc-...@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 2/5] mfd: AXP20x: Add bindings documentation
On Sat, 31 Jan 2015, Chen-Yu Tsai wrote:
> Hi Lee,
>
> On Thu, Jan 22, 2015 at 5:02 PM, Lee Jones wrote:
> > On Thu, 22 Jan 2015, Chen-Yu Tsai wrote:
> >
> >> From: Carlo Caione
> >>
> >> Bindings documentation for the AXP20x driver. In this file also
> >> sub-nodes are documented.
> >>
> >> Signed-off-by: Carlo Caione
> >> Acked-by: Maxime Ripard
> >> [w...@csie.org: clarify interrupt source for the axp PMIC]
> >> [w...@csie.org: explain dcdc-workmode in detail and trim lines to 80 chars]
> >> [w...@csie.org: make regulator supplies optional if using unregulated
> >> input]
> >> [w...@csie.org: use cubieboard2 regulator nodes as example]
> >> [w...@csie.org: change dcdc-workmode to dcdc-workmode-pwm boolean property]
> >> [w...@csie.org: use clock-frequency for dcdc regulator work frequency]
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> Documentation/devicetree/bindings/mfd/axp20x.txt | 102
> >> +++
> >> 1 file changed, 102 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
> >
> > This looks okay to me now.
> >
> > If Mark is happy with the remainder, I'll merge this.
>
> So Mark is not happy with this actually, for a few reasons:
>
> 1. The driver was already merged a couple versions back, and
>we have been using the dcdc-freq binding.
>
> 2. Furthermore, the dcdc-freq binding has nothing to do with
>the common clock framework. Using the clock-frequencies
>binding implies it does.
>
> 3. The change from a integer value to a boolean flag for
>dcdc-mode makes it less capable, i.e. the kernel can't
>just accept the current state of the hardware, which
>should be a valid option for regulators to not screw
>up the system accidentally.
>
> Any chance you could merge the previous version (v8)?
You'll have to re-send it as v10 and obtain Acks in the normal way.
> > For my own reference:
> > Acked-by: Lee Jones
> >
> >> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
> >> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> >> new file mode 100644
> >> index ..c3c80db242c7
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> >> @@ -0,0 +1,102 @@
> >> +AXP202/AXP209 device tree bindings
> >> +
> >> +The axp20x family current members :
> >> +axp202 (X-Powers)
> >> +axp209 (X-Powers)
> >> +
> >> +Required properties:
> >> +- compatible: "x-powers,axp202" or "x-powers,axp209"
> >> +- reg: The I2C slave address for the AXP chip
> >> +- interrupt-parent: The parent interrupt controller
> >> +- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
> >> +- interrupt-controller: axp20x has its own internal IRQs
> >> +- #interrupt-cells: Should be set to 1
> >> +- regulators: A node that houses a sub-node for each regulator. The
> >> regulators
> >> + are bound using their name as listed here: dcdc2, dcdc3, ldo1,
> >> + ldo2, ldo3, ldo4, ldo5. The bindings details of individual
> >> + regulator device can be found in:
> >> + Documentation/devicetree/bindings/regulator/regulator.txt with
> >> + the exception of x-powers,dcdc-freq. Regulators not used should
> >> + still be listed for completeness and that the regulator
> >> subsystem
> >> + properly registers them.
> >> +
> >> +Optional properties:
> >> +- regulator supplies - may be omitted if inputs are unregulated, such as
> >> using
> >> +the IPSOUT output from the PMIC
> >> + - acin-supply: The input supply for LDO1
> >> + - vin2-supply: The input supply for DCDC2
> >> + - vin3-supply: The input supply for DCDC3
> >> + - ldo24in-supply: The input supply for LDO2, LDO4
> >> + - ldo3in-supply: The input supply for LDO3
> >> + - ldo5in-supply: The input supply for LDO5
> >> +
> >> +Optional properties for regulators node:
> >> +- clock-frequency: defines the work frequency of DC-DC regulators
> >> +(range: 750kHz - 1875kHz). Default: 1.5MHz
> >> +
> >> +Optional properties for DCDC regulators:
> >> +- x-powers,dcdc-workmode-pwm: Force the DCDC regulators to run in PWM mode
> >> + The DCDC regulators rormally work in a mixed
> >> + PWM/PFM mode, using PFM under light loads and
> >> + switching to PWM for heavier loads. Forcing
> >> + PWM mode trades efficiency under light loads
> >> + for lower output noise. This probably makes
> >> + sense for HiFi audio related applications that
> >> + aren't battery constrained.
> >> +
> >> +Example:
> >> +
> >> +axp209: pmic@34 {
> >> + compatible = "x-powers,axp209";
> >> + reg = <0x34>;
> >> + interrupt-parent = <_intc>;
> >> + interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> >> + interrupt-controller;
> >> + #interrupt-cells = <1>;
> >> +
> >> +
Re: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A
> do you have reviewed this patchset?
Yes, but ...
a) You only sent it 7 working days ago -- give me a chance
b) We are already at -rc7, so I have stopped accepting patches
c) I currently have my head buried under a tonne of my own work
... so please don't nag -- you're beginning to sound like my Mrs! ;)
> On 01/22/2015 03:30 PM, micky_ch...@realsil.com.cn wrote:
> > From: Micky Ching
> >
> > add support for new chip rts524A.
> >
> > Signed-off-by: Micky Ching
> > ---
> > drivers/mfd/rts5249.c| 186
> > ---
> > drivers/mfd/rtsx_pcr.c | 25 +-
> > drivers/mfd/rtsx_pcr.h | 7 ++
> > include/linux/mfd/rtsx_pci.h | 125 -
> > 4 files changed, 310 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
> > index 3977946..97dde92 100644
> > --- a/drivers/mfd/rts5249.c
> > +++ b/drivers/mfd/rts5249.c
> > @@ -65,15 +65,17 @@ static void rts5249_fill_driving(struct rtsx_pcr *pcr,
> > u8 voltage)
> > 0xFF, driving[drive_sel][2]);
> > }
> >
> > -static void rts5249_fetch_vendor_settings(struct rtsx_pcr *pcr)
> > +static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr *pcr)
> > {
> > u32 reg;
> >
> > rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, );
> > dev_dbg(&(pcr->pci->dev), "Cfg 0x%x: 0x%x\n", PCR_SETTING_REG1, reg);
> >
> > - if (!rtsx_vendor_setting_valid(reg))
> > + if (!rtsx_vendor_setting_valid(reg)) {
> > + pcr_dbg(pcr, "skip fetch vendor setting\n");
> > return;
> > + }
> >
> > pcr->aspm_en = rtsx_reg_to_aspm(reg);
> > pcr->sd30_drive_sel_1v8 = rtsx_reg_to_sd30_drive_sel_1v8(reg);
> > @@ -87,15 +89,21 @@ static void rts5249_fetch_vendor_settings(struct
> > rtsx_pcr *pcr)
> > pcr->flags |= PCR_REVERSE_SOCKET;
> > }
> >
> > -static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
> > +static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
> > {
> > /* Set relink_time to 0 */
> > rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
> > rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 2, 0xFF, 0);
> > rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
> >
> > - if (pm_state == HOST_ENTER_S3)
> > - rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
> > + if (pm_state == HOST_ENTER_S3) {
> > + if (PCI_PID(pcr) == 0x524A)
> > + rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
> > + D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
> > + else if (PCI_PID(pcr) == 0x5249)
> > + rtsx_pci_write_register(pcr, PM_CTRL3,
> > + D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
> > + }
> >
> > rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
> > }
> > @@ -104,6 +112,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
> > {
> > rtsx_pci_init_cmd(pcr);
> >
> > + /* Rest L1SUB Config */
> > + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, L1SUB_CONFIG3, 0xFF, 0x00);
> > /* Configure GPIO as output */
> > rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
> > /* Reset ASPM state to default value */
> > @@ -189,27 +199,27 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
> > PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12);
> > }
> >
> > -static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
> > +static int rtsx_base_turn_on_led(struct rtsx_pcr *pcr)
> > {
> > return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
> > }
> >
> > -static int rts5249_turn_off_led(struct rtsx_pcr *pcr)
> > +static int rtsx_base_turn_off_led(struct rtsx_pcr *pcr)
> > {
> > return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
> > }
> >
> > -static int rts5249_enable_auto_blink(struct rtsx_pcr *pcr)
> > +static int rtsx_base_enable_auto_blink(struct rtsx_pcr *pcr)
> > {
> > return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
> > }
> >
> > -static int rts5249_disable_auto_blink(struct rtsx_pcr *pcr)
> > +static int rtsx_base_disable_auto_blink(struct rtsx_pcr *pcr)
> > {
> > return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
> > }
> >
> > -static int rts5249_card_power_on(struct rtsx_pcr *pcr, int card)
> > +static int rtsx_base_card_power_on(struct rtsx_pcr *pcr, int card)
> > {
> > int err;
> >
> > @@ -236,7 +246,7 @@ static int rts5249_card_power_on(struct rtsx_pcr *pcr,
> > int card)
> > return 0;
> > }
> >
> > -static int rts5249_card_power_off(struct rtsx_pcr *pcr, int card)
> > +static int rtsx_base_card_power_off(struct rtsx_pcr *pcr, int card)
> > {
> > rtsx_pci_init_cmd(pcr);
> > rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
> > @@ -246,22 +256,31 @@ static int rts5249_card_power_off(struct rtsx_pcr
> > *pcr, int card)
> > return
linux-next: Tree for Feb 2
Hi all, Changes since 20150130: The net-next tree gained conflicts against the net tree. The spi tree lost its build failure. The kvm tree gained conflicts against Linus' tree. The target-updates tree gained a conflict against Linus' tree. The akpm-current tree gained a conflict against the fsl tree. Non-merge commits (relative to Linus' tree): 6831 6851 files changed, 276792 insertions(+), 157095 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 206 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (00845eb968ea sched: don't cause task state changes in nested sleep debugging) Merging fixes/master (b94d525e58dc Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging kbuild-current/rc-fixes (a16c5f99a28c kbuild: Fix removal of the debian/ directory) Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4) Merging arm-current/fixes (fba289054f24 ARM: 8298/1: ARM_KERNMEM_PERMS only works with MMU enabled) Merging m68k-current/for-linus (f27bd5bfeda5 m68k: Wire up execveat) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (31345e1a071e powerpc/pci: Remove unused force_32bit_msi quirk) Merging powerpc-merge-mpe/fixes (c59c961ca511 Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging sparc/master (66d0f7ec9f10 sparc32: destroy_context() and switch_mm() needs to disable interrupts.) Merging net/master (0d32ef8cef9a net: sched: fix panic in rate estimators) Merging ipsec/master (59343cd7c480 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (4161b4505f16 ALSA: ak411x: Fix stall in work callback) Merging pci-current/for-linus (19c5392eb1c1 PCI: designware: Reject MSI-X IRQs) Merging wireless-drivers/master (e3f31175a3ee ath9k: fix race condition in irq processing during hardware reset) Merging driver-core.current/driver-core-linus (26bc420b59a3 Linux 3.19-rc6) Merging tty.current/tty-linus (ec6f34e5b552 Linux 3.19-rc5) Merging usb.current/usb-linus (54eb4cd46542 Merge tag 'fixes-for-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus) Merging usb-gadget-fixes/fixes (0df8fc37f6e4 usb: phy: never defer probe in non-OF case) Merging usb-serial-fixes/usb-linus (a6f0331236fa USB: cp210x: add ID for RUGGEDCOM USB Serial Console) Merging staging.current/staging-linus (41c9e95d641a MAINTAINERS: add Android driver entries) Merging char-misc.current/char-misc-linus (26713c812313 drivers/Kconfig: remove duplicate entry for soc) Merging input-current/for-linus (47c1ffb2b6b6 Input: elantech - add more Fujtisu notebooks to force crc_enabled) Merging crypto-current/master (3e14dcf7cb80 crypto: add missing crypto module aliases) Merging ide/master (f96fe225677b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging devicetree-current/devicetree/merge (6b1271de3723 of/unittest: Overlays with sub-devices tests) Merging rr-fixes/fixes (d5db139ab376 module: make module_refcount() a signed integer.) Merging vfio-fixes/for-linus (7c2e211f3c95 vfio-pci: Fix the check on pci device type in vfio_pci_probe()) Merging kselftest-fixes/fixes (f5db310d77ef selftests/vm: fix link error for transhuge-stress test) Merging drm-intel-fixes/for-linux-next-fixes (6b96d705f3cf drm/i915: BDW Fix Halo PCI IDs
Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug
On 31/01/15 10:21, Daniel Lezcano wrote:
On 01/31/2015 02:08 AM, Stephen Boyd wrote:
Kept meaning to get back to this thread. Have you resolved it?
On 10/29/14 03:38, Marcin Jabrzyk wrote:
So I've tried this patch, it resolves one problem but introduces also
new ones. As expected the BUG warning is not showing after applying
this patch but there are some interesting side effects.
Well that's half good news.
I was looking on /proc/interrupts output. IRQ for CPU0 have "MCT" name
and IRQ for CPU1 has unexpectedly no name at all.
This is pretty confusing. I don't see how the patch could cause this to
happen.
After making hotplug cycle of CPU1 I've observed that IRQs attached
originally for that CPU are generating on really low count and not in
order with IRQ for CPU0.
What's more the interrupt for CPU1 is showing to me as being counted
for both CPUs, so it's probably not being attached to CPU1.
yeah. Can you give the output of /proc/timer_list in addition to
/proc/interrupts? It may give some hints on what's going on. It may also
be interesting to see if irq_force_affinity() is failing. Please check
the return value and print an error
Hi Stephen, Marcin,
can you have a look if the patch [1] fixes this issue ?
-- Daniel
[1] https://lkml.org/lkml/2015/1/30/423
Hi Daniel,
I've checked this patch on the board that have problems and it fixes
this issue completely. Everything looks fine after power cycle of the CPU.
Best regards,
Marcin Jabrzyk
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 1800053b4644..3c4538e26731 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
{
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+int ret;
mevt = container_of(evt, struct mct_clock_event_device, evt);
@@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
enable_irq(evt->irq);
-irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu],
cpumask_of(cpu));
+if (ret)
+pr_err("force failed %d\n", ret);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
--
Samsung R Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iio: ad_sigma_delta: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, rather
than introducing a new variable the wait_for_completion_timeout is moved
into the if condition as the return value is only used to detect timeout.
Signed-off-by: Nicholas Mc Guire
---
Aside from the fixup of the wait_for_completion_timeout handling
a minor coding style issue in the else branch was fixed - the {} is
not needed for the one-line body.
Patch was compile tested only for imx_v6_v7_defconfig + CONFIG_IIO=m
CONFIG_STAGING=y, CONFIG_AD7780=m, CONFIG_AD_SIGMA_DELTA=m
Patch is against 3.19.0-rc6 -next-20150130
drivers/iio/adc/ad_sigma_delta.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c
index d10bd0c..fbc5824 100644
--- a/drivers/iio/adc/ad_sigma_delta.c
+++ b/drivers/iio/adc/ad_sigma_delta.c
@@ -196,14 +196,12 @@ static int ad_sd_calibrate(struct ad_sigma_delta
*sigma_delta,
sigma_delta->irq_dis = false;
enable_irq(sigma_delta->spi->irq);
- ret = wait_for_completion_timeout(_delta->completion, 2*HZ);
- if (ret == 0) {
+ if (!wait_for_completion_timeout(_delta->completion, 2*HZ)) {
sigma_delta->irq_dis = true;
disable_irq_nosync(sigma_delta->spi->irq);
ret = -EIO;
- } else {
+ } else
ret = 0;
- }
out:
sigma_delta->bus_locked = false;
spi_bus_unlock(sigma_delta->spi->master);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
On 30/01/15 15:21, Damian Eppel wrote:
This is to fix an issue of sleeping in atomic context when processing
hotplug notifications in Exynos MCT(Multi-Core Timer).
The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
(Arndale Octa board).
Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
request_irq() and free_irq() in the context of hotplug notification
(which is in this case atomic context).
root@target:~# echo 0 > /sys/devices/system/cpu/cpu1/online
[ 25.157867] IRQ18 no longer affine to CPU1
...
[ 25.158445] CPU1: shutdown
root@target:~# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 40.785859] CPU1: Software reset
[ 40.786660] BUG: sleeping function called from invalid context at
mm/slub.c:1241
[ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 40.786678] Preemption disabled at:[< (null)>] (null)
[ 40.786681]
[ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.19.0-rc4-00024-g7dca860 #36
[ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 40.786728] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 40.786747] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 40.786767] [] (dump_stack) from []
(kmem_cache_alloc+0xd8/0x170)
[ 40.786785] [] (kmem_cache_alloc) from []
(request_threaded_irq+0x64/0x128)
[ 40.786804] [] (request_threaded_irq) from []
(exynos4_local_timer_setup+0xc0/0x13c)
[ 40.786820] [] (exynos4_local_timer_setup) from []
(exynos4_mct_cpu_notify+0x30/0xa8)
[ 40.786838] [] (exynos4_mct_cpu_notify) from []
(notifier_call_chain+0x44/0x84)
[ 40.786857] [] (notifier_call_chain) from []
(__cpu_notify+0x28/0x44)
[ 40.786873] [] (__cpu_notify) from []
(secondary_start_kernel+0xec/0x150)
[ 40.786886] [] (secondary_start_kernel) from [<40008764>]
(0x40008764)
Solution:
Clockevent irqs cannot be requested/freed every time cpu is
hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
that signals hotplug or unplug events are sent with both preemption
and local interrupts disabled. Since request_irq() may sleep it is
moved to the initialization stage and performed for all possible
cpus prior putting them online. Then, in the case of hotplug event
the irq asociated with the given cpu will simply be enabled.
Similarly on cpu unplug event the interrupt is not freed but just
disabled.
Note that after successful request_irq() call for a clockevent device
associated to given cpu the requested irq is disabled (via disable_irq()).
That is to make things symmetric as we expect hotplug event as a next
thing (which will enable irq again). This should not pose any problems
because at the time of requesting irq the clockevent device is not
fully initialized yet, therefore should not produce interrupts at that point.
For disabling an irq at cpu unplug notification disable_irq_nosync() is
chosen which is a non-blocking function. This again shouldn't be a problem as
prior sending CPU_DYING notification interrupts are migrated away
from the cpu.
Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for
local timer registration")
Signed-off-by: Damian Eppel
Cc:
Reported-by: Krzysztof Kozlowski
---
drivers/clocksource/exynos_mct.c | 45
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9..9beca58 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
if (mct_int_type == MCT_INT_SPI) {
- evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
- if (request_irq(evt->irq, exynos4_mct_tick_isr,
- IRQF_TIMER | IRQF_NOBALANCING,
- evt->name, mevt)) {
- pr_err("exynos-mct: cannot register IRQ %d\n",
- evt->irq);
+
+ if (evt->irq == -1)
return -EIO;
- }
- irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+
+ irq_force_affinity(evt->irq, cpumask_of(cpu));
+ enable_irq(evt->irq);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -487,10 +484,12 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
static void exynos4_local_timer_stop(struct clock_event_device *evt)
{
evt->set_mode(CLOCK_EVT_MODE_UNUSED, evt);
- if (mct_int_type == MCT_INT_SPI)
- free_irq(evt->irq, this_cpu_ptr(_mct_tick));
- else
+ if (mct_int_type == MCT_INT_SPI) {
+ if (evt->irq != -1)
+
Re: [PATCH perf/core 1/2] [BUGFIX] perf-probe: Fix to handle optimized not-inlined but has no instance
(2015/01/30 23:32), Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 30, 2015 at 11:21:35AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Jan 30, 2015 at 06:37:44PM +0900, Masami Hiramatsu escreveu:
>>> Fix to handle optimized no-inline functions which have
>>> only function definition but no actual instance at
>>> that point. To fix this problem, we need to find actual
>>> instance of the function.
>>>
>>> Without this patch:
>>>
>>> # perf probe -a __up
>>> Failed to get entry address of __up.
>>> Error: Failed to add events.
>>> # perf probe -L __up
>>> Specified source line is not found.
>>> Error: Failed to show lines.
>>>
>>>
>>> With this patch:
>>>
>>> # perf probe -a __up
>>> Added new event:
>>> probe:__up (on __up)
>>>
>>> You can now use it in all perf tools, such as:
>>>
>>> perf record -e probe:__up -aR sleep 1
>>>
>>> # perf probe -L __up
>>> <__up@/home/fedora/ksrc/linux-3/kernel/locking/semaphore.c:0>
>>> 0 static noinline void __sched __up(struct semaphore *sem)
>>>{
>>> struct semaphore_waiter *waiter =
>>> list_first_entry(>wait_
>>> struct
>>> semaphore_waite
>>> 4 list_del(>list);
>>> 5 waiter->up = true;
>>> 6 wake_up_process(waiter->task);
>>> 7 }
>>>
>>
>> Since __up here was built in some other way, I looked for another
>
> Nah, I saw you trying to add "perf probe -a __up" and stopped there,
> hadn't seen that it fails _as well_ for just listing the source code...
>
> Yes, I managed to reproduce the problem and test your fix, it works:
Thanks for testing!
>
> [root@zoo ~]# perf probe --del __up
> Removed event: probe:__up
> [root@zoo ~]# perf probe -L __up
> Specified source line is not found.
> Error: Failed to show lines.
>
> >> APPLY THE PATCH, rebuild and try again:
>
> [root@zoo ~]#
> [root@zoo ~]# perf probe -L __up
> <__up@/home/git/linux/kernel/locking/semaphore.c:0>
> 0 static noinline void __sched __up(struct semaphore *sem)
>{
> struct semaphore_waiter *waiter =
> list_first_entry(>wait_list,
> struct
> semaphore_waiter, list);
> 4 list_del(>list);
> 5 waiter->up = true;
> 6 wake_up_process(waiter->task);
> 7 }
> [root@zoo ~]#
>
> --
>
> So its just this other case that fails, vmalloc_fault, can you check
> this one? Does it happen in your machine as well?
OK, I'll try reproducing this and dig deeper.
>
> Applying your patch, thanks,
Thank you!
>
> - Arnaldo
>
>> 'noinline' function to try, and it failed here:
>>
>> [root@zoo ~]# perf probe -L vmalloc_fault | head -5
>>
>> 0 static noinline int vmalloc_fault(unsigned long address)
>> 1 {
>> pgd_t *pgd, *pgd_ref;
>> pud_t *pud, *pud_ref;
>> [root@zoo ~]# perf probe vmalloc_fault
>> Added new event:
>> Failed to write event: Invalid argument
>> Error: Failed to add events.
>>
>> >> APPLY THE PATCH, rebuild and try again:
>>
>> [root@zoo ~]# perf probe vmalloc_fault
>> Added new event:
>> Failed to write event: Invalid argument
>> Error: Failed to add events.
>> [root@zoo ~]# perf probe -v vmalloc_fault
>> probe-definition(0): vmalloc_fault
>> symbol:vmalloc_fault file:(null) line:0 offset:0 return:0 lazy:(null)
>> 0 arguments
>> Looking at the vmlinux_path (7 entries long)
>> Using /lib/modules/3.19.0-rc6+/build/vmlinux for symbols
>> Open Debuginfo file: /lib/modules/3.19.0-rc6+/build/vmlinux
>> Try to find probe point from debuginfo.
>> Probe point found: vmalloc_fault+0
>> Found 1 probe_trace_events.
>> Opening /sys/kernel/debug/tracing/kprobe_events write=1
>> Added new event:
>> Writing event: p:probe/vmalloc_fault _text+289600
>> Failed to write event: Invalid argument
>> Error: Failed to add events. Reason: Invalid argument (Code: -22)
>> [root@zoo ~]# grep -w vmalloc_fault /proc/kallsyms
>> 81046b40 t vmalloc_fault
>> [root@zoo ~]# grep -w _text /proc/kallsyms
>> 8100 T _text
>> [root@zoo ~]# python
>> Python 2.7.5 (default, Nov 3 2014, 14:26:24)
>> [GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> 0x81046b40 - 0x8100
>> 289600L
>> >>>
>> [root@zoo ~]# readelf -s /lib/modules/3.19.0-rc6+/build/vmlinux | egrep -w
>> _text\|vmalloc_fault
>> 3499: 81046b40 410 FUNCLOCAL DEFAULT1 vmalloc_fault
>>48873: 8100 0 NOTYPE GLOBAL DEFAULT1 _text
>> [root@zoo ~]#
>>
>>
[PATCH 2/3] iio: qcom-spmi-iadc: cleanup wait_for_completion return handling
This patch fixes two issues:
* return type of wait_for_completion_timeout is unsigned long not int,
rather than adding a dedicated variable the wait_for_completion_timeout
is moved into the condition directly
* the timeout of wait_for_completion_timeout is in jiffies but the value
being passed was a unsigned long not converted to jiffies and thus was
dependent on the HZ settings which is probably not what you want.
Signed-off-by: Nicholas Mc Guire
---
Note that the timeout value changed very significantly as wait was
initially in the range of 2 milliseconds, so this converts to 1 jiffies
for HZ < 1000 and 2 jiffies for HZ=1000 - thus the timeout value changed
by 3 orders of magnitude. This needs a review by someone that knows the
details of the hardware to judge if this change is ok - in any case the
timeout passed should go through usecs_to_jiffies or msecs_to_jiffis and
to ensure it is no longer HZ dependent.
Patch was compile tested only for imx_v6_v7_defconfig + CONFIG_IIO=m
CONFIG_COMPILE_TEST=y, CONFIG_SPMI=m, CONFIG_QCOM_SPMI_IADC=m
Patch is against 3.19.0-rc6 -next-20150130
drivers/iio/adc/qcom-spmi-iadc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-iadc.c b/drivers/iio/adc/qcom-spmi-iadc.c
index b9666f2..61fb88d 100644
--- a/drivers/iio/adc/qcom-spmi-iadc.c
+++ b/drivers/iio/adc/qcom-spmi-iadc.c
@@ -296,8 +296,8 @@ static int iadc_do_conversion(struct iadc_chip *iadc, int
chan, u16 *data)
if (iadc->poll_eoc) {
ret = iadc_poll_wait_eoc(iadc, wait);
} else {
- ret = wait_for_completion_timeout(>complete, wait);
- if (!ret)
+ if (!wait_for_completion_timeout(>complete,
+ usecs_to_jiffies(wait)))
ret = -ETIMEDOUT;
else
/* double check conversion status */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kprobes/x86: Use the current code when modified by Kprobes using ftrace
(2015/01/31 0:45), Petr Mladek wrote:
> can_probe() checks if the given address points to the beginning of
> an instruction. It analyzes all the instructions from the beginning
> of the function until the given address. The code might be modified
> by another Kprobe. In this case, the current code is read into a buffer,
> int3 breakpoint is replaced by the saved opcode in the buffer, and
> can_probe() analyzes the buffer instead.
>
> There is a bug that __recover_probed_insn() tries to restore
> the original code even for Kprobes using the ftrace framework.
> But in this case, the opcode is not stored. See the difference
> between arch_prepare_kprobe() and arch_prepare_kprobe_ftrace().
> The opcode is stored by arch_copy_kprobe() only from
> arch_prepare_kprobe().
Good catch!
> This patch makes Kprobe to use the current code when it is modified
> by ftrace. It is not the original one but it is a valid instruction
> of the same length. Therefore it is perfectly fine for the check.
Hmm, but there is a chance we can hit it in the period of replacing code.
This means we'll see 5byte nop but started with int3. (see P6_NOP5 in
arch/x86/include/asm/nops.h)
So, I think we'd better return a special buffer which has a 5byte NOP.
Thank you for reporting!
>
> Note that I found this problem when playing with Kprobes. I did it
> on x86_64 with gcc-4.8.3 that supported -mfentry. I modified
> samples/kprobes/kprobe_example.c and added offset 5 to put
> the probe right after the fentry area:
>
> --- cut ---
> static struct kprobe kp = {
> .symbol_name= "do_fork",
> + .offset = 5,
> };
> --- cut ---
>
> Then I was able to load kprobe_example before jprobe_example
> but not the other way around:
>
> $> modprobe jprobe_example
> $> modprobe kprobe_example
> modprobe: ERROR: could not insert 'kprobe_example': Invalid or incomplete
> multibyte or wide character
>
> It did not make much sense and debugging pointed to the bug
> described above.
>
> Signed-off-by: Petr Mladek
> ---
> arch/x86/kernel/kprobes/core.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 98f654d466e5..ef321caae3ba 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -225,8 +225,14 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned
> long addr)
> struct kprobe *kp;
>
> kp = get_kprobe((void *)addr);
> - /* There is no probe, return original address */
> - if (!kp)
> + /*
> + * Use the current code if it is not modified by Kprobe
> + * or when the Kprobe is using ftrace. In the second case
> + * we do not have any information about the original code
> + * but it is not a problem. Ftrace has put there a valid
> + * instruction of the same length.
> + */
> + if (!kp || kprobe_ftrace(kp))
> return addr;
>
> /*
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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/
[PATCH 1/3] iio: vf610_adc: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch only fixes up the return handling.
Signed-off-by: Nicholas Mc Guire
---
drivers/iio/adc/vf610_adc.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Rather than changing timeout to unsigned long it can be moved into the
if condition and dropped.
Patch was compile tested only for imx_v6_v7_defconfig + CONFIG_IIO=m,
CONFIG_VF610_ADC=m
Patch is against 3.19.0-rc6 -next-20150130
diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
index 8ec353c..5b72d17 100644
--- a/drivers/iio/adc/vf610_adc.c
+++ b/drivers/iio/adc/vf610_adc.c
@@ -259,7 +259,6 @@ static void vf610_adc_cfg_post_set(struct vf610_adc *info)
static void vf610_adc_calibration(struct vf610_adc *info)
{
int adc_gc, hc_cfg;
- int timeout;
if (!info->adc_feature.calibration)
return;
@@ -271,9 +270,7 @@ static void vf610_adc_calibration(struct vf610_adc *info)
adc_gc = readl(info->regs + VF610_REG_ADC_GC);
writel(adc_gc | VF610_ADC_CAL, info->regs + VF610_REG_ADC_GC);
- timeout = wait_for_completion_timeout
- (>completion, VF610_ADC_TIMEOUT);
- if (timeout == 0)
+ if (!wait_for_completion_timeout(>completion, VF610_ADC_TIMEOUT))
dev_err(info->dev, "Timeout for adc calibration\n");
adc_gc = readl(info->regs + VF610_REG_ADC_GS);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 14/42] perf record: Add --index option for building index table
On 01/02/15 20:06, Jiri Olsa wrote:
> On Thu, Jan 29, 2015 at 05:06:55PM +0900, Namhyung Kim wrote:
>> The new --index option will create indexed data file which can be
>> processed by multiple threads parallelly. It saves meta event and
>> sample data in separate files and merges them with an index table.
>>
>> To build an index table, it needs to know exact offsets and sizes for
>> each sample data. However the offset only can be calculated after the
>> feature data is fixed, and to save feature data it needs to access to
>> the sample data because it needs to mark used DSOs for build-id table.
>>
>> So I ended up with reserving 1MB hole for the feature data area and then
>> put sample data and calculated offsets. Now an indexed perf data file
>> will look like below:
>>
>> +-+
>> | file header |
>> |-|
>> | |
>> | meta events |
>> | |
>> |-|
>> | feature data|
>> | (contains index) -+--+
>> |-| |
>> | ~1MB hole | |
>> |-| |
>> | | |
>> |sample data[1] <-+--+
>> | | |
>> |-| |
>> | | |
>> |sample data[2] <-|--+
>> | | |
>> |-| |
>> | ... | ...
>> +-+
>
> I also dont see how to store it in a nice way under current header layout,
> but how about bump up the header version for this feature? ;-)
>
> currently it's:
>
> struct perf_file_header {
> u64 magic;
> u64 size;
> u64 attr_size;
> struct perf_file_sectionattrs;
> struct perf_file_sectiondata;
> /* event_types is ignored */
> struct perf_file_sectionevent_types;
> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> };
>
>
> - we already store attrs as a FEATURE so we could omit that
> - your patch stores only synthesized data into 'data' section (-1 idx)
> this could be stored into separate file and get merged with the rest
> - new header version would have 'features' section, so the features
> position wouldnt depend on the 'data' end as of now and we could
> easily store after all data is merged:
>
> struct perf_file_header {
> u64 magic;
> u64 size;
> u64 attr_size;
> struct perf_file_sectionfeatures;
> DECLARE_BITMAP(adds_features, HEADER_FEAT_BITS);
> };
>
>
> thoughts?
How come the features are being written before the sample data anyway?
I would have expected:
- write the data (update the index in memory)
- write the features (including index)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: file name changes between reboots : /sys/class/hwmon/hwmon[0->1]/temp1_input
Toralf Förster wrote: > I'm wondering where to blame a nagging issue with these file names : > > # ls -l /sys/class/hwmon/hwmon?/temp?_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon1/temp1_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp1_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp2_input > -r--r--r-- 1 root root 4096 Jan 30 13:57 /sys/class/hwmon/hwmon2/temp3_input > > It appears sometimes after a reboot / new minor stable kernel that the first > file name is found in hwmon0 instead of hwmon1. Those numbers get assigned in the order in which the drivers get attached, which is essentially random. You have to use the permanent device path, which isn't as easy. Run something like this to find it: find /sys -name 'temp*_input' Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] spi: sh-msiof: cleanup wait_for_completion return handling
From: Nicholas Mc Guire
return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than assigning it to an incorrect type variable.
Signed-off-by: Nicholas Mc Guire
---
The return type of wait_for_completion_timeout is unsigned long not
int. This patch resolves the type missmatch by moving the call to
wait_for_completion_timeout into the condition.
This patch was only compile tested with: polaris_defconfig
CONFIG_SPI=y, CONFIG_SPI_SH_MSIOF=m
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-sh-msiof.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 9a884e6..9409873 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -640,8 +640,7 @@ static int sh_msiof_spi_txrx_once(struct sh_msiof_spi_priv
*p,
}
/* wait for tx fifo to be emptied / rx fifo to be filled */
- ret = wait_for_completion_timeout(>done, HZ);
- if (!ret) {
+ if (!wait_for_completion_timeout(>done, HZ)) {
dev_err(>pdev->dev, "PIO timeout\n");
ret = -ETIMEDOUT;
goto stop_reset;
@@ -751,8 +750,7 @@ static int sh_msiof_dma_once(struct sh_msiof_spi_priv *p,
const void *tx,
}
/* wait for tx fifo to be emptied / rx fifo to be filled */
- ret = wait_for_completion_timeout(>done, HZ);
- if (!ret) {
+ if (!wait_for_completion_timeout(>done, HZ)) {
dev_err(>pdev->dev, "DMA timeout\n");
ret = -ETIMEDOUT;
goto stop_reset;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] spi: spi-imx: cleanup wait_for_completion handling
return type of wait_for_completion_timeout is unsigned long not int and
always returns >=0 , this patch adds a suitable return variable and
simplifies the return value checking as there is no < 0 case.
Signed-off-by: Nicholas Mc Guire
---
The return type of wait_for_completion_timeout is unsigned long not
int. This patch resolves the type missmatch by adding an appropriately
type return variable as well as simplifying the return value checking.
If the return was not 0 it only can be positive so the > 0 check is
unnecessary.
This patch was only compile tested with imx_v6_v7_defconfig
(implies CONFIG_SPI_IMX=y)
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-imx.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
index 6a2ff75..5eaecbb 100644
--- a/drivers/spi/spi-imx.c
+++ b/drivers/spi/spi-imx.c
@@ -891,6 +891,7 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
{
struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
int ret;
+ unsigned long timeout;
u32 dma;
int left;
struct spi_master *master = spi_imx->bitbang.master;
@@ -938,17 +939,17 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
dma_async_issue_pending(master->dma_tx);
dma_async_issue_pending(master->dma_rx);
/* Wait SDMA to finish the data transfer.*/
- ret = wait_for_completion_timeout(_imx->dma_tx_completion,
+ timeout = wait_for_completion_timeout(_imx->dma_tx_completion,
IMX_DMA_TIMEOUT);
- if (!ret) {
+ if (!timeout) {
pr_warn("%s %s: I/O Error in DMA TX\n",
dev_driver_string(>dev),
dev_name(>dev));
dmaengine_terminate_all(master->dma_tx);
} else {
- ret = wait_for_completion_timeout(_imx->dma_rx_completion,
- IMX_DMA_TIMEOUT);
- if (!ret) {
+ timeout = wait_for_completion_timeout(
+ _imx->dma_rx_completion, IMX_DMA_TIMEOUT);
+ if (!timeout) {
pr_warn("%s %s: I/O Error in DMA RX\n",
dev_driver_string(>dev),
dev_name(>dev));
@@ -963,9 +964,9 @@ static int spi_imx_dma_transfer(struct spi_imx_data
*spi_imx,
spi_imx->dma_finished = 1;
spi_imx->devtype_data->trigger(spi_imx);
- if (!ret)
+ if (!timeout)
ret = -ETIMEDOUT;
- else if (ret > 0)
+ else
ret = transfer->len;
return ret;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] spi: ti-qspi: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than assigning it to an incorrect type variable.
Signed-off-by: Nicholas Mc Guire
---
The return type of wait_for_completion_timeout is unsigned long not
int. This patch resolves the type mismatch by moving the call to
wait_for_completion_timeout into the condition.
This patch was only compile tested with omap2plus_defconfig
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-ti-qspi.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 6146c4c..3364e3e 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -201,7 +201,7 @@ static void ti_qspi_restore_ctx(struct ti_qspi *qspi)
static int qspi_write_msg(struct ti_qspi *qspi, struct spi_transfer *t)
{
- int wlen, count, ret;
+ int wlen, count;
unsigned int cmd;
const u8 *txbuf;
@@ -230,9 +230,8 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
}
ti_qspi_write(qspi, cmd, QSPI_SPI_CMD_REG);
- ret = wait_for_completion_timeout(>transfer_complete,
- QSPI_COMPLETION_TIMEOUT);
- if (ret == 0) {
+ if (!wait_for_completion_timeout(>transfer_complete,
+ QSPI_COMPLETION_TIMEOUT)) {
dev_err(qspi->dev, "write timed out\n");
return -ETIMEDOUT;
}
@@ -245,7 +244,7 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
static int qspi_read_msg(struct ti_qspi *qspi, struct spi_transfer *t)
{
- int wlen, count, ret;
+ int wlen, count;
unsigned int cmd;
u8 *rxbuf;
@@ -268,9 +267,8 @@ static int qspi_read_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
while (count) {
dev_dbg(qspi->dev, "rx cmd %08x dc %08x\n", cmd, qspi->dc);
ti_qspi_write(qspi, cmd, QSPI_SPI_CMD_REG);
- ret = wait_for_completion_timeout(>transfer_complete,
- QSPI_COMPLETION_TIMEOUT);
- if (ret == 0) {
+ if (!wait_for_completion_timeout(>transfer_complete,
+ QSPI_COMPLETION_TIMEOUT)) {
dev_err(qspi->dev, "read timed out\n");
return -ETIMEDOUT;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] spi: match var type to return type of wait_for_completion
From: Nicholas Mc Guire return type of wait_for_completion_timeout is unsigned long not int, this patch changes the type of m from int to unsigned long. Signed-off-by: Nicholas Mc Guire --- The return type of wait_for_completion_timeout is unsigned long not int. This patch resolves the type missmatch by changing the type to unsigned long. This patch was only compile tested with x86_64_defconfig + CONFIG_SPI=y Patch is against 3.19.0-rc6 -next-20150130 drivers/spi/spi.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b9fb711..c64a3e5 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -784,7 +784,7 @@ static int spi_transfer_one_message(struct spi_master *master, struct spi_transfer *xfer; bool keep_cs = false; int ret = 0; - int ms = 1; + unsigned long ms = 1; spi_set_cs(msg->spi, true); -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] spi: mxs: cleanup wait_for_completion return handling
return type of wait_for_completion_timeout is unsigned long not int, this
patch uses the return value of wait_for_completion_timeout in the condition
directly rather than adding a additional appropriately typed variable.
Signed-off-by: Nicholas Mc Guire
---
The return type of wait_for_completion_timeout is unsigned long not
int. This patch resolves the type mismatch by moving the call to
wait_for_completion_timeout into the condition.
This patch was only compile tested with mxs_defconfig
Patch is against 3.19.0-rc6 -next-20150130
drivers/spi/spi-mxs.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-mxs.c b/drivers/spi/spi-mxs.c
index 4045a1e..d051312 100644
--- a/drivers/spi/spi-mxs.c
+++ b/drivers/spi/spi-mxs.c
@@ -282,9 +282,8 @@ static int mxs_spi_txrx_dma(struct mxs_spi *spi,
dmaengine_submit(desc);
dma_async_issue_pending(ssp->dmach);
- ret = wait_for_completion_timeout(>c,
- msecs_to_jiffies(SSP_TIMEOUT));
- if (!ret) {
+ if (!wait_for_completion_timeout(>c,
+ msecs_to_jiffies(SSP_TIMEOUT))) {
dev_err(ssp->dev, "DMA transfer timeout\n");
ret = -ETIMEDOUT;
dmaengine_terminate_all(ssp->dmach);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] clocksource: mmp: add mmp timer driver
From: Chao Xie
MMP timer is attached to APB bus, It has the following
limitation.
1. When get count of timer counter, it need some delay
to get a stable count.
2. When set match register, it need disable the counter
first, and enable it after set the match register.
The disabling need wait for 2 clock cycle to take
effect.
To improve above #1, shadow register for count is added.
To improve above #2, CRSR register is added for quick updating.
So there are three types of timer.
timer1: old timer.
timer2: old timer with shadow register.
timer3: old timer with shadow and CRSR register.
This timer driver will be used for many SOCes.
1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
2. pxa1L88, pxa1U88 have timer1 and timer3.
3. pxa1928 has timer 2.
The driver supports DT and non-DT initialization.
The driver supports UP/SMP SOCes and 64 bit core.
Signed-off-by: Chao Xie
---
.../devicetree/bindings/arm/mrvl/timer.txt | 61 +-
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-mmp.c| 837 +
include/linux/mmp_timer.h | 40 +
4 files changed, 933 insertions(+), 6 deletions(-)
create mode 100644 drivers/clocksource/timer-mmp.c
create mode 100644 include/linux/mmp_timer.h
diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
index 9a6e251..b49cb3e 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
@@ -1,13 +1,62 @@
* Marvell MMP Timer controller
+Each timer have multiple counters, so the timer DT need include counter's
+description.
+
+1. Timer
+
Required properties:
-- compatible : Should be "mrvl,mmp-timer".
+- compatible : Should be "marvell,mmp-timer".
- reg : Address and length of the register set of timer controller.
-- interrupts : Should be the interrupt number.
+- clocks : The first clock is the fequency of the apb bus that the timer
+ attached to. The second clock is the fast clock frequency of the timer.
+ This frequency and fast clock are used to calculated delay
+ loops for clock operations.
+
+Optional properties:
+- marvell,timer-has-crsr : This timer has CRSR register.
+- marvell,timer-has-shadow : This timer has shadow register.
+
+2. Counter
+
+Required properties:
+- compatible : It can be
+ "marvell,timer-counter-clkevt" : The counter is used for clock event
+ device.
+ "marvell,timer-counter-clksrc" : The counter is used for clock source.
+ "marvell,timer-counter-delay" : The counter is used for delay timer.
+- marvell,timer-counter-id : The counter index in this timer.
-Example:
- timer0: timer@d4014000 {
- compatible = "mrvl,mmp-timer";
- reg = <0xd4014000 0x100>;
+Optional properties:
+- marvell,fast-clock : whether the counter use the fast-clock for counting.
+- interrupts : The interrupt for clock event device.
+ Only valid for "marvell,timer-counter-clkevt".
+- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
+ "marvell,timer-counter-clkevt".
+- marvell,timer-counter-broadcast : When this counter acts as clock event
+ device. It is broadcast clock event device.
+ Only valid for "marvell,timer-counter-clkevt".
+- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
+ event device, it cannot switch the IRQ of broadcast clock event to any CPU.
+ Only valid for "marvell,timer-counter-clkevt".
+
+3. Examples
+
+timer0: timer@d4014000 {
+ compatible = "marvell,mmp-timer";
+ reg = <0xd4014000 0xc8>;
+ clocks = <_clocks MMP2_PLL1_24>, <_closk MMP2_CLK_TIMER>;
+ status = "okay";
+
+ counter0 {
+ compatible = "marvell,timer-counter-clkevt";
interrupts = <13>;
+ marvell,timer-counter-id = <0>;
+ marvell,timer-counter-cpu = <0>;
+ };
+
+ counter1 {
+ compatible = "marvell,timer-counter-clksrc";
+ marvell,timer-counter-id = <1>;
};
+};
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 94d90b2..6a66d4d 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_ORION_TIMER) += time-orion.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835_timer.o
obj-$(CONFIG_ARCH_CLPS711X)+= clps711x-timer.o
obj-$(CONFIG_ARCH_MARCO) += timer-marco.o
+obj-$(CONFIG_ARCH_MMP) += timer-mmp.o
obj-$(CONFIG_ARCH_MOXART) += moxart_timer.o
obj-$(CONFIG_ARCH_MXS) += mxs_timer.o
obj-$(CONFIG_ARCH_PXA) += pxa_timer.o
diff --git a/drivers/clocksource/timer-mmp.c b/drivers/clocksource/timer-mmp.c
new file mode 100644
index 000..b6a9ce1
--- /dev/null
+++ b/drivers/clocksource/timer-mmp.c
@@ -0,0 +1,837 @@
+/*
+ * driver/clocksource/timer-mmp.c
+ *
+ *
[PATCH 4/4] arm: mmp: remove the old timer driver
From: Chao Xie
The new timer driver has been created under
drivers/clocksource/.
After change all SOCes to use the new driver,
remove the old one.
Signed-off-by: Chao Xie
---
arch/arm/mach-mmp/Makefile | 2 +-
arch/arm/mach-mmp/time.c | 247 -
2 files changed, 1 insertion(+), 248 deletions(-)
delete mode 100644 arch/arm/mach-mmp/time.c
diff --git a/arch/arm/mach-mmp/Makefile b/arch/arm/mach-mmp/Makefile
index 98f0f63..18ba814 100644
--- a/arch/arm/mach-mmp/Makefile
+++ b/arch/arm/mach-mmp/Makefile
@@ -2,7 +2,7 @@
# Makefile for Marvell's PXA168 processors line
#
-obj-y += common.o devices.o time.o
+obj-y += common.o devices.o
# SoC support
obj-$(CONFIG_CPU_PXA168) += pxa168.o
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
deleted file mode 100644
index 2756351..000
--- a/arch/arm/mach-mmp/time.c
+++ /dev/null
@@ -1,247 +0,0 @@
-/*
- * linux/arch/arm/mach-mmp/time.c
- *
- * Support for clocksource and clockevents
- *
- * Copyright (C) 2008 Marvell International Ltd.
- * All rights reserved.
- *
- * 2008-04-11: Jason Chagas
- * 2008-10-08: Bin Yang
- *
- * The timers module actually includes three timers, each timer with up to
- * three match comparators. Timer #0 is used here in free-running mode as
- * the clock source, and match comparator #1 used as clock event device.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include "clock.h"
-
-#ifdef CONFIG_CPU_MMP2
-#define MMP_CLOCK_FREQ 650
-#else
-#define MMP_CLOCK_FREQ 325
-#endif
-
-#define TIMERS_VIRT_BASE TIMERS1_VIRT_BASE
-
-#define MAX_DELTA (0xfffe)
-#define MIN_DELTA (16)
-
-static void __iomem *mmp_timer_base = TIMERS_VIRT_BASE;
-
-/*
- * FIXME: the timer needs some delay to stablize the counter capture
- */
-static inline uint32_t timer_read(void)
-{
- int delay = 100;
-
- __raw_writel(1, mmp_timer_base + TMR_CVWR(1));
-
- while (delay--)
- cpu_relax();
-
- return __raw_readl(mmp_timer_base + TMR_CVWR(1));
-}
-
-static u64 notrace mmp_read_sched_clock(void)
-{
- return timer_read();
-}
-
-static irqreturn_t timer_interrupt(int irq, void *dev_id)
-{
- struct clock_event_device *c = dev_id;
-
- /*
-* Clear pending interrupt status.
-*/
- __raw_writel(0x01, mmp_timer_base + TMR_ICR(0));
-
- /*
-* Disable timer 0.
-*/
- __raw_writel(0x02, mmp_timer_base + TMR_CER);
-
- c->event_handler(c);
-
- return IRQ_HANDLED;
-}
-
-static int timer_set_next_event(unsigned long delta,
- struct clock_event_device *dev)
-{
- unsigned long flags;
-
- local_irq_save(flags);
-
- /*
-* Disable timer 0.
-*/
- __raw_writel(0x02, mmp_timer_base + TMR_CER);
-
- /*
-* Clear and enable timer match 0 interrupt.
-*/
- __raw_writel(0x01, mmp_timer_base + TMR_ICR(0));
- __raw_writel(0x01, mmp_timer_base + TMR_IER(0));
-
- /*
-* Setup new clockevent timer value.
-*/
- __raw_writel(delta - 1, mmp_timer_base + TMR_TN_MM(0, 0));
-
- /*
-* Enable timer 0.
-*/
- __raw_writel(0x03, mmp_timer_base + TMR_CER);
-
- local_irq_restore(flags);
-
- return 0;
-}
-
-static void timer_set_mode(enum clock_event_mode mode,
- struct clock_event_device *dev)
-{
- unsigned long flags;
-
- local_irq_save(flags);
- switch (mode) {
- case CLOCK_EVT_MODE_ONESHOT:
- case CLOCK_EVT_MODE_UNUSED:
- case CLOCK_EVT_MODE_SHUTDOWN:
- /* disable the matching interrupt */
- __raw_writel(0x00, mmp_timer_base + TMR_IER(0));
- break;
- case CLOCK_EVT_MODE_RESUME:
- case CLOCK_EVT_MODE_PERIODIC:
- break;
- }
- local_irq_restore(flags);
-}
-
-static struct clock_event_device ckevt = {
- .name = "clockevent",
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .rating = 200,
- .set_next_event = timer_set_next_event,
- .set_mode = timer_set_mode,
-};
-
-static cycle_t clksrc_read(struct clocksource *cs)
-{
- return timer_read();
-}
-
-static struct clocksource cksrc = {
- .name = "clocksource",
- .rating = 200,
- .read = clksrc_read,
- .mask = CLOCKSOURCE_MASK(32),
- .flags = CLOCK_SOURCE_IS_CONTINUOUS,
-};
-
-static void __init
[PATCH 0/4] drivers: clocksource: add mmp timer driver
From: Chao Xie These patch will create a new timer driver in drivers/clocksource/ The timer driver will support all SOCes in mach-mmp There are two patches #2 and #3 changing the arch/mach-mmp to make DT and no-DT supported SOCes to make use of new timer driver The final patch will remove the old timer driver. The patches are tested at pxa910 and mmp2(DT and no-DT support). Because pxa168 is too old, and it is hard to find the board. So only pass the compiling. Chao Xie (4): clocksource: mmp: add mmp timer driver arm: mmp: make SOCes without DT use new timer driver arm: mmp: make SOCes with DT use new timer driver arm: mmp: remove the old timer driver .../devicetree/bindings/arm/mrvl/timer.txt | 61 +- arch/arm/boot/dts/mmp2.dtsi| 19 +- arch/arm/boot/dts/pxa168.dtsi | 20 +- arch/arm/boot/dts/pxa910.dtsi | 26 +- arch/arm/mach-mmp/Kconfig | 2 + arch/arm/mach-mmp/Makefile | 2 +- arch/arm/mach-mmp/common.h | 2 - arch/arm/mach-mmp/mmp-dt.c | 4 +- arch/arm/mach-mmp/mmp2-dt.c| 4 +- arch/arm/mach-mmp/mmp2.c | 23 +- arch/arm/mach-mmp/pxa168.c | 23 +- arch/arm/mach-mmp/pxa910.c | 24 +- arch/arm/mach-mmp/time.c | 247 -- drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-mmp.c| 837 + include/linux/mmp_timer.h | 40 + 16 files changed, 1058 insertions(+), 277 deletions(-) delete mode 100644 arch/arm/mach-mmp/time.c create mode 100644 drivers/clocksource/timer-mmp.c create mode 100644 include/linux/mmp_timer.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] arm: mmp: make SOCes without DT use new timer driver
From: Chao Xie For no DT support, directly call new timer's APIs to initialize timer. It need to initialize the timer first, then initialize the clock event device or clock source which are based on counter. Signed-off-by: Chao Xie --- arch/arm/mach-mmp/common.h | 2 -- arch/arm/mach-mmp/mmp2.c | 23 ++- arch/arm/mach-mmp/pxa168.c | 23 ++- arch/arm/mach-mmp/pxa910.c | 24 +++- 4 files changed, 67 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-mmp/common.h b/arch/arm/mach-mmp/common.h index cf445ba..015b209 100644 --- a/arch/arm/mach-mmp/common.h +++ b/arch/arm/mach-mmp/common.h @@ -1,8 +1,6 @@ #include #define ARRAY_AND_SIZE(x) (x), ARRAY_SIZE(x) -extern void timer_init(int irq); - extern void __init mmp_map_io(void); extern void mmp_restart(enum reboot_mode, const char *); extern void __init pxa168_clk_init(void); diff --git a/arch/arm/mach-mmp/mmp2.c b/arch/arm/mach-mmp/mmp2.c index a70b553..12ba28a 100644 --- a/arch/arm/mach-mmp/mmp2.c +++ b/arch/arm/mach-mmp/mmp2.c @@ -16,12 +16,14 @@ #include #include #include +#include #include #include #include #include +#include #include #include #include @@ -133,7 +135,26 @@ void __init mmp2_timer_init(void) clk_rst = APBC_APBCLK | APBC_FNCLK | APBC_FNCLKSEL(1); __raw_writel(clk_rst, APBC_TIMERS); - timer_init(IRQ_MMP2_TIMER1); + /* +* Make use of timer 1 which id is 0. +* It has no shadow and crsr regsiters. +* The fast lock is 6.5M. +* apb bus is 26M. +*/ + mmp_timer_init(0, TIMERS1_VIRT_BASE, 0, 650, 2600); + + /* +* Enable counter 1 to be clock source. +* The frequency is 32K. +*/ + mmp_counter_clocksource_init(0, 1, 32768); + + /* +* Enable counter 0 to be clock event device. +* The frequency is 32K. +* Only one cpu and there is no broadcast timer. +*/ + mmp_counter_clockevent_init(0, 0, IRQ_MMP2_TIMER1, 32768, 0, 0); } /* on-chip devices */ diff --git a/arch/arm/mach-mmp/pxa168.c b/arch/arm/mach-mmp/pxa168.c index 144e997..bb65d8f 100644 --- a/arch/arm/mach-mmp/pxa168.c +++ b/arch/arm/mach-mmp/pxa168.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include @@ -22,6 +23,7 @@ #include #include #include +#include #include #include #include @@ -78,7 +80,26 @@ void __init pxa168_timer_init(void) /* 3.25MHz, bus/functional clock enabled, release reset */ __raw_writel(TIMER_CLK_RST, APBC_TIMERS); - timer_init(IRQ_PXA168_TIMER1); + /* +* Make use of timer 1 which id is 0. +* It has no shadow and crsr regsiters. +* The fast lock is 3.25M. +* apb bus is 26M. +*/ + mmp_timer_init(0, TIMERS1_VIRT_BASE, 0, 325, 2600); + + /* +* Enable counter 1 to be clock source. +* The frequency is 32K. +*/ + mmp_counter_clocksource_init(0, 1, 32768); + + /* +* Enable counter 0 to be clock event device. +* The frequency is 32K. +* Only one cpu and there is no broadcast timer. +*/ + mmp_counter_clockevent_init(0, 0, IRQ_PXA168_TIMER1, 32768, 0, 0); } void pxa168_clear_keypad_wakeup(void) diff --git a/arch/arm/mach-mmp/pxa910.c b/arch/arm/mach-mmp/pxa910.c index eb57ee1..e8ae5b1 100644 --- a/arch/arm/mach-mmp/pxa910.c +++ b/arch/arm/mach-mmp/pxa910.c @@ -15,11 +15,13 @@ #include #include #include +#include #include #include #include #include +#include #include #include #include @@ -114,7 +116,27 @@ void __init pxa910_timer_init(void) __raw_writel(APBC_APBCLK | APBC_RST, APBC_TIMERS); __raw_writel(TIMER_CLK_RST, APBC_TIMERS); - timer_init(IRQ_PXA910_AP1_TIMER1); + /* +* Make use of timer 1 which id is 0. +* It has no shadow and crsr regsiters. +* The fast lock is 3.25M. +* apb bus is 26M. +*/ + mmp_timer_init(0, TIMERS1_VIRT_BASE, 0, 325, 2600); + + /* +* Enable counter 1 to be clock source. +* The frequency is 32K. +*/ + mmp_counter_clocksource_init(0, 1, 32768); + + /* +* Enable counter 0 to be clock event device. +* The frequency is 32K. +* Only one cpu and there is no broadcast timer. +*/ + mmp_counter_clockevent_init(0, 0, IRQ_PXA910_AP1_TIMER1, + 32768, 0, 0); } /* on-chip devices */ -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] arm: mmp: make SOCes with DT use new timer driver
From: Chao Xie
Change the dtsi and DT support for mmp SOCes to make them
use the new timer driver.
Signed-off-by: Chao Xie
---
arch/arm/boot/dts/mmp2.dtsi | 19 ---
arch/arm/boot/dts/pxa168.dtsi | 20 +---
arch/arm/boot/dts/pxa910.dtsi | 26 --
arch/arm/mach-mmp/Kconfig | 2 ++
arch/arm/mach-mmp/mmp-dt.c| 4 +++-
arch/arm/mach-mmp/mmp2-dt.c | 4 +++-
6 files changed, 57 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 766bbb8..e63e3a3 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -127,9 +127,22 @@
ranges;
timer0: timer@d4014000 {
- compatible = "mrvl,mmp-timer";
- reg = <0xd4014000 0x100>;
- interrupts = <13>;
+ compatible = "marvell,mmp-timer";
+ reg = <0xd4014000 0xc8>;
+ clocks = <_clocks MMP2_CLK_VCTCXO>,
<_clocks MMP2_CLK_TIMER>;
+ status = "okay";
+
+ counter0 {
+ compatible =
"marvell,timer-counter-clkevt";
+ interrupts = <13>;
+ marvell,timer-counter-id = <0>;
+ marvell,timer-counter-cpu = <0>;
+};
+
+counter1 {
+ compatible =
"marvell,timer-counter-clksrc";
+ marvell,timer-counter-id = <1>;
+};
};
uart1: uart@d403 {
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index b899e25..5a2f385 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -51,9 +51,23 @@
ranges;
timer0: timer@d4014000 {
- compatible = "mrvl,mmp-timer";
- reg = <0xd4014000 0x100>;
- interrupts = <13>;
+ compatible = "marvell,mmp-timer";
+ reg = <0xd4014000 0xc8>;
+ clocks = <_clocks PXA168_CLK_PLL1_24>,
<_clocks PXA168_CLK_TIMER>;
+ status = "okay";
+
+ counter0 {
+ compatible =
"marvell,timer-counter-clkevt";
+ interrupts = <13>;
+ marvell,timer-counter-id = <0>;
+ marvell,timer-counter-cpu = <0>;
+};
+
+counter1 {
+ compatible =
"marvell,timer-counter-clksrc";
+ marvell,timer-counter-id = <1>;
+};
+
};
uart1: uart@d4017000 {
diff --git a/arch/arm/boot/dts/pxa910.dtsi b/arch/arm/boot/dts/pxa910.dtsi
index 0868f67..beb25fc 100644
--- a/arch/arm/boot/dts/pxa910.dtsi
+++ b/arch/arm/boot/dts/pxa910.dtsi
@@ -56,16 +56,22 @@
ranges;
timer0: timer@d4014000 {
- compatible = "mrvl,mmp-timer";
- reg = <0xd4014000 0x100>;
- interrupts = <13>;
- };
-
- timer1: timer@d4016000 {
- compatible = "mrvl,mmp-timer";
- reg = <0xd4016000 0x100>;
- interrupts = <29>;
- status = "disabled";
+ compatible = "marvell,mmp-timer";
+ reg = <0xd4014000 0xc8>;
+ clocks = <_clocks PXA910_CLK_PLL1_24>,
<_clocks PXA910_CLK_TIMER0>;
+ status = "okay";
+
+ counter0 {
+ compatible =
"marvell,timer-counter-clkevt";
+ interrupts = <13>;
+ marvell,timer-counter-id = <0>;
+ marvell,timer-counter-cpu = <0>;
+};
+
+counter1 {
+ compatible =
"marvell,timer-counter-clksrc";
+ marvell,timer-counter-id = <1>;
+};
};
uart1:
