Monday, January 20, 2014

linux.kernel - 26 new messages in 11 topics - digest

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

linux.kernel@googlegroups.com

Today's topics:

* serial: samsung: Move uart_register_driver call to device probe - 3 messages,
3 authors
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
* mfd: Add realtek USB card reader driver - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/1f81ba73abf8778b?hl=en
* drivers: staging: lustre: lustre: include: add "__attribute__((packed))" for
the related union - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6e12b00a474676f9?hl=en
* Dwarf: unwind the recorded stack frame of different target address sizes - 4
messages, 1 author
http://groups.google.com/group/linux.kernel/t/0de6d3597b701465?hl=en
* xen-netback: Handle guests with too many frags - 10 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fa3947f0129612f2?hl=en
* thinkpad_acpi: Add support for controlling charge thresholds - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/043a7f030fe602a3?hl=en
* fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/f572a9a7c79d3bdd?hl=en
* linux-next: build failure after merge of the tip tree - 2 messages, 2
authors
http://groups.google.com/group/linux.kernel/t/5d213db28c0ba532?hl=en
* lockdep: (Was: check && lockdep_no_validate) - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/07e5799772466cd4?hl=en
* MAINTAINERS tree branches [xen tip as an example] - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/e080ae587afdec2e?hl=en
* ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/0bc8f0bfd15b8d30?hl=en

==============================================================================
TOPIC: serial: samsung: Move uart_register_driver call to device probe
http://groups.google.com/group/linux.kernel/t/8b321f7043371d52?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 20 2014 1:20 pm
From: Greg KH


On Mon, Jan 20, 2014 at 10:05:30AM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> > uart_register_driver call binds the driver to a specific device
> > node through tty_register_driver call. This should typically happen
> > during device probe call.
> >
> > In a multiplatform scenario, it is possible that multiple serial
> > drivers are part of the kernel. Currently the driver registration fails
> > if multiple serial drivers with same default major/minor numbers are
> > included in the kernel.
> >
> > A typical case is observed with amba-pl011 and samsung-uart drivers.
>
> The samsung-uart driver is at fault here - the major/minor numbers were
> officially registered to amba-pl011. Samsung needs to be fixed properly.

I agree, the Samsung driver is "broken" here, but that's no reason why
these two drivers can't register with the tty layer _after_ the hardware
is detected, and not before.

That saves resources on systems that build the drivers in, yet do not
have the hardware present, which is always a good thing.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 3 ==
Date: Mon, Jan 20 2014 1:40 pm
From: Russell King - ARM Linux


On Mon, Jan 20, 2014 at 01:16:01PM -0800, Greg KH wrote:
> On Mon, Jan 20, 2014 at 10:05:30AM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 20, 2014 at 02:32:34PM +0530, Tushar Behera wrote:
> > > uart_register_driver call binds the driver to a specific device
> > > node through tty_register_driver call. This should typically happen
> > > during device probe call.
> > >
> > > In a multiplatform scenario, it is possible that multiple serial
> > > drivers are part of the kernel. Currently the driver registration fails
> > > if multiple serial drivers with same default major/minor numbers are
> > > included in the kernel.
> > >
> > > A typical case is observed with amba-pl011 and samsung-uart drivers.
> >
> > The samsung-uart driver is at fault here - the major/minor numbers were
> > officially registered to amba-pl011. Samsung needs to be fixed properly.
>
> I agree, the Samsung driver is "broken" here, but that's no reason why
> these two drivers can't register with the tty layer _after_ the hardware
> is detected, and not before.
>
> That saves resources on systems that build the drivers in, yet do not
> have the hardware present, which is always a good thing.

Great, so what you're saying is that we need to wait until the first
device calls into the probe function. What about removal... how does
a driver know when it's last device has been removed to de-register
that?

I guess it needs the driver model to provide some way to know when a
driver is completely unbound - but isn't that racy?

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@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 of 3 ==
Date: Mon, Jan 20 2014 1:50 pm
From: Alan Cox


> I had earlier submitted a patch [1] to remove the hard coded
> major/minor number for Samsung UART driver, but that was rejected
> because of userspace breakage. Without this patch, Samsung UART driver
> can't bind to the hard-coded device node. Changing the default
> major/minor will also not help to fix the objections raised in [1].
>
> Would you please suggest a way forward?
>
> [1] https://lkml.org/lkml/2013/12/27/2

The dynamic major/minor is the right patch. If the userspace breaks then
the userspace was broken, but I see no evidence in the discussion that
the userspace broke.

204,64 belongs to Altix so neither of the clashing drivers should use it.
We had a table to stop messes like this, and we have dynamic numbering
to stop the table being needed for the future

50 = /dev/ttyIOC0 Altix serial card
...
81 = /dev/ttyIOC31 Altix serial card


Thats what the list says. Samsung should have followed the rules, they
didn't so they get to pick up the pieces. The Amba driver wants moving as
well. It's easy. If you want something to be ABI then make sure you get
it upstream first, if not you get to own all the pain down the line.

Hacking up the core code to paper over this crap is not on. We've been
insisting firmly and robustly for years that people don't keep borrowing
names and numbers they are not allocated, and use dynamic values whenever
possible.

If the hardware isn't present then the driver shouldn't even register
with the tty layer in the first place so it doesn't make any resource
differeneces either for properly written code.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: mfd: Add realtek USB card reader driver
http://groups.google.com/group/linux.kernel/t/1f81ba73abf8778b?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 1:20 pm
From: Greg Kroah-Hartman


On Mon, Jan 20, 2014 at 04:55:52PM +0800, Roger wrote:
> On 01/16/2014 05:35 PM, Lee Jones wrote:
> >>>>+static int rtsx_usb_bulk_transfer_sglist(struct rtsx_ucr *ucr,
> >>>>+ unsigned int pipe, struct scatterlist *sg, int num_sg,
> >>>>+ unsigned int length, unsigned int *act_len, int timeout)
> >>>>+{
> >>>>+ int ret;
> >>>>+
> >>>>+ dev_dbg(&ucr->pusb_intf->dev, "%s: xfer %u bytes, %d entries\n",
> >>>>+ __func__, length, num_sg);
> >>>>+ ret = usb_sg_init(&ucr->current_sg, ucr->pusb_dev, pipe, 0,
> >>>>+ sg, num_sg, length, GFP_NOIO);
> >>>>+ if (ret)
> >>>>+ return ret;
> >>>>+
> >>>>+ ucr->sg_timer.expires = jiffies + msecs_to_jiffies(timeout);
> >>>>+ add_timer(&ucr->sg_timer);
> >>>>+ usb_sg_wait(&ucr->current_sg);
> >>>>+ del_timer(&ucr->sg_timer);
> >>>>+
> >>>>+ if (act_len)
> >>>>+ *act_len = ucr->current_sg.bytes;
> >>>>+
> >>>>+ return ucr->current_sg.status;
> >>>>+}
> >>>
> >>>Code looks fine, but shouldn't this live in a USB driver?
> >>>
> >>We have studied drivers in usb/storage, the place that most likely
> >>to put the driver. All of them are for STANDARD usb mass storage
> >>class(something like USB_CLASS_MASS_STORAGE). But this is not the
> >>same case. This driver is for our vendor-class device with
> >>completely different protocol. It is really an USB interfaced flash
> >>card command converter(or channel) device rather than a real
> >>storage. It also has two derived modules(rtsx_usb_sdmmc,
> >>rtsx_usb_memstick) for other two subsystems.
> >>
> >>We also have another driver: rtsx_pcr.c resident in mfd/ for similar
> >>devices but of PCIe interface. It is nature for us to choose the
> >>same place for this variant.
> >
> >Very well, as long as it truly does not fit in drivers/usb. It would
> >be good to have one of the USB folk give the nod though.
> >
> I found Greg K-H is exactly one of the maintainers of USB subsystem as I
> read the MAINTAINERS document.
>
> Greg, would you please comment this subsystem concern or introduce other
> members? Thanks.

It's the middle of the merge window, nothing can happen until after
3.14-rc1 is out. So how about resending all of this in two weeks after
that happens so we can all properly discuss it?

As for where the driver should be located, if it shares logic with the
usb storage driver, then it should be in drivers/usb/storage, otherwise
put it wherever makes most sense, there's no need to put all USB drivers
under drivers/usb/ at all.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/





==============================================================================
TOPIC: drivers: staging: lustre: lustre: include: add "__attribute__((packed))
" for the related union
http://groups.google.com/group/linux.kernel/t/6e12b00a474676f9?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 20 2014 1:20 pm
From: Dan Carpenter


I made a quick and dirty sparse patch to check for this. I don't think
I will bother trying to send it to sparse upstream, but you can if you
want to.

It found 289 unions which might need a __packed added. The lustre
unions were not in my allmodconfig so they're not listed.

Perhaps there could be a command line option or a pragma so that unions
will work in the kernel. We don't care about linking to outside
libraries.

regards,
dan carpenter

diff --git a/symbol.c b/symbol.c
index ebba56deaf94..596e47883aad 100644
--- a/symbol.c
+++ b/symbol.c
@@ -187,6 +187,12 @@ static struct symbol * examine_struct_union_type(struct symbol *sym, int advance
bit_size = (bit_size + bit_align) & ~bit_align;
}
sym->bit_size = bit_size;
+
+ if (!advance && (info.bit_size / 8) % 4) {
+ int pad = 4 - (info.bit_size / 8) % 4;
+ warning(sym->pos, "'%s' union will be padded with %d bytes unless __attribute__((packed)).", sym->ident ? sym->ident->name: "<null>", pad);
+ }
+
return sym;
}






==============================================================================
TOPIC: Dwarf: unwind the recorded stack frame of different target address
sizes
http://groups.google.com/group/linux.kernel/t/0de6d3597b701465?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Jan 20 2014 1:30 pm
From: Jean Pihet


When in compat mode, correctly unwind the recorded stack frame. The
returned pointers are cast to the desired target address size.

Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
---
src/dwarf/Gparser.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)

diff --git a/src/dwarf/Gparser.c b/src/dwarf/Gparser.c
index b251e31..d676861 100644
--- a/src/dwarf/Gparser.c
+++ b/src/dwarf/Gparser.c
@@ -706,6 +706,29 @@ eval_location_expr (struct dwarf_cursor *c, unw_addr_space_t as,
return 0;
}

+/* Cast pointer content to the type of target address size */
+static inline int cast_value_to_addr_size(unw_word_t *val, int addr_size)
+{
+ switch (addr_size) {
+ /*
+ * Return the value of the type found at binary load time (e.g. from the
+ * ELF format)...
+ */
+ case TARGET_ADDR_SIZE_32:
+ *val = (uint32_t) *val;
+ break;
+ case TARGET_ADDR_SIZE_64:
+ *val = (uint64_t) *val;
+ break;
+ /* ... otherwise leave it as is */
+ case TARGET_ADDR_SIZE_DEFAULT:
+ default:
+ break;
+ }
+
+ return 0;
+}
+
static int
apply_reg_state (struct dwarf_cursor *c, struct dwarf_reg_state *rs)
{
@@ -743,6 +766,8 @@ apply_reg_state (struct dwarf_cursor *c, struct dwarf_reg_state *rs)
regnum = dwarf_to_unw_regnum (rs->reg[DWARF_CFA_REG_COLUMN].val);
if ((ret = unw_get_reg ((unw_cursor_t *) c, regnum, &cfa)) < 0)
return ret;
+ /* Cast value to the type as found in the ELF binary format */
+ cast_value_to_addr_size(&cfa, as->target_addr_size);
}
cfa += rs->reg[DWARF_CFA_OFF_COLUMN].val;
}
@@ -797,6 +822,8 @@ apply_reg_state (struct dwarf_cursor *c, struct dwarf_reg_state *rs)
ret = dwarf_get (c, c->loc[c->ret_addr_column], &ip);
if (ret < 0)
return ret;
+ /* Cast value to the type as found in the ELF binary format */
+ cast_value_to_addr_size(&ip, as->target_addr_size);
c->ip = ip;
}

--
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/




== 2 of 4 ==
Date: Mon, Jan 20 2014 1:30 pm
From: Jean Pihet


In the case of unwinding the debug info from a binary that has a different
address size than the current native platform, it is needed to record
it in the address space struct, in order to correctly parse the debug
info later. This mode is known as compat mode.

This is the case when e.g. profiling an ARMv7 binary that runs on an
ARMv8 (aka AARCH64) platform.

Depending on the target binary address size, loading and parsing of the
dwarf debug info and unwinding of the recorded stack frame must be
performed accordingly.

Tested dwarf local unwinding on ARMv8 (aka AARCH64) with ARMv7 and
ARMv8 binaries; and natively on X86_64.

Note:
- this series is an RFC, although tested OK on ARMv7, ARMv8 and x86_64,
- only local unwinding has been tested,
- retrieval of the next ip and frame pointer is performed using a
native read followed by a cast to the desired target address size.


Jean Pihet (3):
Add support for different binary target address sizes
Dwarf: load and parse the debug info of different target address
sizes
Dwarf: unwind the recorded stack frame of different target address
sizes

include/libunwind_i.h | 7 ++
include/tdep-aarch64/libunwind_i.h | 1 +
include/tdep-arm/libunwind_i.h | 1 +
include/tdep-hppa/libunwind_i.h | 1 +
include/tdep-ia64/libunwind_i.h | 1 +
include/tdep-mips/libunwind_i.h | 1 +
include/tdep-ppc32/libunwind_i.h | 1 +
include/tdep-ppc64/libunwind_i.h | 1 +
include/tdep-sh/libunwind_i.h | 1 +
include/tdep-x86/libunwind_i.h | 1 +
include/tdep-x86_64/libunwind_i.h | 1 +
src/dwarf/Gfde.c | 25 +++--
src/dwarf/Gfind_proc_info-lsb.c | 194 +++++++++++++++++++++++++++++--------
src/dwarf/Gparser.c | 27 ++++++
14 files changed, 214 insertions(+), 49 deletions(-)

--
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@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 of 4 ==
Date: Mon, Jan 20 2014 1:30 pm
From: Jean Pihet


When in compat mode, load and parse the dwarf debug info accordingly.

Tested dwarf local unwinding on ARMv8 (aka AARCH64) with ARMv7 and
ARMv8 binaries.

Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
---
src/dwarf/Gfde.c | 25 ++++--
src/dwarf/Gfind_proc_info-lsb.c | 194 +++++++++++++++++++++++++++++++---------
2 files changed, 170 insertions(+), 49 deletions(-)

diff --git a/src/dwarf/Gfde.c b/src/dwarf/Gfde.c
index 8659624..81959d1 100644
--- a/src/dwarf/Gfde.c
+++ b/src/dwarf/Gfde.c
@@ -59,14 +59,23 @@ parse_cie (unw_addr_space_t as, unw_accessors_t *a, unw_word_t addr,
/* Pick appropriate default for FDE-encoding. DWARF spec says
start-IP (initial_location) and the code-size (address_range) are
"address-unit sized constants". The `R' augmentation can be used
- to override this, but by default, we pick an address-sized unit
- for fde_encoding. */
- switch (dwarf_addr_size (as))
- {
- case 4: fde_encoding = DW_EH_PE_udata4; break;
- case 8: fde_encoding = DW_EH_PE_udata8; break;
- default: fde_encoding = DW_EH_PE_omit; break;
- }
+ to override this, but by default, we pick the target binary address
+ size unit for fde_encoding. */
+ switch (as->target_addr_size)
+ {
+ /* If defined at binary load time (e.g. from the ELF format) */
+ case TARGET_ADDR_SIZE_32: fde_encoding = DW_EH_PE_udata4; break;
+ case TARGET_ADDR_SIZE_64: fde_encoding = DW_EH_PE_udata8; break;
+ /* If not defined, use the current address size unit */
+ case TARGET_ADDR_SIZE_DEFAULT:
+ default:
+ switch (dwarf_addr_size (as))
+ {
+ case 4: fde_encoding = DW_EH_PE_udata4; break;
+ case 8: fde_encoding = DW_EH_PE_udata8; break;
+ default: fde_encoding = DW_EH_PE_omit; break;
+ }
+ }

dci->lsda_encoding = DW_EH_PE_omit;
dci->handler = 0;
diff --git a/src/dwarf/Gfind_proc_info-lsb.c b/src/dwarf/Gfind_proc_info-lsb.c
index f75bda2..8c35e58 100644
--- a/src/dwarf/Gfind_proc_info-lsb.c
+++ b/src/dwarf/Gfind_proc_info-lsb.c
@@ -81,36 +81,89 @@ linear_search (unw_addr_space_t as, unw_word_t ip,

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home


Real Estate